Skip to content

SCAR: How Supplier Corrective Action Actually Works

By Christian Fieg · Last updated: April 2026

Two thirds of the SCARs I have read in twenty-five years of automotive quality work were closed on paper without ever being fixed in the process. The audit trail showed root cause analysis, corrective action, effectiveness verification, signed off, file closed. Six months later the same defect arrived from the same supplier, sometimes from the same machine, sometimes with the same operator. Different SCAR number. Same problem. Same closure.

SCAR — Supplier Corrective Action Request — is one of the most useful and one of the most abused tools in supplier quality management. Useful because the underlying logic (formalise the problem, force a structured root cause analysis, verify the fix) is exactly what permanent defect elimination requires. Abused because it is also the easiest quality process in the world to fake. A competent quality engineer can produce a SCAR response that looks like genuine 8D work in under an hour and satisfies most receiving organisations' approval workflows.

This article is written from both sides. I have issued thousands of SCARs to suppliers as a Tier 1 quality lead at Johnson Controls and Visteon. I have also been on the receiving end, responding to OEM SCARs as the same Tier 1's supplier-quality function. The honest view of the tool only forms when you have done both.

What is a SCAR, and what is the test of whether one was used properly?

A Supplier Corrective Action Request is a formal, documented request from a customer to a supplier requiring (1) immediate containment of a quality defect, (2) systematic root cause analysis, (3) implementation of a permanent corrective action, and (4) evidence that the corrective action actually prevents recurrence. The output is a structured response document — typically built on the 8D methodology — that satisfies the customer's quality system and creates a permanent audit record.

The test of whether a SCAR was used properly is simple and uncomfortable: does the same defect appear again? If yes, the SCAR was paperwork. If no over a defined observation period (typically 90 days minimum, six months for safety-critical parts), the SCAR did its job. Everything else in the SCAR document — the fishbone diagrams, the Pareto charts, the five-whys, the signature blocks — is decorative if recurrence happens.

The two perspectives: writing a SCAR vs. responding to one

Most articles on SCAR treat it as a one-sided process — the customer issues, the supplier responds. In practice both sides shape the outcome, and the most common reason a SCAR fails to fix anything is that one or both sides treated their part as administrative rather than analytical.

Perspective Done well Done as theatre
Issuing the SCAR (customer side) Specific problem statement with quantified scope (PPM, parts, dates, defect mode), affected lots, photographs, contained-vs-suspect distinction, response deadlines tied to risk "Quality issue noted, please respond" — vague problem, no scope, no evidence package, generic 14-day deadline regardless of severity
Receiving the SCAR (supplier side) Genuine 8D, real fishbone with named contributors, validated root cause distinct from symptom, corrective action targeting the cause, effectiveness data measured over time Root cause: "operator error." Corrective action: "operator retraining." Effectiveness verification: "training records attached." Closed.
Read-across Customer asks "where else does this apply?" Supplier proactively checks similar parts/processes/sister plants and reports findings Both sides treat the SCAR as scoped to the specific part number; identical problem on a sister part 200 km away is "out of scope"
Closure decision Closed only after 60–180 days of recurrence-free production with statistical evidence Closed when the response document is signed and filed, before any production proves the fix

The supplier-side failures are the ones discussed openly in industry literature. The customer-side failures are at least as common and rarely talked about. A vague SCAR with no evidence package and a one-size-fits-all deadline produces a vague response by design — the supplier cannot do real root-cause work without the data, so they produce a defensible-looking response that satisfies the form. Both sides agree, the file closes, the defect persists.

How 8D fits inside a SCAR — and where each step usually breaks

The 8D methodology — Eight Disciplines, originated at Ford in the 1980s — is the structural backbone of most modern SCAR responses. The framework is sound. The execution, in my experience reviewing several thousand 8D responses across Johnson Controls, Visteon, and now SYMESTIC customers, fails predictably at specific steps:

  1. D1 — Form the team. A cross-functional group with the knowledge to solve the problem. Common failure: the "team" is one quality engineer and a name list. No production engineer, no maintenance, no operator who actually runs the process.
  2. D2 — Describe the problem. Specific, quantified, with timeline. Common failure: the problem statement is the customer's complaint copy-pasted, with no independent characterisation by the supplier. If the supplier hasn't restated the problem in their own measurements, they haven't understood it yet.
  3. D3 — Interim containment. Stop the bad parts from reaching the customer while you investigate. Common failure: "100 % inspection" listed without specifying who, where, with what tooling, on what shift coverage. 100 % inspection by a fatigued operator without a gauge fixture is not containment, it is a hope.
  4. D4 — Root cause analysis. Distinguish symptom from cause via five-whys, fishbone, or similar. Common failure: the analysis stops at "operator error" or "machine variation" — these are categories, not causes. The five-whys exercise, done properly, almost never terminates at the operator. It terminates at a missing standard, an inadequate work instruction, an unverified tool change, a process that allows the error to occur. "Operator error" is where a five-whys exercise starts, not where it ends.
  5. D5 — Identify permanent corrective actions. Specific actions targeting the validated root cause. Common failure: "operator retraining" as the action, regardless of what the actual root cause was. If the root cause is a missing tool-change procedure, the corrective action is the procedure, not training people on a procedure that doesn't exist.
  6. D6 — Implement and verify. Put the action in place, prove it works. Common failure: implementation date listed, verification skipped or limited to "no defects observed for two days" — statistically meaningless on a process that produced one defect in 50,000 parts.
  7. D7 — Prevent recurrence. System-level changes (FMEA update, control plan revision, lessons learned across product family). Common failure: the FMEA is updated for the specific failure mode and never read again. No read-across to sister parts. No update to the design FMEA when the issue is design-driven.
  8. D8 — Recognise the team. Officially close, recognise the work. Common failure: closure happens at the response submission, not after the recurrence-free observation period. By the time recurrence shows up, the team has moved on and the institutional learning is gone.
