Which BPM Modeling Notation Should We Use?

Comments: 4
Rate this:
Total votes: 5

Should we use flow charts, swim lanes, value stream mapping, proprietary software notation, or BPMN?  Yes, there a number of notations you could use, and you want to pick the right one for your organization.

The first question to ask is what is the purpose of the process diagramming notation?  Since there are several purposes for process diagramming at different stages of a BPM/ process improvement project, you may switch to one type of notation or another at different times.

Purpose 1:  A high level map to scope the project and as part of the charter.  Here I suggest using a simple flow chart with 6-10 steps using rectangle for activities/steps, diamond shaped decision diamonds and directional arrows.  You could actually create it in PowerPoint, but I usually do it in Visio.  The purpose of this map is to get people understanding what a process looks like. 

A high level process map is:

  • Not a bulleted list of the activities.  You want to begin to switch to a process focus, so model the high level map by drawing a process.  It gets everyone seeing it on the wall or screen, and shifts the conversation away from just one person talking. 
  • Not Chevrons.  Chevrons are a popular way of showing concepts or stages at a high level.  They serve that purpose well.  I would not use them here, because you want the organization to begin to see what a process map is--the flow, a few standard symbols, and the directional arrows.  The chevrons are a good way to represent a roadmap of what will be happening in the overall BPM effort; I used them to depict that.
  • Not your creative symbols.  If you use symbols that you like (some boxes, some parallelograms, arrows that go all over the place, some other stencil figures) you will have to explain the whole map, and you will be the only person who knows what the symbols mean.  The high level map is a good time to introduce the basic notational symbols.  If you want to do something creative, do a storyboard, but do not call it a high level map.  The storyboard might better represent a story about today’s process and some of the challenges.  I really do not recommend it here; in fact you would still need the high level map for the charter.
  • Not a BPMN top level map because creating an accurate BPMN map could mean having a black box customer pool, message lanes, and multiple end state—which seems more complicated than needed at this stage. I suggest keeping the BPMN diagram until a bit later in the methodology, but if you prefer to use just the straightforward level one BPMN symbols it could work.(See “A variation” below.)  
  • Sometimes a value stream map.  This map has many lean notational symbols and may be unfamiliar and overwhelming to the business side.  If your organization has adopted Lean as a whole and many employees and managers have had training on the Lean tools then you would want to use a high level value stream map.  I love the data on the value stream map, but use it at a later stage in the BPM methodology.
  • A variation.  I have had colleagues tell me they start using Business Process Modeling Notation (BPMN) as the process modeling standard right from the get-go.   They use Level 1 or the basic BPMN symbols and keep the model simple with the same 6-10 tasks --often one internal pool, no swim lanes, one start event and one end event, activities, gateways, and sequence flows. Often they are using a proprietary BPMN modeling tool that they are selling as well.  I prefer to start with BPMN in the next phase, as described in Purpose 2.

Purpose 2: Transition to BPMN at the Top Level

After the high level map is completed (which is part of the charter—another critical element to get a BPM project off to the right start), I suggest taking the high level map and use BPMN to develop a top level model.  There are many similarities to the high level map you have already done, but three critical differences:

  1. Now the model uses BPMN, the standard notation that allows the process model to be shared across tools, departments and between business and IT.
  2. The top level BPMN model is the hierarchical parent for the process and will become more detailed with child sub-processes and even more detailed “grandchildren” sub-processes under the first level of sub-process.
  3. The top level BPMN model will elucidate the critical exception end states, so whereas the high level will only have the happy path end state, the top level BPMN will show critical end states, differentiating how the process ends under specific conditions. 

Purpose 3:  Detailed As Is Process Diagrams.  Here you want to model process diagrams that show actors and the tasks they perform or are automated in their area of responsibility.

Now I suggest using a combination of methods:

  • Draft of an instance with swim lane process displayed using ‘stickies’ on a large piece of butcher (9 feet by 4 feet) 
  • BPMN captured by a notation expert at the same time on a laptop.

I like the butcher paper because it engages the full BPM team the best.  The facilitator runs the session and captures one instance of process. Capturing one instance of a real completed process makes it easy to document the model in 90 minutes or less, and it won’t have the spaghetti diagram like a process model showing all the exceptions.  It will show what happened in that one instance. 

More instances?  Yes, you may need to model some other instances beyond the original one.  You need to capture instances that include each of the exception end states.  You also may want to capture additional instances for different levels of complexity, different customer groups, or variations in process at different locations.  Carefully decide which additional instances are useful.  Don’t make this an exercise in creating multiple models.  Often after doing a few models the team begins to see what sections of the process are consistent and sections where they are not.  I then create a consolidated model and use that for analysis.  The consolidated model can be the first step in standardizing the process.

Creating the As Is Instance using stickies on the butcher paper is a light touch way of documenting a current state model.  The team has fun, gets the model done, and identifies issues, data, and improvement ideas quickly.  I set it up with the black box customer lane at the top, and the internal pool underneath.  It is very easy to make changes – just throw out and rewrite the stickies.

