Drawbacks to FMEA Methods

[Rob Nix]

In reply to Wes Bucey’s post in the thread "What is the most under-rated, over-rated tool or technique..", I decided to create a new thread, since it deviates from the specific intent of the first thread.

I’ll try to answer Wes’ question, ‘what about FMEA grates on you?’ below.

There are a number of specific issues, like the one Wes assumed, namely, the use of risk priority numbers (RPNs). They are:

1. Subjective use of rating numbers and and RPNs. Whether using a 5 point system or a 10 point system, or whether you draw the line at an RPN of 50 or 250, it still comes down to choosing between what issues you will address, and which ones you will accept as is. Either do something or don’t. So why have a numerical system at all? While going through the exercise, just list what actions you plan to take (perhaps in a prioritized order).

2. Lack of causal chains and logical root cause categorization. One of the things I’ve found with FMEAs is that they don’t allow for the typical problem-solving mind-set. It is difficult to think in terms of causal chains, categorized root causes, or 5WHYs. For example, for each failure mode you must list a failure cause. Well, does that cause have a deeper root cause? Could that “cause” also be listed as a “failure mode”? This can get muddy. Trust me.

3. Inefficient use of manpower. Although creating a Failure, Modes, and Effects Analysis follows many of the same rules as brainstorming, it can easily degenerate into a lot of time wasting discussions and side bars. You need plenty of the right people there. But the same high level talent you utilize are also the big idea people. Without strong facilitation, this methodology is difficult to control.

4. Legal ramifications. Some time ago, an associate of mine discussed FMEA methods with an attorney. This is what he said, “By forcing ORGANIZATION to assign numerical values to [severity] criteria, it is our opinion that CUSTOMER is placing ORGANIZATION in a “no win” situation from a product liability standpoint… if an injury ever occurs due a failure mode which has been assessed [with any severity ranking], it may well be alleged that ORGANIZATION negligently failed to determine the correct effect of failure”. Their argument is that if any possibility of injury is documented, no matter the ranking, and nothing is done about it, it is a set up for a law suit.

5. Does not allow for correlation and interactions. The format of the FMEA, i.e. independent line by line consideration of each failure mode, does not take into consideration the possible negative effects of the interaction of two seemingly benign failure modes. For example, if switch “A” fails, there is an obvious visual indicator - no big deal. If slide “B” sticks, production stops - no chance of defects. But if switch “A” fails when slide “B” sticks then mangled parts get jammed into fixture.

6. Assumption that product is “in tolerance” is moot. This applies mostly to machine and process FMEAs. For the sake of clarity and control, the assumption is made the products going into the process/machine are 100% within all specifications. To assume otherwise expands the FMEA scope exponentially. However, in real life, out of spec parts (in one way or another) are an all too common occurrence, and they cause all sorts of failure modes to occur which are not addressed during the FMEA creation.

These are just a few thoughts I have based on real life experience. Others may see it differently (please chime in). Anyway, I have been working on creating a more comprehensive analysis of this subject. I don’t have any original alternatives right now, but I’m working on it.

There are other methods for risk analysis that often do not get the "air time" that FMEAs get, like FTA, MORT, PRA, HAZOP, TRIZ, etc. that may better fit certain situations better.

 

[Jim Wynne]

A most excellent post

. It's easy to tell when the voice of experience is speaking. I'll offer a few interspersed observations, as this is a subject near and dear...

1. Subjective use of rating numbers and and RPNs.

Yes! The RPN concept is of diabolical origin, I think.

2. Lack of causal chains and logical root cause categorization. One of the things I’ve found with FMEAs is that they don’t allow for the typical problem-solving mind-set. It is difficult to think in terms of causal chains, categorized root causes, or 5WHYs. For example, for each failure mode you must list a failure cause. Well, does that cause have a deeper root cause? Could that “cause” also be listed as a “failure mode”? This can get muddy. Trust me.

I think it's possible to get hung up on the form itself, which is not the FMEA. Of course, there are problems with the form too, but you're free to use whatever brainstorming or root-cause seeking you want, and then figure a way to integrate it into the form. I agree wholeheartedly about the modes/causes thing--it really can get murky. My solution has been (when dealing with PFMEAs) to define the mode as the process failure, not the part defect. The defect is the effect. This isn't perfect, but it does help to alleviate some of the confusion, and is more likely to direct efforts towards fixing the process.

3. Inefficient use of manpower.

Perhaps the biggest logistical problem in APQP. Done correctly, it takes time and commitment from a lot of people, and that ain't easy to arrange. My own approach in some situations has been to interview people separately, but it's always better to get people together if you can, and there definitely needs to be firm leadership.

4. Legal ramifications.

An excellent, seldom-considered point, but one that relates to almost any sort of formal failure prevention analysis. In situations where life-and-limb are at stake, lawyers should be involved, at least in reviewing the documentation.

