Failure Mode and Effects Analysis (FMEA)
Failure Mode and Effects Analysis (FMEA) is an integral part of product and process design activity. The FMEA process is applicable in Design of Products, Processes and Services. FMEA is a universal tool that is used in any industry or service, where risk of failure has detrimental effects on the users of a product, process or service. The primary reason for performing a FMEA is taking action to prevent a failure, improve a design control through testing or evaluation, or a process control through inspection.
What is FMEA?
FMEA is an analytical methodology used to ensure that potential problems have been considered and addressed throughout the product and process development cycle. FMEA helps to:
- Discover the potential failures, their potential cause mechanisms and the risks designed into a product or process
- Develop actions that reduce the risk of failure
- Follow-up and evaluate the results of actions on the risks that were discovered
A Design FMEA (DFMEA) is performed prior to the completion of the design of the product. A Process FMEA (PFMEA) is performed prior to the release of the design for the process. PFMEAs should ideally be conducted when DFMEAs provide special characteristics or when new process technology is planned. It is critical that a FMEA be performed with sufficient time to take counter measures against the risk and still capture the changes within the design before its release. Quality-One FMEA Training and FMEA Facilitation techniques are the “Best-in-Class” and provide a great understanding about how a FMEA works.
How are FMEAs Conducted?
FMEAs are conducted by a core team of three or four people with supporting Subject Matter Experts (SME). This group creates the Cross Functional Team (CFT). Ideally, the CFT should be selected from disciplines that have a slightly different view of the product or process under investigation. The synergy created by the CFT is what makes FMEA so powerful.
A single person will not be able to develop a comprehensive FMEA without input from the CFT. It is easy to tell when a FMEA is created by one individual rather than the team. Such FMEAs are typically generated to satisfy customer requirements but have very little value to the program or organization. FMEAs are a means to achieve better quality products and processes. Many Original Equipment Manufacturers (OEMs) require the proper use of FMEA. Industry standards in diverse industries, such as automotive, medical device manufacturing, aerospace, chemical processing and more, have been developed to utilize the power of FMEA.
1. FMEA Pre-Work
To ensure the FMEA will work smoothly through the development phases, an investigation of past failures and preparatory documents is required. Preparatory documents may include:
- Failure Mode Avoidance (FMA)
- Boundary/Block Diagram (For the DFMEA)
- Parameter Diagram (For the DFMEA)
- Process Flow Diagram (For the PFMEA)
The purpose of Pre-Work is to create a list of:
- Known causes from surrogate products
- Potential causes from interfaces
- Potential causes from design choices
- Potential causes from noises and environments
- 6 M’s / Fishbone list of potential causes from past FMEAs and Eight Disciplines of Problem Solving (8D)
2. Path 1 Development (Failure Modes)
Path 1 consists of inserting the Functions, Failure Modes, Effects of Failure and Severity Rankings. The Pre-Work documents assist in this task by simply taking information previously captured to populate the first 4 to 7 columns (depending on the worksheet selected) of the FMEA.
Functions should be written in verb-noun context. Each function must have an associated measurable. Functions may include:
- Wants, Needs and Desires translated
- Specifications of a Design
- Government Regulations
- Program-specific Requirements
- Characteristics of Product to be analyzed
- Desired Process Outputs
Failure Modes are Anti-Functions; Effects are the results of failure, where each individual Effect is given a Severity Ranking. Actions are considered at this stage if the Severity is 9 or 10.
3. Path 2 Development (Causes & Occurrences)
Causes are selected from the Boundary Diagram, Parameter Diagram, or past failures and placed in the Cause column when applicable to a specific failure mode.
The columns completed in Path 2 are:
- Causes from ION or 6M’s
- Preventions from Standard Work and previously successful designs
- Occurrence Rankings for each Cause
- Classification of Special Characteristics, if indicated
- Actions are developed to address high risk Severity and Occurrence combinations, defined in the Q-1 Criticality Matrix.
4. Path 3 Development (Testing & DV Development)
Path 3 Development involves the addition of Detection Controls to prevent a design flaw (for Design FMEA) or Cause and/or a Failure Mode that may reach a customer (for Process FMEA).
The columns completed in Path 3 are:
- Detection Controls
- Detection Ranking
Actions are taken to improve the controls if they are insufficient to the risks determined in Paths 1 and 2.
5. Action Priority & Assignment
The Actions that were previously determined in Paths 1, 2 or 3 are assigned a Risk Priority Number (RPN) for Action follow-up. RPN is calculated by multiplying the Severity, Occurrence and Detection Rankings for each potential failure / effect, cause and control combination. Actions should not be determined based on an RPN threshold value. This is done commonly and is a practice that leads to poor team behavior.
6. Actions Taken / Design Review
Actions indicated from the FMEA analysis are closed through the collection of data and observations after a counter measure has been taken. The purpose of an FMEA is to discover and mitigate risk. FMEAs which do not find risk are considered to be weak and non-value added. Effort of the team did not produce improvement and therefore time was wasted in the analysis.
7. Re-ranking RPN & Closure
After successful confirmation of risk mitigation actions the core team or team leader will re-rank the appropriate ranking value (Severity, Occurrence or Detection). The new rankings will be multiplied to attain the new RPN.
The Old RPN is compared to the new RPN and the relative improvement made to the design or process has been confirmed. Columns completed in step 7:
How Do I Analyze a FMEA? – Criticality vs. RPN
The RPN is often used to determine the relative risk of a FMEA line item. In the past, RPN has been used to determine when to take action. RPN should not be used this way. Quality-One recommends never using RPN for action determination.
Actions are determined by Criticality. Criticality is the combination of Severity and Occurrence, as displayed in the Q-1 Criticality Matrix.
The actions, when completed, move the risk from its current position in the Q-1 Criticality Matrix to a lower risk position. Items with the greatest risk are based on Severity of the Effect combined with the likelihood of Occurrence in a specific Cause. When risk is determined to be too high, Q-1 recommends the priority of action to be applied as follows:
- 1.Error Proofing
- a. Failure Mode (Only Severity of 9 or 10)
- b. Cause with High Occurrences
- 2.Improve Potential Process Capability
- a. Increase Tolerance (Tolerance Design)
- b. Reduce Variation of the Process (Statistical Process Control and Process Capability)
- 3.Control Plan Methodology (Improve Controls)
- a. Mistake Proofing of the Tooling or Process
- b. Improve the Inspection and Evaluation Techniques
Failure Mode and Effects Analysis from Quality-One; Discover the Value!
Design Failure Mode and Effects Analysis (DFMEA) is used to uncover design risk, which includes possible failure, degradation of performance and potential hazards. The DFMEA is typically the first FMEA tool used in product development. When performed properly, there are many benefits of DFMEA. Quality-One has been facilitating DFMEAs for decades and has developed a list of helpful activities to make your DFMEA beneficial.
In a FMEA, risk is the substitute for failure. This risk is treated as if the failure had already occurred and corrective action is required.
Create an Effective DFMEA Cross Functional Team
Cross Functional Teams (CFTs) have been developing DFMEAs since the late 1940’s, when they were used to uncover risk of failure on aerospace products. The DFMEA uncovers opportunities to prevent failure prior to an actual failure. The DFMEA treats risk as actual failure and therefore takes actions as if a failure has already occurred.
Path 1 Team includes:
- Responsible Design Engineer
- Contrarian of the same Function
- Data or Reliability Function / Facilitator
Path 2 Team includes:
- Members from Path 1
- Selected Subject Matter Experts (SMEs) related to high severity Failure Modes
- Neighboring Systems (interfaces)
- Process Engineer of the targeted process
Path 3 Team includes:
- Members from Path 1
- Testing or CAE Engineers
Collect Pre-Work for Faster DFMEA Development
Design FMEA can be brutal if the correct information is not available during development. Some of the information that is most beneficial is listed as follows:
- Comprehensive list of Past Failures and Lessons Learned from various sources
- Problem Solving Activities (such as 8Ds)
- Warranty and Recall Information
- Plant Problems relating to Scrap and / or Rework
- Past Test Failures
- Applicable legacy documents
- Similar Product FMEAs
- Fault Tree Analysis (FTA)
- Test Results
- Similar or Surrogate Design examples or advanced prototypes
- Engineering Drawings and CAD / Math Data
- Statistical Data and past Tolerance Studies
- Robustness Tools to assist in discovering Causes of Failure in Interfaces and Noises
- Boundary Diagram
- Reliability Block Diagram
- Parameter Diagram
Use an Efficient DFMEA Path Development
Many teams start a DFMEA by opening a blank form and filling it in horizontally across the page. This approach is very inefficient. DFMEAs should be created vertically down the page in three paths.
- Path 1 includes Requirements, Potential Failure Modes, Effects of Failure and Severity Ranking
- Path 2 includes Causes, Prevention Controls, Occurrence and Class Column (if applicable)
- Path 3 includes Detection Controls
Determine Recommended Actions as Soon as Possible
When using the Three-Path Model and the FMEA Risk and Detection Matrices, the need for actions becomes apparent prior to calculating the Risk Priority Number (RPN). Actions should include the person responsible and timing for completion. A milestone date linked to a project timeline may also be used for the completion date.
pic slash pic
The RPN (Risk Priority Number) is the product of Severity, Occurrence and Detection (RPN = S∗O∗D), and is often used to determine the relative risk of a DFMEA line item. In the past, RPN has been used to determine when to take action. Quality-One does not recommend using an RPN Threshold to determine when an action should be taken. Actions are created based on the following:
- High Severity of 9 or 10 (Can a design be changed to eliminate a Failure Mode?)
- High Occurrence when linked to severity
- High Detection linked to high Occurrence-Severity items
The Detection column in the DFMEA is an input into the Design Verification Plan & Report (DVP&R). Design Controls should be developed to excite failure modes through their causes and related mechanisms. The likelihood of Occurrence provides the test planning activity with possible changes to current test or the need of an additional test if the cause/mechanism is not currently used in the test.
Design Review must address risks to ensure prevention of the risk in the final design. The Design Review and DFMEA relationship has historically been poor. DFMEA provides risks, which are substitutes for failure. The risks must be treated as if a test has failed and requires counter measures or a design change. Using DFMEA risks as Design Review topics will provide a focal point for engineers prior to design release.
The illustration above depicts a process flow of the design review, where inputs come from many sources (upper left) and eventually are mitigated and tracked using a ROY chart (illustrated below). ROY stands for Red, Orange, and Yellow. These colors correspond with the FMEA Criticality Matrix.
- Red is associated with Severity of 9 or 10 and drives design changes to eliminate Failure Modes
- Orange is associated with high Severity and Occurrence combinations and drives Occurrence actions
- Yellow is a transition zone which may drive actions to lower Occurrence or Detection Rankings
A Pareto of Risk and/or a Glideslope Chart can be used to discuss progress in Project or Program Gateway Reviews.
Process Failure Mode and Effects Analysis (PFMEA) is often developed at the time when a new product or process is being introduced. This activity is very beneficial when ordering tooling and equipment as well as determining process controls. PFMEA is a collection of possible causes and mechanisms for failure modes, as determined by a team. It can also play an important role in day to day improvement and problem solving.
In a FMEA, risk is the substitute for failure. This risk is treated as if the failure had already occurred and corrective action is required.
Using PFMEA in Problem Solving
The relationship between Eight Disciplines of Problem Solving (8D) and Process FMEA (PFMEA) is very strong. When a problem is encountered, the 8D is often used to find a Root Cause and permanent solution. The PFMEA may provide many of the 8D inputs. Many organizations struggle with the relationship between 8D and PFMEA. Quality-One has developed a process which seamlessly integrates the 8D and PFMEA to ensure the tools are always used together.
The PFMEA and 8D share many similarities:
- 8D Symptoms are similar to PFMEA Effects
- 8D Problem Statements and Problem Descriptions are similar to PFMEA Failure Modes
- 8D Possible Causes and Root Causes are similar to PFMEA Causes
- 8D Escape Points are PFMEA Process Controls
Using PFMEA in Daily Continuous Improvement
The PFMEA is often placed on a shelf and forgotten about after initial development. When done properly by a Cross Functional Team (CFT), PFMEA can be used by Kaizen or Continuous Improvement teams.
PFMEA Development activities can be shortened significantly by reviewing all known data and preselecting areas which are new, changed, historical issues or impacted by the environment. The Quality-One PFMEA Legacy Matrix (shown below) allows known and brainstormed Failure Modes and Causes/Mechanisms to be captured in an easy to use spreadsheet. The Q-1 Legacy Matrix has been constructed from many years of experience in a variety of industries and is used to shorten the time required to develop a valuable and focused PFMEA. Elements on the Matrix include:
- Technology or Process Names (Verbs and Synonyms)
- Failure Modes (Historical and Perceived)
- Causes by Six Categories (Man – Human Factors, Method, Material, Machine, Measurement and Environment)
- Process Controls Detection
- Process Controls Prevention
- Historical Severity Rankings
- Historical Linkage between Failure Modes and Causes
- Linkage between Causes and Prevention approaches
A PFMEA is not always easy to develop. Thorough PFMEA Development is critical to receive value from the exercise, but should not translate into an excessive amount of time. The Quality-One Methodology and PFMEA Facilitation Techniques help to reduce the time needed to develop a thorough and beneficial PFMEA.
Collecting and using a database of legacy information for PFMEA Development ensures the same problem will never have to discussed and brainstormed more than once. Failure Modes and Causes can be quickly reviewed for their relevance for the specific PFMEA being developed. Process Controls are linked and easily developed into the Control Plan.
Operator Error is often used in PFMEA as a Cause of Failure. Although operators can make errors, Operator Error is not an acceptable Cause of Failure because it is not actionable.
Processes must be designed to expect that operators wish to do the correct thing. Training and providing Work Instructions and Procedures are not robust enough for repetitive processes. Poor Training and / or Work Instructions are inadequate secondary choices to Operator Error. The real issue is the operator discovers errors made in the process design. The process designer / engineer must strive to engage operators into the process and help reduce the number of possible errors available for operators to find.
Quality-One approaches Operator Error by considering the interfaces of the process that the operator is engaged in. The process should be designed to permit communication between the process and the operator.
Processes designed with operators provide feedback to the process status. This process interface can be passive or active. Passive interfaces use visual cues, such as seeing parts remaining in a kitted bin or tactile feedback when installing a part or engaging a clamp. Active interfaces use logic, sounds, lights, process interruption or lockouts as feedback. Ultimately, Error and Mistake Proofing are deployed in order to eliminate or reduce errors discovered by operators.
With the process interface in mind, there is a cascade from Operator Error (Level 1), down to specific actionable topics (Level 2 and 3 Causes).
- Work Station Design
- Documentation and Training
- Assists and Tool Design
- Cognitive Attention and Concentration
Operator Error is not an acceptable Cause of Failure because there is no direct action that can be taken. Level 2 and/or 3 Causes of Operator Error can be addressed directly through process or product change.