Identifying Bottlenecks

Who this is for

You are a Business Analyst mapping processes in BPMN and need to spot where work piles up, customers wait, and teams struggle. This subskill helps you find the true constraint and suggest practical fixes.

Prerequisites

• Basic BPMN: tasks, events, gateways, lanes, message flows
• Know cycle time, throughput, and work-in-progress (WIP)
• Comfort with simple arithmetic for rates and capacities

Why this matters

Real tasks you will do:

• Annotate BPMN with timings and volumes to find the slowest step
• Explain why queues form and what to change first
• Estimate impact (minutes saved, capacity gained) before stakeholders invest
• Prioritize fixes across teams without local sub-optimizations

Concept explained simply

A bottleneck is the step where demand consistently exceeds capacity, so work waits. In BPMN, it often shows up at tasks after a merge, before a specialized role, or around rework loops and waiting events.

How to spot bottlenecks in BPMN

1. Scope clearly: Mark start and end events you are analyzing.
2. Annotate the map: For each task, note average handle time, resources, hours of availability, arrival volume.
3. Check capacity vs demand: Capacity ≈ (available hours × number of resources) ÷ handle time. Compare to arrival rate.
4. Check gateways: After a parallel split, each branch must have sufficient capacity. After merges, watch for queues before the next single lane.
5. Find waiting and rework: Timers, message waits, and error loops often hide delays.
6. Look at variability: High variability steps cause intermittent queues even if averages look okay. Prefer percentiles (e.g., P80) over only averages.

Worked examples

Example 1: Loan approval

Data per hour: 30 applications arrive. Tasks:

• Data entry: 3 clerks × 0.08 h/app ≈ 37.5 cap/hr
• Credit check (specialist): 1 analyst × 0.25 h/app = 4 cap/hr
• Auto-decision gateway: 40% auto-approve; 60% to manual review
• Manual review: 2 analysts × 0.5 h/app = 4 cap/hr

Flow: 30 arrive → after credit check (4/hr capacity) queue forms. Manual review gets 60% of 30 = 18/hr, but capacity is 4/hr, so even bigger queue. Bottleneck: manual review. Fixes: tighten auto-decision rules to reduce manual load; add analysts; triage simple cases to a faster lane.

Example 2: E-commerce returns

20 returns/hour. Steps:

• Receive package: 2 workers × 0.1 h = 20 cap/hr
• Quality inspection: 1 worker × 0.3 h ≈ 3.3 cap/hr
• Refund processing (system): 60 cap/hr

Queue before inspection explodes because 20 > 3.3. Bottleneck: inspection. Fixes: parallelize inspection stations; pre-triage low-risk items to spot-check; standardize to cut handle time to 0.2 h (raising capacity).

Example 3: IT service desk

Tickets: 12/hr. Steps:

• Triage: 1 agent × 0.1 h = 10 cap/hr
• Auto-solve (script): 5/hr siphoned off
• Specialist queue: 2 specialists × 0.4 h = 5 cap/hr

Effective demand for specialists ≈ 12 − 5 = 7/hr, capacity 5/hr → queue grows there. Bottleneck: specialists. Fixes: expand automation to 7/hr, or add 1 specialist (capacity to 7.5/hr), or introduce a swarming policy for spikes.

Step-by-step playbook

1. Map the current state BPMN with lanes and gateways.
2. Attach data labels: arrival rate, handle time, % split at gateways, rework rate, resource counts, availability hours.
3. Compute each task’s hourly capacity and utilization (util ≈ demand ÷ capacity). Flag util > 85% as risky.
4. Trace token flow through splits/merges to estimate branch demand.
5. Validate with observed queues and SLA breaches.
6. Prioritize bottlenecks by impact (delay, cost) vs effort (people, policy, tooling).
7. Draft countermeasures: eliminate, simplify, parallelize, automate, add capacity, reduce variability, change batch size.
8. Simulate small changes on the map (what-if) and communicate expected gains.

Common mistakes

• Optimizing non-bottlenecks: speeding a fast step doesn’t fix the queue.
• Using only averages: ignores spikes; check P80/P90 times when possible.
• Ignoring merges: branches may be fine alone but jam at a merge before a single resource.
• Misreading rework: frequent loops mean hidden demand; include it in capacity math.
• Forgetting availability: lunch, meetings, outages reduce real capacity.
• Counting touches not waits: the pain is usually in queues, not handle time.

Exercises

These mirror the exercises below. Do them here, then open the solution when ready.

Exercise 1: Spot the bottleneck from data

Given: 24 items/hour arrive.

• Task A (2 clerks, 0.15 h each)
• Exclusive gateway: 50% to Task B, 50% to Task C
• Task B (1 specialist, 0.4 h)
• Task C (1 specialist, 0.3 h)
• Merge then Final Approval (1 manager, 0.5 h)

Question: Which element is the bottleneck and why? Suggest one fix.

Exercise 2: Gateway-induced congestion

A parallel gateway splits work equally into three tasks D, E, F. Capacities are: D = 8/hr, E = 8/hr, F = 4/hr. Arrival is 12/hr. After the split, where does WIP build and what BPMN tweak helps without adding people?

Practice checklist

• I annotated each BPMN task with handle time, resources, availability
• I computed capacity and compared to arrival on every branch
• I examined merges and rework loops
• I identified the single slowest step and the next constraint
• I proposed at least two countermeasures with expected impact

Practical projects

1. Choose one live process (e.g., onboarding). Build a BPMN current state with data annotations. Identify the bottleneck and propose three fixes with rough ROI.
2. Take a process with a timer wait. Redesign to parallelize prep work during the wait. Estimate cycle time reduction.
3. Create a simple what-if analysis: show how adding 1 resource at the bottleneck changes throughput and where the next bottleneck appears.

Learning path

• Before: BPMN basics → Data collection for processes
• Now: Identifying Bottlenecks
• Next: Prioritizing Improvements, Simulation/What-if, Designing Future State BPMN

Next steps

• Run the quick test below to check understanding. Everyone can take it; only logged-in learners will see saved progress.
• Apply one countermeasure in a small pilot and observe changes in WIP and cycle time.
• Update your BPMN with learned parameters and note the new constraint.

Mini challenge

You have a process where arrival is 10/hr. After a gateway, 70% go to a task with 1 person at 0.5 h per item; 30% go to a task with 1 person at 0.25 h per item. There is a merge and then a final task at 0.33 h per item with 1 person. Identify the bottleneck and one no-cost change to ease it.