You'd never trust an unvalidated gauge. Why trust an unaudited DFMEA?
Would you trust a measurement system before it passes a Gage R&R? Of course not.
Would you launch a product without a production validation run? No way.
Do you trust your DFMEA without ever auditing the process that produced it? Well…
That's backwards. We validate the gauge, the machine and the line before we believe what they tell us. The DFMEA, the process that decides what gets designed out, what gets tested and what ships, usually gets signed off on faith.
The cost runs the wrong way
Look at what each of those failures costs when it slips through:
- A bad gauge gets recalibrated. $
- A bad machine setting gets changed on the next trial. $$
- A failure mode the DFMEA missed gets cut into the tooling, built into inventory and shipped to customers. $$$$$
The process with the most expensive escapes is the one we check least.
What a Gage R&R would ask of your DFMEA
A Gage R&R asks two questions of a measurement system. Ask the same two of your DFMEA process:
- Repeatability. If the same team analyzed the same product again next month, how many of the same failure modes would they write? How many of the same scores?
- Reproducibility. If a different team analyzed it, would they find the same risks, or a different set?
Few teams have ever run that test. If the answers are "not many" and "a different set," then a good part of what's in your DFMEA depends on who was in the room and how the day went, not on the product. On a gauge, we'd call that measurement error, and we wouldn't ship on it.
The audit you can run this week
Pull your last ten field failures. Open the DFMEA signed before launch. For each failure, ask where the process broke:
- Not in the DFMEA at all. A coverage escape. The failure mode was never written.
- In the DFMEA, scored low. A scoring escape. It was found and judged not worth acting on.
- In the DFMEA, acted on, still shipped. A verification escape. The test that was supposed to catch it didn't.
Each one points at a different weakness in the process, and each needs a different fix. Count them, and you have something most teams never see: a defect rate for the DFMEA process itself.
Fix the process, not the list
The usual response to a field failure is one more line on the lessons-learned list. That catches the same failure next time. It does nothing for the next escape, because the next one isn't on the list yet.
Treat escapes the way you'd treat any process defect. Find the root cause in the process: who was in the room, when quality got involved, what the review was asked to look for, how scores were set. Then fix that. A process maturity matrix for risk management is a good place to start, and almost no one has one.
Where RiskForge fits
This is one of the reasons I built RiskForge. It gives your team an independent first draft, worked out from the product itself rather than from whoever happened to be in the room, so your engineers spend their time probing the analysis instead of building it from scratch.
When did you last audit your DFMEA process?