The popularity of BPMN keeps rising from year-to-year. The “State of Business Process Management 2014" report from BPT emphasizes the growing importance of BPMN in which they referred to it as “dominating the process standards space”.
To get an understanding of what Business Process Model and Notation (BPMN) is, it is certainly helpful to look at it from the angle of what it is not. According to Jakob Freund and Bernd Rücker, Authors of Real Life BPMN, BPMN was designed to represent processes and not:
- Organizational structures
- Business rules or
- Process/IT landscapes.
BPMN is instead, a standard for defining how processes should be executed. I like to think of it as flowcharting on wheels. It contains graphical notations that facilitate modelling to a level of detail that is not readily available with other notations.
The Pros And Cons
The standardization of how business processes are represented implies that if you change your modelling tool, you get the advantage of sticking to the same set of symbols and diagrams.
The fact that it is a standard notation also increases the probability that stakeholders will understand the diagrams you produce, though some would argue that BPMN is complex. To address this potential issue of complexity, I always have a legend at the bottom of my models to explain the symbols used.
One of the most common complaints around the use of BPMN for modelling processes is the initial difficulty stakeholders face in understanding the multitude of notations when compared with the existing (though not “given” in all cases) familiarity they have with notations like flowcharts. One can however argue that flowchart symbols, generally perceived to be more straightforward, still have to be learnt when faced with it initially or infrequently.
With BPMN, I limit myself to a collection of symbols to avoid complexity and the steep learning curve that users might face in understanding my diagrams. It is not possible or even necessary to use all the existing symbols so it is best to identify the barest minimum for stakeholder communication, process definition and accurate representation to happen. According to a report by Michael zur Muehlen, “How much BPMN do you need?”, the average BPMN model uses less than 20% of the available vocabulary.
Though BPMN may seem overwhelming at the beginning, it certainly has its benefits.
So, what can a BA expect from using BPMN?
In our team, we use BPMN to:
- Standardise how processes are represented. Even though these diagrams are not currently created with the intention of executing them directly in a BPMN Engine (An executable process model can be implemented directly by a process engine), the day the company decides to make a move in that direction, we won’t have to start from scratch. Our process diagrams are however, tightly integrated with requirements specification and form the basis for the technical design of business applications. Workflow notations are necessary to indicate the sequence of process steps (BPMN is only one example).
- Convey meaning. The latest version, BPMN 2.0.2, provides 100+ different symbols. I have never had difficulty finding the appropriate modelling notation to use for conveying the right meaning of process flows.
- Model to an increased and more accurate level of precision, e.g. displaying different types of events.
What has been your experience with BPMN?