Your SQE just sent back your PFMEA with 47 comments. The severity ratings are inconsistent across similar failure modes, the detection controls listed don't match what's in your Control Plan, and at least a dozen process steps are missing from the analysis entirely. The PPAP is due in six days.
If this scenario sounds familiar, you already know that most Process FMEAs are built wrong from the start -- rushed to satisfy a checklist rather than built to actually analyze the process.
This guide covers how to build a PFMEA that holds up under customer review and IATF 16949 audit scrutiny.
What is a Process FMEA?
A Process FMEA (PFMEA) is a structured analysis of how your manufacturing process can fail, what the effects of those failures are, and what controls you have in place to prevent or detect them.
The emphasis is on process. A PFMEA does not analyze product design failures (that's the DFMEA's job). It analyzes the steps in your manufacturing process: machining, assembly, welding, heat treat, shipping, inspection -- every step where a process failure could produce a non-conforming part.
The governing standard for automotive suppliers is the AIAG FMEA Reference Manual, most recently updated as the AIAG-VDA FMEA Handbook (1st Edition, 2019). If you're still using the pre-2019 AIAG methodology, your customers may flag this during audits. The 2019 update is not optional for most Tier 1 and Tier 2 automotive suppliers.
PFMEA vs DFMEA: Quick Distinction
These two get conflated often, especially by suppliers who are design-responsible for some components but not others.
| PFMEA | DFMEA | |
|---|---|---|
| What it analyzes | Manufacturing/assembly process steps | Product design |
| Who owns it | Manufacturing/Process Engineering, supported by Quality | Engineering (design-responsible party) |
| When it's built | During APQP, before production launch | During product design, before PFMEA |
| PPAP element | Element 6 | Element 4 (design-responsible only) |
If you're a contract manufacturer who builds to customer drawings, you typically don't own a DFMEA -- but you always own a PFMEA.
The Structure of a PFMEA
A PFMEA is organized in columns. The 2019 AIAG-VDA format introduced a more structured approach than older methods. Here's what each column contains:
Process Step / Function
What is the manufacturing process step, and what is its function? Be specific. "Machining" is not a process step. "Mill datum face to 25.4mm +/-0.05mm" is a process step. Generic descriptions produce generic failure modes and miss real risks.
Potential Failure Mode
How could this process step fail to perform its function? Failure modes are process failures, not product failures. Examples:
- Datum face milled out of tolerance (overcut)
- Torque applied below minimum spec
- Wrong part revision used in assembly
- Heat treat temperature not reached
One process step typically has multiple potential failure modes.
Potential Effects of the Failure
If this failure mode occurs and is not detected, what happens to the customer? "Customer" means the next operation, the end assembly, and ultimately the vehicle or end user. Effects drive the Severity rating.
Severity (S)
A 1-10 rating of how bad the effect is if it reaches the customer. Severity is rated on the effect, not the likelihood of occurrence. A 10 means the failure could cause a safety issue or regulatory non-compliance. Severity ratings should be consistent across similar effects -- if "loss of vehicle control" is a 10 in one PFMEA, it is a 10 in every PFMEA. Inconsistent severity ratings are one of the first things auditors notice.
Severity cannot be reduced by process controls. If the design has not changed, a severity 9 characteristic stays at 9 regardless of how many inspection steps you add.
Potential Causes of the Failure
What process inputs, conditions, or human errors could cause this failure mode? Causes must be specific enough to be actionable. "Operator error" is not a cause. "Operator uses wrong torque wrench (not calibrated to spec)" is a cause.
Multiple causes per failure mode are expected and encouraged. Each cause gets its own Occurrence rating and controls.
Occurrence (O)
A 1-10 rating of how often this cause leads to the failure mode, given current prevention controls. Occurrence is rated based on your historical data, process knowledge, and the effectiveness of prevention controls already in place.
Prevention Controls
What is already in the process to prevent this cause from occurring? Mistake-proofing (poka-yoke), SPC, calibration intervals, work instructions, setup approvals -- these are prevention controls. Prevention controls reduce the Occurrence rating.
Detection Controls
What is in place to detect the failure mode or its cause before the part ships? Inspection steps, gauging, CMM checks, functional tests -- these are detection controls. Detection controls reduce the Detection rating.
Detection (D)
A 1-10 rating of how effective the detection controls are at catching the failure before it reaches the customer. A 1 means detection is nearly certain (e.g., 100% automated vision inspection). A 10 means no detection control exists or the control is unlikely to catch the failure.
The 2019 AIAG-VDA Shift: Action Priority Replaces RPN
This is the change most quality teams are still catching up on, and it's significant.
The legacy AIAG FMEA methodology used Risk Priority Number (RPN) as the primary risk metric:
RPN = Severity x Occurrence x Detection
The problem with RPN is mathematical: a severity 10 / occurrence 1 / detection 1 (RPN = 10) looks lower-risk than a severity 3 / occurrence 3 / detection 2 (RPN = 18) -- even though the first involves a safety-critical failure mode. RPN comparisons across FMEAs are meaningless, and action thresholds based on RPN cutoffs (e.g., "take action on anything over 100") have no statistical basis.
The 2019 AIAG-VDA FMEA Handbook replaced RPN with Action Priority (AP):
| AP Rating | Meaning |
|---|---|
| H (High) | Action required -- must reduce risk. Justify if no action taken. |
| M (Medium) | Action recommended -- consider reducing risk |
| L (Low) | Action at discretion of responsible team |
Action Priority is determined by a lookup table that prioritizes Severity first, Occurrence second, and Detection third. High Severity ratings (8-10) push toward High AP regardless of occurrence frequency -- which is the correct engineering logic.
Practical implication: If you're submitting PPAPs to customers who have adopted AIAG-VDA FMEA (most major OEMs now have CSRs referencing it), your PFMEA needs to include AP ratings, not just RPN. Using legacy format can trigger a non-conformance on submission review.
If your customer hasn't explicitly mandated AIAG-VDA, check their CSR. Ford, GM, BMW, and Volkswagen have all issued guidance aligned with the 2019 handbook.
The Alignment Requirement: PFMEA, Process Flow, and Control Plan
This is where most PFMEA packages fall apart.
The PFMEA does not exist in isolation. It must align with two other documents:
- Process Flow Diagram -- defines every step in the manufacturing process
- Control Plan -- defines how each characteristic is controlled during production
All three documents must tell the same story. Every process step in the Flow must appear in the PFMEA. Every detection control listed in the PFMEA must appear in the Control Plan. Every characteristic controlled in the Control Plan should trace back to the PFMEA analysis that justified controlling it.
Auditors call this the "golden triangle" of process quality documentation. A gap in alignment -- a PFMEA step missing from the Control Plan, a detection method in the PFMEA that doesn't match what the Control Plan specifies -- is a major finding under IATF 16949 Clause 8.3.3 and 8.5.1.
The most common alignment failures:
- PFMEA was built from a different process flow revision than the current Control Plan
- Detection controls updated in the Control Plan but not reflected in the PFMEA
- Process steps added after launch (capacity changes, line rebalancing) never analyzed in the PFMEA
- PFMEA numbering doesn't correspond to Control Plan characteristic numbering
Building these three documents in parallel, referencing the same process step numbering throughout, eliminates most alignment issues before they become audit findings.
Common PFMEA Mistakes That Get Flagged in Audits
1. Copy-Paste from the Last Program
The fastest way to build a PFMEA is to copy an existing one and change the part number. The result is a PFMEA filled with failure modes and controls that don't apply to this part or process. Auditors who know the product can spot this immediately. More importantly, genuine risks unique to this part or process never get analyzed.
2. Failure Modes Written as Effects
"Defective part produced" is an effect, not a failure mode. "Hole diameter undersize due to worn drill" is a failure mode. If your failure modes could apply to any manufacturing process in any industry, they're written at the wrong level of abstraction.
3. "Operator Training" as the Only Control
Listing "operator training" as the sole prevention or detection control for high-severity failure modes is a red flag. Training is not a reliable control -- it degrades over time, doesn't prevent every error, and can't be verified at the point of manufacture. Auditors will challenge any High Action Priority item where the only control is training.
4. Severity Ratings That Don't Match the DFMEA
For design-responsible suppliers, the effects and severity ratings in the PFMEA should be consistent with the DFMEA. If the DFMEA rates a dimensional non-conformance as severity 8 (loss of primary function), the PFMEA failure mode that could produce that non-conformance should not be rated severity 4. Traceability between the two documents is expected.
5. No Review or Revision History
A PFMEA with no revision history, or one that was last updated at launch five years ago, signals that the quality system isn't maintaining it. Every significant process change, corrective action, or engineering change should trigger a PFMEA review. The revision history is evidence that the PFMEA is a living document, not a launch-time artifact.
6. Treating Detection as the Primary Risk Reduction Strategy
Adding inspection steps is the default risk reduction approach for many teams. But detection controls don't prevent defects -- they catch them. For high-severity failure modes, prevention controls (poka-yoke, SPC, process design) are the right answer. A PFMEA where the primary risk reduction is "we added a check" for every High AP item will not satisfy a customer audit on its own.
PFMEA in the Context of PPAP
PFMEA is Element 6 of the 18 PPAP elements. Customers reviewing a Level 3 PPAP package will review the PFMEA in detail, and they will cross-reference it against the Control Plan (Element 7) and Process Flow (Element 5).
The most common PPAP rejection reasons tied to PFMEA:
- PFMEA does not include all process steps shown in the Process Flow
- Detection controls in the PFMEA do not match the Control Plan
- No evidence of team review (required: cross-functional team sign-off)
- Action Priority items with no documented closure or justification for non-action
- PFMEA revision level doesn't match other PPAP documents
Before submitting any PPAP package, run a deliberate alignment check: every step in the Flow, every control in the Plan, every Action Priority item accounted for. This takes time up front and saves the back-and-forth that eats programs.
For more on PPAP requirements and submission levels, see What is PPAP? A Complete Guide for Automotive Suppliers. For the broader quality planning context that feeds PFMEA development, see What is APQP?.
The Bottom Line
A PFMEA is only as good as the process knowledge behind it. Rushed, generic, copy-pasted FMEAs don't just fail audits -- they fail to identify the risks that cause quality escapes. The quality engineers who build FMEAs well are the ones who understand the process well enough to articulate exactly how it can fail and what it takes to prevent it.
The AIAG-VDA 2019 update raised the bar. Action Priority logic, alignment requirements, and the expectation that FMEAs are living documents -- these are not optional for suppliers working in the modern automotive supply chain.
Build the PFMEA like it matters, because in the event of a field escape, it becomes exhibit A.
Streamline PFMEA Management Across Your Programs
QualityEngineer.ai helps quality teams build, maintain, and cross-reference PFMEA documents alongside their Control Plans and Process Flows -- with AI-assisted gap detection to flag alignment issues before your customer does.
Try it free at app.qualityengineer.ai
No implementation consultant. No 6-month rollout. Built for quality engineers who need it to work now.
QualityEngineer.ai -- Built by quality engineers, for quality engineers.