FMEA is hard enough to implement without any mistake. FMEA’s mistakes are the most common non-conformity in almost the IATF 16949 audits (formerly ISO/TS 16949). In the following sections, we will describe the common mistakes of FMEA with reason and resolution.
1. Process Step of a PFMEA does not match with Control Plan
Number and Name of Process Step do not match with those in Control Plan. Control Plan and PFMEA have explicit linkage in the process, and they need to be the same in both PFMEA and Control Plan.
Example: PFMEA does not mention about shipping process even though Control Plan does.
This mistake is the most common mistake when Control Plan and PFMEA are conducted separately. Control Plan or PFMEA changes from time to time, and the team might forget to update the remaining document when one changes. The practical solution is using specialized FMEA software. The software will automatically update the other document whenever the team changes one.
#1 FMEA Creator for Excel
Complete your FMEA analysis faster than ever right inside Excel
DFMEA’s failure modes are not considered to reflect in PFMEA’s failure effects. Logically, the process’s failure effects that occur on the product are the product’s failure modes.
Example: A fuel tank’s DFMEA mentions about leaking problem. However, the corresponding PFMEA does not mention about this effect.
Not all of DFMEA’s failure mode can become PFMEA’s failure effects. However, the team should consider if there is any linkage between process failure and product failure. If any, the team should mention product failure as an effect of process failure. With the above example, the leaking problem can be considered as an effect of failure in the corresponding process, such as welding or piping assembling.
DFMEA’s potential causes are not considered to transfer to PFMEA’s failure mode. Logically, a potential cause of product failure can become a failure in the corresponding process, so it should be mentioned in both Design and Process FMEA. However, it should be transferred by considering the scope of Process FMEA.
Example: A fuel tank’s DFMEA mentions that leaking failure causes because of broken welding join. However, corresponding PFMEA does not indicate this failure from the production aspect.
While using DFMEA as input for PFMEA, the team should consider if any potential cause of DFMEA could also happen in the process. In the above example, the welding joint can also be broken if the welding current is set too low.
4. The ranking is not correct.
Detection, Occurrence, and Severity aren’t evaluated consistently with the criteria and ranking system. For example, two detection controls have different rankings, even though they use the same method. Two failure modes have the same effects, but they have different severity rankings.
Each organization may have its criteria to evaluate detection, occurrence, and severity. Sometimes, the criteria come from customer standards. The team should apply the criteria consistently in the whole project and both Design and Process FMEA.
5. Mixing of Prevention Control Method and Detection Control Method
The FMEA team may misunderstand which control method is a prevention method and which one is a detection method. A Prevention method eliminates or reduces the chance a failure or cause of failure to happen while a detection method detects an existing failure.
Example: in a turning process, there are two controls in place: checking tooling position and checking the diameter of the workpiece. Are both of them detection method? No, checking tooling position can be considered a prevention method because it prevents detention defects that cause by the tools in the process.
6. PFMEA or DFMEA does not reflect recent defect or customer reject
Recent defects or customer rejected products always are the reason to start an investigation process and review Design and Process FMEA. If a similar failure was mentioned in FMEAs, then some potential causes of failure mode could be ignored, or the current control methods are not sufficient. If any similar failure was not mentioned, the team should it reflect in FMEAs and update the FMEAs with new failure to prevent it happen again.
Example: if a leaking product is found in the market, the team should start to review the PFMEA and see if it is mentioned or not. If leaking failure is mentioned in FMEAs, the current controls do not effective, or some failure causes are unknown.
7. No improvement plan or risk reduction activity
Some organizations create FMEA documents only because their customers request it. After getting customer approval, the FMEA documents were put in a file and never be reviewed again. They are wasting the most valuable tool to improve their product and save their business.
Making an FMEA is just the beginning of the FMEA process. The primary purpose of FMEA is reducing the risk by conducting corrective actions. If they don’t have an activity to reduce the risk with FMEAs continuously, the problem will come.