I find the best approach is to have a BPMN recorder simultaneously capture the process model on his/her laptop.  That way the BPMN model is done real time and there is no time delay.  This method avoids a few of the problems with going straight to the laptop, such as

  1. The person recording on the laptop cannot facilitate at the same time
  2. Team members get focused on the BPMN symbols and the laptop rather than articulating the process
  3. The lap top model can be projected on a screen but often the symbols get small and it is hard to show all the steps on one screen.

Now there are a few things to finish up these BPMN models. 

  • Make sure the swim lane has message flows that match the top level BPMN model. (You will have to go back and review these and adjust after completing the instance.)
  • Make sure the end states are properly represented.
  • Go back and fill in the other sides of each gateway. They will not represent the one instance but are needed to complete an accurate BPMN diagram.
  • Consolidate multiple instances into one BPMN as is process model to represent the totality.

Modeling in BPMN provides a standard that can be communicated and shared.  It uses an explicit language and method.  I can’t tell you how often clients tell me. “ We have already modeled our current state processes.”  I always say, “Great.  We will build off that work.”  Later when I look at these models, I often don’t understand them.  The person who documented them used flow chart symbols and other symbols in a ‘creative’ way and only s/he can read the model. 

So create As Is models flowing the process on the wall and capture it in BPMN simultaneously.  Then go back and review the BPMN process diagram with the team.  The team will soon be able to read the BPMN diagram easily but they may not have been able to build it initially.  And the BPMN process model conveys the logic of the process unambiguously from the diagram.  That means its executable as well.

As Is process models represent how the process is currently performed.  They are the baseline model, just like baseline metrics.  You need to know where the process is today, but don’t worry about getting the diagram perfect.  The current state diagram is used for analysis.  You will learn what is working, identify the current problems, see who does what, find out how many hand offs there are, and identify the many layers of approval.  The current state map is the first technique for analysis.

Two sources to learn more about BPMN:

  • Contact Shelley Sweet, the author, by email (shelleysweet @i4process.com) or call 650-493-1300 for free phone advising.
  • Take the BPMInstitute.org Training Process Modeling in BPMN.


Shelley Sweet
posted 11 years 3 weeks ago

Steve, I have always felt

I have always felt that industry process reference models are a good idea, and have looked at them, but never used them in my method. How do you use them? Shelley
Shelley Sweet
posted 11 years 3 weeks ago

Hi Frederic I appreciate your

Hi Frederic
I appreciate your thoughtful comment. I have talked about when to use BPMN with Bruce on several cases, and know his book. I agree with your steps 1, 2, and 3 above and use them. I often use Visio with #4. But I feel it is useful to get the business user to see and understand BPMN, and Bruce feels this is best using OMG level one symbols and structure. So I would say that your #5 is where I would involve more technical people. It is fine with me to wait until the design phase to use BPMN. Bruce has been encouraging me to use it earlier. I am not always sure we get it exactly right, but we do a much better job of thinking. For me the analysis phase is best looking at a graphical model and then doing the data analysis, root cause, standardization etc off of that vs. narrative use cases. Thank you for your comment. Shelley
posted 11 years 8 weeks ago

From my own experience, I

From my own experience, I really do NOT subscribe to this method.

Recently, I've been involved as a BPM expert in two already started projects which were in a bad situation. One of the main issue was precisely that analysts tried to use BPMN and Visio before having a vision on their user and business requirements. They drew BPMN and Visio diagram, but having not a precise idea of the sense of the drawn items and how to use it in the next phases of the project. Diagrams mixed diffent concepts (objectives, user requirements, business requirements, design requirements). They were also many and many inconsistencies between the diagrams. They were also sometimes too much detailed, and sometimes not detailed enough.

'Some colleagues use the BPMN notation level 1' Why not if it's for giving an idea of the processus. But it's a short term diagram and must not be maintained. However, using a wording description is certainly much more efficient.

'I prefer to start with BPMN in the next phase, as described in Purpose 2.' (Shelley)

By the way, from my own experience, and with all your respect, this is one of the biggest possible mistakes on a BPM project.

It's always pleasant to start describing a project using BPMN (and I'm a BPMN expert !). However, it's becoming hard to update the process using BPMN for being consistent with the moving business requirements. Quickly, the analysis phase is being sclerosed. Why ? Because updating a BPMN model requires much more time than updating a wording scenario. Business people can be involved more easily in writing a narrative scenario than a BPMN business process.

From my 10 years of BPM experience, it's almost impossible to use BPMN during the analysis phase.

Why ? Writing a business process requires to move/add tasks, add alternatives and extensions, to delete it, to add again etc ...

Trying to be agile in the analysis phase keeping the consistency with the BPMN is almost not possible in an actual project, mostly because of time constraints.

Try it using BPMN and try it using words ! Quickly, you'll understand the difficulty of maintening the BPMN model and the business process solution.

