# Kaizen

**URL:** https://kaizumi.com/dictionary/kaizen

**Description:** Kaizen is improvement made by the people doing the work, written into the standard so it holds. A cell that writes 60 cards a quarter keeps 9 of them. The hold rate is the number that matters.

**Japanese:** 改善 (kaizen) — "change for the better"

**Category:** lean-principles

**Tags:** problem-solving, culture, foundational

## The unit | What actually counts as one kaizen

Most kaizen programmes cannot say how much kaizen they did last year. They can say how many ideas were submitted, which is a different number and a much less useful one. Before any of the arithmetic on this page works, the unit has to be countable.

A change counts as one kaizen when all three of these are true.

1. **It changed the standard.** Not a good intention, and not a workaround somebody uses on their own. The written method for doing the job is different now.
2. **The people who do the work made it.** An improvement handed down by an engineer or a consultant may be a fine improvement. It is not a kaizen, because the capability it builds leaves with the person who leaves.
3. **It survived.** Re-check it at six months. If the cell has drifted back to the old method, the kaizen was an event, not a change.

Take one twelve-person assembly cell over a quarter. The team writes `60` improvement cards. `23` of them change standard work and get implemented. At the six-month re-check, `9` are still being done the new way.

```kz-tiles
lead: Holding
tile: Written | 60 | cards
tile: Implemented | 23 | changes
tile: Holding | 9 | at 6 months
```

Three numbers, and only the last one is kaizen. `9` changes across `12` people is `0.75` per person per quarter, or about `3` per person per year. That is a real and fairly unremarkable figure — and it is the one almost nobody reports, because it is the only one that requires going back six months later to look.

```kz-figure
id: idea-funnel
caption: The two drops are different problems. 60 to 23 is a response problem. 23 to 9 is a standard-work problem. A programme that only counts the left-hand bar cannot tell them apart.
wide: true
```

The `60` is the easiest figure to collect and the easiest to inflate. Run a campaign, put up a poster, and the card count doubles inside a month. Neither of the other two numbers moves, because neither of them is about how many ideas people have.

## The arithmetic | Why the conversion rate beats the idea count

Two things happen to an idea between the card and the standard. It gets implemented, or it does not. Then it holds, or it does not. Multiply the two and you have the only rate that matters.

```kz-formula
expr: Kaizens per person =
expr: Ideas × Implementation rate × Hold rate ÷ People
var: Ideas | **Cards written in the period.** The number every suggestion scheme already collects, and the one it over-weights.
var: Implementation rate | **Share that reached the standard.** Set almost entirely by how fast a card gets an answer, not by how good the ideas were.
var: Hold rate | **Share still being done at six months.** Set by whether standard work was rewritten, and by who rewrote it.
var: People | **Everyone the programme covers**, including the ones who wrote nothing. Dividing by contributors only flatters the result.
```

Two programmes, both twelve people, both running a full year.

```kz-compare
leftTitle: Programme A — the box
left: `300` cards a year, `25` per person
left: `8` percent implemented — `24` changes
left: `38` percent still holding at six months
left: Cards answered by a monthly committee, median reply `31` days
left: Standard work rewritten by the CI office, when it gets to it
left: **`9.1` kaizens a year. `0.76` per person.**
rightTitle: Programme B — the board
right: `90` cards a year, `7.5` per person
right: `78` percent implemented — `70` changes
right: `62` percent still holding at six months
right: Cards answered at the daily huddle, median reply `1` day
right: Standard work rewritten by the team, same shift as the change
right: **`43.5` kaizens a year. `3.6` per person.**
```

Programme A collects `3.3` times as many ideas as Programme B and delivers about a fifth as much change. Per card, A converts at `0.08 × 0.38 = 0.0304`. B converts at `0.78 × 0.62 = 0.4836`. That is a **`16`-times gap in conversion**, and it swamps the idea count completely.

Run it the other way and the size of the gap becomes obvious. For Programme A to land where Programme B lands, at A's conversion rate, it would need `43.5 ÷ 0.0304 = 1,431` cards a year. That is `119` per person, one every other working day, from twelve people who currently write `25`.

```kz-callout
tone: warn
title: No campaign closes a 16× conversion gap.
p: The instinct when kaizen output is low is to ask for more ideas — a poster, a target, a competition with a prize. It works: card counts do rise. Conversion does not move, because nothing about the reply time or the standard changed.
p: Both of A's weak numbers are mechanisms, not attitudes. `8` percent is what a `31`-day reply teaches people. `38` percent is what happens when the standard is rewritten by somebody who does not work in the cell.
```

Reply time is the lever nobody costs properly. A card answered the next day gets implemented by the person who wrote it, while they still remember why. A card answered in `31` days gets implemented by nobody, and the twelfth unanswered card is the last one that person writes.

## The ratchet | What standard work is actually for

The hold rate is not a measure of discipline or enthusiasm. It is a measure of whether a mechanism exists, and [standard work](/dictionary/standard-work) is the mechanism. Without it a gain decays, and it decays fast enough to measure.

