Archive for the ‘FMEA’ Category

FMEA and the 8D

Monday, February 11th, 2008

In Canada this week and boy is it cold. I was teaching an 8D class with the Global 8D Ford twist. While teaching we got into a discussion on the FMEA relationship to the 8D. My response was that these two processes are one in the same except FMEA is an 8D that we do before the need for an 8D. The FMEA Failure Mode corresponds to the problem statement and description on the 8D. The effects of failure in the FMEA and customer symptom in 8D are related and the causes in the FMEA are the possible causes and the most likely causes in 8D. The MLC have higher Occurrence ratings. The FMEA is usually related to the D7 (prevention) step but I want you to take a look at the FMEA at the D4 step just to see the legacy of causes already captured from the FMEA. Updating the FMEA is also a way to assure that the 8D talks to the FMEA. If you would like more on this topic please write me or comment or go to www.quality-one.com

FMEA Linkage

Friday, January 25th, 2008

I am in Japan this week training and mentoring in APQP and FMEA. Once here and working with my customer teams, I noticed how difficult it might be to understand the FMEA linkage.

Much has been said about the linkage between Design FMEA and Process FMEA. My thoughts on this are to be as prescriptive as possible. I am very much a supporter of the idea that there is an intermediate step between the two documents. That intermediate step is a Characteristic Matrix. The Characteristics Matrix is actually part of the QFD process, where the House of Quality converts Voice of the Customer to requirements definitions. Second phase has the requirements being translated to specifications at the platform, system or component level. This output enters the Design FMEA as the function with measures. Causes of failure once converted to dimension or feature is transferred over to the PFMEA, but confusion exists at this stage. Process people often state that they cannot do a Process FMEA without the Design FMEA. This is principally correct and wrong simultaneously. The outputs of the Design FMEA is what we need, and there are many parts where no outputs will be necessary. More on this point on a further blog entry. The Characteristics Matrix provides a clear way to transfer the Design FMEA outputs to the Process FMEA. The linkage exists in three areas:

  • Characteristic
  • Effect of Failure (on the customer)
  • Severity assigned to the Design Failure Mode and Cause Mechanism.

These three items drive an additional Process FMEA effort for the process steps that affect theses characteristics. The Process FMEA does not have any choice on Severity for the characteristic as it is dictated by the Design FMEA. This assures that the Process is analyzed on its’ impact on that characteristic. For more on this idea stay tuned. Please comment if you want to continue this discussion.

FMEA for 2008

Tuesday, January 8th, 2008

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.

FMEA Thoughts

Wednesday, December 26th, 2007

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