Hi Craig,

Great post on Process Analysis 101.  I will have to agree with you that there is lots of ambiguity when it comes to process modeling.  However, with the advent of the "new" Business Process Management systems there has been more focus on modeling business processes.

By far, the best modeling notation that I have seen is the Business Process Modeling Notation (BPMN).

I love BPMN for many reasons, here are some:

• It includes all the standard features of workflow/activity modeling such as tasks, sub-tasks, splits, joins, swim lanes, etc.
• It has a very rich set of adornments for tasks/activities which visually show a variety of task attributes such as: repeated task, sub task, etc.
• It has a very rich set of events which can trigger a process, be in the midst of the process, or trigger as a result of ending a process.  Examples: error events, message events, timer events, etc.
• There are many more reasons but here is one more: the concept of a Pool.  BPMN supports the idea of multiple processes/organizations running independently but with interdependencies.  Each organization is modeled as a pool with its own lanes.  BPMN has the concept of messages which are used to communicate between processes in different pools.

All I can say is check it out!  I am currently working on a large muli-million dollar project and BPMN has proven very versatile and useful for creating business process flows and modeling processes in general. In many cases, I have been using BPMN instead of the UML Activity Diagram.

Oh ya, one more thing!  The value of BPMN is clearly understood by the industry as it has been recently adopted as a standard by the OMG (Object Management Group) which is also the standards body for UML.

If this stirred your interest, check out the BPMN specification and other resources at bpmn.org.

Best regards,

- Adrian

Craig,

You are absolutely correct... the principles and patterns of process modeling apply regardless of the actual process modeling notation.  I just really like BPMN because it allows the practitioner to create models which are much less ambiguous.  Also - there is a written specification on what the symbols mean and how to use them as opposed to the more traditional workflow diagrams for which there isn't a standard specification - not that I'm aware of.

- Adrian