One kaizen in the cell: an operator moves the parts feed so the reach is shorter. The station was `46.0` seconds. It is now `37.0` seconds — `9.0` seconds off. The cell builds `520` units a day.

```kz-pass
title: Pass 1 — the change, no new standard
step: Day 0, re-timed over 20 cycles = **37.0** s
step: Day 90, re-timed over 20 cycles = **43.5** s
out: `2.5` of the `9.0` seconds left. Worth `22` minutes a day, not `78`.
```

```kz-pass
title: Pass 2 — standard rewritten the same shift
step: Day 0, re-timed over 20 cycles = **37.0** s
step: Day 90, re-timed over 20 cycles = **37.2** s
out: `8.8` of the `9.0` seconds left. Worth `76` minutes a day.
```

Nothing went wrong in Pass 1. Nobody was lazy and nobody sabotaged anything. Three people rotate through that station, two of them learned the job before the change, and the written method they were taught from still described the old reach. Over ninety days the cell converged on the method that was written down, which is exactly what a standard is for. It just happened to be the wrong one.

The gap between the two passes is `54` minutes a day. Across `240` working days that is `216` hours from a single change — more than the change itself was ever worth, because it is the difference between owning the gain and renting it.

```kz-figure
id: ratchet
caption: The same improvement, twice. The pawl is the rewritten standard: it does not make the step bigger, it stops the step coming back.
wide: true
```

This is why a kaizen programme without standard work has a low hold rate no matter how good its ideas are, and why the fix for a `38` percent hold rate is never a better suggestion form. Rewriting the standard costs about twenty minutes. It is the cheapest part of the whole change and the only part that decides whether the change still exists next quarter.

```kz-callout
tone: note
title: Rewrite it in the cell, on the shift.
p: The rewrite has to happen while the change is fresh and the people who made it are standing there. Sent to a CI office to be typed up properly, it joins a queue, and the queue is where hold rates go to die.
p: A [standardized work combination table](/tools/swct) drawn on paper at the bench beats a perfect document that lands three weeks later.
```

## Scale | Daily kaizen, kaizen events and kaikaku

People compare one kaizen to one transformation project, conclude kaizen is trivial, and stop. The comparison is wrong, because the two run on different clocks and the arithmetic only works when each is allowed to run its own.

| | Daily kaizen | [Kaizen event](/dictionary/kaizen-event) | [Kaikaku](/dictionary/kaikaku) |
|---|---|---|---|
| Typical size | `2`–`15` s of work content | `20`–`40` percent of a cell's cycle time | A new line or a new layout |
| How long | This week | `5` days, `8` people off the line | `6`–`9` months |
| Who decides | The team, at the board | A chartered team with a sponsor | Executive, with capital |
| Cost | Effectively zero | About `200` person-hours | Capital budget |
| How often | Continuously | `2`–`6` times a year per area | Once every few years |

Programme B's `43.5` holding kaizens a year, at a modest `4` seconds each, take `174` seconds out of the cell's work content. That is a substantial change to a cell, delivered with no capital, no project team and no downtime — and it arrives in `43` pieces, none of which was ever worth a meeting.

**[Kaikaku](/dictionary/kaikaku)** — radical change, the deliberate opposite of kaizen — buys a step that no amount of incremental work would reach. A new layout, a different process technology, a line designed for a product that does not exist yet. The step is real, and the two are not in competition.

```kz-figure
id: two-curves
caption: The dashed line is a kaikaku with no kaizen behind it. The step is real, and it decays for exactly the reason Pass 1 decayed, on a longer clock.
wide: true
```

The failure worth naming is that dashed line. A kaikaku installs a new standard for everybody at once, and then nothing keeps it. Twelve months later the line is running to methods nobody wrote down, and the step that was paid for in capital has quietly given back a third of itself. Kaizen after kaikaku is not optional polish; it is the pawl again, on a bigger step.

<!--GAME:busy-work-->

## The cycle | One kaizen, run as PDCA

[PDCA](/dictionary/pdca) is the loop one kaizen runs in. Written out on the `9`-second change, the useful part is the cycle that failed — which is the cycle almost every teaching example leaves out.

```kz-pass
title: Cycle 1 — move the bins
step: **Plan** — walking timed at `9.0` s per unit across 20 cycles
step: **Do** — bins moved to the far side of the bench, one shift
step: **Check** — re-timed at `44.0` s. `2.0` seconds, not `9.0`
out: **Act** — abandon it. The bin move put the fixture out of reach and added a turn. Nothing is written into the standard.
```

```kz-pass
title: Cycle 2 — feed by gravity
step: **Plan** — a chute from the rack over the bench; the bins stay where they are
step: **Do** — chute fitted in one shift from stock parts
step: **Check** — re-timed at `37.0` s across 20 cycles. `9.0` seconds
out: **Act** — standard work rewritten that shift, three operators re-taught, the check added to the team leader's audit round.
```

Cycle 1 is not a wasted week. It is the programme working. A two-second reading on a `46`-second station timed over twenty cycles sits inside ordinary variation, so the honest reading of Cycle 1 is *no measurable effect*, and the honest response is to stop rather than write it up as a win. A kaizen programme in which nothing ever fails a Check is not measuring; it is collecting testimonials.

