Dear all,
When performing a PFMEA would you recommend to base the severity estimation on the product non-conformance (as potentialy recieved by customer) or effect on the process (the "internal" severity of the non-conformance, i.e. re-work/scrap/production stop etc.)?

In my opinion it's difficult and inappropriate to merge the severity estimation for the product and process effects in the same sentence and number. In addition, the effect on the process will only occur if the product non-conformace is actually detected. Is it just me being confused?

//MH

Dear all,
When performing a PFMEA would you recommend to base the severity estimation on the product non-conformance (as potentialy recieved by customer) or effect on the process (the "internal" severity of the non-conformance, i.e. re-work/scrap/production stop etc.)?

In my opinion it's difficult and inappropriate to merge the severity estimation for the product and process effects in the same sentence and number. In addition, the effect on the process will only occur if the product non-conformace is actually detected. Is it just me being confused?

//MH

My own opinion is that process FMEAs should be concentrated on processes, not products. There will be disagreement in this regard, but to me, it's fairly simple. If a customer has done a DFMEA, and the output of that process is reflected in the product specifications, and the product is manufactured in accordance with the specifications, everyone should be happy, all else being as it should be. This means that I, as the producer of the product, should be able to concentrate on designing a process that will produce product that meets the specifications, and I shouldn't need to concern myself with what might blow up in end use if the product doesn't conform--that's the designer's responsibility.

So to answer your question, I think that the PFMEA Severity factor should be based on the risks of the producer, not the customer.

Thanks for your prompt reply Jim.
It's the disagreement that bothers me, have yet to choose a side. I'm working for a medical device company where patient safety has to be the main quality concern. We're asked to perform the PFMEA with focus on the risks of "manufacturing products out of spec." To me its sounds like I, as a producer, need to know how critical each specification item are and base severity levels on that knowledge.

In your opinion, the severity level of a process failure resulting in misplaced labels will be higher than a process failure resulting in unsterile products, if the re-work effort/scrap amount/production delay etc. are worse for the cosmetic defect?

Severity for a pFMEA should focus on impact on customer/user. Matter of fact the rankings for Severity in pFMEA should come from the dFMEA. You could also include effect on manufacturing, but if you do that you'll either need to have two Severity numbers (which will cause the FMEA to expand phenomenally), or you'll use the higher of the two (e.g., effect on customer vs. effect on process).

Dear all,
When performing a PFMEA would you recommend to base the severity estimation on the product non-conformance (as potentialy recieved by customer) or effect on the process (the "internal" severity of the non-conformance, i.e. re-work/scrap/production stop etc.)?

In my opinion it's difficult and inappropriate to merge the severity estimation for the product and process effects in the same sentence and number. In addition, the effect on the process will only occur if the product non-conformace is actually detected. Is it just me being confused?

//MH

I am not sure why you would consider it difficult or inappropriate to merge the severity estimation. When considering effects you should consider all customers. Customer could include end user, downstream operation etc... List all potential effects and use the worst case (highest) severity of the effects listed as the number in the severity column.

In most cases the severity of a end user effect is greater than that of an internal effect.

Remember that effects are what could happen if you don't have process controls. So potentially all failure modes "could" get to the customer.

I strongly disagree with Jim. Design FMEAs focus and design issues not on problems that could occur in the manufacturing process.

Thanks for your prompt reply Jim.
It's the disagreement that bothers me, have yet to choose a side. I'm working for a medical device company where patient safety has to be the main quality concern. We're asked to perform the PFMEA with focus on the risks of "manufacturing products out of spec." To me its sounds like I, as a producer, need to know how critical each specification item are and base severity levels on that knowledge.

In your opinion, the severity level of a process failure resulting in misplaced labels will be higher than a process failure resulting in unsterile products, if the re-work effort/scrap amount/production delay etc. are worse for the cosmetic defect?

I knew there would be disagreement. The problem with the other responses thus far is that people are reading the AIAG/SAE manual as if it were sacred scripture, and it's far from it. True enough, if you have automotive customers who demand that you go according to the book, you're stuck. But if you don't, you can do what makes sense for you.

I should have stipulated in my original post that I was speaking from the perspective of a job shop or contract manufacturer, and not a captive operation where a DFMEA document and its team might be accessible.

