PFMEA – Process Failure Mode and Effects Analysis
A PFMEA (Process Failure Mode and Effects Analysis) is a structured method for proactively identifying, evaluating, and prioritizing potential failure causes in manufacturing processes before they occur in series production. It is a mandatory deliverable within the PPAP process under IATF 16949 and has been governed since 2019 by the harmonized AIAG-VDA FMEA Handbook, which replaced the legacy RPN scoring system with the Action Priority (AP) framework.
PFMEA vs. DFMEA: A Critical Distinction
A common source of confusion: many practitioners treat PFMEA and DFMEA as the same tool applied to different subjects. They are not – they address fundamentally different questions.
The DFMEA asks: Can the product design itself fail? The PFMEA asks: Can the manufacturing process produce a defective part from an otherwise correct design?
A practical example: a weld seam below minimum depth is a PFMEA issue if the root cause is incorrect welding parameters or insufficient operator qualification. If the design-specified weld depth is structurally inadequate to begin with, that is a DFMEA issue.
This distinction is not academic. It determines which team owns the problem, which countermeasures apply, and who is accountable for implementation.
PFMEA Structure Under AIAG-VDA 2019
The 2019 AIAG-VDA Handbook harmonized the previous AIAG 4th Edition standard with VDA Volume 4, fundamentally restructuring the analysis workflow into a seven-step approach:
| Step | Content |
|---|---|
| 1 – Scoping | Define analysis boundaries, process scope, and team |
| 2 – Structure Analysis | Decompose the process into process steps and elements |
| 3 – Function Analysis | Describe functions and requirements for each process step |
| 4 – Failure Analysis | Identify failure effects, failure modes, and failure causes |
| 5 – Risk Analysis | Rate Severity (S), Occurrence (O), Detection (D) → Action Priority (AP) |
| 6 – Optimization | Define, assign, and track risk-reduction actions |
| 7 – Documentation | Summarize results, track status, communicate findings |
Action Priority Instead of RPN: What Changed and Why It Matters
Teams still using the legacy RPN system (Risk Priority Number = S × O × D) are working to a standard that AIAG and VDA jointly retired in 2019. The RPN had a fundamental flaw: different combinations of S, O, and D could produce identical RPN values despite representing entirely different risk profiles. A failure with Severity 10, Occurrence 1, and Detection 1 yielded RPN 10 – the same value as S=1, O=2, D=5. From a risk management perspective, these are not comparable situations.
Action Priority resolves this through a matrix-based prioritization that treats Severity as the dominant dimension. The output is always one of three categories: H (High) – immediate action required, M (Medium) – action required, L (Low) – action optional, justification must be documented.
Practice warning: Many organizations have not yet migrated their FMEA templates to AIAG-VDA 2019 and continue working with RPN. During an IATF audit or OEM supplier audit, this can result in findings if the customer has defined the new standard as a requirement – which is already the case for most Tier-1 suppliers to German OEMs.
What Separates a Useful PFMEA from a Compliance Document
In practice, PFMEAs are frequently documents that exist to be presented at audits – not to actually manage risk. Common indicators of an ineffective PFMEA:
Failure causes are too generic: "Operator error," "machine wear," or "material variation" are not useful root causes – they are categories. A actionable cause is specific: "Incorrect torque setting when tightening M8 fasteners due to absence of torque verification on hand tool type X."
Detection ratings are unrealistically optimistic: A Detection score of 1 (certain detection) is assigned to a manual visual inspection. Manual visual inspection is not certain detection – it is uncertain detection performed with good intentions.
The PFMEA is not updated after production launch: A PFMEA is a living document. If new failure patterns emerge in production and the PFMEA is not updated, it loses its function as a control instrument.
Practical Example: PFMEA for a Welding Process
A Tier-2 supplier manufactures brackets for vehicle structures. Process step: MAG welding of a structural joint.
Failure mode: Weld depth below specification (< 4 mm instead of 4–6 mm)
Failure effect: Joint fails load test → rejection at OEM, potential field recall review (Severity: 8)
Failure cause: Welding current too low due to incorrect parameter setting after shift changeover
Current controls: Visual inspection of weld appearance by operator (Detection: 6), parameter set approval without digital verification (Occurrence: 5)
AP result: H – immediate action required
Defined action: Automatic parameter lock via MES integration, digital approval required before process start, ultrasonic spot-check measurement of weld depth
After implementation: Occurrence reduced to 2, Detection to 3, AP: L
FAQ: PFMEA in Manufacturing Practice
1. Is a PFMEA mandatory for every manufacturing process? Within the PPAP (Production Part Approval Process) under IATF 16949, a PFMEA is required for all new or changed processes that are part of a supplier approval submission to an automotive customer. Outside this context, it is methodologically recommended but not normatively mandated – unless the customer explicitly requires it.
2. Who needs to be involved in a PFMEA? The AIAG-VDA Handbook recommends a cross-functional team: process planning, quality assurance, manufacturing, maintenance, and – for safety-relevant characteristics – engineering. A PFMEA created solely by the quality department without production involvement consistently contains gaps in practically relevant failure causes.
3. How often does a PFMEA need to be updated? With every relevant process change, after customer complaints or internal quality events that reveal new failure patterns, and as part of regular reviews – at minimum annually for running productions.
4. What is the difference between a PFMEA and a Control Plan? The PFMEA identifies and evaluates risks. The Control Plan describes how the defined detection and prevention actions are implemented and monitored in ongoing production. Both documents must be consistent – characteristics, inspection methods, and frequencies in the Control Plan must reflect the actions defined in the PFMEA.
5. Can a PFMEA be created with software tools? Yes – and for organizations managing multiple concurrent FMEA projects, it is strongly recommended. Tools such as Plato SCIO, PTC Windchill FMEA, or Siemens Teamcenter provide structured AIAG-VDA-compliant templates, version control, and linkage to the Control Plan. A PFMEA managed in Excel is error-prone at scale and practically unmanageable from a version control perspective.
Strategic Value
A consistently maintained PFMEA is not overhead – it is preventive quality management with direct impact on scrap rate, rework ratio, and warranty costs. Organizations that use their PFMEA as an active control instrument identify systematic process weaknesses before they generate costs in series production. The financial leverage lies not in creating the document, but in the consistent implementation and follow-up of the actions defined within it.
Start working with SYMESTIC today to boost your productivity, efficiency, and quality!
