PFMEA Severity - What is Process FMEA Severity estimation based on?

  • Thread starter Matthew_Hopkins
  • Start date

Helmut Jilling

Auditor / Consultant
Hi all,

I'm new to this site, and forums in general, but feel lucky to have come across this wealth of information. I've been involved with and facilitated FMEAs in the past, and my current employer has me looking at their pFMEA methods to extract more value and to streamline the process (pFMEA). I need to make this tool practical and valuable for the product/process development efforts I'm involved in.

This thread hits on an item that continues to nag me as I try to clarify and standardize certain aspects of our pFMEAs. I'd appreciate any help to get to a workable solution. I hope you'll forgive my wordiness here to try to express my complete thoughts.

It seems that failure mode definition is very key in getting the pFMEA started in the right direction. For a dFMEA, I think failure mode definition is more clear than for a pFMEA. A pFMEA has a potential dual path for FM definition: 1) a symptom/defect on the product or 2), failure of a process step to perform its intended function.

If I choose #1 (a symptom/defect on the product), I seem to be more in line with how most pFMEAs are done (is this true)?

Possible Benefits of #1 Approach:
> Failure mode generation seems more straight forward (if requirements are well defined) basing them on the ways in which the built product can vary from the product requirements - dimensional, visual, design..
> FM at the product makes Effect and SEV easier to tie to critical design characteristics and customer impacts.
> Causes in the process can be expressed at a higher level to help with efficiency of the pFMEA, but still identify areas of concern that may require further root cause investigation.

Potential Problems with #1:
> It seems to me, this approach makes identifying internal effects and SEV meaningless. Since the severity assessment is supposed to be based on the failure, without consideration of frequency or probability of occurance, I can't see how to tie a non-conforming product into a quantifyable internal impact. For instance, often I've seen generic process impacts of scrap, downtime, rework in these types of FMEAs. Sure, but in order to assign a SEV ranking to these, I need to understand the nature of the cause, or failure in the process, to determine how much - scrap, downtime, etc.
> I saw in an earlier post, and agree, that working from a product based symptom to a process cause can miss failure potentials in the process because the focus is not on the process based requirements/functions, but on the product based requirements.

#2 FM defined as failure of a process step to perform its intended function.

Possible Benefits:
> This method focuses on the process requirements (such as - hold energy at XmJ +/- YmJ; clamp part; spin part at Xrpm, etc), which need to stem from the product requirements, and can capture more ways in which the process can fail by focusing on how the process requirements could not be met.
> The causes for these FMs are closer to, or are, the root causes of the problems, getting the team closer to proper mitigation action.
> The internal effects can be assessed at the failure mode stage of the analysis because the nature of the process failure is more clear. Also, the external effect can still be assessed. Note: I think a tie to the external is always needed to put failures into context so appropriate actions and priorities can be set. All product requirements are not equal - some can kill if not met, others make the product less pretty.


Possible Problems:
> This seems to me a deeper level FMEA. We have moved down one notch in the cause-effect; or effect-cause in this case, hierarchy by choosing process failure - which is the cause of the product defects - as our FM. A deeper FMEA requires more up front time, better understanding of product/process relationships, better defined steps and functions, more specific process SME involvement - maybe not bad things? But this may not be as familiar and will take more time - which management won't like, (but I can sell it if it's the right thing to do).

Lastly, I've seen FMEAs where both #1 and #2 types of failure modes are used which would be very confusing - one FM is a defect and another FM can cause the same defect.


I hope you can see how this has been bothering me, and that I've given it some significant thought. I believe that I need to choose one path here to help avoid some of the pitfalls and get a more functional system Please send your thoughts and recommendations. Thank You!!


Welcom to the Elsmar Cove. You might be overthinking this. It may be helpful to read the sections by the Tables again.

For Severity, you are to consider both columns, and select the higher rating. For example, a missing mounting bracket thread would show a moderate Severity on the Assembly line, but nothing on the end user. But a defective sensor on an airbag could score low on the assembly line, but would be very severe to the end user.

Frequency and Amounts would factor into Occurance. Volume of something is a little less clear. You would need to make a judgement as to whether it would factor into Occurance or Severity.
 

Jim Wynne

Leader
Admin
Hi all,

I'm new to this site, and forums in general, but feel lucky to have come across this wealth of information. I've been involved with and facilitated FMEAs in the past, and my current employer has me looking at their pFMEA methods to extract more value and to streamline the process (pFMEA). I need to make this tool practical and valuable for the product/process development efforts I'm involved in.

This thread hits on an item that continues to nag me as I try to clarify and standardize certain aspects of our pFMEAs. I'd appreciate any help to get to a workable solution. I hope you'll forgive my wordiness here to try to express my complete thoughts.

It seems that failure mode definition is very key in getting the pFMEA started in the right direction. For a dFMEA, I think failure mode definition is more clear than for a pFMEA. A pFMEA has a potential dual path for FM definition: 1) a symptom/defect on the product or 2), failure of a process step to perform its intended function.

