How to identify bottlenecks in a process

A worked example, stage by stage

1. 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.

2. 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.

3. 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.

4. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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.