A process FMEA (PFMEA) is a structured, line-by-line analysis of how a manufacturing process could fail to make a good part, scoring each failure mode by severity, occurrence, and detection so the highest-risk steps get mistake-proofed before they reach the customer. It analyzes the making of the product, not the design.
The word to hold onto is process. A PFMEA does not ask whether the product design is sound; it assumes the design is fixed and asks whether the plant can build it right, shift after shift, at every station. That makes it the FMEA that lives closest to the floor, and the one most likely to change what an operator actually does tomorrow. This guide walks the seven-step method line by line, shows how a PFMEA differs from a design FMEA and from the general FMEA method, and how its scores turn into real controls on the line.
What is a process FMEA?
A process FMEA is a bottom-up, preventive risk analysis of a production process. A cross-functional team breaks the process into steps, states what each step is supposed to do, lists the ways it could fail to do it, traces the effect on the customer and the cause on the floor, then scores how bad, how likely, and how catchable each failure is. The American Society for Quality describes 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?).
Applied to a process, that method targets things a plant controls every shift: a torque that drifts, a label that gets swapped, a fixture loaded backward, a seal that skips a bead. Because those are process causes, the fixes are process fixes, better setup, a poka-yoke, a stronger check, not a redesign. A PFMEA done before a launch or a changeover is cheap insurance; done after the first customer complaint, it is an autopsy.
How is a process FMEA different from a design FMEA and a general FMEA?
All three share the same scoring engine, severity, occurrence, and detection on 1-to-10 scales, and only differ in what they point that engine at. The general FMEA method is the umbrella; a design FMEA (DFMEA) aims it at the product; a PFMEA aims it at the process that builds the product. Getting the three straight is the difference between fixing a failure and documenting it.
| Question | Design FMEA (DFMEA) | Process FMEA (PFMEA) |
|---|---|---|
| What it analyzes | The product design itself | The manufacturing and assembly process |
| The question it asks | Can this design fail even if built perfectly? | Can the plant build this design consistently? |
| Failure-mode example | Bracket cracks under rated load | Bolt under-torqued at station 4 |
| Typical owner | Design or product engineering | Manufacturing or process engineering, quality |
| Typical fix | Change geometry, material, or tolerance | Mistake-proof, change setup, add a check |
| When it runs | Early, while the design can still change | After the design freezes, during process planning |
The practical takeaway: the two are a relay, not rivals. A design characteristic the DFMEA flags as critical becomes a special characteristic the PFMEA must guarantee the process can hold, and later a checkpoint in the control plan the floor runs every shift. When that handoff breaks, the plant controls the wrong dimensions tightly and the important one loosely.
How do you score severity, occurrence, and detection in a PFMEA?
You rate every failure mode on three separate 1-to-10 scales, and all three point the same way, higher is worse. What each measures is different, and keeping them apart is what makes the numbers mean anything.
| Factor | What it measures on a process | 1 means | 10 means |
|---|---|---|---|
| Severity (S) | How bad the effect on the customer or next operation | No noticeable effect | Safety hazard or regulatory breach, often without warning |
| Occurrence (O) | How often the process cause is likely to happen | Cause is prevented by design of the process | Failure is almost certain, controls are absent |
| Detection (D) | How likely current controls catch it before it ships | Fault is detected automatically, cannot pass | No control, or the defect is not detectable |
Two rules keep a PFMEA honest. First, severity belongs to the effect not the cause: a rare failure that can hurt someone is still a severity 10, and severity never drops because occurrence is low. Second, detection scores the controls you have today not the ones you plan to add. If the only thing catching a mislabel is an operator glancing at the box, that is a weak control and a high detection number, however good the operator is. In the AIAG-VDA method, occurrence and detection are also split by type: a prevention control lowers occurrence, and a detection control lowers detection, and confusing the two is a common scoring error.
How do you build a process FMEA step by step?
The current automotive reference, the AIAG & VDA FMEA Handbook published jointly in 2019, lays out a seven-step approach that replaced the older three-column workflow. Written plainly for a process team, the flow is this.
- Plan and prepare. Fix the scope, one process or line, what is in and out, and pull together the people who know it: operators, process and quality engineers, maintenance. Gather the inputs, the DFMEA, the process flow, past warranty and defect data.
- Analyze the process structure. Break the line into process steps, and each step into its four work elements, man, machine, material, and method. This structure tree is the map the rest of the analysis hangs on.
- Analyze the functions. For each step, state what it is supposed to do in measurable terms, and the requirement it must meet. You cannot list the failures of a function you have not clearly defined. A process map built beforehand makes this step far faster.
- Analyze the failures. For each function, ask how it could fail, then chain it: the failure mode at the step, its effect at the next step and the customer, and its cause down in the work element. A fishbone diagram helps the team surface causes they would otherwise miss.
- Analyze the risk. Rate each line on Severity, Occurrence, and Detection, listing the current prevention control against occurrence and the current detection control against detection, then set an Action Priority (High, Medium, or Low).
- Optimize. For the high-priority lines, assign an action, an owner, and a date. Lower severity by changing the process to remove the effect, lower occurrence by mistake-proofing the cause, or improve detection with a better check. Re-rate after the change to confirm the risk actually dropped.
- Document the results. Record the analysis, the actions, and the residual risk, and carry the confirmed controls forward into the control plan the floor runs every shift. A PFMEA that never reaches the control plan changes nothing.
By the numbers: how PFMEA risk is ranked
For decades, FMEA teams multiplied the three ratings into a Risk Priority Number (RPN) from 1 to 1,000 and chased the biggest numbers. ASQ still documents the three factors on 1-to-10 scales with RPN as their product (ASQ, FMEA). The 2019 AIAG & VDA FMEA Handbook, used across the automotive supply chain, replaced the single RPN with Action Priority (AP), which sorts each failure mode into High, Medium, or Low using a lookup table that weights severity most heavily (AIAG & VDA FMEA Handbook). The change fixed a real flaw: RPN treated all three factors as equal, so a low-severity nuisance with high occurrence could outscore a rare but safety-critical failure and send a team to work on the wrong thing. Both methods score the same three factors; they differ only in how they turn the scores into a priority.
What are the most common process FMEA mistakes?
The biggest is treating the PFMEA as paperwork for an auditor instead of a working tool. Fill in the worksheet to satisfy a checklist and the scores go soft, everything lands around 100, nothing stands out, and no action follows. A real PFMEA is uncomfortable: it surfaces failure modes people would rather not discuss.
The other frequent errors: scoring alone instead of as a team, so the numbers reflect one person's blind spots; inflating detection scores by counting controls you intend to add rather than the ones that exist today; mixing prevention and detection controls so occurrence and detection both look better than they are; ranking on a bare number and missing a severity-10 line hiding at a modest score; and, most common of all, 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 process FMEA connect to the floor?
A PFMEA is the front end of process risk, and it hands off to everything downstream. Its confirmed controls become lines in the control plan; its high-occurrence causes become targets for mistake-proofing and for statistical process control on the line; and when a defect still escapes, the corrective action record links straight back to the PFMEA line that predicted it, so you can ask why the ranking was wrong. Used this way, a PFMEA is not an isolated form; it is where a plant decides where to spend its quality effort inside the broader discipline of lean manufacturing and it is a direct lever on the cost of quality.
The scores are only as good as the data behind them, and this is where most PFMEAs 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. When that data is captured live at the point of work, every defect, every escape, every stop tied to the step and the cause, the PFMEA can be re-scored against reality instead of recollection, and a failure mode trending worse shows up before it becomes a complaint. That live feedback is what Harmony gives a plant through station-level capture and it is the difference between a PFMEA that ages into fiction and one that stays a true picture of risk. CLS made that shift, from failure data found the next morning to failure data visible during the shift, which is exactly the loop a PFMEA needs to keep earning its place. No rip-and-replace.