If I choose #1 (a symptom/defect on the product), I seem to be more in line with how most pFMEAs are done (is this true)?

Possible Benefits of #1 Approach:
> Failure mode generation seems more straight forward (if requirements are well defined) basing them on the ways in which the built product can vary from the product requirements - dimensional, visual, design..
> FM at the product makes Effect and SEV easier to tie to critical design characteristics and customer impacts.
> Causes in the process can be expressed at a higher level to help with efficiency of the pFMEA, but still identify areas of concern that may require further root cause investigation.

Potential Problems with #1:
> It seems to me, this approach makes identifying internal effects and SEV meaningless. Since the severity assessment is supposed to be based on the failure, without consideration of frequency or probability of occurance, I can't see how to tie a non-conforming product into a quantifyable internal impact. For instance, often I've seen generic process impacts of scrap, downtime, rework in these types of FMEAs. Sure, but in order to assign a SEV ranking to these, I need to understand the nature of the cause, or failure in the process, to determine how much - scrap, downtime, etc.
> I saw in an earlier post, and agree, that working from a product based symptom to a process cause can miss failure potentials in the process because the focus is not on the process based requirements/functions, but on the product based requirements.

#2 FM defined as failure of a process step to perform its intended function.

Possible Benefits:
> This method focuses on the process requirements (such as - hold energy at XmJ +/- YmJ; clamp part; spin part at Xrpm, etc), which need to stem from the product requirements, and can capture more ways in which the process can fail by focusing on how the process requirements could not be met.
> The causes for these FMs are closer to, or are, the root causes of the problems, getting the team closer to proper mitigation action.
> The internal effects can be assessed at the failure mode stage of the analysis because the nature of the process failure is more clear. Also, the external effect can still be assessed. Note: I think a tie to the external is always needed to put failures into context so appropriate actions and priorities can be set. All product requirements are not equal - some can kill if not met, others make the product less pretty.


Possible Problems:
> This seems to me a deeper level FMEA. We have moved down one notch in the cause-effect; or effect-cause in this case, hierarchy by choosing process failure - which is the cause of the product defects - as our FM. A deeper FMEA requires more up front time, better understanding of product/process relationships, better defined steps and functions, more specific process SME involvement - maybe not bad things? But this may not be as familiar and will take more time - which management won't like, (but I can sell it if it's the right thing to do).

Lastly, I've seen FMEAs where both #1 and #2 types of failure modes are used which would be very confusing - one FM is a defect and another FM can cause the same defect.


I hope you can see how this has been bothering me, and that I've given it some significant thought. I believe that I need to choose one path here to help avoid some of the pitfalls and get a more functional system Please send your thoughts and recommendations. Thank You!!

Welcome to the Cove. :D

What you're struggling with is, I believe, a problem with the SAE/AIAG strategy, and something I recognized a long time ago when I first came innocently and relatively uncorrupted :tg: to automotive production.

To my way of thinking, if a DFMEA is properly done (which means that efficacious specifications and requirements have been developed and codified) a person in a job shop should not need to see it or take it into consideration when doing a PFMEA. I know that this idea is heretical, but no one has ever been able to convince me otherwise.

As far as the PFMEA and failure modes are concerned, I take a similarly unorthodox stance in believing that we should concentrate primarily on potential failures of the process, and not the manifestations of those failures in the product (part defects). This approach causes people to concentrate on process control and its effects on the finished product.

Before you veer away from the FMEA manual guidelines and do what you think makes good sense (not always a welcome strategy) you should carefully consider your customers' requirements, and what they expect to see.
 
P

PaulMac

Thank you very much for your considerations Helmut and Jim!

Helmut,
This would definitely not be the first time I'd be guilty of overthinking something :).

I don't have time at the moment to ask a bit more, but wanted to thank you guys for your help so far. Talk to you later.
 
P

PaulMac

Welcom to the Elsmar Cove. You might be overthinking this. It may be helpful to read the sections by the Tables again.

For Severity, you are to consider both columns, and select the higher rating. For example, a missing mounting bracket thread would show a moderate Severity on the Assembly line, but nothing on the end user. But a defective sensor on an airbag could score low on the assembly line, but would be very severe to the end user.

Frequency and Amounts would factor into Occurance. Volume of something is a little less clear. You would need to make a judgement as to whether it would factor into Occurance or Severity.


Thanks again Helmut,
Again, I may be overcomplicating but these types of questions are the kinds of things that slow down our pFMEA sessions. My point is that I can more easily assess the external effect of a failure in a product characteristic than I can an internal (process) effect. If I define my failure mode as a product defect/dimensional/design related failure, I cannot assess internal impacts at the FM/severity level. I must go into the causes/probability, and even detection to assess process impact.

From your example, missing bolt threads and missing air bag sensors may look equally severe/or not severe to me from just an internal standpoint because I don't know how many defectives were created, what broke in the line, and how long it will take to fix it, etc. These I get from understanding the process causes.

So, does anyone have a solution to this?

Thanks.
 
P

PaulMac

Welcome to the Cove. :D

