There are three major challenges in using BPMN 2.0 as a holistic (360°) approach to Business Process Management (BPM):
- Semantic Alignment
BPMN like all other high-level process languages is context agnostic. This is good, as it allows a wide adoption throughout the industry. On the other hand it means that it does not explicitly express concepts found in business contexts, such as customer, accounts, discounts etc. As people from business and IT often have a very different view on certain business aspects, it is essential that they share the same semantic context in order to understand each other. If not, a process designed by a business person will not be understandable by an IT person and vice versa. In case BPMN is applied in combination with an outsourcing approach things get even worse. - Level of Details
BPMN2.0 is designed for automatic execution on a process engine. The goal is to have one process model from analysis to execution. But people from business and IT require different very levels of detail in their process descriptions. This is why a processes created by business people are usually not detailed enough for IT people. IT processes are usually full of technical information required for automation, rendering the process almost useless for business people. - Portability
The BPMN standard introduces several conformance levels (modeling, execution, BPEL, choreography). This is good as it fosters reusability of BPMN diagrams amongst different tools. At the same time the standard explicitly allows model extensions, “to satisfy a specific need, such as the unique requirements of a vertical domain” (quote from the spec). Thus, to avoid vendor lock-in, one at least has to be very careful in choosing the right model elements.
BPMN 2.0 should not be applied naively. Unfortunately this is often happens, especially when the standards are young. To be successful with BPMN 2.0 one has to find the right mixture of standards, design principles and methods.
For instance the semantic aligment problem can be mitigated by applying Scrum for analysis and process development. A multi-layer process design can help to address the level of detail problem. And choosing the the right product can increase portability.
This is nothing that comes for free by just using BPMN 2.0. It is rather something that needs to be actively managed by experienced engineers.
Hi Wolfgang, we have exactly the same problem in our organization implementing TIBCO. However, I’m of the opinion that the business model (end to end) should be the same model for business and for IT. It is when decomposing sub processes & transactions that IT has more technical detail. Also we make use of the IBM SOMA principles and have tagged BPMN symbols accordingly i.e.
– sub process = SOMA long running process
– transaction = SOMA short running process
– user task = SOMA human task etc.
This allows one to have a “technical definition” at the lowest level and still have end to end business views. Hope this makes sense?
Hi Etienne, thank you for your comment.
I agree with you, business and IT should work with the same model.
Having one model for business and IT clearly eases the communication. And it helps to keep the model consistent.
But as those people usually have a different background and knowledge, they might need different views to the model.
A a multi layer process design can help. Ideally all diagrams are stored in the same model and are linked to ensure model consistency.
I think in addition to that, it is essential that the people working with a model need to share the same semantic context in order to really understand the meaning of the model.