Are generic lists of failure information useful to FMEA teams? Are they a good idea or not?
There is a lot of discussion amongst FMEA practitioners on automating and standardizing FMEAs. In this article, I will discuss the pros and cons of using generic lists of failure modes, effects and causes.
The Oxford English dictionary defines “generic” as “characteristic of or relating to a class or group of things; not specific.”
Referencing Effective FMEAs, chapter 5:
FMEA practitioners should be aware of the benefits and limitations of using generic listings of failure modes, effects, causes, etc. Generic lists of failure information can be good thought-starters for FMEA teams, provide standardized descriptions, and ensure completeness of analysis. Controlling the description of individual failure modes enables analysis and dissemination of failure information between project teams and the entire organization.
The limitations of using generic failure information include the suitability of generic descriptions to the current project, potential for inclusion of information in current FMEA that is not of concern to FMEA team, and the possibility of stifling the creativity of the FMEA team to “think outside the box” and identify issues not previously seen. This last issue can be addressed by the proper use of brainstorming before exposing the FMEA team to generic failure information. In addition, generic failure data may come from significantly different operating environments and usages than current application.
How can “generic” words or phrases be useful in FMEA?
The FMEA team can consider past lists of actual failures, or published lists of generic failures to begin discussions within the FMEA team. It should be thought-starters, for opening up discussion, not “canned.” The team should end up with failure mode, effect, cause descriptions after listening, discussing and arriving at consensus, based on the specific circumstances of the item being analyzed. There is nothing wrong with working in the direction of standardized descriptions, as long as it aids in the identification of the most important failures, effects and causes. The key is staying faithful to the fundamentals of FMEA.
How can use of “generic” words or phrases be detrimental in FMEAs?
The FMEA team should consider the suitability of generic descriptions to the current project. What is the same, or different between the current project and the generic list?
The FMEA team should avoid inclusion of information in the current FMEA that is not of concern to anyone on the team. As covered in the “Tips” section of the article “Application Tip – Begin with Concerns”
It is a good practice to limit the discussion of failure modes to those of concern to at least one member of a properly constituted FMEA team.
Above all, the FMEA team should work in the direction of enhancing the creativity of the team to identify issues not previously seen. Yes, it is important to ensure past problems are not repeated. But it is equally important to ensure unseen problems do not manifest. Too much emphasis on “canned” lists of failures can make it more difficult to think outside the box, see what is potentially not yet visible, and will stifle creativity.
When integrating model-based engineering with FMEA, it is essential to use the power of the team to focus on the most important issues and get to viable root causes and risk prioritization.
See the article “Why FMEA Needs to be Team-Based,” which includes what elements of the FMEA can be prepopulated or automated, and what elements must be considered by the team.
Next Article
In the next Inside FMEA article, I will share an fascinating reader question about the use of a company-defined policy to identify Special Characteristics in FMEAs.
Leave a Reply