8D and SCAR follow-up: why corrective actions stall after the report is filed

A supplier quality engineer at a Tier 1 stamping plant closes an 8D on a recurring weld defect in March. Containment worked, the corrective action box gets checked, and the report goes to a shared drive. By August, the same defect shows up on a different line, and nobody can say for certain whether the original root cause was ever verified, or just assumed once the line ran clean for a week.

Why it happens

The 8D or SCAR itself usually isn't the problem. Teams are decent at filling out the form: define it, contain it, find a root cause, pick a fix. What breaks down is everything supposed to happen after the report gets marked complete.

• No single owner past containment. Whoever led the initial response moves to the next fire, and the corrective action sits in a spreadsheet or email thread with no one checking on it.
• Due dates exist on paper but nothing escalates when they slip. A 30-day target quietly becomes 60, then 90, because nothing flags the date once it passes.
• Root cause verification gets skipped. The fix goes in, the line runs clean a few days, and that gets treated as proof, when the real check, a re-test or capability study, never happens.
• Effectiveness checks live in a different system than the report itself, so closing the loop depends on someone remembering to look weeks or months later.

What it costs

The direct cost is the recurrence itself: scrap, rework, and containment that repeat because the fix was never confirmed. The less obvious cost is what it does to an OEM relationship. A supplier with a pattern of repeat defects on the same part family tends to draw more audits and tighter PPAP requirements, usually costing more staff hours than the original corrective action would have.

Diagnose before you automate

Before assuming this needs a new system, it's worth checking where your follow-up actually breaks.

1. Pull the last 10 closed 8Ds or SCARs and check whether the effectiveness step has a date, an owner, and evidence attached, not just a checkbox.
2. Ask each corrective action owner how they find out a due date is approaching. If the answer is roughly 'I just remember' or 'someone emails me,' that's the gap.
3. Look for repeat defect codes on the same part number over the past 12 months. That's usually the clearest sign a prior root cause wasn't actually fixed.
4. Check whether effectiveness checks get scheduled when a corrective action is approved, or added later as an afterthought.

Where automation helps, and where it doesn't

When it's a process fix

If nobody owns follow-up once containment ends, that's usually assigning ownership and a review cadence, not buying software. A short weekly open-items review, with one person accountable for every open corrective action, closes most of this gap on its own. Same with verification: build the effectiveness check into the approval step itself, with its own due date, instead of leaving it for someone to remember.

When it's worth automating

Where automation earns its place is routing and reminders, not judgment. A system that flags an open corrective action when its due date is a few days out, escalates once it's overdue, and won't show a report as closed until the effectiveness check has a date and evidence attached, removes the memory problem entirely. That's not AI. It's date-based routing and a checklist gate, and it's usually enough to fix what spreadsheets and email can't.

The takeaway

An 8D or SCAR that stalls after filing is rarely a documentation problem. It's usually a missing owner and a missing deadline alarm. Fix those two things first, whether by hand or with routing rules, and most of what looks like a recurring quality problem turns out to be a recurring follow-up problem instead.