Thanks. Nice to have the other standpoint represented as well.

Even though I would have a hard time "ignoring" the end user in a PFMEA, I still recognize and understand Jims point of view as well. For example, I don't believe many of our component suppliers have an idea about the DFMEA of our final product. I wouldn't expect all of them to have the risks of using our product as input to their PFMEA, yet their manufacturing processes is contributing to considerable risks to our end users.

tac123, I like your way of looking at downstream operation as one of my customers and I will probably end up estimating severity of both "internal" and "external" consequences in one way or another. It just felt like a confusion of ideas when I was about to combine this with detect abilitity. An additional process control would reduce the "external" customer RPN but somehow increase the "internal" RPN since the rejection/re-work/lead time increases....

Severity for a pFMEA should focus on impact on customer/user. Matter of fact the rankings for Severity in pFMEA should come from the dFMEA.

It depends on the circumstances. In job shops, it's unlikely that a customer DFMEA will ever be available, and there's no point in guessing if it's not. I'll say it again: process FMEAs should focus on potential process failures. It doesn't make any sense to do it any other way.

I strongly disagree with Jim. Design FMEAs focus and design issues not on problems that could occur in the manufacturing process.

One of the outputs of the design process is specifications. If the specifications reflect end-use requirements, there is no need to consider end-use requirements per se in production. If we make it like the drawing says, it will have met design intent. If the specifications don't include enough information, there's a different problem that won't be helped by a PFMEA.

It depends on the circumstances. In job shops, it's unlikely that a customer DFMEA will ever be available, and there's no point in guessing if it's not. I'll say it again: process FMEAs should focus on potential process failures. It doesn't make any sense to do it any other way.


I agree that it focuses on processing problems, but also the effect of that processing problem on the resulting product.

The poster should use the Severity table in the FMEA book as a guide.

For example, a dull stamping die could leave a sharp burr. That burr could have a significant impact on either the assembly plant or possibly the end user, when that part is assembled on the vehicle. So, it would get a fairly high Severity number.

The poster should use the Severity table in the FMEA book as a guide.



hjilling, What FMEA book are you referring to?

best regards,

hjilling, What FMEA book are you referring to?

best regards,


I was not looking at the book when I wrote the reply. But, it would be the current version - 3rd ed. I believe. They changed the Severity table in the Process PFMEA section to show two columns - one for End User and one for customer, which is explained in the narrative to mean the assembly plant.

Been a while since I read it, but I am pretty certain of the information.

Why do you ask?

Why do you ask?

Because I assumed you were suggesting me to read an unspecified FMEA book. Is it some fundamental book used in the automotive industry? I guess I'm not enlightened since I'm not working with vehicles, and in a way I envy quality people in the automotive industry for having all the quality tools quite prepared for their needs...

Because I assumed you were suggesting me to read an unspecified FMEA book. Is it some fundamental book used in the automotive industry? I guess I'm not enlightened since I'm not working with vehicles, and in a way I envy quality people in the automotive industry for having all the quality tools quite prepared for their needs...

So sorry, sometimes we get a little too brief on the Cove with our acronyms and all.

AIAG.com is the website for the Big 3 US automotive companies. They published a FMEA guide manual that is a very useful document for anyone who want to use FMEAs as a planning tool, automotive or not. They will sell to the public as well. You do not need to be a member.

So sorry, sometimes we get a little too brief on the Cove with our acronyms and all.

AIAG.com is the website for the Big 3 US automotive companies. They published a FMEA guide manual that is a very useful document for anyone who want to use FMEAs as a planning tool, automotive or not. They will sell to the public as well. You do not need to be a member.

OK. I will see what they got and perhaps order their book as well. Thanks.

OK. I will see what they got and perhaps order their book as well. Thanks.


SORRY. IT IS AIAG.ORG


:mg:

For example, a dull stamping die could leave a sharp burr. That burr could have a significant impact on either the assembly plant or possibly the end user, when that part is assembled on the vehicle. So, it would get a fairly high Severity number.

If a burr can cause problems downstream, it's the responsibility of the designer(s) to make sure that the potential problem is addressed in the specifications. If it is, then it's possible that there's nothing to be gained by giving potential burrs a high severity number in the PFMEA.

