Friday, May 9, 2008

Has BPMN delivered the expected benefits?

There has been much discussion recently about the BPMN standard, as the new version of the standard (2.0) is being agreed.

First to recap; the goals of the notation have been defined as:

“.. to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.”


(Source: BPMN specification document)

The key point in the above statement, in my opinion, is the fact that the notation aims to address both the technical perspective and the needs of business people. As a result it had to be simple to learn yet powerful enough to depict the potential complexities of a business process; therefore it may not be a surprise that a recent research conduct by Michael zur Muehlen: How much BPMN do you need? found that “the average BPMN model uses less than 20% of the available vocabulary”; suggesting that the notation is used in a simplistic way.

He also indicates in his findings that there are two types of BPMN modellers, which can be summed-up (more or less) as business v. IT focused:

1) the business focused modellers who use BPMN for process re-engineering and process improvement type work, and
2) the IT solution focused modellers who use it for workflow engineering or process automation.

However, in my experience, the first type of users, people carrying out process documentation that is not IT driven, have not yet fully embraced BPMN (many are not even aware of it). Organisations are still using a wide range of inconsistent notations; and making use of numerous symbols and objects in their processes models. It’s not rare to see that within the same organisations or sometimes within the same projects, process maps utilise different symbols, objects and terminology; making it difficult to compare different models or to deliver a consistent message across the organisation (especially in large change programmes).
In 2-3 years BPMN has become the de-facto standard when it comes to workflow automation design, but hasn’t seem to be fully adopted for every process modelling activity.

Sebastian Stein has been asking Where is BPMN heading to?

My view is that the next challenge for BPMN is to ensure that it truly develops into a common business language understood by all; and becomes more accepted beyond the domain of workflow automation and system analysis to be used across all facets of business.

This may require enhancing the notation by adding additional views to help express the full complexity of business processes or business architecture as a whole, for example, a view that covers the organisational perspective showing roles and responsibilities in a hierarchical structure?!. This, since business processes can not be fully expressed using only one type of diagram (The fact that the UML notion includes 13 different diagrams, representing different points of views, illustrates this point). However, this may be difficult to achieve without increasing its complexity.

It will be interesting to see how BPMN evolves over the next few years.