What you're struggling with is, I believe, a problem with the SAE/AIAG strategy, and something I recognized a long time ago when I first came innocently and relatively uncorrupted :tg: to automotive production.

To my way of thinking, if a DFMEA is properly done (which means that efficacious specifications and requirements have been developed and codified) a person in a job shop should not need to see it or take it into consideration when doing a PFMEA. I know that this idea is heretical, but no one has ever been able to convince me otherwise.

As far as the PFMEA and failure modes are concerned, I take a similarly unorthodox stance in believing that we should concentrate primarily on potential failures of the process, and not the manifestations of those failures in the product (part defects). This approach causes people to concentrate on process control and its effects on the finished product.

Before you veer away from the FMEA manual guidelines and do what you think makes good sense (not always a welcome strategy) you should carefully consider your customers' requirements, and what they expect to see.


Thanks again Jim,

Points well taken in regard to what the customer expects. I want to clarify something between a dFMEA and pFMEA that seems stupidly simple but I've worked myself into an FMEA circle of confusion that will need some basic thinking to get me out of it.

In the typical / std approach for dFMEA and pFMEA, are the FMs the same considering they are both product characteristics oriented? The difference being the dFMEA causes would be design related and the pFMEA causes would be process related? Thanks.
 

Helmut Jilling

Auditor / Consultant
Thanks again Helmut,
Again, I may be overcomplicating but these types of questions are the kinds of things that slow down our pFMEA sessions. My point is that I can more easily assess the external effect of a failure in a product characteristic than I can an internal (process) effect. If I define my failure mode as a product defect/dimensional/design related failure, I cannot assess internal impacts at the FM/severity level. I must go into the causes/probability, and even detection to assess process impact.

From your example, missing bolt threads and missing air bag sensors may look equally severe/or not severe to me from just an internal standpoint because I don't know how many defectives were created, what broke in the line, and how long it will take to fix it, etc. These I get from understanding the process causes.

So, does anyone have a solution to this?

Thanks.

Perhaps you are misunderstanding the purpose of the Severity column. The focus is to evaluate Severity impact on the customer and the end user, not on you. (The Detroit 3 don't care about your impact). The focus is to evaluate the Severity impact that a process failure like a broken tap would have. You compare the rankings in the table to the expected impact (ie: like a broken tap) on the customer assembly and the end user. The rankings in the table give you some guidance on what ranking value to assign. It is not a precise science, but is a legitimate analysis and assigning of risks, to help you focus attention on the more significant issues.
 

Stijloor

Leader
Super Moderator
Perhaps you are misunderstanding the purpose of the Severity column. The focus is to evaluate Severity impact on the customer and the end user, not on you. (The Detroit 3 don't care about your impact). The focus is to evaluate the Severity impact that a process failure like a broken tap would have. You compare the rankings in the table to the expected impact (ie: like a broken tap) on the customer assembly and the end user. The rankings in the table give you some guidance on what ranking value to assign. It is not a precise science, but is a legitimate analysis and assigning of risks, to help you focus attention on the more significant issues.

The "Customer" in an FMEA study can also be the next (internal) operation. To state that the "Detroit 3 don't care about your impact" is a little strong IMHO.

Stijloor.
 

Helmut Jilling

Auditor / Consultant
The "Customer" in an FMEA study can also be the next (internal) operation. To state that the "Detroit 3 don't care about your impact" is a little strong IMHO.

Stijloor.

I agree the internal customer is always important, and a key part of my work. But, the focus of Severity in a PFMEA, as cleary sated in the AIAG manual is the impact on the OE assembly and the ultimate end-user. They even give a dual scale to help measure that.



As to how much the Detroit 3 care about their suppliers might make for an interesting and robust debate on a different thread. :notme:

Hint, people should ask their customers' Purchasing agents to read the 8 principles in ISO, particularly #8. But that should be a different discussion.
 

bobdoering

Stop X-bar/R Madness!!
Trusted Information Resource
I agree the internal customer is always important, and a key part of my work. But, the focus of Severity in a PFMEA, as clearly sated in the AIAG manual is the impact on the OE assembly and the ultimate end-user. They even give a dual scale to help measure that.

I used to think the origin of the severity should be the OEM's DFEMA or SystemFMEA, but I am thinking now it should also include be the OEMs assembly PFMEA.

Think they would share? Why should the tier have to guess? I am really tired of the guessing game. I think if the OEM does not share, the Severity value should default to 1. Maybe then some cooperation in the process would ensue.
 

Helmut Jilling

Auditor / Consultant
I used to think the origin of the severity should be the OEM's DFEMA or SystemFMEA, but I am thinking now it should also include be the OEMs assembly PFMEA.

Think they would share? Why should the tier have to guess? I am really tired of the guessing game. I think if the OEM does not share, the Severity value should default to 1. Maybe then some cooperation in the process would ensue.

I agree. The FMEA book specifically states you are to use the DFMEA to guide the PFMEA. Good luck with that. I would guess OE's give the DFMEA maybe 3% of the time. Sometimes I wonder if they even do one.
 
Top Bottom