1. What is FMEA?
Failure Mode and Effects Analysis (FMEA) is a risk assessment method, used to identify, analyze and evaluate potential failure mode and promote corrective action.
2. Why FMEA
Today, quality is one of the most critical factors of a product (or service) for the customer. Serious quality problems can ruin the reputation of companies or put them out of business. Less, it requires a lot of time and money to handle.
Therefore, developing a high-quality product/service becomes the most critical target of any company in the world. Applying FMEA at the right phases of the product development process can help a company not only prevent the costly quality problem but also help them build high-quality product/service.
Failure Mode and Effects Analysis can be used in many areas from manufacturing to non-manufacturing. Depending on the application, FMEA format could be different for different applications.
3.1. Manufacturing Area
Failure Mode and Effects Analysis is a useful risk assessment method for any manufacturing area, both design phase (DFMEA) or production phase (PFMEA).
DFMEA (Design FMEA) is an FMEA type that focuses on product failure in the design phase to prevent or reduce the product failure before production.
PFMEA (Process FMEA) is an FMEA type that focuses on process failure in production to prevent or reduce the chance that failure product delivered to the customer.
3.2. Non-Manufacturing Areas
Failure Mode and Effects Analysis is also effectively used in non-manufacturing areas. For example, logistics companies can use FMEA to analyze the risk in their process to reduce the quality risk of their new transportation routes. A hospital can use Failure Mode and Effects Analysis to examine their medical procedures to reduce the safety risk. A restaurant can use FMEA to assure food quality and improve their service.
4. FMEA Format
FMEA has many formats depending on organization and purpose. For easy understanding, we introduce a basic FMEA format.
4.1. FMEA Header
Top of the FMEA worksheet is a header which includes general information about document and product/process analyzed. Below is an example of a DFMEA header.
① Part Number: The unique number to identify the part/component/item analyzed.
② Model: Extra information for a model of component or system including the component.
③ Part Name: Name, description of the part/component/item analyzed.
④ Subsystem: The subsystem includes the part/component/item analyzed.
⑤ System: The System includes the part/component/item analyzed. In our FMEA example, Ball Point Pen is the system including Ball Point Pen’s Tip.
⑥ Team Members: members involved in the FMEA process. FMEA is not one person’s job; it needs idea and knowledge from many people from many departments like engineering, production, quality, inspection, logistic.
⑦ Manager: The leader who has responsibility for the FMEA process. In some companies, this person may be a quality manager or project manager.
⑧ Customer: Who uses the product
⑨ Number: The number of FMEA document. Some companies may use part number for this purpose.
⑩ Revision: Revision number of the document.
⑪ Original Date: The date that the document firstly issues.
⑫ Revision Date: The date that the document is revised.
4.2. Columns of FMEA
The content of analysis is listed in the columns of FMEA. Below is a list of basic columns of an FMEA. Depending on usage, the user can add, remove or modify the columns to meet their needs. 20 columns are divided into 6 groups:
4.2.1. Product/Process Information
① Component: component, part or item of the object product analyzed.
Note: with PFMEA, this column is replaced by Process Step, the step of the object process analyzed.
② Function: the respective functions of the component. A Component has one or many functions; a function should be separate from others but still aligned with its component.
③ Requirement: respective requirements of the function. A Function has one or many requirements; a requirement should be separate from others but still aligned with its function.
4.2.2 Failure Modes
④ Potential Failure Mode: Way that product/process potentially fails to meet the requirement. A requirement has one or many potential failure modes.
⑤ Potential Effects: Effects of the potential failure mode on the function and customers.
⑥ Potential Cause: What allows the failure mode to occur. A failure mode has one or many potential causes; the potential causes should be separate from each other but still aligned with its failure mode.
4.2.3 Control Methods
The below columns describe the current control methods and its capabilities to prevent the failure modes
⑦ Prevention is a control method for preventing potential cause to occur.
⑧ Detection is a control method for detecting the cause or failure if it happens.
4.2.4 Risk Evaluation:
⑨ Severity (S): a ranking number reflects the most severe potential effect of a failure mode. Severity ranks on a 1 to 10 scale, 10 is the most severe risk.
⑩ Occurrence (C): a ranking number reflects the possibility of occurrence of the Failure. Occurrence ranks on a 1 to 10 scale, 10 means the highest possibility of occurrence.
⑪ Detection (D): a ranking number reflects the best detection control method. Detection ranks on a 1 to 10 scale, 10 means worst detection capability.
⑫ Risk Priority Number: An indication to evaluate the risk of the process based on Severity, Occurrence, and Detection.
RPN = S X O X D
4.2.5 Corrective Action
Depend on RPN and S, O, D, the team has to decide corrective action needed for each failure mode.
⑬ Corrective Action: Corrective action to eliminate or reduce the chance of the causes of failure mode.
⑭ Person In charge: Person/Department who has a responsibility to complete the corrective action.
⑮ Plan Date: The plan completion date.
⑯ Completion Date: The actual completion date.
4.2.6 Re-Evaluate Risks After Corrective Action
The columns below has the same meaning as the above columns. However, they are used to re-evaluate RPN after corrective action complete.
⑰ Severity: re-rating severity of failure mode
⑱ Occurrence: re-rating occurrence possibility
⑲ Detection: re-rating detection capability
⑳ RPN: re-calculate Risk Priority Number
5. FMEA Team
One person doesn’t know everything, especially with a complicated area as failures analysis. Failure Mode and Effects Analysis require knowledge and experience of many departments in a company. Typically, a cross-functional team should handle Failure Mode and Effect Analysis in an organization.
The team should be led by an experienced leader who has excellent FMEA understanding and good knowledge of product/process analyzed. Moreover, the conflict resolve skill some time is needed for the leader because it involves a lot of discussion and controversy.
Team members qualification
A successful PFMEA requires team members have to involve in failure analysis actively. So their qualification is essential for an effective result. Below we describe the recommended qualification and experience of PFMEA team members. However, company management should adequately determine appropriate PFMEA qualification based on their business and resources.
• Good knowledge of the application of his/her area in the process.
• Good knowledge of FMEA tool and other quality tools as Control Plan, Failure Tree Analysis, and Process Flow Diagram.
A minimum of one year experience in the representative area of a member is recommended to achieve effective PFMEA. An inexperienced member should be avoided to participate in a PFMEA project without the support of other experienced members.
The team should be led by an experienced engineer with excellent knowledge of the objective process. The conflict resolve skill some time is needed for the leader because it involves a lot of discussion and controversy.
Failure Mode and Effects Analysis should start as soon as possible in the project timeline, and all recommended action should complete before product/service launching. Because FMEA can prevent the problem occur or reduce the chance that problems occur, It is so much easier for the project team to dealing with an issue in the early phase of a project than later when product/service has released.
Example: Repairing a molding die while production running is hard and costly than doing it from the prototype phase. The question here is How soon will you realize the problem?
FMEA is not a fixed document, but a living document. Once it is created, the product/service/process can change time to time. The team should keep FMEA updated with the current condition.