How to simulate a business process: eight steps, fully worked
Simulating a process means: scope it in one sentence, break the flow coarsely into five to ten steps, collect volume, processing duration as a range and capacity per step, describe the arrival stream with variation and a peak factor, run the model hundreds of times, cross-check the result against reality with Little's Law, then change exactly one lever and recompute. The effort is about half a day, most of it data collection rather than computing. The result is a range — P50 and P90 — plus a statement of where the constraint moves after the measure.
This walkthrough is tool-independent: it works in a simulation lab, in a Python library, and in a lean decision instrument alike. The click-by-click version for FlowVisual is in the guide.
Step 1: Scope it, in one sentence
"From receipt of the invoice to release for payment."
Everyone involved must be able to sign that sentence. Without it, two departments discuss different processes and wonder why their numbers do not match.
If the sentence is missing, producing it is the real work — not the arithmetic.
Step 2: Break it down coarsely, five to ten steps
Not thirty. The constraint sits where utilisation is highest, and that is as visible in a coarse model as in a fine one. Every extra activity costs five input fields and does not move the result.
Three rules:
- A branch only where a case genuinely diverges — with a share per edge.
- An abort for everything that leaves the process: withdrawn, rejected, abandoned. Without aborts you compute with volumes that never arrive.
- Waiting times are not steps. They emerge on their own once capacity is tight. Entering "waiting: 3 days" as a step means assuming the answer instead of computing it.
Step 3: Three numbers per step
| Input | Where it lives | Substitute |
|---|---|---|
| Volume per day | ERP, ticket system, intake list | Count for four weeks |
| Processing from–to | Time recording, self-report | Ask three processors separately, take the range from their answers |
| Capacity | Headcount × productive hours | People × hours × 0.7 |
On the range: "5 to 15 minutes" is a better input than "10 on average" — and departments give it more readily, because it is more honest. The spread is not imprecision; it is the cause of the queue.
On capacity: count seven productive hours per full-time equivalent, not eight. Meetings, queries and interruptions are not processing time.
Step 4: Describe the arrival stream
The most frequently skipped step, and the most consequential. Three inputs:
- Mean volume per working day.
- Variation — do cases arrive evenly or in bursts?
- Peak factor — how much more on a busy day? Month end or start of week; a factor of 1.5 to 2 is common.
Computing with a flat average simulates a process that is never under load — and produces a lead time that never occurs in operations.
Step 5: Run it, hundreds of times
A single run is a sample of one. Only repetition with fresh random numbers produces the result that matters: a distribution from which P10, P50 and P90 can be read.
Output you need: throughput, lead time as a band, utilisation per step, queue lengths.
Step 6: The cross-check
Little's Law is the cheapest check available, and it holds without assumptions about distributions:
Lead time W = work in progress L ÷ throughput λ
Count the cases waiting today, divide by daily throughput, compare with what your model reports.
- Roughly matching: carry on.
- Model much faster than reality: a queue is missing. Almost always a query, a second approval tier or a batch run.
- Model much slower: you underestimated capacity or missed a branch that takes volume out.
Step 7: Change one lever
Save the baseline. Then make exactly one change:
- Increase capacity
- Reduce variation (separate cases by type, level the inflow, abolish queries)
- Divert volume (value thresholds, sampling instead of full checks)
- Automate a step
Recompute, compare. Then revert and take the next lever. Three changes at once produce a number that cannot be attributed to any lever afterwards.
Step 8: Write it up, with assumptions
Four components: ranking of utilisations on the peak day, lead time as P50 and P90, the effect of the lever in time and money including the new constraint, and the list of what is not covered.
The worked example
Example model, not client data.
Process: handling reimbursement claims. 80 claims per working day, peak factor 1.6 at the start of the month.
| Step | Processing | Capacity | Demand/day | Capacity/day | Utilisation |
|---|---|---|---|---|---|
| Intake check | 3–6 min | 1 person | 360 min | 420 min | 86 % |
| Substantive review | 8–20 min | 3 people | 1,120 min | 1,260 min | 89 % |
| Approval | 2–5 min | 1 person (side task) | 280 min | 300 min | 93 % |
| Payout | batch | 2× per week | — | — | — |
First reading: the constraint is approval (93 %), just ahead of substantive review (89 %). All three sit above 85 % — meaning waiting is already a multiple of processing time, and on a peak day with factor 1.6 all three exceed 100 %.
Simulation result: lead time P50 = 4.8 days, P90 = 11.2 days. Processing time sums to 13–31 minutes. Between 25 minutes and 4.8 days sits the actual question.
Cross-check: the tray holds about 390 claims on average, throughput 80/day → 4.9 days. It fits.
Lever A — half an additional FTE in substantive review: P50 falls to 3.9 days, P90 to 8.4. The constraint is now unambiguously approval (93 %).
Lever B — named cover for approval instead of one person's side task: P50 falls to 3.1 days, P90 to 6.0. The variation of the approval step was the bigger lever, and it costs no position.
Lever C — daily payout instead of twice weekly: P50 −0.7 days, essentially free.
Ranking by effect per effort: C, B, A. The classic answer — more staff — comes last.
The five expensive mistakes
- Entering waiting time as a step. That assumes the result.
- Computing with averages instead of ranges. No variation, no queue; no queue, no realistic lead time.
- Omitting the peak day. A process at 85 % on average sits above 100 % on the peak day — that is where the backlog forms and persists for weeks.
- Modelling too finely. Thirty steps, the same answer, triple the effort.
- Publishing without the cross-check. Little's Law costs five minutes and saves your credibility.
Frequently asked
How long does it take to simulate a process?
For a scoped process with five to ten steps: half a day of actual work, spread across roughly a calendar week. Most of it is data collection rather than model building — the model itself takes around 30 minutes. It only takes longer when the scope is contested.
What is the minimum data I need?
Three numbers per step — volume, processing duration as a range, capacity — plus a description of the arrival stream with variation and a peak factor. Everything may be estimated as long as the estimate is carried into the result as an assumption. No event log is required; you need one only if you want to measure the past rather than compute a change.
How do I know my model is wrong?
Little's Law: count the waiting cases and divide by daily throughput. If measured lead time is far above the computed one, a queue is missing from the model — usually a query, a second approval tier or a batch run. This check costs five minutes and is the most effective one available.
Should I model waiting times as their own steps?
No. Waiting emerges by itself once a step lacks capacity for the arriving volume. Entering it as a fixed step presupposes the result you set out to compute — and afterwards you can no longer show how waiting changes when capacity or variation changes.
Why change only one lever per run?
Because otherwise the effect cannot be attributed. Change capacity, variation and routing at once and you get a better number but no business case: nobody can say which part of the investment produced it. Computed separately, you get a ranking by effect per effort — and it often has a free measure at the top.
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
What is process simulation? Definition, methods, limits
Process simulation executes a flow artificially instead of describing it. The difference is not academic: it decides whether you have an opinion about a change or a number.
Read - Method
How to calculate a bottleneck: why 85 % utilisation is already too much
The bottleneck is not the longest step, it is the step with the highest utilisation. And waiting time does not grow linearly with utilisation — it explodes just before the limit. The maths behind it fits on one page.
Read - Method
Business process simulation: a practical guide
In an organisation, simulation is not a statistics project but a decision instrument. This guide covers which processes are worth it, what ends up on paper, what a first attempt looks like — and the four mistakes that cost most attempts.
Read