BPMN: why I love it for process modelling!

I’ve been using the BPMN modelling standard for about a decade now, and I’ve yet to find a better method for mapping business processes! Since stumbling upon it, I’ve grown to become a huge fan! In this article, I explain why I think it’s such a useful framework and language.

An example of a process model produced using the BPMN specification.

What is BPMN and where did it come from?

The ‘Business Process Model and Notation’ (BPMN) specification is a standardised set of symbols and syntax rules for describing business processes.

The specification was created by the Object Management Group in 2005, and “upgraded” to version 2.0 in 2011. You can find the formal specification for BPMN here. Don’t be alarmed by how nerdy it looks!

Since its creation, use of the specification has grown massively, and it is now widely considered to be an essential skill in professional process modelling. The symbol set and syntax rules are available in most mainstream modelling tools, including Visio and Aris. Job descriptions for BAs frequently request competence in BPMN.

My history in adopting BPMN

I’d been using UML activity diagrams for about 5 years before I stumbled on the BPMN symbol set in MS Visio. I was immediately smitten by its flexibility and elegance, so when I undertook the BCS Process Modelling certification as part of my BA Diploma, I chose a course provider that used BPMN as the modelling method in the training and exam.

Although the language provides a wide range of notation symbols (it gets quite arcane in places!), the training course showed that you can model most processes perfectly well with a limited sub-set of these.

Since then, I’ve used the language extensively in modelling complex legal processes. A legal claim will typically follow a convoluted path, looping around on itself, running many parallel streams, or pivoting based on gnarly logic. Producing process models that must be useful to lawyers, IT developers and other stakeholders is challenging to say the least!

So what’s so great about it?

Many past colleagues will have heard me wax lyrical about BPMN, and some have become real converts! Here are my top reasons for loving it:

BPMN encourages robust and unambiguous models

The syntax rules actually help you to produce models that can’t be misunderstood. It’s always clear who is doing what, and in what order. For example, parallel gateways are used to show that every outgoing path is always followed each time. Boundary events on activities show how a task can be interrupted before completion.

While any process model is at best only a representation of reality, eliminating ambiguity is essential – particularly if technology is to be developed to support or automate a process.

The rules help me to ask the right questions

A BPMN model can be thought of as a set of pipes and valves through which water flows. When an activity is complete, or an event takes place, water continues to flow down the pipe to the next part of the process. This analogy helps me to consider whether I am missing activities or decision-points. As I’ve grown more experienced with BPMN, I actually find myself thinking about how I’d model the process while stakeholders are describing it. This helps me ask the right questions up-front.

A great example of this is the use of exclusive gateways. In some other modelling notations, decision-making can take place “within” a gateway. In BPMN, the gateway simply serves to direct the process, and any “thinking” around the decision will be done inside an activity performed by a person or system.

BPMN enables more elegant models

Complex processes are difficult to model elegantly. They can rapidly becomes tangled and chaotic webs that do little to illuminate how the process works. Your choice of modelling language can make a real difference; compared to UML activity diagrams (for example), BPMN encourages more streamlined, elegant models. Some of its features (such as boundary events or event-based gateways) allow for abstract or knotty logic to be expressed simply, preventing the model from becoming bloated and unwieldy.

The models are easily understandable by all stakeholder groups

I’ve found BPMN models to be readily understandable by both business and technical stakeholders, which saves a lot of effort in translation. I typically provide a key to the symbols used in a model, but many stakeholders have said the models are usually self-explanatory. This is really important, as it facilitates better discussions around the actual process design and issues to be resolved.

BPMN is really flexible

BPMN provides a great deal of flexibility within a reasonably small notation set. The various types of gateways, the use of boundary events on activities, and the ability to decompose sub-processes – these all mean the notation can be applied effectively to any kind of process. I’ve used it at a high level to explore abstract processes, and at a very detailed level to look at user-system interactions and automation behaviour.

Your modelling is easily scalable

Using BPMN, a process model can be constructed simply as a standalone diagram. However, the language allows for processes to be connected or decomposed elegantly, and many enterprise architecture tools can make use of this by linking models together. This makes it straightforward for modelling processes across a larger domain and navigating between them.

BPMN models are more portable (and therefore more sustainable!)

Using a standard like BPMN means that your models become more “portable” – other modellers can work on the model (so they’re more likely to be maintained and useful in the future), and the model can be reconstructed in or imported to other tools or platforms. The models can be picked up and re-used in the future without having to worry about the author’s proprietary approach.

It’s so easy to start identifying requirements

BPMN models separate activities, events and logic gateways very clearly. It’s really easy to spot where use cases or user stories are likely to apply, and to identify specific business rules that will inform acceptance criteria (such as “given these circumstances, this must happen”.

I typically include process models alongside the functional requirements that arise from the process. Stakeholders can see how they relate and are more likely to identify any gaps or errors.

What can BAs do to get started with BPMN?

If you’ve not yet used BPMN for modelling business processes, I’d really recommend digging into some of the free resources available online.

Check out the free tool from Camunda – handy if you don’t have access to a premium tool, and Camunda provide a lot of useful information on applying the BPMN standard.

There are loads of videos on YouTube to teach you the basics.

MS Visio comes with stencils for BPMN – more expensive versions come with more symbols! – so if you have this, why not have a bit of a play around?

There are even LinkedIn groups for BPMN modellers!

Finally, whether you’ve just got a query on a knotty modelling problem, or if you’re looking for training to get you and your team started with BPMN, why not get in touch for a chat?