BPMN Modeling : Most Common Mistake 2021

We all have specific work to accomplish, and much of it can be planned, outlined, and executed thanks to process modeling. BPMN, or business process model and notation, is the system used to write these process models, and it’s a universal business process planning language. However, there are some ways in which the practice can be misused, and while some are age-old mistakes, others are growing more common now, and need to be corrected if you plan to utilize BPMN to keep you and your business consistent and always on track.

To figure out what’s hindering your best possible usage of BPMN, you might need to look at the most common mistakes being made in 2021 regarding business process modeling in general — so read on to get acquainted and fix your own habits.

It’s All The Same

Events are used to indicate specific milestones that exist outside a process’s actual workflow; and while some events may all seem relevant to a process, that’s not always the case. More specifically, there are times wherein events occurring at the same time, sharing a common name, are mistaken for different events — but upon closer inspection, it’s clear that they are all the same event. Indicating two “Start Process” events, for example, means that the process is intended to start twice. This makes no sense, given that a process only starts once (with the exception, of course, a BPMN loop, where the process is indicated to repeat). 

This dual start is commonly seen in processes with multiple paths which start separately. But for them to start separately, that means they would be triggered by different events, not the same one; this discrepancy means that if you plan to use separate start events, it’s more appropriate and easier to understand fully if you write each start event is unique in some way, such as “Start Editing” and “Start Auditing” as two separate starts to a dual-track process.

Otherwise, it’s better to simply write one Start to the process as a whole, and the path can diverge into two or more from there. Even implementing start and end events for each subprocess is a practice that proves more useful, since specificity is key.

It’s All In The Name

In the same vein as the above, event naming can prove to be a big issue as well. Why? Because being too general can cause issues, as seen above. This is also the case with other situations wherein event cues are given names that are not appropriate for the intended meaning — like the difference between “terminate process” and “end process”. It may seem like “terminate” and “end” can be used interchangeably, but this is rarely the case. 

These event names are different because “terminate process” would be an event that actually causes the process to stop, even while certain tasks are still underway. In this case, it’s important to note that some processes require loops of action, and to terminate prematurely would potentially risk damaging that BPMN loop in terms of its integrity. However, the “end process” event is one that indicates where a process ends, and “termination” doesn’t interrupt these other tasks, since each is implied to reach the end in this case.

Because of this major difference, the name of an event, in this case, can be detrimental to the process, and with that in mind, it’s best that when modeling a business process, you name things accurately and discretely. 

You also should consider the names of gateways, which are sometimes mistakenly named as activities. When this occurs, it’s often because the model is meant to indicate the gateway (or decision point) is decided by the outcome of a certain activity. However, this comes across as a redundancy — the task shouldn’t share its name with a gateway as well, and in the case that you do associate a gateway with a task’s outcome, simply putting an unnamed gateway right after the activity is the best practice.

It’s All About Consistency

Whether it’s inconsistent naming or an actual problem with the diagram itself, there is a sincere need for consistency that isn’t always met with process models. One example of this is when an event-triggered gateway produces a path and workflow that is unrelated to the triggering event. While sometimes this results from vagueness in naming the following tasks and other elements, other times the problem arises from an actual lack of connection in this case.

This lack of connection to the trigger event means that there’s too much ambiguity regarding which continuation of the process from said gateway is relevant to the event occurring, and which is actually the alternative flow. 

Because of this, the best way to resolve the issue is to ensure that the event-based flow after such a gateway is only relevant to that event — and to use timer events for alternate outflows that are unrelated to any other such event. On the subject of consistency, it’s also important that even the diagram itself is printed or drawn to be consistent in appearance.

Common mistakes in this sense include mixed directions of flow, uneven spacing (which is often incorrectly used to indicate changes in duration of a transition), and even bending or curved lines for flow that can cause additional frustration — or at worst, confusion. The only way to be sure these aren’t an issue is to simply be consistent with BPMN standards from the get-go, and to be clear and concise about what your model indicates.