Intelligent Enterprise

That might be one way to restate the premise of a survey on the Business Process Management Notation standard that has stirred up quite a controversy. The survey is interesting (because it raises some some good questions about BPMN and business process modeling) and entertaining (because it challenges dogmatic thinking on the topic).

In nutshell, the researchers reviewed 126 BPMN diagrams collected from "consultants, seminar participants, and online sources" (in other words, more or less unscientifically, which of course does not automatically invalidate the research), and found that of the 52 distinct elements (symbols) that exist in BPMN 1.1 specifications:

- Only nine elements were used on the average in each diagram (i.e. less than 20%)
- Only five elements were used in more than half the models, and another six symbols in a fourth of the models
- 17 elements (more than 30%) were used in three or fewer models, including five elements not used at all!

The five elements commonly used were the normal flow, task, end event, start event, and pool — in other words, symbols that any Visio diagrammer would be comfortable using.

The researchers conclude that (restated in my own words, loosely and lightly):

- Novice process modelers should learn the most common elements, and not waste time on the rest.
- Vendors of modeling tools should implement — ditto
- Standard-makers (e.g. OMG) should focus on — ditto

The findings of the survey are surprisingly unsurprising: They rediscover the good old "80-20 rule" — a majority of practitioners use only a small fraction of the features. Why would BPMN be the exception? As for the conclusions, the first two are already widely prevalent, in general — starting with a small/core subset of the tool works best for a novice, and vendors typically start with limited product functionality which grows as they gain market foothold.

For process modeling, there's another benefit in keeping things simple: we cannot expect our users to all be experts in BPMN, or any other notation. Keeping the model relatively simple allows the discussion to focus on the business process rather than the presentation, and enables user groups to discuss the model internally without a "modeling expert" present.

The final conclusion above seems dubious — a standards body must, by definition, look at the big picture.

Interested? Read the research paper by authors Michael zur Muehlen and Jan Recker, or their blog titled How much BPMN do you need?, both of which came out in March. For a weighty response to the survey and findings, which led me to the original research in the first place, read this post by fellow Intelligent Enterprise blogger Bruce Silver.