When it comes to describing business processes BPMN 2.0 is my notation of choice.
This post is about what I mean when I say “process model” and “process map”, so let’s not get hung up on the terms themselves. If you are an advocate of and expert in BPMN and you choose to call your models “maps”, I’ll die a little inside, but I won’t argue with you over your choice of term. Here I want to talk about rich language versus simplistic.
I’ve had many business analysts argue against using BPMN for describing business processes. I have always found it interesting that the ones who are argue against it, don’t know how to use it. One senior BA I interviewed for a client expressed great confidence in his ability to model processes using BPMN (which was a mandatory skill for the role) until he made a complete mess of an exercise I gave him. Suddenly he started arguing why the client should not use BPMN.
Most BAs I have met produce process maps rather than process models, so what’s the difference? In my experience, a process map is a simplistic flowchart that is not capable of expressing all aspects of the process. As I shall explain below, process maps simply lack the vocabulary to be adequately expressive. For me, one of the key points of a model is that you can test its robustness against a thorough set of likely scenarios. You model so that you can test before you implement. Bear in mind that implementation of a process does not necessarily involve software.
If you search online for images using the search term “process map”, you’ll see examples that contain as few as two different shapes. The most expressive I have seen contained 7 different shapes. The shapes are vocabulary. Make no mistake, such limited vocabulary does not make process maps “simple”, it makes them simplistic. The fact that something is easy to produce does not necessarily make it good. The fact that the limited vocabulary of process mapping allows anyone in a business to do it does not necessarily make it good. In my experience, business processes tend to be subtle and layered. The lack of expressiveness in process mapping cannot represent the true nature of the process. Against the advice of Albert Einstein, process mapping, in its attempt to be simple, surrenders the adequate representation of the business process.
Some BAs argue in favour of UML for modelling business processes. However:
“The OMG’s Unified Modeling Language® (UML®) helps you specify, visualize, and document models of software systems” (source)
I used to use UML activity diagrams for modelling business processes and stopped when I learned BPMN for several reasons. Firstly, because (per the OMG’s statement above) that’s not what UML is for; secondly, because they suffer from the same problem of restricted vocabulary; thirdly, because there is no standard vocabulary and grammar for activity diagrams.
Note, however, that I resisted learning BPMN at first. I suspect I wanted my experience up to that point to remain valid and relevant. Then I decided that the only way to truly choose was to learn both, so I did. Sadly, I have the impression that a lot of people these days would rather remain expert in an old way of doing things than invest in learning something new.
Unlike process mapping, BPMN 2.0 has a broad vocabulary of shapes and shape types that allows us to express the richness and sophistication of business processes as simply as possible, while ensuring the consistency of the use of that language through a standard grammar and syntax. BPMN doesn’t merely allow you to model the steps of a process, but also the nature of the steps (manual, user, automated, etc), the nature of what triggers the process (a timer, the receipt of a message, a human choice, etc), how the process must respond to different types of events that take place in the world, what to do if one of many parallel paths does not complete. These are just a few examples. What’s more, BPMN also allows us to build hierarchical models in three dimensions, as opposed to the two-dimensional nature of process maps. This is analogous to having a model of a town, showing the detail of every building, rather than just a map of it. One of the key things about BPMN is that it allows you to test the process.
In Waterfall software developments, business analysts often never find out that their simplistic process maps are not adequately descriptive because by the time everyone realises that the software doesn’t actually reflect the real business process, the people who produced the process maps have moved on and don’t learn the truth.
In Agile software developments, they can flesh out any lack of clarity in conversations but in my experience the clarifications get reflected in the screen flows of the software design while the original process maps are never refined. The result is that after the software goes into production, it and the process maps do not match, so the maps are useful neither for training nor as a reflection of the new “As Is”. This is largely down to people’s misinterpreting the Agile principle “Value conversation over documentation” as “Value conversation instead of documentation”.
Any modelling technique is a language and business processes are usually quite sophisticated. Would you rather learn and use a rich language to describe that sophistication, or would you rather stick with 2 to 7 shapes? Here’s the hidden bonus: a richer vocabulary enables richer thinking and better problem-solving skills.
BPMN 2.0 has a two palettes of shapes: Level 1 and Level 2. Learning Level 1 first allows process modellers to start getting to grips with the language. It also gives business people enough vocabulary to be able to start drawing initial drafts of models themselves, which can then be refined in collaboration with modellers who are fluent in Level 2.
For a slide deck tutorial on Level 1, click here. Anyone can learn it.
Kind regards.
Declan Chellar
I agree with your comparison to a language and the vocabulary but I the more languages you know the better you can express a concept. I agree BPMN is extensive but for certain processes you may need more. I also agree that modeling a process and testing it viability is essential to a successful implementation.
I would appreciate if you could you give some examples of a three dimensional model.
Hello, Phillip. Thanks for reading and commenting.
No language is perfect, which is why spoken languages evolve to be able to talk about new phenomena. However, when uncontrolled you end up with several languages where there used to be one, the many descendants of Latin, for example.
BPMN has evolved from version 1.0, through versions 1.1 and 1.2 to the current version 2.0. There will be a version 3.0 but I understand it’s a few years away yet. The evolution of a modelling language (unlike a spoken language) has to be controlled, otherwise one of its main advantages (that it’s a lingua franca) is lost.
I have heard many people say: “You can’t model everything using BPMN”. I think some mean: “You can’t model all of business architecture using BPMN” and that’s certainly true because process is only one aspect of the architecture of a business. I think others mean that they have come across an aspect of a business process that they couldn’t model using BPMN and that is down more to their lack of knowledge of BPMN. However, it’s likely that there are aspects of unusually sophisticated business processes that cannot be modelled using BPMN (yet) but I have yet to come across an example.
Can you give me an example of some part of a business process that you cannot model using BPMN? I’d welcome the challenge.
Kind regards.
Declan
Phillip, regarding 3D, I think of process “maps” as 2D because they are on a single sheet of paper (at least, all the process “maps” that I have seen have been on a single canvas, albeit one made up of several sheets of paper taped together).
Because of the “collapsed” sub-process shape in BPMN, you can show a sub-process as a single activity and where that activity fits at one level of the model, but show the details of that sub-process at the next level down. You can have sub-processes within sub-process as needed ad infinitum. This is where the use of the words “map” and “model” really make sense. A map is all on one level. With a model, you can lift up the top level to reveal levels below it.
Kind regards.
Declan
But still, I think a process model in BPMN is not enough to understand the process because it’s still flat and misses the dynamics of execution.
This is what I mean with that: http://procesje.blogspot.nl/2016/05/process-models-really-helpful-for.html
Thanks for reading and commenting, Emiel.
You make valid points in your own blog post, although all your examples use what I refer to as “process maps” and not “process models”. Moreover, a BPMN diagram is not the entirety of the information in a process model, as there would be meta-information behind each of the shapes.
Kind regards.
Declan