Compressing kaizens — can we, and should we?

A kaizen is a five-day event in which six to ten people examine a process, redesign it to reduce its inefficiencies, test the redesign, and deploy it for use the following week. Each phase of the work takes the time it does for a reason — and the most common question we receive from new clients is whether the time can be compressed.

Most engagements at eta begin with a question along the lines of: could the kaizen run in three days? Two? Could we just send the team to a class? The answer is almost always no, and the reason is worth taking the time to articulate.

We see four typical use cases for kaizens. The first is a particular problem — excessive errors on a line, high turnover at a station, an onboarding process that does not produce competent operators. The second is a particular target — a margin to be improved, an inventory turn to be lifted, monthly throughput to be raised. The third is a problem that requires teamwork: typically several departments needing to coordinate to arrive at a solution, the way engineers must modify component designs to make assembly easier based on feedback from the production team. The fourth is when there is a need for speed and standardisation; processes that rely on tribal knowledge are hard to improve, and a kaizen is the discipline by which they get documented and standardised so that improvement becomes possible at all.

Why, then, do kaizen events take the time they take?

Current-state mapping takes time. Mapping a process step by step, particularly when several people do the same work differently, takes longer than people expect. Teams enjoy this work and it generates many ideas for improvement, but the discipline of fully documenting what is actually happening cannot be hurried.

Identifying pain points through what we call constructive complaining takes time to learn. Seeing what one has learned to ignore, while continuing to get on with daily work, is harder than it sounds. Often there is a wish list of solutions — new software, new tools — but the root causes have been forgotten and turn out to be relatively easy to fix once they are surfaced.

Radical redesign takes time and extended facilitation. Kaizens aim for radical change. Doubling process throughput or reducing the number of tools in use by seventy-five per cent is normal in a successful event, but those stretch goals require facilitation and a change of approach to realise. The alternative is incrementalism, which is what the operation has already been doing — and which is what brought it to the kaizen in the first place.

Implementation and testing takes a day, and then more. Relocating workstations, drafting new process forms, reprogramming robots — even when the changes are carefully curated to be quick to do, they take time. The team also needs to test the changes under real load, which means running the new process for at least a shift before declaring it ready.

Learning to present and thereby commit to something can be a new thing for participants. The closing presentation to leadership matters because it transforms the team’s work into a public commitment. The typical kaizen exceeds its declared targets, which is exciting; but it also brings a sense of ownership that is, ultimately, the thing that makes the change durable.

Kaizens save time by optimising processes. Our recommendation is more kaizens, not shorter ones.

· · ·