I can think of no better technique than FMEA to get engineers together and “hash out” the possible failures of a design or process. The word HASH is appropriate because of all the ingredients necessary to get it to taste good. Many FMEA’s are not developed with enough ingredients to assure that the true issues come out.
All engineers believe they have done a great job, this is not what the FMEA is about. The FMEA is about where and when unknowns can affect performance. The testing and verification of the design or validation of the process should be a confirmation of the FMEA outputs. When risk is uncovered, the actions that come from the FMEA should affect both the design of the product and/or process but also the testing for verification and validation. Too many times we hear “we will test for that” But what if it fails? Will there be enough time to redesign and reconfirm the design? These issues should be discussed during the FMEA process.
I am sitting at a major manufacturer of farm machinery (typically painted green) listening to a discussion about Failure Modes, and it occurs to me that there is a general misunderstanding of Failure and how to mitigate risks. I am writing this initial entry into the FMEA Blog to take the opportunity to clarify some key items about Failure and subsequent causes. In an FMEA, it is fairly common to get the causes, Failure modes and effects all mixed up. I like to follow a simple set of rules to make this easier.
- Get the function in a verb noun combination with a measurement defined.
- Simply reverse the Function into a failure mode.
- E.g Must dry clothes within 15 minutes (verb/noun underlined) Failure modes become: does not dry, takes too long to dry, uneven drying
- Effects are limited to customer effects in this order: Regulatory, Consumer/User, and assembly and manufacturing customers. Keep these words in the context of a non engineer. This means how would your mother or uncle describe the failure and rate how bad each is.
- Severity is assigned to each effect but only 1 severity number matters and the rest of the FMEA is driven from this one severity number. Remember that for each Failure Mode there is only 1 Severity or a 1 to 1 relationship. We do not look at Causes of each Effect.
- Causes must be associated with:
- individual components or subsystems, specifically things like geometry, materials, fatigue and other physics of failure.
- Interfaces of other systems and their impact on your design.
- Noise factors, or items that can affect performance but are outside the control of the team doing the FMEA
These are best understood by using Boundary diagrams and P diagrams. By clearly defining the differences between Failure Modes, Effects and Causes, the FMEA experience will be much more palatable for the team members. Remember the F in FMEA still does not stand for Fun. If you have any comments or wish to add something, please go the comments section and/or email me with your suggestions.
Lee