When a SCAR response lands on my desk and I read "root cause: operator error, corrective action: retraining," I know the supplier did not do the work. Not because operators never make errors — they do — but because in twenty-five years I have never once seen a five-whys exercise honestly performed terminate at the operator. Either the analysis was skipped, or the supplier knows the real cause and would rather not say.

Red flags in a SCAR response — what to push back on immediately

If you are on the customer side reviewing a supplier's SCAR response, the following signals indicate the response is paperwork rather than analysis. Push back; do not close:

  • "Operator error" as the terminal root cause. See above. Send back with a request for the underlying process gap that allowed the operator error to occur.
  • "Retraining" as the only corrective action. Training is a corrective action only when the gap is genuinely a knowledge gap — not a procedure gap, not a tooling gap, not a control gap.
  • Effectiveness verification dated within a week of implementation. Statistically meaningless on most defect rates. Demand a defined observation window proportional to defect frequency.
  • No mention of read-across to similar parts or sister processes. If the root cause is real, it almost certainly applies somewhere else in the supplier's operation.
  • No FMEA update referenced. The PFMEA exists precisely so that learnings from defects feed back into preventive controls. A SCAR that does not update the FMEA is a defect that will recur.
  • The response document is signed before the corrective action is implemented. Common in suppliers under deadline pressure. Implementation date in the future, signature in the past — the SCAR was closed for the file, not for the process.
  • Identical phrasing to a previous SCAR response. Some suppliers maintain a library of pre-written 8D responses and adapt them to incoming SCARs. The tell is identical sentence structures across supposedly independent investigations.

Where SCAR is genuinely valuable, when both sides do their part

None of the above means SCAR is a bad tool. Used honestly, with both sides treating it as analytical work rather than administrative work, it is the most effective supplier-quality mechanism the industry has produced. The genuine outcomes I have seen across the better implementations:

  • Defect recurrence rates drop by 60–80 % on parts under active SCAR governance, compared to defects reported informally without a formal corrective action process.
  • Supplier capability development accelerates — suppliers who go through three or four well-executed SCARs improve their internal quality systems substantially, often beyond what the original defect required.
  • Customer-supplier trust increases when SCARs close cleanly and stay closed. The relationship moves from policing to partnership. The opposite is also true: a relationship dominated by recurring SCARs degrades quickly into adversarial escalation.
  • Knowledge transfers across product families when read-across is taken seriously, eliminating defects from products that were never directly affected.

From the supplier side, the constraint that determines whether you can do honest SCAR work is whether you have the production data to back up your root-cause analysis. Most weak SCAR responses I have seen — both as the recipient at JC/Visteon and now as a vendor working with manufacturers — are weak because the supplier genuinely cannot reconstruct what happened on their line at the time the defective parts were produced. They have shift logs, manual entries, paper records that don't tie back to specific cycles. The SCAR response is generic because the data is generic. SYMESTIC's role here is upstream of the SCAR itself: the per-cycle production data captured in Process Data, alarm history surfaced in Alarms, and order-bound KPI history in Production Metrics mean that when a defect is found two weeks later in a customer's incoming inspection, the supplier can reconstruct exactly what the machine, the process parameters, the operator, and the upstream batch were at that moment. That is the difference between an 8D that names the actual root cause and an 8D that names the operator.


Related quality and operations topics: OEE · MES · Statistical Process Control · 8D Report methodology · FMEA · PPAP · Six Sigma · DMAIC · Traceability · Quality management · IATF 16949 · Alarms.

About the author
Christian Fieg
Christian Fieg
Head of Sales at SYMESTIC. 25+ years in manufacturing — Johnson Controls (Six Sigma Black Belt, Global MES & Traceability lead, 900+ machines across 7 countries), Visteon Center of Excellence, iTAC, Dürr. Author of OEE: Eine Zahl, viele Lügen (2025). · LinkedIn
Start working with SYMESTIC today to boost your productivity, efficiency, and quality!
Contact us
Symestic Ninja