BPMN is simple and powerful - one tool for all your business processes. But suddenly, after you have sketched everything, the result is quite different from what you expected. The process picture seems to be in a completely different language you've never heard before. Does that ring a bell? Don’t worry; If you follow some tips when working with BPMN, you can easily avoid confusion or mistakes in process management. Since even small mistakes can have a big impact on the result, we will show you the eleven most common mistakes made when modeling processes in BPMN and give you solutions on how to avoid them.
All of the following eleven process examples are more or less a result of the following situation: The Mayers, a family of four, are planning their summer vacation. However, they sometimes have differing views regarding the destination and how to get there. So naturally, this leads to many discussions and a lot of very different considerations.
Tip 1: Always model start + end events
Just like a story, every process has its starting point and hopefully a satisfying end.
Although BPMN allows a process model without start and end events, for many processes, it is still essential to define when this particular process is first initiated and what result is to be achieved. And in any case, you eliminate the possibility of misunderstandings.
Tip 2: Never place an activity between lanes
Sometimes it is not clear where to place an activity. Especially when the activity involves communication between two process participants.
Every interaction between two process participants has a sender and at least one receiver. In the case of an information exchange, this activity is simply expressed by a message sending activity and a message receiving activity. An activity must never be between lanes or pools, but must always be clearly declared as an outgoing or incoming message.
Tip 3: Avoid inadequate event naming
Try to use meaningful names for events and activities.
The names "process start" and "process end" are redundant. Rather, it is important to make clear which event is the initial trigger for this process and which result is to be achieved at the end of the process. Process modelling can only work with accuracy and meaningful names.
Tip 4: Exclusive gateways to show the relationship between different paths
Not every process is as straightforward and simple as the one shown above. You can express alternative and additional paths in a process by using gateways.
Even the Meyer family has different opinions when it comes to choosing a holiday destination.
The Exclusive Gateway is essential here, otherwise rumors could spread that the Meyer family could not agree and are now on separate holidays. This gateway therefore expresses that either one or the other way will be taken. Each Split Gateway also needs a Join Gateway, which brings the two paths together and leads to the common goal.
Tip 5: View concurrent activity with parallel gateways
Often in a complex process, different activities can or must run simultaneously and independently of each other.
This requires the use of a parallel gateway. Otherwise, expensive time is wasted when an instance in the process waits for an activity to complete when it does not need to. In the case of the Mayer family, the request to the dog sitter, the message to the neighbor and the purchase of sun cream are (fortunately) independent of each other in terms of time.
Tip 6: Avoid overusing “terminate end events”
Terminated end events can be misinterpreted as stronger process endings. But be careful! If one of the paths reaches the end, all other process paths (currently active and activities waiting to be performed) will stop immediately.
A process ends successfully when all started activities have finished, and a process is terminated only when an unplanned event occurs. Terminate end events are useful in situations where we are working through related tasks simultaneously. When one task is completed, the others may become redundant. By using the termination event, you can ensure that all remaining process instances are terminated immediately. In our example, the dog sitter takes care of the food herself, so the Mayers no longer need to get any.
Tip 7: Always name exclusive gateways with the relevant question
In a process, it is not always clear what the issue and exclusion criteria are. Let us accompany the Mayer family in their travel budget planning.
In this process, it is not clear what criteria are applied to the exclusive gateway. Is this about the amount of savings? About the cost of the hotel? About the flights?
This model clearly states what the decision is (if the flights are more than 2000€, they can only afford an Airbnb home for their holidays...) and what the decision criteria are. In our example, the exclusive gateway decision can easily be made manually. In certain business processes, a pre-defined decision table is stored (as shown here in the model). Today, DMN diagrams are used instead of decision tables.
Tip 8: Uniqueness for exclusive gateways is mandatory
For exclusive gateways, the different paths should be clearly mutually exclusive. In fact, our previous example is not clear enough.
The second and third paths are not mutually exclusive or vice versa: ≤ 2000 € includes ≤ 1000 €.
If we want to keep a third possibility open, we need to define the second path more precisely: ≤ 2000€ > 1000€. The Mayer family now has three options: Book an Airbnb home for the lowest price, a hotel with half board, or an all-inclusive hotel booking if the cost of flights is low.
Tip 9: Be careful with mixed gateway types
The join gateway does not match the outbound gateway. The process is stuck.
Using different gateway types at the outbound and join gateways only makes sense in very rare exceptional situations, and will result in the process getting stuck at the join gateway (try it in simulation!). In those rare exceptional situations, modeling a terminated end event is much better. So always close your outbound gateway with the appropriate join gateway.
Tip 10: Avoid unnecessary gateways
In our efforts to model the process as accurately as possible, we sometimes go too far: we build gateways where none are needed.
Whether the Mayers are on holiday by the sea or on a city trip to Prague, the booking situation remains the same: They need a hotel and they need to book flights, but there is no need for an exclusive gateway.
Tip 11: Use Loops instead of plural
To resolve this rather cryptic tip, we need to take a closer look at the activities within a process. An activity should always be named with an object and a verb in the infinitive (e.g. book hotel). Of course, you could make it easy for yourself and, in the case of several hotel bookings in a row (e.g. for a round trip), define your activity as "Book all hotels". But here is the problem: How does your process engine know how many and which hotels have already been booked?
You can solve this problem by using a so-called “loop”:
Always define an activity with only one object. If multiple objects exist, stay in the singular and loop your process until all objects are processed.
Conclusion: Precision is key
A process is only as good as its designer. A process engine cannot interpret or assume knowledge of what someone might have in mind. So it is essential to build a process without doubt and without room for interpretation. The tips above are only intended to help you avoid some of the most common modeling mistakes. But by following them, your accuracy and awareness will be trained to recognise and overcome other challenges.
Now it only remains for us to wish the Mayers a Merry Christmas.
Automate complex Business Processes and Workflows with Simplicity
Mapping single Jira workflows won't necessarily go far enough. Flower Workflow Automation adds the strategic layer to your business process management.
Unlock the full power of Jira by aligning and streamlining your BPMN processes and workflows directly with your team: Every business process turns into an automated workflow by creating a Jira issue for each business process activity.