Shelley, I know you known Bruce Silver. Bruce is by far, my favorite BPMN writer. His book (which I very strongly recommand it : BPMN Method & Style) shows perfectly what naive modeling is. Using BPMN for the analysis phase (level 2) often involves the design of a naive model which can not be executable, or at least not optimized.

What is my method for leading a BPM project ?

The first step is to instantiate the business architecture (example : the OMG Motivation Model or the Togaf Business Architecture).
From the goals and objectives, how to identify process and business rules ? But this thread is not relative to this topic.

The second step is to draw use cases, actors and their relationships using a UML modeler or Visio or even Powerpoint. This part provides a high level vision of the business processes and often allows the identification of other processes.

For each UML use case relative to a business process, I write a narrative use case (using the method of Allistair Cockburn : Writting effective use cases). This is very efficient, really much more than modeling an analysis BPMN model.

Updating the BPMN process from a well written narrative use case is becoming not only easier but also more natural. However, writting good narrative use cases is probably one of the most difficult part of a project.

It's also easier to think about alternatives and extensions using a narrative use case. For helping me, I wrote an efficient Microsoft Word macro. I'm also developping a powerful Eclipse plugin for replacing this macro (not yet available).

There is another great advantage using a narrative use case. A use case is a business requirement ... that I can use as the core input of the functional testing phase. The narrative use case can be easily inserted in the requirements table of a testing tool, example : Mercury testing tools ... the BPMN model can not !

How to operate a narrative use case ?

For improving the organisation model and business rules, identifying business rules, business entities and services candidats. It's also of course the main input for the BPMN modeling.

The relation between the narrative use case and BPMN ?

I use heuritics for writing the each step of the narrative use case :

1) Each step is testable.

2) I'm able to model the step in BPMN ... if not, the step is probably not well written, and I have to re-write it !

3) Each nominal step can have alternative and extension scenarii. Once the narrative use case is approved (after having been modified, approved, disapproved, again modified, again approved etc ...), then the business requirements are now much more stable. Then, it's relativly easy to translate it into a BPMN executable model. As I said, I strongly recommand to follow the Bruce Silver advices for avoiding many traps and for optimizing the model.

'Modeling in BPMN provides a standard that can be communicated and shared.'

This was the primary goal of BPMN ...From my own experience, business people often don't want to read BPMN. For the rare people ready for that, how do you maintain the consistency between the model level 1 or 2 and the model level 3 ? In an actual project, it's almost impossible. Anyway, using the BPMN level 1 or 2 involves so many lackings that I prefer not to use it.

Using BPM at level 1 or 2 and level 3 ? (level 1 = descriptive model, level 2 = analytical model, level 3 = executable model).

BPMN is efficient for creating executable models and than, in the project lifecycle, it MUST be used at least at level 3. And, because I don't want to maintain consistency between Level 1 or 2 and Level 3, then I use only the level 3.

'Why don't I use first the model level 1, then level 2, then level 3 '

I know that I have to use the level 3. Because, I work with a method using iterative and incremental phases, I can not work on a executable model and then, cycling back on the analysis phase and submitting the model to the business people. An executable model contains events, transactions, signals, compensentions, gateways and so on that business people don't have to know. The execution of a BPMN model uses the Pi-Calculus theory. Even for BPM designers it's difficult to understand (Cf. workflowpatterns.org), than let's imagine for business people !

'Consistency between a use case and a BPMN diagram'
Of course, this consistency must be managed, but it has a lower cost than maintening consistency between the levels 1 or 2 and 3.

Summary, for a BPM project :
BPMN has to be used for the design phase, not for the analysis phase.
Steps :
1) Identify goals and objectives (then relative indicators).

2) Identify business process and business rules.

3) Draw use case diagrams showing business processes, actors and relationships.

4) Write narrative use cases.

5) Operate each narrative use case : extend business rules, identify business entities, organization model and service candidates (for SOA).

6) Create your SOA contracts (WSDL) and Schemas (XSD) which will be used in BPMN).

7) Then model the processes using BPMN. There is only ONE level of BPMN modeling : the executable level.

8) Cycle back on the previous phases.
Best regards

Frederic Fontanet (Business senior architect, OMG UML & BPM certified, also SOA and J2EE Web Services certified)

Steven Madden
posted 11 years 8 weeks ago

Good advice on the use on

Good advice on the use on notation. From a practice aspect I have utilized an excepted industry business process reference model with a hierarchy of decomposing processes levels and use BPMN to model the high-level. Each lower level of process decomposition provides more details. Using an industry expected reference model has been a real time saver and provides an enormous amount of consistency between process modelers. I have found combining a industry accepted reference model with BPMN, makes for a visual representation that both the operating origination can find useful, and be shared with other industry solution providers with little or no interruption. If you are in the industry, then the taxonomy should be understood.

Join the Discussion

Shopping cart

There are no products in your shopping cart.

0 Items

Business Process Management Jobs

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.