Find the constraint — with three numbers per step
A bottleneck analysis needs no ERP extract and no consulting programme. It needs volume, duration and capacity per step, an honest range instead of an average, and the willingness to believe the result even when it points at a different step than expected.
A bottleneck analysis computes utilisation ρ = demand ÷ capacity for every process step and ranks the steps by it. The highest value is the constraint — not the step with the longest processing time, and not the one people complain about most. It becomes critical from roughly 85 %: at that point waiting time is already 5.7× processing time, and at 95 % it is 19×. Compute for the peak day rather than the monthly average, and recompute after every measure, because once a constraint is fixed it moves to the next step.
2.3×
Waiting time relative to processing time.
5.7×
From here every increase in volume gets expensive.
19×
Ten points more, three times the wait.
5–10steps
Modelling more finely does not move the constraint.
The constraint is the step with the highest utilisation
Not the slowest, not the loudest. This distinction decides whether a measure works or evaporates.
Utilisation ρ = demand ÷ capacity
= (volume × processing time) ÷ available working time
Example. The step "review" receives 120 cases a day, each taking 12 minutes. Three people work seven productive hours each.
- Demand: 120 × 12 min = 1,440 min/day
- Capacity: 3 × 7 h = 1,260 min/day
- ρ = 1,440 ÷ 1,260 = 114 %
Above 100 % means the queue grows every day — not "it takes a bit longer" but without bound, until somebody escalates, works overtime, or cases are left undone.
That another step takes 40 minutes is irrelevant as long as there is enough capacity there. Duration is not utilisation. The full arithmetic, including Little's Law and the Kingman approximation, is in the article Calculating the bottleneck.
Five steps, half a day
Sequence matters more than precision. Start with data collection instead of scoping and you will spend three weeks collecting numbers for steps that are not part of the question.
1. Scope it — where does the process start and end? One sentence everyone involved would sign: "From receipt of the invoice to release for payment." Without that sentence two departments discuss different processes and wonder why their numbers differ.
2. Model coarsely — five to ten steps. Not thirty. Draw decisions only where a case genuinely branches, with a routing share per edge. Anything that leaves the process (withdrawn, rejected, abandoned) becomes an abort — otherwise you compute with volumes that never arrive.
3. Collect three numbers per step. Volume, processing duration as a range, capacity. Estimates are allowed, invention is not: every estimate is recorded as an assumption and carried into the result.
4. Compute and rank. ρ per step, descending. Mark anything above 85 %, flag anything above 100 %. Cross-check with Little's Law: work in progress ÷ daily throughput should roughly equal the measured lead time. A large deviation means a queue is missing from the model — usually a query or an approval.
5. Test levers — one at a time, not as a package. Increase capacity, reduce variation, divert volume, automate a step. Recompute after each single change. Three changes at once produce a number nobody can attribute to a single lever — and therefore no business case.
Which numbers you need and where they live
The most common excuse against a bottleneck analysis is "we do not have the data". Usually it sits in four systems any department head can open.
| Input | Source | Substitute if nothing exists |
|---|---|---|
| Volume per day | ERP, ticket system, invoice intake, post book | Count for four weeks — enough for a first round |
| Peak day | same source, maximum instead of mean | Rule of thumb: month end or start of week, factor 1.5–2 |
| Processing duration from–to | time recording, self-report | Ask three processors separately, take the range from their answers |
| Capacity per step | headcount × productive hours | People × hours × 0.7 for interruptions and side work |
| Work in progress | in-tray, waiting list, open tickets | Count on three days |
| Fully loaded rate per role | controlling | Gross salary × 1.5 to 1.8 ÷ 1,500 hours a year |
On the last line: a €50,000 position costs roughly €53 per hour, not the naive €24 that comes from salary ÷ 2,080 hours. With the naive rate every statement in money becomes attackable later — and it will be attacked. The other common arithmetic errors are covered in Process costs in Excel.
Five errors that sink a bottleneck analysis
1. 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.
2. Mistaking the longest step for the constraint. Duration is not utilisation. A 40-minute step with ample capacity is harmless; a 12-minute step without capacity is not.
3. Mistaking the loudest step for the constraint. Whoever complains often sits behind the constraint and receives work in bursts. The complaint is real; the cause is one station earlier.
4. Ignoring the migration. Once the constraint is fixed, the full volume hits the next step. Business cases that omit this knock-on effect promise savings that never arrive — the single most common reason an automation project misses its numbers.
5. Trying to maximise utilisation. 95 % utilisation is not a sign of efficiency but of waiting. Running a process at high utilisation buys throughput with lead time, at a very poor exchange rate.
What a defensible finding looks like
A finding a steering committee accepts has four components. Miss one and you get the question that stalls everything.
- The ranking of utilisations, computed for the peak day, with the assumptions visible per step.
- Lead time as a band: P50 and P90, not an average. A commitment is made against the P90, not against the median.
- The effect of exactly one lever, before against after, in time and in 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 in the room before it is asked.
Those four components are exactly what FlowVisual exports: the constraint with utilisation on the P90 day, lead time as a range, the before/after comparison in money and the assumption list — as a proposal PDF for the decision maker and a documentation PDF for traceability.
- Metric
- Utilisation ρ = demand ÷ capacity, per step, on the peak day
- Alarm level
- ρ > 85 % — waiting time is already 5.7× processing time there
- Cross-check
- Little's Law: work in progress ÷ daily throughput ≈ measured lead time
- Model size
- 5–10 steps; modelling more finely does not move the constraint
- Collection
- Volume, processing duration as a range, capacity. Estimates allowed if they stay visible as assumptions
- Output
- Ranking, P50/P90 lead time, effect of one lever in money, assumption list
Frequently asked
At what utilisation does a process step become critical?
As a rule of thumb, from 85 %. The reason is the factor ρ/(1−ρ) from queueing theory: at 85 % waiting time is already 5.7× processing time, at 95 % it is 19×. Only ten percentage points of volume growth separate the two — which is why a collapse feels sudden although it is not.
Can I do a bottleneck analysis in Excel?
Utilisation per step, yes, and that is the most important part. What Excel cannot do is the coupling: a step behind the constraint looks relaxed in the spreadsheet because it only receives what the constraint lets through. Once that is fixed, it becomes the constraint itself. This migration is why spreadsheet business cases do not materialise in operations.
Do I need process mining for a bottleneck analysis?
No. Process mining measures the past from system logs and is strong where a continuous event log exists. For the question of what happens once a step is automated or a position is filled, you need arithmetic about a process that does not exist yet — and for that, volume, duration and capacity per step are enough.
How long does a bottleneck analysis take?
For a scoped process with five to ten steps: half a day, most of it data collection. The model itself takes around 30 minutes. It takes longer when the scope is contested — in which case that, not the arithmetic, is the actual work.
What if I have several bottlenecks?
Work through them one at a time. At any moment there is exactly one limiting step; the others only look high because they are not yet receiving the full volume. Fix the top one, recompute, then take the next. Tackling everything at once creates cost whose effect can no longer be attributed afterwards.
A bottleneck analysis of your process
Add the steps, enter volumes and ranges, run the stress test — the top bar is your constraint. Then change one lever and watch where it moves.
Guide: seven steps to the number- 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 - Use case
Invoice approval: why OCR does not halve your lead time
Invoice approval is the most automated administrative process — and the one where the promised savings most often fail to appear. A worked example model shows why.
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