If a burr can cause problems downstream, it's the responsibility of the designer(s) to make sure that the potential problem is addressed in the specifications. If it is, then it's possible that there's nothing to be gained by giving potential burrs a high severity number in the PFMEA.

1. In my example, the burr was caused by a dull punch die. That is a tooling issue and should be addressed by sharpened the tooling. In some cases, the designer could reduce and ameliorate the potential effect, but not always.

2. It is unlikely you could persuade a customer engineer to give that request any attention. It is difficult enough to get them to pay attention to root causes they are respnsible for.


:)

The whole point of a PFMEA is to focus attention on the most important functional areas of the product.
If a poor weld would result in a wheel falling off a car then the consequences of failure are far more important than something cosmetic, like scratched paintwork. The weld may have a specification, but a specification won’t stop you making bad parts.
The reason for having a severity rating is to ensure that features which are of a safety critical nature are properly controlled.
The severity ratings must, therefore, consider implications to the end user as well as downstream processes.

The whole point of a PFMEA is to focus attention on the most important functional areas of the product.


No, that's DFMEA territory. The whole point of a PFMEA is to understand (and mitigate, as far as possible) the risks in the production process.

The whole point of a PFMEA is to focus attention on the most important functional areas of the product.
If a poor weld would result in a wheel falling off a car then the consequences of failure are far more important than something cosmetic, like scratched paintwork. The weld may have a specification, but a specification won’t stop you making bad parts.
The reason for having a severity rating is to ensure that features which are of a safety critical nature are properly controlled.
The severity ratings must, therefore, consider implications to the end user as well as downstream processes.

Very good. In fact, if one reads the Severity table (in the PFMEA section of the AIAG FMEA book, 3rd ed.), it does a very good job of describing possible severity levels to both the assembly plants and the end users. A mandatory read if you are going to use FMEAs.

You can also reference the Ford FMEA handbook version 4.1 which was released in February 2004.
The guidelines for PFMEA severity include both the effect to the customer, "Very high severity ranking when a potential failure mode effects safe vehicle operation and/or involves noncompliance with goverment regulation without warning", as well as the effect to downstream assembly/manufacturing operations.

Very good. In fact, if one reads the Severity table (in the PFMEA section of the AIAG FMEA book, 3rd ed.), it does a very good job of describing possible severity levels to both the assembly plants and the end users. A mandatory read if you are going to use FMEAs.

Sure, I agree that the AIAG FMEA 3rd edition book does have severity levels listed but they are pretty tough with the exception of a rating of 9 or 10 which are for safety.

Let's take rating 8 for an example.

"vehicle/item inoperable (loss of primary function)" or in the plant "0r 100% of the product may have to be scrapped, or vehicle/item repaired in repair department with a repair time greater than one hour"

That is pretty easy if a car does not start - 8 but in the plant it becomes fuzzy. If we are missing a hole and the parts will not assemble, we have to come up with a disposition of 100% scrap?? More than 1 hour in the repair department? It could be less than an hour depending upon when the nonconformity was caught. Maybe we have parts mixed with some have all the holes and some with a hole missing.

How is this? Doesn't work (won't assemble) - 8 and don't worry about the disposition
7 - works but needs big hammer or car starts but sputters down the road
6 - works but needs smaller hammer.
4 - visually pretty ugly - everyone sees it
3 - visually bad - less severe than ugly

The AIAG standard is recommended but not manditory. I would use it to come up with something a bit easier in the plant.

The AIAG and Ford listed severity levels are purely guidelines to aid the selection of an appropriate severity rating. Tha manuals could not possibly cover all eventuality.
At the end of the day, a common sense approach is needed and as long as you can justify your selection as conforming to the guidelines, you won't get many arguements.
Remember that PFMEA is a tool to help you to predict failure and improve your controls. Be realistic, based on your knowledge of the fit and function of the product and your customer processes (internal and external).

My own opinion is that process FMEAs should be concentrated on processes, not products. There will be disagreement in this regard, but to me, it's fairly simple. If a customer has done a DFMEA, and the output of that process is reflected in the product specifications, and the product is manufactured in accordance with the specifications, everyone should be happy, all else being as it should be. This means that I, as the producer of the product, should be able to concentrate on designing a process that will produce product that meets the specifications, and I shouldn't need to concern myself with what might blow up in end use if the product doesn't conform--that's the designer's responsibility.

