Process FMEA - No evidence that actions are considered or taken - High RPNs

[LEC]

During our last audit a nonconformance was issued "there is no evidence that actions are considered or taken for high RPN in PFMEA".

The PFMEA manual says that RPN's can be between 1 and 1000 and that "for higher RPN's the team must undertake efforts to reduce this calculated risk through corrective action(s)".

Higher RPN's is a vague requirement, what is higher? We had already established in our procedure a threshold of 100. We would react anytime the RPN goes above 100.

My current thought is to challenge our registrar. I would like to have other opinions before undertaking.

 

[Kevin Mader]

You ask a very common question. What is the answer though? I'm not exactly sure, but I'll toss out an idea or two.

The process requires that the FMEA document be a living document. This means periodic reviews, re-evaluation of original RPNs, and updates and amendments as necessary. I have seen the Pareto technique used to identify the "vital few" over the "trivial many". But what if the vital failure modes only generate numbers below the arbitrarily selected 100 score? Should no action be taken because it is not warranted?

A closer look at how the RPN was derived might be necessary. Severity plays a very important role, 9 and 10 rating should require addressing. Also, a longer term study needs to be done to determine if your arbitrarily selected threshold has any merit. You may find that a higher/lower number is more appropriate. So what is appropriate?

Based on individual organizational circumstances, what is appropriate for one may not be for another. Your organization is made up of many "experts" for your product or service. These experts need to determine the appropriate number if you decide to use the scaling method. I would suggest using a statistical method but give consideration to those "gutt feel" issues (i.e. what resources do we have/can afford?). The most important factor I believe is that you record the events leading up to your designated threshold as this would indicate that your organization approached this issue as objectively as possible and that your 'experts' have given due consideration.

For the record, we also had the 100 point threshold in our SOPs. Arbitrarily selected, but a reasonable estimation in retrospect (studies of past results has shown that this number floats between 70-160). I should mention though that if you do select a threshold that you run the risk of creating bias in generating the RPN value (keep it under 100 or we'll have to do CA!). Additionally, as a group of experts you may decide that an item with an RPN of a lower number requires attention while one that is higher goes untreated. An inherent problem with scaling systems, they are linear and cloud vision. As I mentioned earlier, items with 9 or 10 severity generally require CA. An S*O*D for an RPN may be 9-2-2=36, another being 5-5-5=125. Which do you address first? Or at all?

Hopefully I haven't muddled up the works for you. My suggestion, give consideration to the non-scaling method. Deal with the vital few and learn from the process. I believe the results will be better.

Regards,

Kevin

 

[Marc]

Have you looked at the APQP and FMEA files in the pdf_files directory? http://Elsmar.com/pdf_files/

This gets wishy-washy because judgement comes into play as pointed out already. But in addition, let's say the severity was the same for 2 separate line items but one line item has an RPN of 400 and the other line item has an RPN of 50. The one with the 400 RPN number you have determined will cost US$5,000,000 to bring down while the RPN 50 you can reduce to 30 with about US$2500. That one with the RPN of 400 may just stay there for a while.

The 'old' automotive RPN rule was attack anything over 60, as I remember, but over the last several years FMEAs have really been picked apart by virtue of QS9000 requirements. There are a lot of judgement calls in what you work on, what you do not work on and why.

[This message has been edited by Marc Smith (edited 13 October 1999).]