Definition
Failure Mode and Effects Analysis, or FMEA, is a structured method for identifying potential failures, evaluating their effects, and prioritizing actions to reduce risk. It asks what an item or process must do, how that function could fail, why the failure could occur, and what controls address it.
FMEA is a preventive analysis rather than proof that every possible failure has been discovered. Its usefulness depends on technical understanding, cross-functional challenge, and follow-through on the actions identified.
Distinguish the function, failure, effect, and cause
A weak FMEA often places the same vague phrase in several columns. A useful analysis preserves the relationships between what is required, what could go wrong, what would happen, and why.
- Function or requirement: The intended performance of the item or process step. Define it clearly enough to evaluate whether it has been achieved.
- Failure mode: The way the function or requirement could fail. Describe the technical problem rather than merely stating “bad quality.”
- Effect: The consequence for the next operation, customer, or end user. The effect informs the assessment of severity.
- Cause: The mechanism or condition that could produce the failure. It should be specific enough to support a preventive action or investigation.
These distinctions help the team choose actions that address the mechanism. An inspection added after the failure occurs serves a different purpose from a control that prevents the cause.
Design FMEA and process FMEA answer different questions
Design FMEA addresses risks associated with the product or system design. Process FMEA addresses risks in the manufacturing or assembly process used to realize that design.
The analyses should inform one another where their requirements and effects connect. A process team should not assume that inspection can compensate for an unresolved design weakness, nor should a design review ignore foreseeable manufacturing constraints.
Confirm the method, scope, and customer requirements before assigning ratings. Teams should use a consistent applicable methodology rather than combining convenient scoring rules from unrelated templates.
A hypothetical process-risk entry
Consider a machining operation producing a component bore specified at 9.900 to 10.100 millimeters. During setup, an incorrect tool-offset value could cause the bore to exceed its upper specification.
| Analysis element | Hypothetical entry |
|---|---|
| Requirement | Produce the specified bore under the approved process |
| Failure mode | Bore diameter above 10.100 millimeters |
| Effect | Assembly fit or retention may not meet the product requirement |
| Potential cause | Incorrect offset restored during a setup change |
| Existing prevention | Setup instructions and controlled program access |
| Existing detection | Defined first-piece inspection and ongoing process monitoring |
| Proposed action | Prevent unapproved offset restoration and verify the release sequence |
| Effectiveness evidence | Controlled challenge tests and review of actual setup records |
The example intentionally assigns no universal severity score or numeric action threshold. Those assessments depend on the product's actual consequences, available evidence, and applicable rating tables.
The proposed control also requires validation. A software restriction is not effective merely because it has been installed if an operator can bypass it or an alternate setup route remains uncontrolled.
Do not reduce FMEA to one score
Some FMEA methods use a Risk Priority Number derived from severity, occurrence, and detection ratings. The AIAG and VDA method uses Action Priority based on combinations of those ratings rather than simply ranking the multiplied number.
Neither approach should be treated as a universal rule across all customers and industries. Use the specified method and do not infer that an apparently low aggregate score makes a severe consequence acceptable.
Better detection generally changes the assessment of detection, not the underlying severity of the failure's effect. A proposed lower rating should be supported by implemented, verified changes rather than the intention to make them.
Make the action record more important than the colored cell
Assign each action an owner, completion date, and required evidence. Distinguish proposed actions, implemented actions, and actions whose effectiveness has actually been demonstrated.
When an action changes the operating process, update the linked work instructions, control plan, training, and relevant approval records. A revised FMEA file alone does not change what happens at the machine.
Review residual risk using the applicable method and authority. Where a risk cannot be reduced sufficiently, escalate the design, process, sourcing, or launch decision instead of adjusting the score to fit the deadline.
Keep the analysis current
Use production experience, customer complaints, corrective actions, and process changes to challenge the existing analysis. A prior FMEA can provide a starting point, but copying it without checking the new context can preserve obsolete assumptions.
AI tools can help organize known failure information and flag inconsistent descriptions. They should not invent customer requirements, certify technical completeness, or assign final risk judgments without qualified review.
Frequently asked questions
- Is FMEA the same as root cause analysis? No. FMEA examines potential failures prospectively, while RCA investigates causes of an observed problem; lessons should flow between them.
- Does a lower risk score prove improvement? No. Improvement requires evidence that the relevant prevention or detection control changed and works.
- Can a supplier's FMEA replace the buyer's review? It is useful evidence, but the buyer still needs to understand the scope, assumptions, applicable requirements, and unresolved risks relevant to its decision.
Connect risk analysis to executable sourcing decisions
VPP uses supplier risk evidence to inform qualification, award, implementation, and performance discussions. The aim is to understand which risks are controlled, which remain open, and what actions the operating team must complete.