The 8 Steps of Toyota Problem Solving

Among lean practitioners, "the Toyota eight steps" is probably the best-known structured problem-solving method — the version Toyota itself calls Toyota Business Practices, or TBP. That is the method this guide covers. A word on scope first: there are other eight-step frameworks — the eight-disciplines (8D) method common in the automotive supply base is a familiar one — and they serve the same broad purpose. This article is about Toyota's current method specifically.

1How Toyota's steps evolved

The exact steps of problem solving at Toyota have not always been the same. The basic method was taught and handed down, but its precise form — and the number of steps — changed over the decades, and today's eight steps are the current version. That history matters, because it explains why the number of steps was never the point.

Toyota had been at this for decades before I arrived. By the 1960s the company was already working PDCA into both hoshin kanri and everyday problem solving. QC circles ran their improvements through long problem-solving storyboards — the twelve-to-fourteen-step QC-story format. The first A3 reports were starting to be written. The thinking was already mature; what kept changing over the years was mostly how many steps it was packaged into.

When I joined Toyota in the latter part of the 1980s, my first problem-solving training book taught a simple five-step method:

That was it — five steps, taught as a way of thinking, not as a form to fill out.

Over my time there the manuals and the step counts changed — to six, seven, and eventually eight. A typical seven-step version ran: clarify the background, define the problem, set a goal, root-cause analysis, implement countermeasures, check results, and then standardize, sustain, reflect, and yokoten. The important thing to understand is how this was taught. There was a corporate standard — but it was not as step-specific as it is today. We were taught example patterns, and the situation was expected to dictate which steps you actually used and how far you carried each one. The emphasis was on the content of the thinking, not the form of the template. In all my years at Toyota, no one ever insisted I use a particular number of steps; what they pressed on was the clarity and effectiveness of my thinking about the problem.

It was around 2000, in the Fujio Cho era when the Toyota Way was formally articulated, that the current eight-step method became the corporate standard. (I state that as recollection, not documented fact — and, honestly, I suspect the steps actually used inside Toyota still vary more than the standard implies.)

For the broader, global history of how structured problem solving arose — Dewey, Shewhart, Deming, Juran, JUSE, and the rest — see the Four Types of Problems guide and One Hundred Years of PDCA Thinking. This section stays inside Toyota.

2The eight steps at a glance

Here is the current method. The four PDCA phases are shown alongside, because the eight steps are simply PDCA worked out in detail: Steps 1–5 are Plan, Step 6 is Do, Step 7 is Check, and Step 8 is Act.

PDCA	Step	Toyota Business Practices
Plan	1	Clarify the problem
	2	Break down the problem
	3	Set a target
	4	Analyze the root cause
	5	Develop countermeasures
Do	6	See countermeasures through
Check	7	Evaluate both results and process
Act	8	Standardize successes and share the learning

3Step 1 — Clarify the Problem

The first step is to establish context and direction — what situation are we in, why does it matter, and what, broadly, is wrong relative to where we should be. Most methods jump straight to "define the problem" and skip this. That is a mistake. Without shared background, a problem-solving meeting spends its first hour establishing context the hard way, through interruptions and cross-talk, and trust erodes before any real work begins.

Clarifying the problem means making sure everyone can answer three questions: what situation are we discussing, why does it matter, and what is the scope of our work. It does not require lengthy documentation — often three to five minutes of deliberate framing — but it does require preparation. Think of it like a race: it does not always matter how fast you leave the gate, but you cannot afford to fall on the first step.

4Step 2 — Break Down the Problem

A large, vague problem cannot be solved; it has to be broken into a specific, measurable one. "We have a quality problem" supports almost any solution anyone wants to propose, which is exactly why it solves nothing. Breaking the problem down narrows it to something actionable: "5% scrap versus a 0.5% standard at drilling station 14, where the standard is a 15.00 mm ±0.2 mm through-hole." Now you know where to look and what to measure.

A problem well defined is half solved. In Toyota practice, breaking it down means three things. Bound it — separate this issue from the blob of adjacent problems so you know exactly what you are investigating. Quantify the gap from standard in real numbers; "we don't have standardized work" is not a problem statement, it is a missing action item in disguise. And get specific about where and when it occurs — above all, separate the point of detection (where you noticed the problem) from the point of cause (where it actually originates). The two are rarely the same place, and mistaking one for the other is how teams end up fixing symptoms.

This is hard because it demands slow, deliberate thinking when the brain wants fast pattern-matching — the System 1 versus System 2 problem. It is a learned skill, built by repetition.

5Step 3 — Set a Target

A good target is not a wish or a slogan. It is a specific, measurable commitment to close a defined gap by a defined time. In gap-from-standard work the target flows directly from the breakdown: if you have quantified 5% scrap against a 0.5% standard, the target is to close that gap — fully or in stated part — by a date. Measurable, time-bound, tied to the gap.

Two common mistakes: setting a stretch target before you have grasped the current condition, and confusing the target with the countermeasure. "Implement standardized work" is not a target — it is a proposed means. The target states the what and the how-much-by-when; the countermeasures come later. Keep targets honest: better a modest target met and understood than an ambitious one missed for reasons no one can explain.

6Step 4 — Analyze the Root Cause

Root-cause analysis is the crucible of problem solving — it reveals the depth of the team's thinking and the quality of its process. It demands the same Analytical, Quantitative, Detailed discipline as the earlier steps, only deeper. The familiar tools live here: the five whys and the cause-and-effect (fishbone) diagram. But the tools do not solve the problem; they only reveal how clearly you have seen it. A perfect five-why chart built in a meeting room, never tested against reality, is still wrong.