So to answer your question, I think that the PFMEA Severity factor should be based on the risks of the producer, not the customer.



Dear sir,


YOU HAVE BROUGHT A BEAUTIFUL ANGLE. I AGREE WITH YOUR STATEMENT YET IN PRACTICE I CONSIDER BOTH PRODUCT & PROCESS & FINAL SEV. I TAKE AS MAX. OF TWO

Hi,
I am new here today. I have gone thru some of the discussion regarding DFMEA & PFMEA.
I am doing a DFMEA & PFMEA for a Throttle Body (butterfly valve) for Automotive/engine. I appreciate if anyone has any example of this.
Thanks,

Hi,
I am new here today. I have gone thru some of the discussion regarding DFMEA & PFMEA.
I am doing a DFMEA & PFMEA for a Throttle Body (butterfly valve) for Automotive/engine. I appreciate if anyone has any example of this.
Thanks,

Welcome to The Cove Forums! :bigwave:

Forum courtesy suggests to not duplicate posts in other threads.

Your other post is addressed.

Stijloor.

I strongly disagree with Jim!!! If a wheel can fall off the car, it's not only caused by design. It can be an improper use of tool, no control in place, etc. That's why the purpose of an PFMEA is to ensure safety and quality to the user, but also to peolple working further on the line. From the PFMEA, you have to create control to reduce failure.

I strongly disagree with Jim!!! If a wheel can fall off the car, it's not only caused by design. It can be an improper use of tool, no control in place, etc. That's why the purpose of an PFMEA is to ensure safety and quality to the user, but also to peolple working further on the line. From the PFMEA, you have to create control to reduce failure.

If the wheel falls off of the car due to a manufacturing defect unrelated to design (i.e., the product didn't meet specifications), then what I said earlier (The whole point of a PFMEA is to understand [and mitigate, as far as possible] the risks in the production process) is correct, no? Keep in mind that one of the prime risks in production processes is production of nonconforming material.

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!!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I've been away from the Cove for a bit, have read all the comments in this forum and will make sure to visit much more often!! Great work to all!!

I have found in doing FMEA's within a number of industries that the team will get hung up on one column and forget that we are looking for priority numbers to ferret out the most significant problem(s). Keep in mind that severity numbers of a 9 or 10 typically involve safety or damage concerns either with or without notice. A design change may be required to eliminate these failure modes.

Don't be afraid to use high severity numbers. If the occurance is low and detection is high, the RPN will tend to drop this failure mode below radar. If this is not the case, well then the FMEA did as intended.

Consider the use of severity x occurance to calculate the Initial Risk. Typically, IR's of 35 or greater require attention; use the RPN to sort out which ones to work on first. This gets away from the old rules still hanging around out there of RPN's of 100 or greater (or whatever). Some how when those rules are applied it is amazing to find that there are no RPN's that reach that value!

Keep up the great work!
Phil

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.


Thanks Helmut,
I have had thoughts that we may be overcomplicating the pFMEA process by trying to focus both on external and internal effects. My life would be easier if I resolved to only consider external effects, except in cases of safety in the building of the product. I may end up there yet. But I wanted to explore a bit more the value in using pFMEA for addressing internal process impacts which can help lower costs for us and the customer. However, I'm not convinced that the benefits outweigh the extra complexity and questions raised - especially if it causes the pFMEA to be bogged down, which is one of the complaints of my current employer.

I think one way to make the internal ratings less confusing is to express process FMs as process failures. This essentially brings the nature of the process failure to the forefront of the FMEA analysis, allowing for a better internal impact assessment without going to the next step - causes. That way we can focus on the high impact stuff first. This also does not limit the team from identifying the end user effect, which now becomes the potential end product failure, due to the product symtom "effect", due to the process FM in the pFMEA. This approach seems to focus the pFMEA team more on understanding the relationships between product and process requirements - which is a good thing.

Still on the fence though. But getting closer...

Thanks all.

Any other thoughts out there on this topic in regard to my comments/questions? This has been a great help so far. Thanks !:bigwave: