The 8D method was formalized by Ford Motor Company in the 1980s under the name "Team Oriented Problem Solving" (TOPS). Ford published it as a supplier requirement after recognizing that most quality problems were being solved at the symptom level, not the root cause level. Suppliers fixed what was visible and shipped the next batch — only to see the same defect return three months later.
The "8D" stands for Eight Disciplines: eight structured steps that guide a cross-functional team from the moment a problem is reported to the moment it is formally closed. Today it is the standard problem-solving format demanded by automotive OEMs worldwide, and its influence has spread into aerospace, medical devices, and any industry where repeat defects carry serious consequences.
Why a Team, and Why Structure?
Most quality problems that require an 8D are not solved by one person in one afternoon. They involve multiple process steps, multiple departments, and root causes that aren't visible without data from more than one vantage point. A single engineer working alone finds the most obvious cause — which is rarely the real one.
The discipline of 8D forces teamwork by design. The first step is literally to assemble the right people before doing anything else. This is not procedural theater. Teams that skip D1 — or form it informally — consistently produce shallower root cause analysis and weaker permanent corrective actions.
フォード・モーター社が1980年代に体系化した8ステップの問題解決手法。顧客クレームや重大不具合に対し、チームで根本原因を特定し恒久対策を実施する。自動車業界では顧客からの品質問題報告に対する標準回答フォーマットとして要求されることが多い。「8Dレポート」「G8D（グローバル8D）」とも呼ばれる。
The Eight Disciplines in Full
The IS / IS NOT Framework for D2
The quality of the entire 8D depends on how well the problem is described in D2. Vague problem statements like "surface defect on part" lead to vague root causes like "operator error." The IS / IS NOT framework forces precision.
For each dimension — What, Where, When, How Much — the team must state both what is true (IS) and what is conspicuously not true (IS NOT). A dimension defect that occurs on the left side of the part but never the right side (IS NOT) tells you the root cause is asymmetric — something in the fixturing, tooling, or material orientation that affects only one side. That observation eliminates half the possible causes before analysis even begins.
"If you cannot describe the problem clearly enough that someone who has never seen it could go find it in the plant, your D2 is not done." — Common 8D training principle
D4: Occurrence Cause vs. Escape Cause
A mistake that undermines many 8D reports is treating the root cause as a single thing. The 8D method requires identifying two distinct root causes for every problem that reaches the customer.
不良が発生した工程上の真因。工具摩耗・条件設定・材料ばらつき・作業者のスキル不足など。発生原因への対策をとらなければ、不良はまた作られ続ける。5-Whyで「なぜ作られたか」を深掘りする対象。
不良が検査・検証をすり抜けた真因。検査方法の限界・サンプリング頻度の不足・測定器の精度不足・検査基準の曖昧さなど。流出原因への対策がなければ、たとえ発生を減らしても顧客に届き続ける。日本の現場では「なぜ流れたか」と表現される。
The corrective actions in D5 must address both causes independently. An action that prevents the defect from being made (occurrence fix) is different from an action that prevents it from reaching the customer (escape fix). Both are required. A D4 that identifies only one is incomplete, and the customer's quality engineer reviewing the report will notice immediately.
D7: The Step That Determines Whether Learning Survives
D6 fixes the problem in the place where it was found. D7 asks whether the same root cause exists elsewhere — in other product families, other lines, other plants. This is called horizontal deployment (横展開, yoko-tenkai in Japanese), and it is one of the most culturally embedded practices in serious Japanese quality organizations.
Beyond the physical fix, D7 requires updating the management system. This means the FMEA must be revised to reflect the new understanding of failure modes. The control plan must be updated to include any new control measures. Work instructions must be revised. Operators must be retrained. And the lesson must be documented in a way that will be findable by whoever inherits this process in three years.
The test of a good D7 is simple: if the same root cause tried to re-enter the process — through a new machine, a new operator, or a process change — would the current management system catch it? If the answer is no, D7 is not done.
Common 8D Mistakes in Practice
Jumping to D5 without completing D4. Teams under pressure skip the analysis and go straight to action. The corrective action then fixes the symptom, not the cause. The problem returns, a new 8D is opened, and the cycle repeats — often three or four times before someone forces a proper D4.
Removing D3 containment before D6 is validated. Containment is costly — extra inspection, sorting labor, material hold. There is always pressure to remove it quickly. But removing D3 before the permanent fix is proven effective exposes the customer to risk again. The data from after D6 implementation must confirm zero recurrence before D3 is lifted.
Writing the 8D after the problem is already closed. An 8D written retrospectively, to satisfy a customer format requirement, is almost always incomplete in D4. The team no longer has the defective parts, the process is running, and no one can verify whether the root cause was actually identified or assumed. The report looks complete but the problem understanding is shallow.
Listing actions without owners and dates. Every corrective action in D5, D6, and D7 must have a named person responsible and a completion date. Actions assigned to "the team" or "quality department" without individual names are never completed on schedule. This is one of the most reliable predictors of 8D failure.
Skipping D8. Teams in Japan especially tend to omit the team recognition step as unnecessary or embarrassing. But recognition signals to the organization that raising problems leads to positive outcomes, not blame. Without it, the silent lesson people learn is to hide problems — the opposite of what any quality system needs.