Easing the ‘complexity’ of BPMN

As a consultant with a business and systems modeling tool vendor, the conversations I have involving business analysts invariably seem to turn to the perceived complexity of the business process modeling notation (BPMN).

It’s a topic which has had much coverage in the last year, following the publication of a research paper on BPMN usage by Michael zur Muehlen and Jan Recker. The paper analysed over 120 examples of BPMN diagrams from a number of sources, to identify the most commonly used BPMN elements, and its findings certainly back-up the experiences of our consultants with a range of users of Select Architect. Further blogged debate by Bruce Silver and Sandy Kemsley, appears to have reached a broad consensus.

Because Select Architect supports an older, simpler notation for workflow modelling, the Process Thread Diagram, in addition to BPMN, we’re often asked which should be used. In general we find that the two notations are used by different groups of user, broadly similar to the groups identified in the paper by zur Muehlen and Recker.

Those who are interested in modeling business processes in order to understand organizational boundaries and responsibilities, or as part of a process improvement exercise, seem to prefer a simpler notation, which they often perceive cannot be achieved with BPMN. They see the multitude of options available on BPMN events (a start event has six trigger types – including undefined, intermediate has nine, end has eight result types) and on tasks themselves (nine task types in Select Architect) and decide, instead, to use the process thread notation which is not universally standardised.

BPMN event trigger and result types

The other group of business process modelers are the analysts who want to precisely model the conditions of the workflow, for whom the range of gateway and event types is essential.

You could say that Select has been implicit in propagating this split in BPM notations; the pragmatic reality is, however, that while we have customers who want to use the process thread diagram rather than BPMN diagram, it would be unwise to force adoption of BPMN.

Rather, I would like to see all of us involved with business process modeling promoting BPMN as a technique which may be adopted by both groups, using the level of detail required for their purposes.

Let modeling with BPMN be seen as an iterative process. Why shouldn’t the process analysts use a validated subset of BPMN to construct ’simpler’ diagrams where the events can be simply start, intermediate and end events. They have no need to worry about the detailed trigger types, and should not feel pressured to do so. Similarly for simple decision points, they need not even use gateways, let alone worry about the gateway type or detail, instead using conditional flows. If the project requires more detailed modeling, those details can be applied as the processes are further analysed and decomposed.

Perhaps we, and other BPMN vendors, should consider BPMN profiles, based on the role of the user, which provide cut-down toolbars of elements and property details?