In last month’s article we discussed the most common FMEA mistakes and how to convert them into quality objectives. This month we will focus on how to audit FMEAs, using the FMEA quality objectives as a guideline.
“Twice and thrice over, as they say, good is it to repeat and review what is good.” Plato
We’ll begin with definitions from the Oxford English dictionary.
“Quality” is defined as “the standard of something as measured against other things of a similar kind; the degree of excellence of something.”
“Objective” is “a thing aimed at or sought; a goal.”
“Audit” is “conduct a systematic review of.”
What are FMEA quality objectives?
Building from the above definitions, FMEA quality objectives are specific goals or aims that measure the degree of excellence of an FMEA. And an FMEA audit is a systematic review of an FMEA against the quality objectives.
How to audit FMEAs using FMEA quality objectives
The following are specific suggestions for “how to audit” each of the FMEA quality objectives, as well as application tips. Please review the article “The Most Common FMEA Mistakes and How to Convert Them into Quality Objectives,” as the FMEA audit procedure builds on this information.
FMEA quality objective No. 1: The FMEA drives design improvements (design FMEA) or manufacturing or assembly process improvements (process FMEA) as the primary objective.
How to audit: Review the FMEA recommended actions and observe whether most of them drive design improvements (for a system or design FMEA) or process improvements (for a process FMEA). Talk with team members to ensure their focus was on improving the design or process.
FMEA quality objective No. 2: The FMEA addresses all high-risk failure modes, with effective and executable action plans.
How to audit: Review high-severity and high-RPN issues to determine whether the corresponding recommended actions are adequate to reduce risk to an acceptable level. Talk with the team members to ensure they are satisfied that all high risks were addressed and no important concerns were left unaddressed.
FMEA quality objective No. 3: The Design Verification Plan (DVP) considers the failure modes from the Design FMEA. The Process Control Plan (PCP) considers the failure modes from the Process FMEA.
How to audit: Review the recommended actions to determine whether there are improvements to the DVPs, PCPs or corresponding procedures based on risk associated with current design or process controls. Talk with the team members to determine whether they had adequate representation from test or controls groups, benefited from their input, and whether test and control procedures were improved.
FMEA quality objective No. 4: The scope of the design FMEA includes interface failure modes in both FMEA block diagram and analysis. The scope of the process FMEA includes inter-operation failure modes, such as transfer devices, and incoming parts and shipping, in both process flow diagram and analysis.
How to audit: Review items, functions, failure modes and other portions of the FMEA to ensure interface issues were addressed within the design FMEA scope. Ensure connections and exchanges between operations were addressed within the process FMEA scope. Review the FMEA block diagram and process flow diagram to verify. Ask the team how it determined no interface issues were missed.
FMEA quality objective No. 5: The FMEA considers all major lessons learned (from in-service warranties, customer service databases, recall campaigns, prior manufacturing or assembly problems and others) as inputs to failure mode identification.
How to audit: Review failure modes and causes to ensure they contain supplemental field failure data (for system and design FMEAs) and manufacturing failure data (for process FMEAs). Talk with the FMEA team to ensure the FMEA benefited from lessons learned and that high-risk issues will not recur.
FMEA quality objective No. 6: The FMEA provides the correct level of detail to get to root causes and effective actions.
How to audit: Verify that the level of detail on high-risk issues is adequate to fully understand root causes and develop effective corrective actions. Review the different worksheet columns of the FMEA to ensure the overall level of detail is proper and adequate. Too much detail may appear in the form of endless pages of FMEAs covering issues no one on the team is concerned about. Too little detail shows up as under-defined functions, failure modes, effects, causes or controls, or as areas of unaddressed concern from one or more FMEA team members. Talk with the FMEA team members to determine how they addressed the level of detail and ensured all concerns were included in the scope of the FMEA project.
FMEA quality objective No. 7: The FMEA is completed during the window of opportunity from where it can most effectively affect the product design or manufacturing process.
How to audit: Review the timing of the FMEA against the product development process timeline. Verify the FMEA was started and completed in the proper timeframe to maximize the value of the FMEA results.
FMEA quality objective No. 8: The right people, adequately trained in the procedure, participate on the FMEA team throughout the analysis.
How to audit: Review the FMEA team member roster to ensure there was adequate representation from the various disciplines based on the type of FMEA and the project scope. Check FMEA team meeting records to ensure attendance was adequate at each meeting. Talk with individual team members to learn whether their input was elicited in decisions.
FMEA quality objective No. 9: The FMEA document is completely filled out by the book, including action taken and final risk assessment.
How to audit: Verify that the FMEA worksheet columns were correctly filled out and that FMEA procedure was properly followed. Talk with the FMEA team members to ensure they rigorously followed FMEA guidelines and practices.
FMEA quality objective No. 10: Time spent by members of the FMEA team is an effective and efficient use of time with a value-added result.
How to audit: Talk with the FMEA team to learn whether each member believes his or her time was well spent and whether a value-added result was achieved. If not, find out why.
How are FMEA quality audits conducted?
The following is excerpted from the book, Effective FMEAs.
In a nutshell, an FMEA subject matter expert or management person reviews the FMEA results with the FMEA team against each of the FMEA Quality Objectives, one by one, using the “How to audit” recommendation. Each quality objective is evaluated for how well it is achieved. This evaluation can be done on a yes/no basis or a variable evaluation, such as high, medium or low. The estimated time is one hour for this audit, about 5 minutes per FMEA Quality Objective. The results of the audit provide valuable feedback to improve future FMEAs. The focus is on improving the FMEA process, not on the person or team doing the FMEA. The auditor is looking for specific process-related issues that underlie deficiencies in achieving the quality objectives, such as lack of training, procedure, facilitation skills, standards, resources, support, etc. Action items from the FMEA quality audit should be documented and pursued to improve the overall FMEA process. Do not expect to achieve all ten FMEA quality objectives instantly. Rather, work to maintain steady improvement.
How can the results of an FMEA audit be summarized?
Here is a simple template for summarizing the results of an FMEA audit. The action focus should be on improving the overall FMEA process. In this template, “1” means quality objective is not in place, “2” means the quality objective is partially in place, and “3” means the quality objective is fully in place.
FMEA Tip
The best use of FMEA quality audits is to improve the FMEA process, not to correct the FMEA team.
Reader Question
“The important thing is not to stop questioning.” – Albert Einstein
I have a question about best practice for traceability of a Design FMEA to Design Requirements. For complex products with many design requirements at multiple system levels, is it preferred to list all requirements in the DFMEA(s) with failure modes corresponding to not meeting each requirement, or to perform “functional” DFMEA from block diagrams for subsystems, modules, etc. and then trace the functional failure modes back to the design requirements?
With the former approach, there are very large number of rows to individually evaluate for risk; with the latter approach, there will often be sets of unitary requirements that trace to one “functional” failure mode from the block diagram. It can be tedious going back and forth between a requirements database and the DFMEA to ensure that all essential requirements are associated with a given failure mode while not including requirements haphazardly that aren’t pertinent. If the risk level is high for a particular failure mode, then all the requirements traced to it become “essential” according to our procedures and require special rigor in verification/validation.
So, is there a “preferred” process most often followed for this in high-tech industries with complex designs?
My Reply
Thanks for getting in touch with me on this important question.
In order to reply to this question, I’ll discuss my preferred method. Since your example talks about a complex product, I’ll assume we are talking about a System FMEA. I prefer to begin a System FMEA with an FMEA block diagram that identifies and visually represents the exact scope of the System FMEA, including all interfaces and integration areas. The FMEA is then populated with the primary functions of the system as well as the interfaces brought into the analysis as interface functions. By definition, each function should include the “standard of performance”, which can be highlighted by corresponding requirements. Some companies include a “Requirements” field that is associated with the corresponding Function. Each function has associated failure modes, and the FMEA is continued in this manner. This way you can trace each failure mode to corresponding functions and requirements.
You are correct that it is important to trace the requirements from the source of requirements to the associated function (and requirements) in the System FMEA, while excluding from the FMEA requirements that are not pertinent to the analysis.
Next Article
The next article will cover the application of Key Product Characteristics in Design FMEAs. This is a very important aspect of Design FMEAs that is often misunderstood or misapplied.
Leave a Reply