The Kaizen That Evaporated

What held and what did not

The 60% travel distance reduction survived because it was a physical change: the layout is the layout, and nobody had to remember anything. The 0.9-hour cycle time gain did not survive because it was a behavioural change resting on three practices - the release rule, the standard work, and the visual review - each of which required a person to choose it again every shift. Physical changes are self-sustaining; behavioural changes are only as durable as their daily reinforcement.

The specific failure points:

1. No named successor. Ownership sat with two individuals and left with them. Standard work needs an owner who is on the floor, not a document.
2. No daily management. The board stopped being updated in June - meaning nobody was looking at the metric daily. The regression was detectable in June and was discovered in August. That is a two-month detection lag, and it is the most damning finding in the case.
3. No leader standard work. Supervisors had no defined routine that included checking the release rule. When peak hit, reverting was rational for the supervisor and invisible to management.
4. No re-entry rule. Reverting under pressure is not the failure; not coming back is. There was no written condition - "batch release is permitted only when backlog exceeds X, and is reviewed at the Monday meeting" - so the exception became the standard.

What March should have produced: named process owner plus a trained backup; a ten-minute daily stand-up at the board with cycle time posted and a defined response when it misses; supervisor standard work including a daily check of the release rule; and an explicit, documented exception protocol with an expiry.

Recommendation: fix fulfillment first, then run returns - but treat "fixing" as a 30-day sustainment package, not a second event.

The case for it:

• The organisation has just proved it cannot hold a gain. Fulfillment gave back 0.9 of the 0.9 hours achieved - a 100% loss of the benefit in five months. Running a second event applies the same method through the same missing sustainment system, so the expected value of the returns event is roughly (returns opportunity) × (probability of holding). That probability has just been measured, and it is low.
• The fix is cheap relative to an event. A daily ten-minute review, a named owner, supervisor standard work, and an exception protocol cost meetings, not capital. It is the highest return available per unit of effort in the plant right now.
• It changes what the second event is worth. If sustainment works on fulfillment, the returns event inherits a working system. If it does not, the plant learns that before spending its one event.

The strongest case against:

• Returns may be a larger and more visible cost than 0.9 hours of cycle time in fulfillment, and delaying it for a governance exercise forfeits real money. Cycle time is also a proxy - if the 4.2-hour figure is not tied to a customer-facing or cost outcome, the regression may be worth less than it looks.
• Momentum and morale matter; a plant that pauses improvement to write procedures can read as bureaucracy, and the associates who ran the March event may disengage.
• The fulfillment regression may be partly a staffing decision (both owners transferred) rather than a repeatable systems failure. If so, one countermeasure - backfill ownership - solves it, and a 30-day package is overkill.

How I would resolve it: ask two questions before committing. Is the returns opportunity large enough that a 50% chance of holding it beats a near-certain fulfillment recovery? And can fulfillment be stabilised in 30 days with a light package? If the answers are "no" and "yes," run returns in Q4 with a sustainment plan designed in from day one - including the owner, the daily review, and the exception rule written during the event, not after it.