Need Help with Process FMEA Basics - Feasibility Analysis Outputs are Inputs to FMEA?

[ilarioduo]

Hello everybody.
It's the first time I post, and i start by begging pardon for my English.

We are a manufacturing company that is trying to move towards compliance to automotive standards.
We are starting preparing the first FMEAs, and it's turning out to be a great pain.

Apart from the time needed, most of the times we have problems in deciding "what goes in which box".

Typical example: when we start the pFMEA there has already been a feasibility analisys, so the most critical aspect of the process have, hopefully, already been analyzed, and a solution proposed, based on which our commercial people have prepared a quotation.

When we perform the FMEA, shall we start from scratch, and pretend that these "solved problems" are still there, assign them a high rpn and then propose the solution we already know as an improvement, or shall we consider as a starting point the solution we proposed in quotations?

Hope (but doubt) I have been clear.

I will certainly have more questions in future.
Thanks in advance

 

[SteelMaiden]

Re: Help with process FMEA

ilarioduo said:


When we perform the FMEA, shall we start from scratch, and pretend that these "solved problems" are still there, assign them a high rpn and then propose the solution we already know as an improvement, or shall we consider as a starting point the solution we proposed in quotations?

Welcome ilarioduo

When creating your FMEA's, start with where you are at right now, you say you have proposals for improvements, right? If you have not implemented them your process is still unchanged, and the rpn should reflect the current system. Implement your proposals and then recalculate your rpn.

If your solutions have already been implemented, you FMEA/rpn should be based on those implementations. Remember, if it is already a low rpn you do not have to make further changes, unless it is in your documented quality plans/documents. FMEA's are living documents, they should change every time you change the process or supporting processes.

Hope that I haven't confused you more, good luck

 

[Sam]

The PFMEA only applies to to the mfg processes. Does your feasibility analysis include problem solving for processes? If so, then those problem areas that have been solved will show up as low RPN numbers on the PFMEA.Although not required, IMO, it is best to address each step of the process during when preparing FMEA.

 

[ilarioduo]

Does your feasibility analysis include problem solving for processes? If so, then those problem areas that have been solved will show up as low RPN numbers on the PFMEA.

That is exactly my opinion as well: we already planned a (potential) solution for this issue, so it's not a high risk point any more.

Some of my collegues think the opposite, because, they say, it's necessary that all preventive measures appear in the FMEA even if they are already planned before the FMEA.
Their suggestion is: let's pretend we do not apply the process improvement, show how big RPN would be in that case, so nobody in future will even dream of remove that improvement for some "cost saving project".

Anyway thanks very much to both contributors for the quick answers.

 

[M Greenaway]

Prevention controls will appear on a process FMEA - are you using the QS9000 recommended format ?

 

[Bill Ryan - 2007]

Some of my collegues think the opposite, because, they say, it's necessary that all preventive measures appear in the FMEA even if they are already planned before the FMEA.

I could support your colleagues only from the aspect of "Corporate Memory" retention. Unless previous Feasibility Analyses are reviewed for new projects, the PFMEA is a great place to document improvements. The excercise can get pretty involved though, and Steel's response is my preferred approach (ie.: if the improvement has already been implemented, the PFMEA should reflect the current state of the process).

How are you coming with what goes in which column? I use two very simple definitions which have helped our teams not get into the "viscious circle" of "Is it a Mode or a Cause?": 1) Failure Mode = measureable on the product; 2) Failure Cause = measureable on the process. You can also use "Process measureables" as Failure Modes (scrap, uptime, etc.)

Hope that helps some.

Bill

 

[ilarioduo]

M Greenaway said:

Prevention controls will appear on a process FMEA - are you using the QS9000 recommended format ?

I am afraid I do not know, since I don't have QS9000 manuals (we are moving from ISO 9001 to ISO/TS).

Do you think we should get QS9000 related manual as well (PPAP, APQP, FMEA, etc?)?

For the time being I am using an internal format derved from a mix of spreadsheets received from training courses, internet searches, friends' suggestions and old internal formats. Perhaps it's not the best approach ...

 

[6MARINE]

ilarioduo said:

I am afraid I do not know, since I don't have QS9000 manuals (we are moving from ISO 9001 to ISO/TS).

Do you think we should get QS9000 related manual as well (PPAP, APQP, FMEA, etc?)?

Thats the very first thing you need to do!

Do not try to do a FMEA without the manual. Part of the ISO /TS package are all the AIAG's manuals.

 

[Bill Ryan - 2007]

I tend to agree with 6marine.

While the format shown in the FMEA and APQP & Control Plan manuals is not a requirement (you can use whatever format works for you), there are certain "things" that must show up in the documents and your customers may (probably do!!) have additional requirements. Overall, your best bet is to use the manuals and their approach (especially if you're new to the excercises).

One thing to remember concerning prevention controls - they have no impact on the "Detection" value. They can only reduce the "Occurence" value you assign. You do not need to have the "Prevention Controls" in a separate column (as shown in the manual) but if you go with the single column approach, you need to define each control listed in the FMEA as "P" or "D" . The "preferred approach is to have the columns separated.

Hope that helps you a little. (BTY - Welcome to the Cove )

 

[Kevin Mader]

My opinion:

I'm with Bill that when doing the PFMEA, start with the current state. Be honest and only consider the controls that are in place, not proposed to be in place. Too often I have seen folks operating under an assumption that a control will be in place (i.e. work instruction) but it never is created or put into place. Then there are instances where instructions are assumed to be created, in deed are created and put in place, only to lower an already low RPN. Resources are scarce in most places, so do a good PFMEA, determine your risk points and address them as effectively and efficiently as possible.

Welcome aboard and good luck!!

Kevin