Course - Getting a Grip on the BPMN Specification

9th of October 2020

  

The accompanying slide deck can be found here.
The BPMN 2.0 poster can be found here.

Business processes are an ephemeral thing to wrap one’s head around. As far back as the 18th century we see intelligent and capable people such as Adam Smith trying to pinpoint what it is all about. Just looking at the Wikipedia page of the business process, we read: “A business process, business method or business function is a collection of related, structured activities or tasks by people or equipment in which a specific sequence produces a service or product (serves a particular business goal) for a particular customer or customers.” Only to be followed by a number of sentences that try to readjust this definition. Such a flow of opinions can be found in the professional literature on the subject as well. This is a clear indication that it is hard to formalize what a business process is all about.

However, it is not because we cannot finetune the concept of what a business process is all about, that we cannot find a way to describe (and automate) individual processes. An alphabet can be used to describe an individual sentence without having to define and limit a language. And in the past, there have been many syntaxes developed to do just that. When we look at the timeline below, we have landed on the Business Process Modeling Notation (BPMN) syntax in its second iteration and this syntax has had permanence for the last 10 years.

History of Process Modelling Notations

To get acquainted with the Business Process Modeling Notation (BPMN) for describing processes, a great resource is Bruce Silver’s book “BPMN Method & Style 2nd Edition”, which is a comprehensive journey through process design. This is an explanation of the OMG standard “BPMN v2.0” by using examples to illustrate its use and implications. “Fundamentals of Business Process Management” also has an interesting chapter on BPMN.

Books about BPMN

According to Bruce Silver, author of “BPMN Method & Style”, BPM in the real world can be classified into 3 levels, based on how the model is used:

  1. Descriptive modeling, the kind most BPM consultants typically talk about -- high-level, occasionally ignoring BPMN's diagram validation rules, but easy to communicate across the organization, linked with a methodology for how to do it. Level 1 modeling requires understanding of fundamental concepts such as pools and lanes, tasks and sub-processes, and sequence flow, but not the complexities of BPMN's various flow control and event patterns. Its goal is to simply document the process flows in an enterprise.
  2. Analytical modeling, more detailed, showing all the steps, including the exception paths, required either to analyze process performance using simulation or to create detailed requirements for an IT implementation. Although Level 2 modeling requires disciplined thinking and attention to detail as well as an understanding of BPMN's various decision and merge patterns, events, and exception handling patterns, it reflects a business-oriented perspective and must thus be understandable by business users, and not just IT. Level 2 diagrams must be both valid according to the rules in the BPMN spec and organized effectively as hierarchical representations of the end to end business process.
  3. Executable modeling, where BPMN is part of the executable process implementation. While this capability of BPMN is a major reason for its widespread adoption, modeling at this level is somewhat vendor tool-dependent, as most BPM Suites do not support all of the gateway and event types defined in the BPMN spec, and may offer their own proprietary extensions as well. Moreover, most tools ignore the BPMN spec's implementation attributes, and instead pro-vide equivalent implementation detail in tool-specific attributes of the model's activities, gate-ways, and events. Its purpose is to enrich the Level 2 model with technical specifications. Level 3 diagrams thus typically impose additional validation constraints beyond those of the BPMN spec.

The main takeaway from a course on using BPMN to model a process should have the fundamental principle that BPMN is an executable language, so that when you use the elements provided by the syntax you use them in their correct way. Otherwise you are needlessly creating confusion between the different stakeholders that work with the mapped-out business process. A second principle is that BPMN is a token-based language. When executing the diagram, a token is passed along the different elements based on clear and unambiguous rules. If you understand this fully, and keep it in mind when writing BPMN, you will avoid 90% of all mistakes.

Token-Based Illustration of BPMN

The course for BPMN modeling introduces the participant to the different elements in the syntax and what they are used for. It also goes into how and when to use these elements. Similar to any language: Even when you know all the words of a language, it is not a given that you know how to form a proper sentence. Bruce Silver calls this the style of BPMN.

At this time, I have given this course at the following companies:
RealDolmen      EDF Luminus      Cronos      DKV      AXA Bank      Ordina     

Course BPM Business Architecture