A PFMEA, or process failure mode and effects analysis, is a structured team review of a manufacturing process that lists how each step could fail, traces the effect and the cause, scores the risk, and drives the highest-risk failures onto controls the floor runs every shift.
The word to hold onto is process. A PFMEA does not judge whether a product design is sound; it assumes the design is fixed and asks whether the plant can build it right, station after station, shift after shift. This guide is about the mechanics of building one: how a single worksheet row is really a failure chain, how the three scores attach to different links in that chain, how to split prevention from detection controls, and how the finished analysis becomes a control plan and a piece of a PPAP. For the full seven-step method, see the companion walkthrough on process FMEA step by step; this guide goes deep on the worksheet itself.
What is a PFMEA?
A PFMEA is a bottom-up, preventive risk analysis of a production process. A cross-functional team, operators, process and quality engineers, maintenance, breaks the process into steps, states what each step is supposed to do, lists the ways it could fail to do it, then scores how bad, how likely, and how catchable each failure is. It is one member of the broader FMEA family, the umbrella method for finding failures before they reach the customer.
What makes a PFMEA worth the meeting is that its fixes are process fixes. Because the failures it targets are things a plant controls every shift, a torque that drifts, a label swapped, a fixture loaded backward, a seal that skips a bead, the corrections are things the plant can actually do: a mistake-proofing device, a better setup, a stronger check. A PFMEA run before a launch or a changeover is cheap insurance; run after the first customer complaint, it is an autopsy.
What is the difference between a PFMEA, a DFMEA, and a general FMEA?
All three run the same scoring engine, severity, occurrence, and detection on 1-to-10 scales, and differ only in what they aim it at. The general FMEA method is the umbrella; a design FMEA (DFMEA) aims it at the product design; a PFMEA aims it at the process that builds the product. Getting them straight is the difference between fixing a failure and merely documenting one.
| Question | DFMEA | PFMEA |
|---|---|---|
| What it analyzes | The product design itself | The process that manufactures it |
| The question it asks | Can this design fail even if built perfectly? | Can the plant build this design consistently? |
| Example failure mode | Bracket cracks under rated load | Bolt under-torqued at station 4 |
| Typical fix | Change geometry, material, or tolerance | Mistake-proof, change setup, add a check |
| When it runs | Early, while the design can change | After the design freezes, in process planning |
The practical link is that a special characteristic the DFMEA flags does not just disappear. It flows into the PFMEA as something the process must guarantee, and then into the control plan as a checkpoint the floor runs. When that handoff breaks, a plant controls the easy dimensions tightly and the important one loosely.
How do you build a PFMEA row: the failure chain?
Every PFMEA row is one failure chain, and reading it as a chain is what keeps the analysis from turning into a form. The chain runs: the function is what the step must do; the failure mode is how it fails to do it; the effect is what that failure does to the next operation or the customer; the cause is why the failure happens, down in the work element; and the control is what you have in place today to prevent or catch it. Miss the chain and teams write a mode in the cause column, or an effect in the mode column, and the scores stop meaning anything.
The discipline that matters most: severity belongs to the effect and nothing else. A rare failure that can injure someone is still a severity 10, and its severity never drops because it happens seldom, only occurrence reflects how often. Keeping the three links separate is the entire reason a PFMEA can rank risk instead of just describing it.
How do you score severity, occurrence, and detection and set Action Priority?
You rate every failure mode on three 1-to-10 scales, all pointing the same way, higher is worse. Severity rates the effect, occurrence rates the cause, detection rates whether your current controls catch the mode before it ships. The deep dive on the scales lives in severity, occurrence, and detection; the short version is that detection is the one teams reverse, a 10 means you would not catch it, and that they score detection on the controls that exist today, not the ones they plan to add.
Once the three numbers are set, the current AIAG-VDA method does not multiply them into a single risk number. It uses an Action Priority of High, Medium, or Low from a lookup table that weights severity first, then occurrence, then detection. The full logic is in the AIAG-VDA FMEA method; the reason it exists is that a severity-first rule stops a rare, dangerous failure from being buried under a pile of high-occurrence nuisances the way a flat multiplied score could.
What is the difference between a prevention control and a detection control?
This is the split that most changes a PFMEA score, and the one most often gotten wrong. A prevention control stops the cause from happening and lowers the occurrence score, a fixture that only accepts a part loaded the right way, an interlock that will not let the machine cycle without the guard closed. A detection control catches the failure after it happens but before it ships and lowers the detection score, an end-of-line gauge, a vision check, a torque audit. List one in the other column and both occurrence and detection look better than they are, which is exactly how a PFMEA quietly lies to the team that wrote it.
The strategic point behind the split: prevention beats detection almost every time. A control that stops the defect from being made saves the cost of making and catching it, while a detection control still lets you build the bad part, then pay to find and sort it. A mature PFMEA pushes as much of the effort as it can from the detection column into the prevention column, from catching to preventing.
How do you turn a PFMEA into a control plan and a PPAP?
A PFMEA is not finished when the scores are filled in. It is finished when its confirmed controls become lines in a control plan the standing document that tells the floor what to check, how often, with what method, and how to react. Every prevention and detection control the PFMEA relied on should show up in the control plan, or the analysis was theater. The handoff is the whole point: the PFMEA decides where the risk is, and the control plan makes the plant act on it every shift.
For automotive and many other regulated supply chains, that same PFMEA is not just an internal tool, it is a deliverable. The PFMEA and the control plan are two of the required PPAP elements a supplier submits to prove the process is capable before production is approved. A weak or inconsistent PFMEA does not just leave risk on the floor; it gets a PPAP package rejected.
How do you build a PFMEA step by step?
The current automotive reference, the AIAG and VDA FMEA Handbook published jointly in 2019, uses a seven-step approach. Written plainly for a process team, the build looks like this.
- Plan and prepare. Fix the scope, one process or line, and pull the people who know it. Gather the inputs: the DFMEA, the process flow, past warranty and defect data.
- Analyze the process structure. Break the line into steps, and each step into its work elements, man, machine, material, method, so no failure mode gets skipped.
- Analyze the functions. State what each step must do in measurable terms. You cannot list the failures of a function you have not clearly defined.
- Analyze the failures. For each function, build the failure chain: the mode at the step, the effect downstream, the cause in the work element.
- Analyze the risk. Rate severity, occurrence, and detection, list the current prevention and detection controls, and set an Action Priority of High, Medium, or Low.
- Optimize. For high-priority rows, assign an action, an owner, and a date. Prefer lowering severity or occurrence over improving detection, then re-rate to confirm the risk actually dropped.
- Document the results. Record the analysis and carry the confirmed controls into the control plan and, where required, the PPAP. A PFMEA that never reaches the control plan changes nothing.
By the numbers: the standard behind the PFMEA
The PFMEA is a standardized method, not a local template. ASQ defines FMEA as a step-by-step approach for identifying all possible failures in a design, process, product, or service so problems can be corrected before they reach the customer (ASQ, What is FMEA?). The 2019 AIAG and VDA FMEA Handbook, used across the automotive supply chain, replaced the older Risk Priority Number with Action Priority and codified the seven-step process teams follow today (AIAG and VDA FMEA Handbook). Both make the same demand: score the same three factors honestly, and act on the highest risk first.
What are the most common PFMEA mistakes?
The biggest is treating the PFMEA as paperwork for an auditor. Fill in the worksheet to satisfy a checklist and every score lands around the middle, nothing stands out, and no action follows. A real PFMEA is uncomfortable; it surfaces failure modes people would rather not discuss.
The rest are familiar: scoring alone instead of as a team, so the numbers carry one person blind spots; inflating detection by counting controls you intend to add rather than the ones that exist; mixing prevention and detection controls so both occurrence and detection look too good; ranking on a bare number and missing a severity-10 row hiding at a modest score; and building the PFMEA once and never touching it again. Occurrence and detection are claims about how the process behaves right now, and those claims go stale the moment the process changes or the field teaches you a new failure.
How does a PFMEA stay honest over time?
A PFMEA is only as good as the data behind its scores, and this is where most of them quietly rot. Occurrence and detection are supposed to reflect how the process actually performs, but when defect counts, escapes, and downtime live on clipboards and month-end tallies, the team re-scores from memory instead of from reality. A failure mode trending worse should show up before it becomes a complaint, and it only can if the data reaches the team while it is still fresh.
That is where live capture changes a PFMEA from a document into an instrument. When every defect, escape, and stop is captured at the station and tied to the step and the cause, the PFMEA can be re-scored against what happened this week, not what someone remembers. That is the loop Harmony closes through station-level data capture feeding real occurrence and detection evidence back to the team that owns the analysis. CLS made exactly that shift, from failure data found the next morning to failure data visible during the shift, which is the difference between a PFMEA that ages into fiction and one that stays a true picture of process risk. No rip-and-replace.