Anthony,
In general terms, what you've listed are ways to
"document" various aspects of a business process, rather than "how to" analyze a
given business process. In order to effectively use UML, for example, one must
first understand the process to be documented. When I work with my clients to
help them formally analyze a given business process, I try to keep it very
simple and use every-day terms rather than technical jargon relating any one
notational system. For example, with one client we needed to analyze the new
product development process. This is how I worked with the "subject matter
experts", the folks actually performing the various activities/tasks. Once we
had gathered the information (acquired the knowledge) then we took that
knowledge off-site and used IDEF to document the process. This was then
validated with the same subject matter experts and appropriately modifed to
reflect accurately what was taking place. We found this approach to be extremely
effective, the client staff was very comfortable and did not at all feel
intimidated by a new jargon. And, as a matter of fact, was able to go on to use
this framework to analyze other processes. The goal is not so much to use a
specific metholodogy or notation, but rather to acquire the necessary knowledge
so that effective decisions can be made regarding any needed changes to existing
processes.
Effectively facilitating and capturing the knowledge
expressed during such process analysis sessions is key and
critial.
Hope this helps.
Rachel
RFA Business Process Analysis
Framework:
- What we’re going to do
- Why we’re doing
it
- What the results will
be
- What we’ll do with the
results
- The groundrules for our
activities
What we’re going to be
doing:
List the various scenarios of managing product and product
data
new product introduction
change a product package (labeling, configuration, pack factors,
etc)
change a product price
discontinue a product
other
Choose
a scenario to begin analyzing first
Identify
all of the activities that need to be done in that
scenario
(the
To-Do Checklist we all have)
Determine what activities need to be done first, second, third,
etc.
Who does them?
What kicks each activity off?
What is the goal for each activity – the expected
outcome?
What information and data is required for each
activity?
Where does that information and data come from?
What are the controls or rules in play
What activities must be done and what activities are
optional
What makes an activity required versus optional
Repeat
for each scenario
Why we’re doing
this
We need to know what’s being done today
Will use as a roadmap to plan the future
What the results will be
A propess model (map), narratives, information requirements, sequencing
and timing of activities, the controls governing each activity and the end
result
What we’ll do with the
results
Will be modified into a “future state” process model showing any needed
modifications
We’ll end up with two sets of models: “current state” and “future
state”
Will be useful beyond this project for subsequent customer’s
new/changing processes and requirements
What’s my role?
Facilitate your analysis
Capture (record) what’s discussed
Review/verify with you that I captured the information (your knowledge)
accurately
Working with my colleagues convert the information (knowledge) acquired
today and Monday into Process Models
Review Process Models with the team, modify as
needed
Work with the Project Team to design “future state”
model
What are the groundrules for our
efforts?
-----Original Message-----
From: Anthony Beecher [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 4:53 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Formal methodologies for business process analysis?
I would like to know if anyone can give me any suggestions on the latest formal methodologies for business process analysis. I am interested in techniques for:
- Project life cycle (RAD?)
- Discovery of relevant facts (JAD?)
- Documentation of business processes (UML?)
- Use case methodologies
- Data analysis (IDEF?)
- Anything else relevant...The basic intention is to improve the quality of my work at design time and improve the success of integration projects. The more I am able to think of and account for ahead of time, the less pains I suffer after implementation.
Any tips, thoughts or pointers to resources will be appreciated!
Thanks,
Anthony Beecher
------ XML/edi Group Discussion List ------
Homepage =http://www.XMLedi-Group.org
Unsubscribe =send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
------ XML/edi Group Discussion List ------
Homepage http://www.XMLedi-Group.org
Unsubscribe send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
