MBA Knowledge Library · Operations

Process Mapping and Bottleneck Analysis

When work is late, adding effort everywhere can create more queues instead of more completed output. Map the process first, then measure the step that limits the flow of work through the whole system.

← Operations hub · Browse all resources

What is process mapping?

A process map shows how a defined piece of work moves from a starting event to a finished output. It makes activities, decisions, handoffs, and exceptions visible. A useful map describes what people actually do, including waiting and rework, rather than reproducing an ideal procedure that nobody follows.

Choose a boundary small enough to investigate: “from a complete customer request to approved delivery” is more useful than “improve operations.” Name the customer, the output they need, and the evidence that the work is complete.

Choose the map that fits the question

Use consistent symbols: an activity box for work, a decision diamond for a question, and arrows for direction. Label decision branches clearly. The exact software matters less than a shared interpretation of the map.

A practical mapping procedure

1. Define the unit: one order, invoice, application, or service request.
2. Set start and finish: decide which delays belong inside the boundary.
3. Observe representative cases: include straightforward work and exceptions.
4. Map steps and owners: record systems, approvals, handoffs, and required inputs.
5. Add evidence: timestamps, active minutes, queue size, completion volume, and error rates.
6. Validate with the people doing the work: revise the map when observation contradicts the written procedure.

What is a bottleneck?

A bottleneck is the step or resource that restricts the system’s achievable throughput under the conditions being studied. A visible backlog is a clue, not proof. The queue could reflect a temporary outage, batching, rework, priority changes, or incomplete inputs. Confirm the limiting resource using capacity, arrival rates, and observed output.

Distinguish four measures: processing time is active work per unit; lead time is elapsed time across the defined process; capacity is sustainable output per period under stated conditions; and throughput is the output actually completed. Teams use “cycle time” differently, so define it before comparing reports.

Worked capacity example

A hypothetical service team has 420 productive minutes per person per day, after planned breaks and routine nonprocessing time. Every complete request passes each stage once. Processing times are constant for this simplified example; there is no rework, downtime, or competing workload.

The system’s capacity is bounded by 42 requests per day, the review stage. With 50 new requests per day, the backlog grows by approximately 8 requests per day under these assumptions. Five working days add 40 requests. Making preparation faster will not lift the 42-request review limit.

If a pilot reduces review time from 10 to 8 minutes without weakening quality, review capacity becomes 420 ÷ 8 = 52.5 requests per day on average. At 50 requests of demand, implied review utilization is 50 ÷ 52.5 = 95.2%. The arithmetic suggests enough average capacity, but variability can still produce significant queues. Do not promise zero waiting from this calculation.

A second reviewer would create 84 requests of review capacity, but preparation would then limit the system to 70. When one constraint is relieved, the bottleneck can move. Hiring also changes cost, training, and coordination requirements; it is not automatically the best improvement.

Improve the constraint deliberately

• Protect its time: route complete inputs to the constrained resource and remove avoidable interruptions.
• Prevent rework: improve upstream checks so the bottleneck is not repeatedly fixing known errors.
• Separate work types: investigate whether standard requests and complex exceptions need different routing.
• Test a change: trial a checklist, batch-size change, training, or scheduling adjustment.
• Add capacity when justified: assess demand durability, cost, and the new downstream limit.

Preserve approvals and independent review where the process requires them. Removing a control can increase apparent speed while increasing error or fraud exposure. Measure completed, acceptable output rather than activity alone.

Measure whether the change worked

Before the pilot, establish a comparable baseline. Track arrivals, accepted completions, beginning and ending backlog, lead-time distribution, rework, quality, overtime, and cost. Name the process owner and a review date. Compare similar work mixes and staffing levels; a quiet week is not evidence that a redesigned process performs better.

Common mistakes

• Drawing only the happy path and hiding exceptions.
• Using paid hours as productive capacity without explaining the assumption.
• Assuming the slowest task is always the bottleneck, regardless of staffing.
• Maximizing every person’s utilization and flooding downstream queues.
• Reporting speed gains without quality or rework measures.
• Changing several things at once and claiming a precise causal result.

Frequently asked questions

Your first improvement worksheet

Record the boundary, unit, owners, current map, observed times, demand, capacity by stage, suspected constraint, proposed change, quality safeguards, and success criteria. Review the result with the team before making the pilot the standard process.

Sources and example notes

• ASQ: Flowchart
• ASQ: Process Analysis Tools
• AHRQ: Process Mapping

Conceptual references are linked above. Examples, scorecards, calculations, checklists, and practical recommendations are original educational illustrations. They are not research findings, vendor endorsements, or universal benchmarks. Adapt decisions to actual evidence, policies, and obligations.