Kaizen examples: eight real cases, and what an office team can take from each
By KaizenProof · Updated · Last reviewed
In short
Kaizen examples are worth reading only when the organisation published what it changed and what happened, so this page keeps to eight that did: Toyota's suggestion system, a Seattle hospital, a machine maker, a software services firm, two US state permit offices, the City of Denver and the UK tax authority. Five of the eight are office, service or knowledge work.
Each case gives the problem, the kaizen practice used, the result as the organisation, its auditor or its researchers reported it, and the one lesson an office team can take. Every figure has a numbered source. The organisations are cited from public sources: none of them is a KaizenProof customer, none has reviewed this page, and their results are theirs, not a forecast of yours.
What do these kaizen examples have in common?
None of them started with software or a slogan. Each started with a specific, recurring problem in the work, named by the people who did it, and a change small enough to try. The table puts the eight side by side; the cases below give the detail and the source for every figure.
Three cases from making things and caring for patients. They are the ones most often retold, and each is retold here only as far as its own sources go.
Toyota: the Creative Idea Suggestion System
Toyota Motor Corporation · Car manufacturing, Japan · From 1951
The problem
A car maker that wanted improvement to come from everyone doing the work, not only from engineers. Toyota Times, Toyota's own publication, says the company's kaizen spirit has its roots in this suggestion system.
What they did
A standing suggestion system, set up in May 1951 by managing officers Eiji Toyoda and Shoichi Saito on the model of the suggestion system at Ford; the first suggestions were put in place in June 1951. Employees are asked to make a habit of noting down problems they meet in their daily work. Ideas are scored for their effect and rewarded, and in 1982 Toyota dropped its company-wide target for the number of suggestions.
What they reported
Toyota's history records the total passing one million suggestions in 1974, ten million in 1984 and 40 million in August 2011. Toyota Times reports about 810,000 suggestions in 2023, or 14.4 per person over the year among plant technical staff, and says they are mostly small: moving a trash can so nobody has to walk around it counts.[1][2]
The lesson for an office team
The volume comes from small ideas about one's own work, written down when they happen. A team that waits for a big project gets few; see small improvements, every week.
Virginia Mason: the Toyota Production System in a hospital
Virginia Mason, Seattle · Healthcare · From 2002
The problem
A health system that wanted to improve safety, quality and cost at the same time, in work whose processes, its chief executive later wrote, were full of defects and waste.
What they did
About 30 executives spent two weeks in Japan in 2002 studying the Toyota Production System, and the hospital adapted it as the Virginia Mason Production System. Every leader is trained in it and must lead formal improvement events each year. Workshops last two to five days, and their improvements are measured and reported at 30, 60 and 90 days afterwards.
What they reported
Its chief executive, Gary Kaplan, reported in 2012 that the time to report lab test results to the patient had been cut by more than 85 percent, and that $11 million of planned capital spending had been saved by using space better. After nursing teams redesigned their work in 2005, steps walked per day fell from 10,000 to roughly 1,200, and the share of nurses' time spent with patients rose from 35 percent to more than 90 percent. These are the organisation's own figures.[3][4]
The lesson for an office team
Many of the gains were in the flow of work and information, not in clinical skill: a lab result waiting to be sent is a hand-off like any other. Go and see how the work is really done before redesigning it.
Lantech · Wrapping-equipment manufacturing · 1990s to 2017
The problem
In the 1990s Lantech used kaizen events to convert its operations from batch production to flow, and its results were featured in Harvard Business Review and in the book Lean Thinking. Its chief executive, Jim Lancaster, later realised the company kept repeating improvements that had deteriorated after just a couple of years, and the gains were not reaching the bottom line.
What they did
Lancaster spent months doing frontline work himself, to see how variation made processes deteriorate. The company then built a daily management system: cascading, standardised steps for every employee and executive, meant to catch and reverse deterioration every day. He presented it at the Lean Enterprise Institute's Lean Transformation Summit in 2017.
What they reported
Lantech's own account gives no before-and-after figures for this second phase, and none is given here. The Lean Enterprise Institute's 2017 write-up names the cause of the relapse: gains were not being sustained because Lantech lacked a daily management system.[5][6]
The lesson for an office team
An improvement nobody checks decays. Decide when you will look again, and what you will count, before the change goes in; see the lessons Did it hold and Keep a standard alive.
What does kaizen look like in office and knowledge work?
Four cases where the product is a decision, a permit, a letter or a piece of software. In each, most of the waste was waiting, hand-offs and steps nobody questioned, which is where it usually is in an office; the 8 wastes in office work names all eight kinds.
Wipro: Lean in software services
Wipro Technologies · Software and IT services, India · From 2004
The problem
Software projects run as a sequence, each step completed in turn by a separate person, so bugs could surface late. Harvard Business School researchers followed the firm to learn how lean ideas built for factories could improve services.
What they did
Wipro launched a lean initiative in 2004 with a small core team of managers, each of whom took one project as an experiment. Teams used value stream mapping to find wasted time and effort, and kaizen pushed projects towards a more iterative way of working. The firm rolled it out only after the first results: by the end of 2006 it had 603 lean projects completed or under way, at a time when it typically had 1,100 projects running.
What they reported
Of the first projects, 8 out of 10 showed more than 10 percent improvement in efficiency, Harvard Business School's Working Knowledge reported in 2007. A peer-reviewed study by Bradley Staats, David James Brunner and David Upton, published in 2011 and comparing lean projects with matched traditional ones, found an overall improvement; lean projects had just as many software defects.[7][8]
The lesson for an office team
Start with one controlled experiment, not a launch, and write down what did not change as plainly as what did. Not every tool translates: there is no line to stop in software. See every change is an experiment.
Vermont Department of Environmental Conservation, Wastewater Management Division · Government permits · 2006
The problem
The division expected more applications once the state took jurisdiction over all small wastewater and water supply systems in July 2007. Before the change, the longest a permit had taken to be issued was 542 days.
What they did
A kaizen event in 2006, with the goal of halving lead time while keeping the same environmental review standards. The team decided to return administratively incomplete applications to the designer for completion, revised the application form, and wrote one permit format, standard permit conditions and checklists for the administrative and technical reviews.
What they reported
The US Environmental Protection Agency's case study reports process steps cut from 150 to 38, decisions from 31 to 5, hand-offs from 18 to 6, loops from 5 to 2 and process delays from 39 to 3. The longest time to issue a permit fell from 542 days to 34.[9]
Florida Department of Environmental Protection, Northwest District · Government permits · 2009
The problem
An application for a dredge-and-fill permit had to be reviewed within 30 days, but it could take as much as 10 days just to reach a processor, which sometimes left only 20 days for the technical review.
What they did
A four-day Lean kaizen event in August 2009, with support from the EPA's regional office. The team mapped the current and the future process and planned the changes: permission to email scanned applications to the US Army Corps of Engineers instead of sending paper, the scanner and fax moved closer to staff, less copying and distribution, and an email address asked for on the form. Implementation continued after the event.
What they reported
The EPA's case study reports the lead time from receipt to a processor cut from 6.5 days to between 0 and 3 days.[10]
The lesson for an office team
The wait was before the work started. Measure how long a request sits before anyone picks it up, not only how long the work takes: working time and waiting time.
Denver: the notice that did not need certified mail
City and County of Denver, Peak Academy · Local government · 2012 to 2018
The problem
An accountant in the sanitation department had sent late-payment notices by certified mail for over a decade: about 11,000 a year, each filled out by hand. The task took about 1,000 hours a year, roughly half of her time, at $4.60 a mailing.
What they did
Denver's Peak Academy trains city employees in Lean-based methods, and each trainee must design an improvement to their own job and put it in place. She proposed sending the notices by first-class mail. Nobody she asked could explain why certified mail had been used in the first place, and her idea became policy.
What they reported
The Progressive Policy Institute reported in 2018 that the change saves the city $50,000 in postage a year, frees half of her time, and increased collections. Across the programme, the city's tracking credited Peak Academy with about $26 million of savings since 2012, of which $9 million were hard savings, counting only an improvement's first year, for a programme costing about $1 million a year.[11]
The lesson for an office team
Before improving a step, ask whether it should exist at all. A habit nobody can explain is the cheapest waste to remove, and the lesson Should this step exist shows how to ask.
What does a kaizen programme look like when it goes wrong?
Lists of kaizen examples rarely include a failure. This one does, because it was audited in public and its lesson is the one office teams most need.
HM Revenue & Customs: what the auditor found
HM Revenue & Customs, United Kingdom · Tax processing · 2004 to 2011
The problem
The UK tax authority had to make efficiency savings and cut headcount. It began piloting Lean techniques in 2004 in large-scale processing, first on Income Tax Self Assessment returns at an Edinburgh site, and launched the work as the PaceSetter programme in 2006.
What they did
Frontline teams and PaceSetter experts analysed and redesigned processes, and teams were trained in visual management and structured problem solving. Productivity was tracked as output per person per day at each site, against a baseline and a target.
What they reported
HMRC estimated productivity gains equivalent to £400 million of resource savings between 2005-06 and 2010-11. The National Audit Office concluded in 2011 that the programme was not yet value for money: the extent of overall efficiency gains was not clear, HMRC had not tracked the impact on service and quality, and while the largest offices reported big rises in output, some reported falls. In 2006 around 14,000 staff took part in industrial action over Lean working, citing excessive individual monitoring and unrealistic targets.[12]
The lesson for an office team
Track quality and waiting time beside output, and measure the process, never the person. Some staff the auditor met welcomed standard work and problem solving; the union's objections were to individual monitoring, targets and procedures that de-skilled the work. See measure honestly and problems are not faults.
What do the eight cases teach a knowledge-work team?
Read together, the cases agree on five things. None of them needs a factory, a consultant or a large budget to start.
Many small ideas beat a few big ones. Toyota's ideas are mostly small; Denver's best-known one was a change of postage.
Ask whether the step should exist before improving it. Denver dropped certified mail that nobody could justify; Vermont sent incomplete applications back instead of chasing the missing parts.
Count waiting and hand-offs, not only effort. Vermont cut hand-offs from 18 to 6 and delays from 39 to 3; in Florida, the days before anyone opened an application were the ones to remove.
Check that the change held. Virginia Mason measures each workshop's improvements at 30, 60 and 90 days; Lantech's gains wore off until checking became daily work.
Measure the process, never the person. HMRC's output figures could not show whether service had improved, and staff took industrial action over individual monitoring.
Strip the cases of their scale and the same small loop is left: one problem, named in plain words, followed to its cause, changed, and checked later. This is how an office team runs it this week, with the free lessons and templates on this site:
Name the kind of waste, in plain words: waiting, hand-offs, rework, steps nobody uses. The 8 wastes in office work has the list.
Ask why until you reach a process, a rule, a tool or an owner, never a person: the 5 Whys lesson and the 5 Whys template.
Ask whether the step should exist at all, before automating it.
Write the smallest countermeasure that could work, with a prediction of what will change: the countermeasure plan template.
Check at day 7, 14 and 30 whether it held, and write down what you counted: the PDCA template.
KaizenProof runs that loop for a team: a person describes the friction, the product names the waste, asks the why questions one at a time, asks whether the step should exist, drafts the countermeasure as text to copy, and sends the check-ins at day 7, 14 and 30. The figures above belong to the organisations that reported them; the only figures KaizenProof shows a team are the ones that team typed or confirmed. To compare it with doing the same in a spreadsheet, see KaizenProof vs a spreadsheet.
How were these examples chosen and checked?
A case is on this page only if the organisation itself, a government audit or case study, a university or a policy institute published what was changed and what happened. Each source was opened and read on the review date shown at the top, and every figure on the page is one a source states; where a source gives no figure, the page gives none. The results are reported results: some are the organisation's own figures, which the page says, and one, HMRC, is an auditor's judgement of the organisation's figures.
Left out: well-known stories whose figures could be found only in secondary summaries, blogs or slide decks, however often they are repeated. Also left out: any company logo, any suggestion that a named organisation uses, knows of or endorses KaizenProof, and any claim that a team using it would see the same results. For the history behind the methods, see the history of Kaizen and Lean; for the methods themselves, the Lean methods reference and the Kaizen glossary.
Sources
Each numbered source was opened and compared with the text of this page on . A number in square brackets after a statement points to the source it rests on.
Pick one task that wastes your team's time every week. Describe it in a sentence; KaizenProof names the waste, asks why until you reach the cause, and writes the fix. No account is needed to start.