Monte Carlo simulation for business processes: what it does and when it lies
Monte Carlo simulation runs the same process hundreds of times with randomly drawn durations and volumes, then evaluates the distribution of results. Instead of a lead time of “6.4 days” you get a band — say P10 4.1 to P90 11.8 days — and therefore a statement that survives contact with operations. It lies when too few runs are computed, when a symmetric distribution is used for visibly skewed durations, when dependencies between inputs are ignored, or when the warm-up phase is included in the evaluation.
“Monte Carlo” sounds like more than it is — which is fine, because the method is pleasantly simple. It is systematic dice-rolling.
The method in four sentences
You do not state that a step takes 10 minutes; you state that it takes 5 to 20 minutes, usually 8. The computer then runs a case through the process, drawing a duration from that range at every step. It repeats this — with a full day of cases, hundreds of times. At the end it does not have one lead time but hundreds, and from those a distribution.
That is all. No model of the universe, no artificial intelligence — just a refusal to pretend the world is exact.
Why processes need it
The obvious objection: if I know the means, why not just compute with the means?
Because processes are non-linear. Two examples make it immediately clear:
Queues. A step at 85 % utilisation produces waiting time of 5.7 times its processing time; at 95 % it is 19 times. If your utilisation fluctuates between 70 % and 100 % across the day, the average of those waiting times is not the waiting time at the average utilisation. It is considerably more. (The underlying maths is in How to calculate a bottleneck.)
The longest path wins. If two branches run in parallel and both must finish, total duration is the maximum of the two — and the expected value of a maximum is greater than the maximum of expected values. A plan computed on means is therefore systematically optimistic.
Both together are Jensen's inequality, popularised as the “Flaw of Averages”. Monte Carlo sidesteps it by not averaging first: it computes, then evaluates.
What you have to supply
| Input | Why it is needed | If it is missing |
|---|---|---|
| Arrival rate and distribution | creates the load | queues never form, or always |
| Duration per step as a range | drives waiting time | result systematically optimistic |
| Capacity per role or pool | creates the limit | no utilisation, no queue |
| Branching shares | distributes the volume | wrong volumes downstream |
| Calendars and shifts | makes waiting realistic | waiting times understated threefold |
The most common gap is the last one. Without a calendar, a case arriving at 16:50 on a Friday waits ten minutes. With one, it waits until Monday.
How many runs?
The question always comes, and the answer is unsatisfying: as many as it takes for the result to stop moving.
What works in practice:
- 100 runs are enough to see which step is the constraint. The ranking stabilises long before the numbers do.
- 500 to 1,000 runs are needed for defensible percentiles — especially P90, which by nature depends on rare events.
- Beyond 5,000 you almost never gain insight at this process size, only compute time.
You can check it yourself: run the same model twice with different seeds. If the results differ noticeably, you used too few runs.
Which distribution?
This is where most people make the second mistake. Processing durations are almost never symmetric: a case cannot be faster than “very fast”, but it can be arbitrarily slow. The distribution therefore has a long right tail.
- Triangular (minimum, most likely, maximum) is entirely sufficient for most administrative processes, and its three values can actually be elicited in a workshop.
- Lognormal represents the long tail better and is the right choice where outliers dominate.
- Normal is almost always wrong. It is symmetric and permits negative durations.
Rule of thumb: if unsure, use triangular and report the result as a band. The choice of distribution shifts percentiles — it almost never shifts which step is the constraint.
The four mistakes that make the result worthless
1. Too few runs. Recognisable because two passes give different answers. Testable in two minutes.
2. A symmetric distribution for skewed durations. Makes P90 come out far too low — precisely the value you should be planning with.
3. Ignored dependencies. If a complicated case takes longer at every step, the durations are correlated. A model that draws each duration independently averages that effect away and understates variability. Remedy: separate case types and model them separately instead of laying one wide distribution over everything.
4. Warm-up included in the evaluation. At the start of a run the system is empty — no queues, short lead times. Including that phase dilutes your result with a state that never occurs in operations.
How to read the result
A Monte Carlo evaluation yields not one number but at least three:
- P10 — the favourable case. It will be this good in roughly one period in ten.
- P50 — the median. Half the cases fall below it.
- P90 — the unfavourable case. Plan capacity with this, not with the mean.
If you collapse that back into a single number in your proposal, the effort was wasted. The range is the result. How to read it, and where P50 misleads, is in Reading P10, P50 and P90.
What Monte Carlo does not do
It does not improve bad inputs. If your volumes are guesses, your results are guesses — merely with decimal places. That is the real danger of the method: it creates confidence the data does not justify.
So three things belong in every evaluation document: which inputs were measured and which estimated, how many runs were computed, and with which seed. Without those the result is not reproducible — and a result that cannot be reproduced is, when challenged, not a result.
FlowVisual works exactly this way and prints seed and run count into the handbook. Not out of pedantry, but because a number nobody can reproduce has no place in a decision paper.
Frequently asked
How many Monte Carlo runs does a process model need?
To identify which step is the constraint, about 100 runs suffice — the ranking stabilises early. For defensible percentiles, especially P90, use 500 to 1,000. To check whether it was enough, run the same model again with a different seed: if results differ noticeably, it was too few.
Which distribution suits processing durations?
For most administrative processes, the triangular distribution of minimum, most likely and maximum — those three values can be elicited in a workshop. Where outliers dominate, lognormal is better. The normal distribution is almost always wrong, because it is symmetric and allows negative durations.
Is Monte Carlo the same as discrete-event simulation?
No, they complement each other. Discrete-event simulation plays out a single run — cases arrive, wait, get processed. Monte Carlo means repeating that run many times with newly drawn random values and evaluating the distribution of results.
Why must the seed be documented?
Because a result that cannot be reproduced has no place in a decision paper. With the same seed and run count anybody arrives at the same figures — and can check whether a deviation comes from changed assumptions or merely from chance.
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.
- 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 - 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
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