5. Does not allow for correlation and interactions. The format of the FMEA, i.e. independent line by line consideration of each failure mode, does not take into consideration the possible negative effects of the interaction of two seemingly benign failure modes. For example, if switch “A” fails, there is an obvious visual indicator - no big deal. If slide “B” sticks, production stops - no chance of defects. But if switch “A” fails when slide “B” sticks then mangled parts get jammed into fixture.

Here's a minor disagreement. If you do as I suggest, and use the process failure as the mode, there's no reason that "Simultaneous failure of switch A and slide B (and Henderson valve C, for that matter)" can't be a single line item.

6. Assumption that product is “in tolerance” is moot.

Another small disagreement. If FMEA is done up and down the line, then the potential failures of process "A" have already been addressed, as well as their potential effects on process "B." Doing it again seems unnecessarily redundant, especially if the goal is prevention (you can't prevent a process "A" occurrences in process "B."

 

[ralphsulser]

Quote: (Originally Posted by Rob Nix)
1. Subjective use of rating numbers and and RPNs.

Response: "Yes! The RPN concept is of diabolical origin, I think."


I have to agree with this assessment. The 2 criticisms I have received from my FMEAs where " Your RPNs should be higher", 1 from a Big 3 rep.
I say why do we need to generate high RPNs just to satisfy someone’s paradigm.
I don't think we need to be chicken little. I realize there is a guide in the FMEA manual, but the real world is what actually is expected. Also as mentioned above pumped up RPNs could be a legal issue too.

 

[Wes Bucey]

Pretty much what I expected, Rob. All very valid. I think the root cause goes back to some wee clerk at an automotive OEM who was the first to say,

"Gee! It's not enough that the supplier stop and think about what could go wrong before he spends money to make our product. We need some metric so we can rank one supplier against another on how well they are looking out for us."

Naturally, another wee clerk at a second OEM heard about it and said, "Wow! this is just like a Cold War arms race. We can't let that other OEM get ahead of us in collecting metrics."
I got past that pressure by simply ignoring it. Our FMEA program was modeled after the original aerospace one and we never bowed to the Automotive method of attaching RPN (Risk Priority Number [FMEA]) emphasis to our process. If a customer requested RPN, I simply refused and said, "When we finish our FMEA, all our risks are zero in our opinion. We won't waste our time attaching meaningless numbers to anything we intend to reduce down to zero."

Once in a while, it was a deal breaker. Our position was that it was not economically or scientifically worth our effort to create a fraudulently derived RPN, so we'd rather "NO QUOTE!"

Hey, we were successful. Success breads arrogance and we were arrogant. The slight mitigating factor was that we delivered what we promised, with no excuses (simply because we never took on a risky project we didn't have 100% confidence in completing.) That CONTRACT REVIEW can save your company!

Perhaps the biggest logistical problem in APQP. Done correctly, it takes time and commitment from a lot of people, and that ain't easy to arrange. My own approach in some situations has been to interview people separately, but it's always better to get people together if you can, and there definitely needs to be firm leadership.

Yep. James has a clear picture. FMEA and PFMEA and APQP need a real leader with a strong sense of the capability and capacity of his operation in mind when it comes to gathering and dealing with the ideas and thoughts put forward by various personnel. It's important to keep everyone focused on the goal of a trouble-free and glitch-free process. The main curse we all fight is the dreaded phrase, "Good enough."

 

[Ron Rompen]

I agree with all the previous statements about PFMEA's, however my basic complaint about them is even more fundamental.

In most (if not all) the places I've worked, the PFMEA is simply another piece of paper, completed to form part of the PPAP package (or the CAR report), and nothing more than that. In a multi-product environment (we have about 500 active parts) there simply isn't the manpower to focus on 'over 250 RPN' or 'over 150 RPN' or 'insert your favorite number here RPN'.

Most of my customers seem to be the same; they see FMEA as a submission requirement and nothing more.

Even when try to do it 'properly', we run into roadblocks. I mentioned previously about the problems we ran into when asking for the DFMEA (which is used to, among other things, derive the SEV score for failure modes).

One that we DID manage to obtain had 7 items, all ranked as SEV 9 or 10. This is for a safety-critical item (occupant restraint system) that is supplied to most major auto manufacturers. It was obvious to me that they (the customer) hadn't done their homework either.

Oh well....for most of us, we'll continue filling out bits of paper, and shuffling them off to that wee clerk.

 

[Paul Simpson]

FMEA can be misused not overused

As a proponent of FMEA as a tool I'll try and put a positive slant on the areas Rob has identified.

1. Subjective use of rating numbers and and RPNs. Whether using a 5 point system or a 10 point system, or whether you draw the line at an RPN of 50 or 250, it still comes down to choosing between what issues you will address, and which ones you will accept as is. Either do something or don’t. So why have a numerical system at all? While going through the exercise, just list what actions you plan to take (perhaps in a prioritized order).

I agree there can be problems with FMEA, particularly the RPN subjectivity. That is where the company can set some boundaries by using look up tables - like in the AIAG manual so that the same type of problem leads to the same severity score, the same probability of occurence (based on data) leads to the same occurence rating and the same evidence of failures having been missed (from warranty data for example) leads to the same detection score. This gives the FMEA a solid grounding.

The RPN only defines the order you do something not whether it gets done or not. I deal with a lot of organizations using FMEA who have a threshold level (say 100) that encourages them to "limbo" the FMEA scores and I encourage them to go for a more resource based sorting process - how many failure modes can we pick up with the resources (money, people) in the time we have?

2. Lack of causal chains and logical root cause categorization. One of the things I’ve found with FMEAs is that they don’t allow for the typical problem-solving mind-set. It is difficult to think in terms of causal chains, categorized root causes, or 5WHYs. For example, for each failure mode you must list a failure cause. Well, does that cause have a deeper root cause? Could that “cause” also be listed as a “failure mode”? This can get muddy. Trust me.

FMEA encourages root cause identification in the event that the RPN requires it. So if the RPN comes up as requiring further action then the analysis methodolgy kicks in. If the RPN does not flag it up then it is left to one side (in this first round) but may come up in the continuous improvement section.

3. Inefficient use of manpower. Although creating a Failure, Modes, and Effects Analysis follows many of the same rules as brainstorming, it can easily degenerate into a lot of time wasting discussions and side bars. You need plenty of the right people there. But the same high level talent you utilize are also the big idea people. Without strong facilitation, this methodology is difficult to control.

Agreed. Encourage teams to focus on key areas of risk (new aspects of design, new process steps before established designs & processes). Like any meeting it needs to be lead.

FMEA facilitators need to be superheros in dealing with people (ego, vested interests etc.)

4. Legal ramifications. Some time ago, an associate of mine discussed FMEA methods with an attorney. This is what he said, “By forcing ORGANIZATION to assign numerical values to [severity] criteria, it is our opinion that CUSTOMER is placing ORGANIZATION in a “no win” situation from a product liability standpoint… if an injury ever occurs due a failure mode which has been assessed [with any severity ranking], it may well be alleged that ORGANIZATION negligently failed to determine the correct effect of failure”. Their argument is that if any possibility of injury is documented, no matter the ranking, and nothing is done about it, it is a set up for a law suit.

Not sure about how the legal system works exactly in the US, I understand there are disclosure issues that don't apply here but FWIW my advice is that if you have assessed a range of risks and prioritized your actions to mitigate those risks you are in a better position than if you have not identified the risk at all. Also in my training I encourage people to take the results of the FMEA to top management for their sign off:

• Here is the list of risks we have identified in the product / process development. This is the last one we will be doing something about (i.e. we will be spending effort and time on fixing this- are you happy that it warrants the effort?)
• This is a summary of the risks that we will be doing nothing about - are you happy these risks are carried forward into production?

At least then the team can get some sort of buy in to their effort and the managment team can decide if the risks require further effort to prevent future injury.

5. Does not allow for correlation and interactions. The format of the FMEA, i.e. independent line by line consideration of each failure mode, does not take into consideration the possible negative effects of the interaction of two seemingly benign failure modes. For example, if switch “A” fails, there is an obvious visual indicator - no big deal. If slide “B” sticks, production stops - no chance of defects. But if switch “A” fails when slide “B” sticks then mangled parts get jammed into fixture.

I don't have a simple answer to this problem (in fact none of the above is easy although I hope it is simple). When dealing with Severity I encourage the product / process to work on "worst case" and rely on them to put forward any interactions but it is easier to say than to do.

6. Assumption that product is “in tolerance” is moot. This applies mostly to machine and process FMEAs. For the sake of clarity and control, the assumption is made the products going into the process/machine are 100% within all specifications. To assume otherwise expands the FMEA scope exponentially. However, in real life, out of spec parts (in one way or another) are an all too common occurrence, and they cause all sorts of failure modes to occur which are not addressed during the FMEA creation.

Again the only reason for assuming incoming product is to spec is to make the FMEA manageable. I always encourage people to keep a running list of assumptions and if they identify a particular risk with incoming parts to flag that up to the FMEA programme leader to ensure that the responsible process FMEA team at the organization or its supplier is aware of the high severity of a failure mode they have responsibility for.

These are just a few thoughts I have based on real life experience. Others may see it differently (please chime in). Anyway, I have been working on creating a more comprehensive analysis of this subject. I don’t have any original alternatives right now, but I’m working on it.

Can't wait to read it. I have been working with FMEA since a final year project in 1980 and would love for something better / easier.

There are other methods for risk analysis that often do not get the "air time" that FMEAs get, like FTA, MORT, PRA, HAZOP, TRIZ, etc. that may better fit certain situations better.

Agreed. FMEA is a "chosen tool" and as such has been pushed harder and faster than the suppliers can cope with.

 

[nilesh]

One Golden rule for fmea is that you have to consider that input of process is ok except inspection process.