Easily Spoting Problems in Your Process With BPMN - COVID Edition

by Daniel Lübke
"Modeling is thinking and not drawing!"
-- Daniel Lübke

Modeling business processes can really help you to find out what information you think is correct and whether you can connect all the dots, i.e., the activities, so that everything play together. In this post I will show you two anti-patterns that are easily detectable when you formally model in BPMN. But don't be scared of "formally". It just means doing it right and knowing the syntax and semantics of the modeling language. I will show you of what you need to take care of. The example will be the quarantine process, which I described in my rant (yes, rant as in strong language) before. I have received mixed feedback to it. I got many comments that were positive and I got two which were negative because they deemed the article too strongly worded and thus inappropriate. Within this blog post we will take the pure technical, analytical route: This is no political blog nor blog post but we will look at two anti-patterns which you can use to improve your customer experience! And perhaps some responsible officials will read it, too... So let's get started!

The Quarantine Process

I had modeled the process in question as part of a university seminar (see the BPMN model above). This is the observable part of process as it has been observed by parents. For your reference: Modeling this took about 10 minutes. So the time you spend on this is minimal. As this is the as-is process there are usually not many discussions, although in a workshop this would take longer because other parts, which are invisible to the "customers", would be discussed.

BPMN-Spottable Anti-Pattern 1: Timeouts signal vital outcome

We start with the problem indicated in red in the bottom-right corner: The timer event has been indicated to be a problem. But why? In this concrete case, a positive test result (i.e., an infection) is notified to the parents but in case of a negative test result no answer is given. This means that the good case is not notified. In this instance this led to many parents calling and thus an increased number of support phone calls, which are avoidable. Why did they call? Because they could not know and/or did not trust whether a positive test result was yet to come or whether their child was tested negatively.

But what is the generic problematic anti-pattern? The problem lies in the fact that an important notification is not sent (probably to reduce workload) which is vital to the receiver. The receiver is reluctant to rely on the missing reply as an indication of a completed test result. And rightly so, because in a real case, no notifications were sent because the test results were lost. Thus, always sending responses increases the reliability of the whole process and will reduce the overall support effort.

So what to do? Just replace the timer event with another message event that waits for the complementary message. That way the outcome is always notified to the waiting participant.

However, the (guessed) motiviation for this step was to reduce workload. What would be options to reduce the workload to not write two letters (probably using some template, print them, send them by postal mail)? For example, another communication channel could be used: parents' email addresses could have been saved alongside the test as well as mobile phone numbers for sending SMS. This could have been easily automated (by software) and would reduce resource utilization while still offering reliable communication to the parents.

You will now think about many deadlines in daily life and whether they are a good choice. Very often missing a deadline is interpreted as acknolwedging something:

  • You can respond to a court filing until a set deadline.
  • You agree to your yearly bank balance if you do not respond within a given timeframe etc.
  • ...
You can easily see that we are used to that but it is that the active participant (i.e., the accused or the bank customer) have to act otherwise they have negative consequences. In this case, however, the passive participant is waiting which is a very different case. You can easily see this when we switch to the technical domain in which we have lots of timeouts; especially in networking protocols. I do not know any case where a protocol asumes success if a message does not arrive "in-time". Instead, all kinds of error handling and recovery strategies start at this point!

BPMN-Spottable Anti-Pattern 2: Multi-Instances of pools do not match activity

The other problem is not easily apparent and unfortunalty many BPMN modelers cannot correctly model with multi-instance pools and activities. As such I have encountered this problem often as a syntactical problem rather than a real problem - but sometimes it is as it is in this case.

Let's clarify multi-instance in BPMN first. Pools, i.e, process participants, in BPMN can be marked as multi-instance. That means that there is not a single participant but a set of participants of the same type. In this case, there is a set of parents involved in the process. Multi-instance pools have a multi-instance marker at the middle bottom as you can see above.

There are also loop markers for activities (i.e, subprocesses and tasks). These can be applied to indicate (from left to right) parallel processing of multiple branches, sequential processing of multiple branches, and normal loops. The syntactical rule is very simple: Message-flows to a multi-instance pool must only originate from a looping activity (optimal is the parallel variant) or from an activity within a looping subprocess. Usually, modelers only forget to set the multi-instance and/or looping activity markers. However, in this case we can see that the missing loop also encompases the test appointment selection. By this syntactical clue we can find out that it is a better idea to have separate appointments for each household.

But wait, you are right that perhaps the modeler only thinks about marking the sending activity as a loop. Let's drill into the subprocess and see what happens.

The clue is in the data object. Data objects can be "lists" as well, i.e., they have the same marker like a multi-instance pool and a parallel loop activity! And here you have a connection between a parallel loop activity (the send task) and a non-list data object, which should raise your attention. If you make this data object a list then you recognize that this list is not filled by a looping activity and thus you are back to the apppoinment making! All you need to do is to follow the marker and you get to the interesting questions!


Of course you cannot find all inefficiencies in projects based solely on some syntactical patterns. For example, the quarantine process could benefit from better business rules as well. Their internals are however not visible in BPMN diagrams. However, by modeling in conformance to the BPMN syntax and semantics and by observing some syntactical patterns you can already spot problems in your process before anyone else - most importantly your customers - will stumble across them. I hope that the example was clear and comprehensible and that you found it useful. If you like this content, please consider to subscribe for updates for this blog below. Any feedback is very welcome. Please drop me an email or share your thoughts on Twitter.

<<< Previous Blog Post
How to implement Pagination properly
Next Blog Post >>>
The easiest rule to not give bad names for your APIs and operations: No Generic Terms!

To stay up to date, we invite you to subscribe to our newsletter and receive notifications whenever a new blog post has been published! You can of course unsubscribe from these notifications anytime.