Big digital (transformation) projects, process automation efforts and RPA endeavors still fail. And fail often! And they don’t fail because of technology. They fail because of limited knowledge of the value-creating business processes.
The time is now; we need better ways to build better knowledge of our processes. We must understand how they impact customer journeys and how value is created. And Yes - BPMN is still an excellent notation to help us achieve this.
Unfortunately, in their wish for completeness OMG (the Object Management Group that manages the standard) has overlooked one crucial thing, and by doing so, they created a tiny monster.
Organizations are eager to adopt new things if it’s low effort. If it’s easy, it’s ok; if it requires a lot of effort - we are reluctant to adopt.
BPMN is no exception to this rule. The standard has almost 100 elements (more than 100 if we take the choreography and the conversation language into account), and some elements can be used for different purposes. But the truth is that you don’t really need many of the elements.
But which? What works, what doesn’t? What shouldn’t you use? And what does work? Which elements are essential? Do we really need those dreaded non-interrupting intermediate events or that crazy complex gateway?
The image below indicates the language’s complexity. The small numbers at the end of the leaf nodes refer to the number of different concepts and visual elements in each of the components. For instance, there are 10 different start events and 19 activity combinations. Yes – I agree it’s crazy.
We are overwhelmed by the sheer amount of BPMN elements, and I truly believe it’s one of the reasons people are still struggling to understand the real power of process modeling.
Unfortunately, we are losing precious time.
Many teams create their own BPMN subsets to deal with the complexity, but often, these subsets hamper the modelers in expressing the processes correctly. And the subsets become a limitation sooner rather than later.
To remedy this, teams invent new interpretations for the elements to accommodate their problems. This defies one of the most important goals of BPMN - a language that can be universally interpreted. Every BPMN element was given a particular meaning for this very reason!
I know it’s not the first BPMN poster that has been created – some previous attempts are shown in the following image – but they have never been of great help to my team and me.
These posters try to be comprehensive but forget to tell you what the elements mean and how they can represent aspects of real-life processes.
Our BPMN poster is incomplete. On purpose! We didn’t want another overview of all BPMN elements – we want to show the 50 elements you really need. (To be honest – there are only 48 elements on the poster, but that was less of a marketing slogan.)
This selection of elements is based on more than 15 years of BPMN practice and trainings. I’m pretty sure about 99% of all processes can be modeled using these elements.
What’s more - instead of just showing each element (like the other posters do) – we give practical guidelines about when and how to use each element.
For instance, we could state that the multi-instance marker can be used to repeat an activity (that's what the other posters tell you). But we didn’t. Okay, Okay - we did, but we did something else as well.
Besides the name of the element, we also provide pointers and guidance on how the elements must be used. This is how we described the multi-instance construct.
We are convinced this is a BPMN poster you can actually use. All feedback is more than welcome at firstname.lastname@example.org. Do let us know what you think!