Two rules make the Check worth running. Time the same number of cycles before and after, because a five-cycle before against a twenty-cycle after compares a sample to a different sample. And re-time it with the operators who were not there when the change was made, because a method that only works for its inventor will not survive a rotation.

One kaizen fits on one side of paper. The [A3](/dictionary/a3-problem-solving) is the format that keeps the Check honest, because it puts the before and after measurements on the sheet where the countermeasure has to sit next to them.

<!--TOOL:a3-->

## Failure modes | Five ways a kaizen programme dies

Every one of these shows up as a low implementation rate or a low hold rate, so the arithmetic in the second section will find them. Naming them is faster.

**The box with no reply loop.** This is Programme A. A card that gets no answer within a week has taught the person who wrote it what the system is for, and that lesson holds much better than any of the improvements do. Reply time is the highest-leverage number in the programme, and it is free to fix.

```kz-callout
tone: warn
title: The moment kaizen banks a saving as a job, it stops.
p: A cell that finds `216` hours a year has just made a case for cutting a post. Do that once and the arithmetic on this page collapses to zero, permanently, because nobody in the cell can be argued back into it.
p: This is why the Toyota system rests on a promise about redeployment rather than on enthusiasm, and why [respect for people](/dictionary/respect-for-people) sits beside continuous improvement as a pillar rather than as a value statement. The saving has to land as capacity, not as headcount.
```

**Events with no follow-up.** A five-day event returns roughly `200` person-hours and an action list, and the list is the part that decays. An event whose actions are `60` percent closed at thirty days was a workshop with a good lunch.

**Kaizen done to people.** Improvement designed by a specialist and installed in a cell fails the second test in the first section. It may well be a better improvement than the team would have made. It builds no capability, and it holds like Pass 1, because the people asked to keep it never chose it.

**Counting the wrong thing.** Publishing card counts makes card counts go up. Publish the hold rate instead and you get a smaller, uglier number that responds to the things actually worth fixing. See [muda](/dictionary/muda) for what the changes should be aimed at once the mechanism works.

**No gemba.** Ideas written away from the work are ideas about the work as remembered, which is why implementation rates for cards written in a meeting room run so far below cards written at the bench. Improvement follows [gemba](/dictionary/gemba); it does not lead it.

## Questions | Kaizen questions people ask

```kz-qa
q: What is kaizen?
a: Improvement made by the people who do the work, small enough to test in a week, and written into standard work so it survives. Counted properly, one kaizen is one change that reached the standard and was still being done six months later — not one idea submitted.
q: What is the difference between kaizen and continuous improvement?
a: [Continuous improvement](/dictionary/continuous-improvement) is the outcome; kaizen is the specific practice that produces it. In everyday Japanese, 改善 simply means "improvement" with no methodology attached — the narrower sense used here is a Western borrowing.
q: How do you measure kaizen?
a: Kaizens per person per year, where one kaizen is one change still holding at six months. `Ideas × implementation rate × hold rate ÷ people`. A twelve-person cell writing `90` cards at `78` percent implemented and `62` percent holding scores `43.5` a year, or `3.6` each.
q: What is a good implementation rate?
a: Above about `70` percent, and it tracks reply time almost exactly. Programmes answering cards at a daily huddle run in the seventies and eighties; programmes answering at a monthly committee run under `10` percent. Idea quality is not what separates them.
q: What is the difference between kaizen and a kaizen event?
a: Size and clock. Daily kaizen changes `2`–`15` seconds of work content this week at no cost. A [kaizen event](/dictionary/kaizen-event) is a chartered five-day team, around `200` person-hours, targeting `20`–`40` percent of a cell's cycle time. A programme that only runs events has no daily kaizen.
q: What is kaikaku?
a: [Kaikaku](/dictionary/kaikaku) is radical change — a new line, a new layout, a different process technology, on a six-to-nine-month clock with a capital budget. It is the deliberate opposite of kaizen and not a competitor to it. A kaikaku with no kaizen behind it gives back part of its step for exactly the reason an unstandardized improvement does.
q: Does kaizen mean only small changes?
a: The changes are small; the total is not. Forty-three holding changes at `4` seconds each take `174` seconds out of a cell's work content in a year, with no capital and no downtime. The constraint is that each one has to be small enough to test and reverse inside a week.
q: How is kaizen different from Six Sigma?
a: [Six Sigma](/dictionary/six-sigma) attacks variation with a trained specialist, a chartered project and statistical tools, on a months-long [DMAIC](/dictionary/dmaic) clock. Kaizen attacks waste with the people already in the cell, on a weekly clock. Use DMAIC when the cause is genuinely unknown and the data is expensive; use kaizen when the team can already see the problem.
q: Where does the word come from?
a: 改 (kai, change) and 善 (zen, good) — "change for the better". Its use as a named improvement practice grew out of the Training Within Industry programmes, particularly Job Methods, taught in Japan during the postwar occupation and then developed far past the original by Japanese manufacturers.
```

Source: https://kaizumi.com/dictionary/kaizen
Licence: free to quote and cite with attribution to Kaizumi.