How to identify bottlenecks in a process
How to identify process bottlenecks: map the flow, find where work queues rather than where people are busy, and separate a genuine constraint from rework and waiting. Live example included.
A bottleneck is the step where work arrives faster than it leaves. Finding it means looking for queues rather than for busy people, and separating a real constraint from rework.
The short version
- The bottleneck is where the queue is, not where the busiest people are.
- There is one constraint at a time; fixing it moves the constraint somewhere else.
- Rework loops look like capacity problems and are not: they are quality problems.
- Waiting on an external party is a bottleneck you can plan around but not staff around.
- Measure the queue in front of a step, not the utilisation of the person doing it.
Busy is not the same as constrained
Ask a team where the bottleneck is and you will usually be told about whoever is busiest. That is a reasonable guess and often wrong. A bottleneck is a structural property of a flow: the one step where work arrives faster than it can leave, so a queue forms in front of it and everything downstream is idle waiting. Busy-ness is distributed everywhere; the constraint is in exactly one place at a time.
The reliable way to find it is to look for the queue. Where do items pile up? Where is the oldest work in the system sitting? Which step do people describe as "waiting for"? A process map makes those questions answerable because it shows the whole flow at once, and it also distinguishes the three things that look identical from inside a single team: a genuine capacity constraint, a rework loop sending the same item round twice, and a wait for someone outside the process.
The example below is a returns process, which is unusually honest about this. Goods arrive faster than they are inspected, inspection routes four different ways, and half the routes come back through the same remedy decision. Step through it and watch where the work accumulates.
Where a process backs up
A returns process from request to refund. Watch which steps have work arriving faster than it leaves.
The gate that protects the queue
A policy check before an RMA is issued. Gates like this look like bureaucracy and are load-bearing: everything that gets past this point becomes work for the constraint downstream, so a loose gate is a capacity problem in disguise.
The step everything waits for
Goods arrive continuously and inspection is a single step with four possible outcomes. This is the classic shape of a constraint: high arrival rate, one route in, judgement required. If returns are slow, this is where to look before adding people anywhere else.
Three loops that look like volume
Faulty items branch into a repair-or-scrap decision, no-fault-found goes back to the customer, and resaleable stock is restocked. Each is more work created by an earlier decision: mapping them separately is how you tell a capacity problem from a quality one.
The convergence at the end
Every route lands on one remedy decision and then one notification step. Convergence points are secondary bottlenecks: they inherit the arrival rate of every branch feeding them, which is easy to miss when each branch is examined on its own.
How it works
Map the whole flow before measuring anything
You cannot find a constraint by looking at one team's steps, because the queue in front of it is by definition somebody else's problem. Draw the end-to-end flow with lanes first; the shape usually suggests the answer before any data is collected.
Find the queues
For each step, ask how many items are waiting in front of it and how old the oldest one is. Those two numbers identify the constraint faster than any timing exercise, and they are usually available from whatever system already tracks the work.
Separate rework from throughput
Follow every loop in the chart. An item going round twice consumes the constraint twice, so a rework rate of twenty percent is a twenty percent capacity cut. That is a quality problem wearing a capacity costume, and adding people to the constrained step will not fix it.
Mark the waits you do not control
Time spent waiting for a customer, a supplier or a carrier is real elapsed time but not a staffing problem. Put those steps in their own lane so the conversation separates what you can schedule around from what you can actually change.
Check the convergence points
Where several branches merge into one step, that step inherits the arrival rate of all of them. These are routinely missed because each branch looks manageable on its own. The chart makes the convergence visible in a way a per-team report cannot.
Fix, then re-map
Relieving a constraint moves it somewhere else, always. Plan for the second bottleneck before you finish the first: re-walk the map after the change and expect the queue to reappear at the next step with judgement in it.
Mistakes to avoid
Measuring utilisation instead of queues
A busy team may simply be well-staffed for a high volume. The queue in front of a step is the signal; how hard the people are working is not.
Treating rework as demand
Adding capacity to absorb rework is expensive and permanent. Finding out why items come back is cheaper and usually faster.
Optimising a non-constraint
Speeding up a step that already has spare capacity produces exactly nothing except a larger queue at the constraint.
Believing the first answer
The step people complain about is the one they can see. The constraint is often one step upstream of the complaint, quietly setting the arrival rate.
Find your own bottlenecks
Open the returns example as your own chart, replace the steps with yours, and note the queue in front of each one.
Related guides
Frequently asked questions
What is a process bottleneck?
The step in a flow where work arrives faster than it can leave, so a queue forms in front of it and every step downstream runs below capacity waiting. There is one constraint at a time in any flow, which is why bottleneck analysis is more useful than general efficiency work: improving anything else changes nothing about the overall rate. Relieve it and the constraint moves, usually to the next step that requires judgement rather than execution.
How do I find the bottleneck in a process?
Look for where work waits, not where people are busy. Two questions find it: how many items are queued in front of each step, and how old is the oldest one. A process map is what makes those questions answerable end to end, because the queue in front of a constrained step usually sits in a different team from the one that owns the step. Utilisation figures, by contrast, look similar everywhere.
Is a bottleneck the same as a delay?
No, and conflating them sends improvement effort to the wrong place. A bottleneck is a capacity constraint: work arriving faster than it leaves. A delay can also be a wait on an external party, a batching rule that holds items until Friday, or a handoff where the receiver is not notified. Those are fixed by changing the trigger or the schedule, not by adding capacity, and the map is what tells them apart.
What should I do once I have found the bottleneck?
In order: stop feeding it work that should not be there, since a loose entry gate is the cheapest fix; remove the rework loops, because an item going round twice consumes the constraint twice; then take work off it that does not need its particular judgement. Adding capacity comes last, because it is the most expensive option and the constraint will simply reappear at the next step that requires a decision.
