BPMN with simulation: what the notation can compute and what it cannot

Table of contents+

One sentence regularly leads tool selections astray: “our BPMN tool does simulation too.” It is usually true and almost always useless, because it can mean anything from a plausibility check to a full discrete-event engine.

The reason lies in the notation itself.

What BPMN describes and what it does not

BPMN 2.0 is an OMG standard for the structure of a process: tasks, events, gateways, lanes, message flows. It answers “what happens in which order, and who does it?” completely and precisely.

To compute, it lacks five inputs that the notation simply does not provide for:

1. The arrival process. How many cases arrive, and distributed how? Twenty applications a day arriving evenly is a completely different picture from twenty arriving in a Monday-morning burst.
2. Variability of processing times. Not “10 minutes” but “5 to 20 minutes, usually 8”. Variability drives the queue, not the mean.
3. Capacity per resource. How many people at what allocation, and which roles share a pool?
4. Branching probabilities. An XOR gateway shows that the flow branches. How often each path is taken appears nowhere in the diagram.
5. Calendars. Eight hours a day, holidays, shifts. A case arriving at 16:50 on a Friday does not wait ten minutes; it waits three days.

BPSim was created for exactly this problem. The WfMC standard attaches simulation parameters to a BPMN model without changing the notation. That such a standard is needed is the best evidence that BPMN alone cannot compute.

What simulation modules in BPMN tools typically provide

The common modelling suites (Bizagi Modeler, SAP Signavio, ARIS and others) offer simulation in graded levels. The usual structure, independent of vendor:

• Structure validation. Does a token even flow through the model, or are there dead ends and unreachable branches? Useful, but not yet simulation in the narrow sense.
• Time analysis. Durations per task, hence lead time. Still without capacity limits, and therefore without queues.
• Resource analysis. Now it gets interesting: people with capacity, and therefore queues and utilisation.
• Calendar analysis. Working hours and shifts, which is what makes waiting times realistic.

Camunda deliberately does not belong in this list: it is an execution engine, not a simulation environment. It runs real cases through the process and measures them. That is more valuable than any simulation. But only once the process is already automated. Before the decision, it does not help.

Five questions for your tool

Open your modelling tool and check within ten minutes:

1. Can I enter a duration as a range? If the field accepts only one number, the tool computes with means. The result will then be systematically optimistic. Queues arise from variability, and without variability none arise.

2. Do I get a result with a range? A lead time of “6.4 days” is a number, not a statement. “P10 4.1 to P90 11.8 days” is a statement. Tools that output only point values either computed deterministically or suppressed the range.

3. Do roles share capacity? In practice, the same person performs three different steps. Tools that track capacity per task rather than per pool will show each step comfortably loaded. The person doing all three is comfortably loaded in none of them.

4. Am I seeing the peak day or the monthly average? On a monthly average almost every role is below 80 % utilised. On the peak day, that is exactly where the process collapsed. If a utilisation figure does not state what it refers to, it is worthless.

5. What does the improvement cost, and what does it return? Almost no modelling tool answers this, because cost rates and investments are not part of the model. Yet that number is what decides the project.

Where even good modules stop

Suppose your tool passes all five checks. One question remains. Most analyses fail on it, not from technical inability, but because nobody asks it:

Where does the constraint move once I relieve it?

An example everyone recognises: review takes too long, so it gets automated. The simulation confirms review time drops by 80 %. What it often does not show: the approval step behind it used to receive a case every 26 minutes, because review did not let more through. Now it receives one every 10 minutes and is overloaded itself. Throughput does not rise as promised, and the time saved reappears as a new queue.

This is not an exotic edge case, it is the rule. A constraint does not disappear, it migrates. A model that cannot play that movement through in seconds produces business cases that do not materialise in operations.

Practical recommendation

• Already have a modelling suite with a simulation module? Use it. A second tool is worth it only once you fail one of the five checks.
• Just starting to model? Do not start with BPMN. The notation is built for documentation; for “where does it break and what is a change worth?” it is a detour through a language you must learn first.
• Have to justify an investment? Then you need ranges, the peak day, shared resource pools and a before/after case in money. Check which of your existing tools delivers that before buying a new one.

FlowVisual deliberately skips BPMN: six building blocks instead of a notation, durations as ranges, utilisation on the peak day, shared pools. At the end there is a before/after in money with a P10–P90 band. If you need BPMN for documentation, this does not replace it. It answers a different question.