01
What should happen?
Start with the product or process requirement. A team cannot identify failure until the expected result is clear.
Example: The wheel must rotate smoothly.
PFMEA Framework
PFMEA is not paperwork. It is a manufacturing prevention system.
A practical framework connecting product requirements, process risks, control decisions, pilot validation, and reusable engineering knowledge.
The engineer owns the logic.
The cross-functional team validates the logic.
PFMEA
Requirement
Control
Evidence
Risk
5
Questions to understand PFMEA in 60 seconds
7
Fields required to write one correct PFMEA row
3
Control levels: Tell, Check, Prevent
7
Closure gates before an action is truly complete
01 · PFMEA in 60 Seconds
Five questions turn uncertainty into prevention.
Scroll through the cards. Each question builds on the one before it, moving from product intent to validated manufacturing control.
02
What can fail?
Describe the failed output, not the machine setting. The failure mode should explain what becomes wrong.
Example: The wheel is too tight and cannot rotate.
03
Why does it fail?
Identify the mechanism behind the failure: Man, Machine, Method, Material, Measurement, or Environment.
Example: Press depth varies because the setting is not locked.
04
How do we control it?
Select the appropriate control level: tell the operator, check the process, or prevent the error from occurring.
Example: Controlled press depth plus a Go/No-Go gauge.
05
How do we prove it?
Validate the control in pilot production. Evidence converts an engineering idea into a closed action.
Example: Pilot data confirms 100% smooth wheel rotation.
02 · Input Readiness
Do not start a PFMEA meeting with blank thinking.
The engineer enters the meeting with product knowledge, a process flow, and initial failure hypotheses. The meeting validates the logic—it does not create it from zero.
Collect Inputs
Requirements, specifications, BOM, drawings, process flow, fixtures, samples, and historical defects.
Form the First Hypothesis
Identify critical characteristics, process risks, possible failure mechanisms, and control gaps.
Enter the Review Prepared
Bring a pre-filled PFMEA, clear questions, and proposed controls for cross-functional validation.
Required Input Documents
- Customer and regulatory requirements
- Product specification and critical-to-quality characteristics
- BOM and material specifications
- Drawings, tooling plan, and decoration plan
- Process flow, line layout, machine, and fixture plan
- Approved samples, limit samples, and acceptance criteria
- Previous CAPA, pilot defects, and lessons learned
Pre-Meeting Engineer Output
- Process flow understood
- Critical product characteristics identified
- First failure hypotheses prepared
- Known historical issues carried forward
- Initial control gaps highlighted
Rule:
Bring the process flow and first failure hypothesis
into the PFMEA meeting.
Before First Review
Pre-fill PFMEA and prepare failure hypotheses.
After Engineering Trial
Update with actual product and process findings.
Before Extended Pilot
Confirm action plans for high risks.
Before Pilot Build
Release L3 controls, WI, and Control Plan.
After Pilot Build
Map the Top 3 defects back to PFMEA.
Before Validation Build
Update PFMEA and confirm closure evidence.
Mass Production
Lock lessons learned and reuse them.
Stage names may differ between organizations.
The prevention and validation logic remains the same.
03 · One Correct PFMEA Row
One row. One bad outcome. One main cause. One control decision.
1
Requirement
What should the process achieve?
2
Failure Mode
What output can be wrong?
3
Effect
Why does it matter to the customer?
4
Cause
Why can it happen?
5
Current Control
How is it controlled today?
6
S / O / D
How serious, likely, and detectable?
7
Action + Evidence
What changes, who owns it, and what proves it?
Simple Example: Wheel Assembly
Requirement
Wheel rolls smoothly.
Failure
Wheel is too tight or cannot roll.
Effect
Main play function fails.
Cause
Press-depth variation.
Current Control
Sampling function check.
Action
Controlled press, Go/No-Go jig, and 100% check.
04 · Write Clearly
Do not mix failure mode, effect, and cause.
F
Failure Mode
What went wrong in the output?
- Gap too large
- Weak weld
- Wheel cannot roll
- Date code unreadable
E
Effect
Why does it matter?
- Customer rejection
- Function failure
- Safety concern
- Traceability loss
C
Cause
Why can it happen?
- Parameter not locked
- Fixture worn
- Wrong material
- Operator sequence missed
Quick check:
If the failure mode sounds like a machine setting,
it is probably a cause.
05 · Practical Scoring
Use questions, evidence, and process reality—not feeling.
S
Severity
If the failure escapes, how serious is the impact on safety, compliance, function, or the customer?
O
Occurrence
How likely is the failure based on process weakness, instability, manual judgement, and historical recurrence?
D
Detection
Can the current control detect the failure before the next process or shipment?
Rule:
Severity normally remains unchanged after action.
Prevention reduces Occurrence.
Stronger verification improves Detection.
06 · Control Decision
L1 Tell — L2 Check — L3 Prevent
Stronger risk requires stronger control. The goal is to move from instruction, to verification, to built-in prevention.
L1 · Tell
WI / Standard Work
Use when a clear method, sequence, and visual standard are sufficient.
- Work Instruction
- Training
- Visual limit
L2 · Check
WI + Control Plan
Use when measurement, frequency, tolerance, and reaction plans are required.
- Control Plan
- Gauge or checklist
- Reaction plan
L3 · Prevent
WI + CP + Poka-Yoke
Use for high risk, repeat defects, safety or function risk, and manual-judgement risk.
- Fixture
- Sensor or interlock
- Automation
- Validation evidence
Classification rule:
If a tool or device is required to prevent the error,
classify the action as L3.
07 · Ownership and Evidence
An action without an owner and evidence is only an idea.
| Activity | Owner | Support | Due | Evidence | Output |
|---|---|---|---|---|---|
| Pre-fill PFMEA | Product Engineering | IE / ME / QA | Before meeting | Draft PFMEA | Failure hypotheses ready |
| Define controls | PE + QA | IE / Production | Before pilot | WI / CP / Poka-Yoke code | L1 / L2 / L3 decision |
| Release documents | IE / QA / PE | Production | Before pilot | Released WI, CP, and tool evidence | Shopfloor control ready |
| Validate action | PE + QA | Production | During pilot | Data, photo, video, or report | Actual residual risk |
Traceability rule:
The same control code should appear in PFMEA,
Work Instruction, Control Plan,
tool identification, and validation evidence.
08 · Closure Criteria
No evidence means not implemented. No pilot validation means not closed.
1
Action implemented
2
WI and Control Plan updated
3
Tool or control code available
4
Owner and due date recorded
5
Evidence attached
6
Pilot effectiveness verified
7
Actual residual RPN confirmed
① Initial RPN
② Target RPN
③ Actual Residual RPN
Rule:
Only pilot-validated results may be recorded
as actual residual RPN.
09 · Pilot Checkpoint
Use the pre-pilot PFMEA as Baseline 0.
Baseline 0
Freeze the pre-pilot PFMEA.
Pilot Run
Collect defects, yield, function, safety, and control data.
Pareto Top 3
Map the actual Top 3 defects back to PFMEA.
Decision
Was the risk captured, controlled, or missed?
Update
Strengthen the control or add a new PFMEA row.
1 · Captured and Controlled
Retain the control and standardize it.
2 · Captured, but Control Failed
Strengthen the control level and validate again.
3 · Not Captured
Run 5-Why analysis and add a new PFMEA row.
10 · Closed-Loop Learning
Every defect must become reusable engineering knowledge.
PFMEA is alive only when actual production learning returns to the risk model and improves the next program.
PFMEA
Learns
Learns
Project Received
Collect Inputs
Pre-Fill PFMEA
Team Review
Pilot + Pareto
Improve Control
Validate Result
Reuse Lesson
“PFMEA becomes alive when every defect becomes new engineering knowledge.”
Portfolio-safe presentation:
company names, customer names, project codes,
internal product data, and confidential documents
have been generalized or removed.
See how L3 prevention is standardized.
Explore the Poka-Yoke Library, or return to the Engineering Systems hub.