The discipline that matters is testing each "why" against evidence at the actual place — the difference between a plausible cause and the real one. (My reconstruction of Ohno's five-why machining case shows how deep a genuine causal chain can run.)

7Step 5 — Develop Countermeasures

The word countermeasure is deliberate. Toyota avoids "solution": a solution implies the problem is gone forever, while a countermeasure is the best action you have now against a specific cause, to be confirmed and improved. Weak countermeasures attack symptoms; strong ones change the conditions that allowed the problem.

Before ranking countermeasures, separate two things English tends to collapse into the single word "fix." In Japanese practice, taisho (対処) is the immediate response that contains the symptom so work can continue — replacing the fuse, reworking the bad part. Taisaku (対策) is the countermeasure aimed at the verified root cause so the problem does not return. Both are legitimate, and a fast taisho is often necessary to protect the customer — but the most common way a "solved" problem comes back is declaring victory at the taisho and never completing the taisaku. Containment actions — segregating suspect parts, adding inspection, reworking — are taisho: necessary to protect the customer while you learn, but not countermeasures. (See the five whys for more on this distinction.)

Not all countermeasures are equally strong, and Toyota's bias is clear: the best one changes the conditions so the problem cannot occur, rather than asking people to try harder. A countermeasure that leans on vigilance — training, a reminder, an updated SOP — is weak; it decays with turnover and distraction. Stronger is in-process detection: a sensor, an andon, a torque or vision check, a mistake-proofing (poka-yoke) device that catches the defect and stops it moving downstream. Useful — but be precise about what it does. It catches the error after it has occurred and contains it; it does not stop the error from happening. The strongest countermeasure does exactly that: it changes the underlying conditions and factors so the problem cannot arise in the first place. In development work we called this mizen-boushi (未然防止) — designing the failure mode out, upstream, before it can ever appear. Push each countermeasure as far toward that as is feasible, and weigh candidates on effectiveness, cost, time, and risk. If your best countermeasure is still a piece of paperwork, that is usually a sign the root cause was never truly reached.

8Step 6 — See Countermeasures Through

This is the Do step: execute the chosen countermeasures with clear ownership and dates, and carry them through to completion. Seeing them through means more than launching them — it means involving the people affected, arranging any retraining, and confirming each countermeasure is actually in place and working as intended. The best plan fails if the people doing the work did not understand it or were not part of building it.

9Step 7 — Evaluate Results and Process

Checking results is the most-skipped step in all of problem solving. Teams declare victory when countermeasures are implemented — but implementation is not improvement. Until you measure the effect against the target from Step 3, using the same metric and basis of comparison, you do not know whether you solved the problem. Did scrap actually fall from 5% to 0.5%? Over what period? Is the gain stable or a one-time blip?

The emphasis here is a check on results, with a second check on the process conditions that keep those results in place. Results is the primary question: did the metric reach the target, measured the same way? But a number that hit target today can quietly slip back, so you also check the process — the concrete conditions and routines the countermeasure depends on to hold.

Take Ohno's five-why machining case. The root cause is metal chips entering the lubrication system; the countermeasure is to add a strainer. The results check is straightforward: did the machine stop failing? The process check is the part teams forget — is the strainer still in place and intact, is there a routine to inspect and clean it, who checks the tank and how often, what happens when it clogs. Those are the standing checks that turn a one-time fix into a sustained one. This is exactly where structured problem solving hands off to daily operations: the Floor Management Development System and three-pillar activity are how those process checks get owned and sustained on the floor rather than forgotten once the project closes.

10Step 8 — Standardize and Share

Solving a problem once is not the goal; the goal is to make sure it stays solved and that the organization keeps what it learned. Three activities do that:

• Standardize — fold an effective countermeasure into the standard: the standardized work, the checklist, the drawing, the training. A countermeasure not built into a standard depends on memory and goodwill, and decays. Standardization locks the gain and resets the baseline.
• Sustain — standards drift. Follow-up — through layered audits, daily management, and visual controls — confirms the standard is still held months later. Without it the old condition quietly returns.
• Share (yokoten) — a problem solved on one line or machine is very often present elsewhere. Yokoten takes the countermeasure and the thinking to similar processes so the whole organization benefits.

This step also carries reflection — hansei. The other steps fix the problem; reflection improves the problem solver. Honest reflection asks what went well, what did not, and why — where did our thinking break down? At Toyota hansei is cultural: expected, scheduled, and taken seriously even when a project succeeds. The point is not blame but learning, so that capability compounds over time. This is the least glamorous and most neglected part of the cycle — and the difference between a culture of real problem solving and a culture of recurring firefighting.

11The eight steps — a reference aid

A one-screen summary you can keep beside a problem. Each panel is one step, its PDCA phase, and the key points that matter most when you actually do it.

12Summary

Toyota Business Practices is PDCA made operational as eight steps: clarify and break down the problem, set a target, find the root cause, develop and carry through countermeasures, evaluate results and process, and standardize and share what worked. Five of the eight steps are Plan — because the method front-loads understanding, and most failures come from rushing that.

But hold the eight steps lightly. They are the current corporate form of a method that has been five, six, and seven steps before — and the number was never the point. What solves the problem is the quality of the thinking inside the steps: clear definition, honest measurement, causes tested against reality, countermeasures that prevent rather than patch, and reflection that makes the next problem easier. Content over form. Do a few things well rather than many poorly.