8D Problem Solving Record

What this tool does

CM8-212 is a working 8D record. Each row is one discipline of one report — D1 to D8 — with its statement, owner, evidence, due date and status. From those rows the tool builds the 8D board (one bar per report, eight disciplines coloured by state), shows where each report is stuck, flags reports whose containment is missing or still open, and prints a report a customer's quality team will recognise on sight.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so customer complaints, defect data and supplier names never leave the computer you are using.

What 8D is

8D — eight disciplines — is the team-based, evidence-driven problem-solving method developed at Ford in the 1980s and since adopted across the automotive, aerospace and wider manufacturing supply chains, where a customer rejecting parts will often demand "an 8D" by name. Its two defining habits: a team works the problem, not a hero; and nothing is asserted without evidence — a root cause is verified, a fix is validated, or it does not count.

8D is the structured discipline that wraps the individual problem-solving tools: a Five-Why Analysis or a Fishbone Diagram does the digging inside D4, and a CAPA Tracker manages the resulting corrective and preventive actions at scale. 8D is the frame that makes sure the digging happens in the right order — after the customer is protected, before the fix is chosen.

The eight disciplines — what good looks like, and the classic failure

D1 — Team. Good: a small cross-functional team with the people who touch the process — including the operator — and one named leader. Classic failure: "the quality department" works it alone, and the fix dies on the shop floor because nobody who runs the process helped design it.

D2 — Problem description. Good: data, not adjectives. What, where, when, how many — and just as important, where it is not: which products, lines, shifts and dates are unaffected. "14 leaking units of 620, all type HF-12 from line 2, none of type HF-08 from the same line" has already halved the search space. Classic failure: "fittings are leaking badly" — a sentence nobody can investigate, with an adjective doing the work data should do.

D3 — Containment. Good: the customer is protected now — typically within 24–72 hours — by inspection, sorting, quarantine or certified replacement stock, and the containment is itself checked for effectiveness. Containment is not correction: it is the tourniquet that buys time for a proper root cause, and it costs money for as long as it runs. Classic failure: skipping D3 because "we'll have the fix next week" — and shipping three more weeks of defects when the fix slips.

D4 — Root cause. Good: a cause you can turn on and off — reproduce the defect by restoring the condition, eliminate it by removing the condition — with the test recorded as evidence. Classic failure: the plausible guess. "Operator error" and "material variation" are where investigations go to die; if the evidence field is empty, D4 is not done, whatever the status says. This tool will not let a D4 be marked verified without its evidence.

D5 — Corrective action chosen. Good: a fix selected against the verified cause, with the alternatives considered and the reason for the choice recorded. Classic failure: choosing the fix before D4 is finished — which is how a plant buys a new machine to fix a calibration sticker.

D6 — Implemented and validated. Good: the fix is in place and shown to work with production data over a meaningful run, after which containment can be switched off. D5 and D6 are separate disciplines for a reason: a decided fix and a working fix are different things, and the gap between them is where problems come back. Classic failure: marking the report closed the day the purchase order is raised. The tool applies the same evidence rule here as at D4.

D7 — Prevention. Good: the system changes so the whole class of problem cannot recur — the FMEA is updated, the standard is rewritten, the check is added to the preventive-maintenance schedule, sister lines and sister products get the same fix. Prevention means systems. Classic failure: "operator briefed" or "team reminded to take care" — a conversation is not a control, and it retires with the people who heard it.

D8 — Recognition. Good: the team is thanked, by name, by someone senior, and the report is formally closed with the customer. This is a discipline and not a courtesy because it is what makes the next 8D possible: teams that get thanked volunteer for the next problem; teams that get blamed hide it until it reaches the customer. Classic failure: the report just… stops.

D4 and the root-cause tools

8D tells you when to find the root cause; it does not tell you how. That is what the analysis tools are for: a five-why chain walks from the symptom to the system that allowed it, and a fishbone session lays out candidate causes so the team tests the likely ones instead of the loud ones. Use whichever fits, but hold the output to the 8D standard — the answer is not the last "why" somebody said out loud; it is the cause you demonstrated, with the demonstration written in the evidence field.

When is a report closed?

That is the definition the tiles, the board and the days-open chart all use, and it is deliberately stricter than "the form is full". A report with eight completed boxes and an empty D4 evidence field is not closed; it is a guess with good handwriting.

The average days to close tile counts only fully closed reports, measured from the earliest entry date to the latest completed date. While a report is open, its clock runs to today.

Reading the stuck-at chart

The stuck-at chart shows, for every report that is not closed, the lowest discipline that is not yet complete — the point where the process has actually stalled, whatever later boxes have been filled in. Two patterns account for most files:

• Stuck at D4. The most common, and the most honest. Root cause is genuinely hard, and a report at D4 with active testing is healthy — for a while. Two months at D4 with permanent containment running is a report being carried, not worked, and the containment cost is the bill for it.
• Stuck at D7. The quiet one. The defect is fixed, the customer is calm, and prevention never happens, because it belongs to nobody and the pressure is off. Files that stall at D7 belong to organisations that solve the same problem annually.

A pile-up at D3 is drawn in red because it is a different kind of problem: those customers are not yet protected, and that outranks everything else in the file.

When 8D is overkill

8D earns its overhead when the problem is significant, the cause is unknown, and more than one function has to act — a customer reject, a recurring defect, a serious internal failure. It is the wrong tool for a problem one person can see and fix in an afternoon. Simple problems get a quick five-why and a corrective action; save the 8D for problems that deserve a team. If everything gets an 8D, soon nothing does — the forms get pencil-whipped and the method loses its authority for the day you need it.

FAQ

One row per discipline — why not one row per report? Because the disciplines have different owners, dates and states, and the whole point of tracking an 8D is seeing which discipline is stalled. Give every entry the same report reference — the tool groups them into reports automatically.

Can a discipline have more than one entry? Keep one row per discipline per report and update it as the work moves; the boards use the most recent entry for each discipline. If a validation fails at D6, set the status back and note why in the entry.

What is D0? Some versions add a D0 — deciding whether the problem warrants an 8D and preparing for it. This tool treats that as the decision to open a report at all; if you want it on record, note it in the D1 entry.

Who owns a discipline? One named person, not a department. The report as a whole belongs to the D1 team leader; each discipline entry names whoever is delivering that piece.

When can containment be removed? After D6 — when the corrective action is implemented and validated with data. Removing it at D5, on the strength of a decision, is how the second customer complaint happens during the gap.

Our customer demands 8D reports in their own format. Keep the record here and transcribe at closure — the discipline structure maps one-to-one, and the format is the easy part.

Saving your work

Entries, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo. An 8D file names customers, defects and people — treat exports as confidential.

Accuracy & disclaimer

This tool tracks the structure of the method faithfully: which disciplines exist, what state they are in, what evidence was recorded, and how long each report has run. It cannot judge whether the evidence is any good — whether the D4 test really isolates the cause, or the D6 run was long enough to mean anything. Those judgements are the team's, and they are the entire value of an 8D.

The form does not solve the problem. A completed 8D with an unverified root cause is paperwork, not problem-solving — and a customer's auditor will read it exactly that way. This is a record-keeping and tracking aid, not quality-management advice, and it does not satisfy any customer-specific or industry-specific reporting requirement by itself.