The Improvement That Made the Bottleneck Worse
A team is improving a three-step assembly process: Step A (cycle time 4.0 min), Step B (6.5 min), Step C (5.0 min). Demand is 7 units/hour; the line currently produces about 6.2 units/hour and uses overtime to meet demand. Step B is clearly the bottleneck. The team's improvement ideas include: (1) add a second operator to Step A to cut its cycle time to 2.5 min; (2) run a kaizen on Step B to reduce changeover and eliminate a walk; (3) add a buffer of WIP between B and C; (4) buy a faster machine for Step C. The team has budget for one initiative this quarter and is under pressure to show a quick win. Step A's operator is enthusiastic about idea 1 and has already begun rearranging the workstation.
1. Evaluate each of the four ideas against the system constraint and recommend which to fund.
Read the worked answer
The system throughput is governed by the bottleneck, Step B at 6.5 min/unit (≈9.2 units/hour theoretical, but actual output is 6.2 units/hour, so there is additional loss - likely starvation/blocking or downtime). The demand is 7 units/hour, so the gap is real but modest.
Idea 1 - second operator at Step A (4.0 → 2.5 min). Step A is not the constraint. Improving a non-bottleneck increases its capacity but does not raise system throughput; it only builds WIP in front of B. This is the classic 'improving the wrong step' error. It will show a local productivity gain and no system gain. Reject.
Idea 2 - kaizen on Step B. Directly attacks the constraint. Reducing changeover and eliminating a walk increases B's effective capacity, which raises system throughput. This is the only idea that can move the system metric. Fund.
Idea 3 - buffer between B and C. A buffer protects B from blocking by C. If C is sometimes slow enough to block B, a buffer could help - but C's cycle time (5.0) is faster than B's (6.5), so C should not be the blocker unless it has high variability or downtime. This is a possible secondary action, not the first. Defer; investigate C's downtime first.
Idea 4 - faster machine at Step C. C is not the constraint. Same error as idea 1. Reject for now.
Recommendation: Fund idea 2. Before or alongside it, measure B's downtime, changeover time, and starvation/blocking to confirm where B's 6.5 min is actually going - the theoretical 9.2 vs. actual 6.2 gap suggests B is losing more time than the cycle time alone explains.
2. The team wants a quick win and the Step A operator has already started rearranging. How do you handle this?
Read the worked answer
Handle it in three moves: stop the wasted work, redirect the energy, and protect the relationship.
- Stop the rearrangement respectfully. Talk to the operator privately. Explain the constraint logic in their terms: 'Step A is already faster than Step B, so making A faster just piles parts in front of B. The line won't ship more units.' Show the numbers. Most operators accept this quickly when the logic is visible.
- Redirect the energy to the constraint. The operator's enthusiasm is an asset. Offer them a role in the Step B kaizen - e.g., help observe B, time changeovers, or join the kaizen event. This converts a potential demotivation into contribution.
- Give the team a legitimate quick win. A quick win does not have to be a capital project. A one-week kaizen on B (5S at the changeover point, move the walk out of the cycle, standardize the setup) can show measurable throughput gain within the quarter. Frame the quick win as 'we improved the step that actually limits us,' which is a better story than a local productivity gain.
- Address the process gap. The fact that work started before the analysis was complete is a team-discipline issue. Agree a simple rule: no implementation until the team reviews the data. Do this as a team norm, not a reprimand.
- Communicate upward. Tell the sponsor the plan and why the quick win is on B, not A, so the 'quick win' expectation is managed before it becomes a surprise.
3. After the Step B kaizen, B's cycle time drops to 5.5 min but output only rises from 6.2 to 6.5 units/hour. What does this tell you and what would you investigate next?
Read the worked answer
The gain is real but far below what the cycle time change predicts. At 5.5 min, B's theoretical capacity is ~10.9 units/hour; output rose only 0.3 units/hour. That gap means B is not realizing its new capacity - the constraint has either moved or B is losing time for reasons other than cycle time.
What it tells us:
- The original 6.5 min cycle time was not the whole story; B was also losing time to downtime, starvation, or blocking.
- Reducing B's cycle time may have exposed a new constraint downstream (C at 5.0 min is now close to B's 5.5) or upstream (A at 4.0 should be fine, but material supply may not be).
- There may be a policy constraint (batch sizes, shift patterns, inspection gates) that caps output regardless of step capacity.
What to investigate next:
- Re-identify the constraint - measure actual cycle time and wait time at each step now. Is B still the bottleneck, or has it moved to C or to a shared resource?
- Measure B's time losses - downtime, changeover, starvation (waiting for A), blocking (C not ready). A simple time log for one week will show where the 5.5 min is being lost.
- Check the WIP and flow - is there a pile-up in front of B or C? Where are parts waiting?
- Check policy constraints - batch sizes, inspection frequency, shift handover losses.
- Re-baseline the system metric - if output is now 6.5 vs. demand 7, the remaining gap is small; a focused effort on the new constraint may close it quickly.
The lesson: after relieving a constraint, always re-identify it. The bottleneck moves, and the next improvement must follow it.