Implementation Guide
Kaizen.
Kaizen is continuous improvement in small steps, made by the people who do the work. It only compounds when it runs as a system: a pipeline that captures ideas at the point of work, triages them within a week, implements most of them through the originating team, verifies the benefit, and changes the standard. Count improvements implemented per person per month, not ideas submitted. Without the pipeline, kaizen is a suggestion box that teaches people their ideas go nowhere.
What kaizen is, and what it is for
Kaizen translates roughly as change for the better. On a factory floor it means something concrete: a continuous stream of small improvements, made by the people who do the work, to the work they do. Moving a tool holster so an operator stops reaching. Rewriting a label that gets misread once a week. Adding a drip tray that turns a slip hazard into a thirty-second wipe. None of these is a project. Together, sustained for years, they are the difference between a plant that improves and a plant that erodes.
Kaizen has two halves, and most organizations only build the first. The first half is the ideas, and almost every workforce already has them; ask any operator what is annoying about their station and you will not get silence. The second half is the system: the pipeline that captures those ideas, decides on them fast, gets most of them implemented by the team that raised them, checks that the benefit is real, and writes the result into the standard. Without the second half, collecting ideas is worse than not collecting them, because every idea that disappears into a box teaches its author not to bother again.
A scope note before going further: this page covers the kaizen system, the everyday pipeline that runs all year. The focused improvement week, three to five days on one process with a cross-functional team, is a different tool with its own mechanics and its own guide: kaizen events. Events are one lane inside the system described here, not a substitute for it.
Where kaizen sits in the transformation roadmap
On the TeamGuru deployment roadmap, kaizen is a practice in the Improve stage, after structured problem solving is working and in parallel with the equipment methods. That placement is deliberate, and worth defending: improvement volume is only worth generating once daily management can hold the gains. In a plant without standards and daily boards, an implemented improvement decays in weeks, nobody notices it decayed, and the third time that happens the team stops improving. Build the system that holds gains first; then open the tap.
The three lanes of improvement
Not every idea deserves the same treatment, and forcing them all through one channel is how systems clog. A working kaizen system routes each idea, at triage, into one of three lanes by scope and effort. The point of the lanes is speed: an idea that needs an hour of maintenance time should never wait behind an idea that needs a capital request.
| Lane | Scope | Effort | Who runs it | Example at the 456 units/day plant |
|---|---|---|---|---|
| Daily kaizen | One workstation or the team's own process | Hours to a few days | The team itself, inside its normal week | Move the fitting bins into the operator's reach zone and save four seconds of reaching per cycle |
| Kaizen event | One process, cell or changeover, crossing shifts or functions | 3 to 5 focused days plus 30 days of follow-up | A cross-functional team of 6 to 8 with a facilitator | Cut the machining changeover from 47 to 18 minutes |
| Improvement project | Cross-departmental change, capital, layout, new equipment | Weeks to months | A named owner with a plan and a review rhythm | Merge welding into the assembly cell: one layout change, one moved crane |
Plants tend to collapse into one lane. Event-only kaizen produces a calendar of workshop weeks with an empty pipeline between them. Project-only kaizen turns every idea into a backlog item owned by an engineer. The daily lane is the one that carries the culture, because it is the only lane where the person who had the idea also makes the change.
How to build the idea pipeline
The pipeline below is the heart of the system. Every stage has an owner and a time expectation, because the two ways pipelines die are ideas without owners and ideas without deadlines. Adapt the numbers to your plant; keep the stages and keep them fast.
| Stage | What happens | Owner | Time expectation |
|---|---|---|---|
| Capture at the point of work | The idea is written where the problem lives: a card at the team board, a note in the app, a photo of the awkward reach. Capture the problem and the proposal, not a polished business case. If capturing takes more than two minutes, people will stop capturing. | Anyone in the area | Same shift |
| Triage | Three honest outcomes: do it now, batch it into an event or project, or decline with the reason given in person. Cheap, reversible, local ideas default to yes. A growing triage backlog is the first symptom of a dying system. | Area leader | Within one week |
| Implement small ideas | The team that raised the idea changes its own process, using a small standing materials budget and scheduled maker time. Maintenance and engineering are on call to help, not in charge of doing. | The originating team | Days, two weeks at most |
| Batch bigger ideas | Ideas that cross areas, need capital or would take a team offline are grouped into kaizen events or improvement projects, each with an owner and a date. The originator stays on the team so the idea keeps its author. | Area leader with CI support | Grouped monthly |
| Verify the benefit | A before and after check against the same measure: a timed sample, a counted defect rate, a walked distance. Light is fine. No verification, no claimed benefit. | Idea owner plus area leader | Same week for small ideas, 30 days for large |
| Standardize and share | The standard work sheet, layout drawing or checklist is updated so the next shift and the next hire inherit the improvement, and proven ideas are offered to sister areas. | Team, then area leader | Within days of verification |
Three design choices that decide whether it lives
- Make triage fast and mostly yes. The area leader answers within a week, and the default for cheap, reversible, local ideas is try it. Declines are given in person, with the reason. A no explained face to face costs one conversation; a no by silence costs every future idea from that person.
- Give teams a small budget and maker time. A standing monthly materials allowance the team can spend without asking, and a scheduled hour or two a week to build. Approval friction kills far more improvements than bad ideas ever will.
- Have leaders ask for ideas at the process. The richest capture channel is a leader standing at a station asking what gets in your way every day. Fold the question into gemba walks and the daily routine, and the pipeline never runs dry.
The third point deserves its own habit: the question belongs in the gemba walk question bank of every leader in the plant. Ideas asked for at the process arrive with their context attached, which makes triage nearly instant.
One idea through the pipeline, end to end
An illustrative pass through the system at the 450-person components manufacturer used across this site, whose assembly cell runs at a takt of 118 seconds to meet 456 units a day. On Tuesday an operator writes a card: the fitting bins sit across the bench, and every cycle includes a long reach. Proposal: move the bins to a rail at the reach zone. Thursday, the supervisor triages it yes, daily lane. The following week the team and a maintenance hour mount the rail; total cost, one bin rail and two brackets. The before and after check is a timed sample of ten cycles: 116 seconds average before, 112 after, four seconds of reaching gone from a cycle that must beat 118. The standard work layout sheet is updated the same week and the second shift is walked through it at the board. Elapsed time, card to updated standard: nine working days. Nothing about this example is heroic, which is exactly the point. The system's job is to make this boring and constant.
Verifying benefit without bureaucracy
Verification is where kaizen systems face a fork: skip it and lose credibility, or over-engineer it and lose speed. The way through is to match the rigor to the size of the idea. For small ideas, a before and after observation at the process is enough: ten timed cycles, a counted defect rate over a shift, a tape measure on a walking route. Done the same week, by the idea owner and the area leader together, written in one line.
Larger ideas, the ones that claim money, need rules agreed with finance once, in advance: what counts as a hard saving, how freed capacity is valued, who signs. Agree the rules one time and every future benefit check takes minutes instead of meetings. Tie the recurring claims to metrics the plant already tracks on its KPI baseline, so a claimed improvement should be visible where the plant already looks.
An opinion, held firmly: claim soft savings honestly or not at all. Four seconds saved per cycle is real; four seconds multiplied by every cycle of the year and priced at a loaded labor rate is fiction unless someone actually redeploys the freed time. Say freed 30 minutes of operator time per shift, not saved 40,000 a year. The first inflated claim that finance dismantles takes the whole system's reputation down with it, and the people who submitted honest ideas pay the price.
Measuring the health of the system
Measure the system itself, not just its outputs, and measure it with numbers that resist gaming. Four are enough. For all of them, the trend matters more than the absolute value, because counting rules differ so much between plants that cross-plant comparison mostly rewards creative counting.
| Metric | What it tells you | Honest guidance |
|---|---|---|
| Improvements implemented per person per month | The headline number: how much of the workforce's thinking becomes reality. Count implemented, never submitted. | Young systems often start near 0.1; strong plants exceed 1. The absolute value depends on what you count as an improvement, so benchmark a plant against its own trend, not against another plant's counting rules. |
| Median days from capture to implementation | How fast the pipeline moves, measured at the middle so one stuck idea cannot hide fifty fast ones. | If the median passes a month, triage has become a committee. The first ideas people submit are tests: they are watching what happens to them. |
| Share implemented by the originating team | Who actually does the improving. A rising share means the system belongs to the floor; a falling one means the CI office has quietly taken over. | Above roughly two thirds is healthy in a mature area. Treat it as a direction, not a target to hit by relabeling who did the work. |
| Verified benefit rate | The share of implemented ideas with a checked before and after. This is the credibility metric for everyone outside the area, finance included. | Aim to verify all of them, lightly: a two minute observation counts for a small idea. What kills trust is not small benefits, it is claimed benefits nobody checked. |
Illustratively, at the 450-person plant: 95 improvements implemented in a month is about 0.21 per person per month, with a median of 12 days from card to change and 71 percent implemented by the originating teams. Whether those numbers are good depends entirely on last quarter's numbers. Rising from 0.1 is a healthy system; falling from 0.4 is a sick one, whatever a benchmark table says.
Recognition that does not backfire
Recognize implementation and sharing, not idea counts. The moment submission itself is rewarded, people optimize submission: one improvement arrives as four cards, trivial ideas flood the triage, and the leader who must now decline most of them becomes the villain of a system meant to build trust.
Be especially wary of paying per idea or per calculated saving. Payment invites valuation disputes, valuation disputes require bureaucracy, and the bureaucracy slows the pipeline until the payments are moot. What works is cheaper and lasts longer: reds and wins named at the daily board, a monthly moment where teams show what they changed, the best improvements presented by their authors to plant leadership, and a person's improvement record counting visibly toward development and promotion. People do not need to be bribed to fix what annoys them. They need to be certain the fix will be welcomed, implemented and remembered.
Common mistakes
Every failure mode below is a pipeline stage missing or a stage owned by the wrong person. That is good news: each one has a structural fix, not a cultural lecture.
What bad looks like
- Ideas go into a box, and a committee meets quarterly to score them
- The CI department implements everything while the floor goes back to waiting
- Kaizen happens only during event weeks; between them the pipeline is empty
- Claimed savings finance cannot find in the P&L, so finance stops believing any of them
- Payment per idea produces a flood of split and trivial submissions
What good looks like
- Most ideas are implemented by the team that raised them, within two weeks
- Triage answers arrive in days, and declines come with the reason, in person
- Every implemented idea has a before and after check, however light
- Improvements end as updated standards, not as anecdotes
- The plant tracks implemented per person per month, and the trend is rising
What happens next
An improvement that does not change a standard did not happen; it merely visited. The last pipeline stage exists so every verified idea lands in the documents people actually work from, which is why kaizen leans so hard on standardized work: the standard is both the baseline that makes an improvement measurable and the container that keeps it from evaporating. Improvements proven in one area then spread deliberately, with the receiving team adapting the method and keeping the result, which is its own discipline: yokoten.
The pipeline itself needs a home in the management system, and running it on paper across three shifts is where most plants feel the strain first. This is where TeamGuru fits: the kaizen use case runs capture, triage, implementation and the benefit check as one pipeline with owners and dates visible at every stage, and the bigger batched ideas travel as projects and actions with the same follow-through. On the roadmap, the improvement stream you have built now feeds upward: volume and verified benefits become part of what leadership steers in Obeya and management reviews, where the question changes from are people improving to are we improving the right things.
