Business process simulation: a practical guide
Simulating business processes pays off wherever cases wait: approvals, applications, complaints, quotations, onboarding, service tickets. The value comes not from the accuracy of the model but from three statements no spreadsheet delivers — which step limits throughput, where the constraint moves after a measure, and what that measure is worth in money, each as a range. A first attempt needs a scoped process, five to ten steps, three numbers per step and about half a day. The most common mistakes are models built too finely, computing with averages, changing several measures at once, and a result without stated assumptions.
Simulation has a poor reputation in business, earned on the factory floor: weeks of model building, specialist knowledge, a report three people understand. For business processes none of that holds — there the effort is half a day and the output is a single sheet that works in a steering committee.
Here is what you need to know.
What simulation is good for in an organisation
Not documentation. Not compliance. Exactly three statements:
1. Where is the actual constraint? The constraint is the step with the highest utilisation, not the slowest and not the loudest. Whoever complains often sits behind the constraint and receives work in bursts.
2. What happens once we fix it? The constraint moves. While step 2 runs at 114 % utilisation, step 3 looks relaxed — it barely receives anything. Fix step 2 and step 3 takes the full volume. This knock-on effect is the most common reason automation projects miss their numbers.
3. What is it worth in money? Not "faster", but a number with provenance, as a range, with stated assumptions.
Everything else — better-looking diagrams, complete process landscapes, standards-compliant notation — is the job of other tools.
Which processes qualify
Rule of thumb: anywhere cases sit in a tray waiting for somebody.
| Process | Why it qualifies | Typical finding |
|---|---|---|
| Invoice approval | Many participants, approval as a side task | Constraint in business approval, not in data entry |
| Quotation process | Lead time acts on revenue, not on cost | Costing and internal approval are the brake |
| Complaint handling | Queries create double waiting | Constraint in the query, not in the handling |
| Applications and permits | Fixed capacity, variable inflow | Peak days determine lead time |
| Employee onboarding | Many participants, small volume, appointment chains | Waiting for appointments, not processing effort |
| IT ticket / service desk | Prioritisation and escalation | Second line is the limiting step |
| Recruitment | Scheduling across several calendars | Time to response decides who drops out |
Not suitable: processes running well below capacity with no backlog. There, processing time is lead time and addition suffices. If nobody waits, there is nothing to simulate.
What ends up on paper
A result a steering committee accepts has four components:
- The ranking of utilisations, computed for the peak day rather than the monthly average.
- Lead time as a band — P50 and P90. A commitment is made against the P90; promise the median and you break the promise half the time.
- The effect of exactly one measure, before against after, in time and money, including where the constraint moves next.
- The list of what is not covered. The sentence "queries to the supplier are not modelled" takes the sting out of the sharpest question before it is asked.
Omit point 4 and the question still comes — but in the meeting, and without an answer.
A first project, realistically planned
| Step | Effort | Who |
|---|---|---|
| Scope it in one sentence | 30 minutes | Process owner |
| Capture the flow coarsely, 5–10 steps | 1 hour | Department, together |
| Obtain three numbers per step | 2 hours | Department, controlling |
| Build the model and run it | 30 minutes | one person |
| Compute measures one by one | 1 hour | same person |
| Prepare the result | 1 hour | same person |
Half a day of actual work, spread over roughly a calendar week — data collection is the bottleneck, not the computing. If the scope is contested, that is the real work; then it takes longer, and rightly so.
The four mistakes that cost projects
1. Modelling too finely. Thirty steps instead of eight. Every extra activity costs five input fields and does not move the constraint. The constraint sits where utilisation is highest, and that is as visible coarsely as it is finely.
2. Computing with averages. A process at 70 % utilisation on the monthly average and 130 % on the first of the month has a problem the average hides. Compute the 90th-percentile day.
3. Changing three measures at once. The result cannot be attributed to a lever afterwards — leaving you with no business case, only an assertion with numbers attached.
4. Publishing a point estimate. "Lead time falls by 43.7 %" is attackable and will be attacked. "P50 from 6.1 to 3.4 days, P90 from 14 to 7, assumptions in the annex" is not.
Which tool
Briefly, because the long version is in the comparison of the four categories:
- Drawing tools (Visio, Lucidchart, draw.io) document but do not compute.
- BPM suites (Signavio, ARIS, Bizagi) govern processes across the organisation; simulation is one module among many.
- Simulation labs (Arena, Simul8, AnyLogic, FlexSim) have the strongest engines and come from manufacturing — right for facilities, heavy for approval processes.
- Decision instruments such as FlowVisual compute less deeply but deliver a before/after in money within hours.
The category decides, not the feature list. And for a first attempt, one thing decides above all: that it happens at all.
In summary
- Simulation pays off where cases wait — not where documentation is wanted.
- The value is three statements: constraint, migration, worth in money.
- A first project costs half a day of work; data collection is the bottleneck.
- Five to ten steps, peak day instead of average, one lever per run, result as a range with assumptions.
Frequently asked
From what company size does process simulation pay off?
Size is the wrong metric. What matters is whether cases wait. A firm with 40 employees and 1,200 invoices a month has the same backlog as a corporation with the same ratio of volume to capacity. Conversely, large organisations have processes running well below the limit — there a simulation is superfluous.
How accurate are the results?
As accurate as the inputs, which is why they come as a range. The value lies not in the absolute figure but in comparing two states under the same assumptions: if the same assumption sits in both runs, it largely cancels out in the comparison. That is why "this measure saves €78,000 to €121,000 a year" is more defensible than "the process costs €412,000".
Do we need data from the ERP?
Helpful, but not a prerequisite. What you need is three numbers per step: volume, processing duration as a range, capacity. Volume sits in the ERP or ticket system, capacity in the headcount plan, and durations you obtain by asking three processors separately and building the range from their answers. Estimates are allowed as long as they stay visible as assumptions.
Who should build the model?
One person, live, in front of the department. Not three people in sequential interviews. The value of modelling together is the objection: every correction raised in the workshop will not be raised in the final presentation — and what remains is a model everyone agreed to before anyone argued about the result.
What if the result contradicts our experience?
First check the model against reality: count work in progress, divide by daily throughput (Little's Law) and compare with the known lead time. A large deviation means a queue is missing — usually a query or a second approval tier. If the cross-check holds and the result still contradicts experience, that is the actual return on the project.
Run the numbers on your own process
FlowVisual turns the figures in this article into a model that runs — with your volumes, your capacities, your range.
Guide: seven steps to the number- Method
Process costs in Excel: four mistakes that sink any business case
Nearly every business case for process improvement is built in Excel. And nearly every one contains the same four mistakes — not through carelessness, but because a spreadsheet structurally cannot represent certain things.
Read - Method
Monte Carlo simulation for business processes: what it does and when it lies
Monte Carlo is not a magic word, it is systematic dice-rolling: the same process, hundreds of times, with different random draws each time. What comes out is not a number but a distribution — and that is the whole point.
Read - Method
Reading P10, P50 and P90 — and where the average misleads you
Percentiles are not statistician's vanity; they are the only honest way to report a result that varies. Three numbers, three purposes — and three misreadings that routinely end up in decision papers.
Read