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.

When I joined Toyota in the latter part of the 1980s, the company training manual taught a simple five-step method:

Step	Japanese (romaji)	English
1	問題を明確にする Mondai o meikaku ni suru	Clarify the problem
2	目標の設定 Mokuhyō no settei	Set the target
3	要因の追究 Yōin no tsuikyū	Pursue the true root cause
4	対策の実施 Taisaku no jisshi	Implement countermeasures
5	結果の確認 Kekka no kakunin	Confirm results

That was it — five clean 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.

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 — and good definition has three attributes I call AQD: Analytical, Quantitative, Detailed.

• Analytical — "analysis" means to break up. Separate this problem from the blob of other problems; bound what you are investigating.
• Quantitative — measure 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.
• Detailed — get specific about where and when it occurs. This is where you separate the point of detection (where you noticed it) from the point of cause (where it actually originates) — they are rarely the same place.

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.)

Years ago I asked a client to grade several dozen of their completed problem-solving reports, using a simple three-level scale I developed — ADP: Administrative, Detection, Prevention. Roughly 80% of their countermeasures were administrative. The lesson stuck: most organizations are busy taking action that does not structurally change the work. The hierarchy, weakest to strongest:

• A — Administrative — influence human behavior and awareness: training, SOP updates, checklists, reminders, meetings. Weak, because it relies on vigilance and decays with turnover and distraction.
• D — Detection — detect the abnormality and trigger an immediate response: sensors, alerts, andon, torque or vision checks, limit switches. Stronger, because it does not depend on memory — but it is still reactive.
• P — Prevention — eliminate the cause so the error cannot occur: error-proofing (poka-yoke), connector keying, interlocks, design change. The strongest, because it is structural and self-sustaining.

Push countermeasures as far up the hierarchy as is feasible — from administrative toward prevention. Evaluate candidates against effectiveness, cost, time, and risk before selecting. A weak countermeasure hides behind paperwork; a strong one changes the process itself. If your best countermeasure is still administrative, that is often 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.