Kaikaku: when a process needs redesign, not another small fix

Kaikaku translates roughly as reform or radical change. In lean it means a large change to a value stream, the chain of steps that creates a product or service. It looks at the full flow, not one team.

Picture an illustrative manufacturer whose parts move between machining, preparation and assembly departments in large batches. Better scheduling would help. The bigger move is to build a compact cell for one product family so parts flow from step to step. That changes the operating model, not just a task. The move from batch processing to single-piece flow is the classic kaikaku example.

Five signs suggest an effort is kaikaku rather than kaizen:

Both aim at better results, at different levels of change:

These are patterns, not hard rules. A kaizen event can produce a big change in a week. The test is the design choice: adjusting a checklist is kaizen; replacing a chain of approvals with a different model is closer to kaikaku.

Most organizations need both. A redesigned onboarding flow with one case owner may cut duplicate data and transfers, and then staff find unclear instructions and uneven workload in the new flow. That list is the next round of kaizen, not proof the redesign failed. Pick the least disruptive step that can close the gap, and stay open to a bigger change when local fixes keep falling short.

Consider a redesign when the structure of the process seems to block an important need. Start from a clear gap between today's results and the required ones, not a wish to transform:

• Problems cross several functions: Requests move between teams, and no single team can fix the end-to-end delay.
• Local gains do not close the gap: Tasks get faster while customers wait just as long.
• The process rests on old assumptions: A flow built for standard orders no longer fits varied ones.
• Work keeps coming back: Missing information, split ownership or broken decisions are built into the design.
• The required service is different: A new delivery promise may need a new flow, not more effort in the old one.

For each, write the suspected structural limit and the evidence you need. Too many handoffs is a hypothesis. Trace real cases to see which handoffs cause delay and which add needed expertise.

1. 1

   Nobody can explain the current process. Map it first.

2. 2

   There is no baseline. You will not be able to tell whether the redesign helped.

3. 3

   The people doing the work are not involved. They know the exceptions the design must handle.

4. 4

   The main reason is copying a competitor. Different needs and limits can call for different answers.

5. 5

   The goal is vague. More efficient does not say whether speed, quality, capacity or effort matters most.

1. 1

   Define the problem and boundaries. Separate the gap from the chosen fix. Customers get uneven finish dates because work waits between planning, preparation and sign-off is a problem statement; we need a new system is not. State where the process starts and ends, what is in scope and which checks or contract duties must stay. Name one owner for the whole flow.

2. 2

   Observe the work directly. Go to the gemba, watch real cases, including exceptions, and ask what people do when the written process does not fit. Treat workarounds as evidence of missing information, decisions or system rules, not as blame.

3. 3

   Describe the future operating model. Who receives the work, what information they need, how they decide and when they escalate. Make it concrete enough to walk a real case through. Define the work before choosing the technology.

4. 4

   Test on a small scope. One product line, request type or customer group. Set the scope, readiness needs, acceptance criteria, escalation path and how unfinished and urgent work will be handled during the move. Run it as a PDCA cycle.

5. 5

   Prepare people and manage the move. Role-based preparation: what changes, why, which decisions move and where to get help. Have people run one normal and one hard case before launch, and check access, instructions, cover and escalation together.

6. 6

   Stabilize and keep improving. Compare the real work with the planned design, track open issues with owners and separate launch problems from design flaws. Write the agreed method into standard work, then let kaizen improve it.

Three illustrative cases, each with a small fix and a redesign:

1. 1

   Buying technology is kaikaku. A tool that leaves the same approvals, queues and rework in place has not changed the work.

2. 2

   Big spending proves a new flow. The size of the budget says nothing about the design.

3. 3

   Radical means chaotic. A redesign still needs a clear problem, a test and a plan for the move.

4. 4

   Small improvement is a lesser option. When no structural change is needed, kaizen is the right answer.

5. 5

   Launch proves success. Results in normal and busy periods do.

A proposal should show the path from design change to gain. Cutting duplicate entry should cut rework and errors; giving a case owner the right information should cut back-and-forth; connecting steps should cut waiting. For each gain, note the design feature, the evidence needed and what could block it, plus the costs: preparation, training, transition support and any temporary drop in capacity.

Set the measures during scoping, with fixed start points, end points and formulas:

Review results in normal and busy periods. A quiet stretch, an easy mix or extra launch support can make early results look better than they will stay.

Give each of these an owner:

Kaikaku earns its place by creating more value with less waste, not by looking dramatic. Start with a clear customer problem, study the connected flow, make the future design concrete, test it and measure the whole result.