FMEA - What is the relationship between Detection and Prevention? QP Newbie question.

[jay_m]

Hello all, first timer here.

I am new to FMEA and have a question about cause, detection/prevention and actions.

For a given cause, I realize I can have multiple detection controls, and multiple prevention controls.

But what is the relationship between detection and prevention? are they just independent lists of controls or does the presence of one require/influence the other (e.g. 1:1, 1:N, etc).

I am trying to build a template for this and these rules are important to understand.

thanks in advance!

ALSO - if there is a good reference for these types of "linkage" questions please let me know and I might stop asking dumb questions faster

 

[cokyat]

I dont think that there is a relationship between prevention and detection. The AIAG FMEA handbook clearly define:

Detection as " An assessment of the probability that the proposed type of current process controls will detect a potential cause...".

I usualy refer to my "rejection history" when we perform FMEA and determine the ranking based on the likelihood the rejection will happen again when using the same detection system.

While preventive measure is defined as "measures which can be done NOW to prevent the occurence of the potential problem by eliminating each most probable cause".

Preventive measures should not only be implemented based on a specific cause...it should create a ripple effect to the whole system. It should be applied to similar processes with similar potential failure modes.

 

[Bill Ryan - 2007]

Welcome to the Cove, Jay

I can only respond from my experience with our automotive customers. The Detection Control should rate your ability to "catch" a nonconformance with the assumption that the nonconformance has occurred. Therefore it is tied directly to the Failure Mode - nothing to do with the Failure Cause.

The Prevention control is a rating of your control of a Failure Cause (ie: process parameter). This may be "preventative" or "detective" in nature but should only influence your Occurrence rating on the PFMEA form.

As a simplistic example: Our die cast machines have a "bad shot alarm" which programs the extractor robot to place the shot into a scrap tub. One of the Failure Modes produced by a "bad shot" is nonfills on the part(s). The scrapping of the shot is "preventative" in the sense that the part is automatically taken out of the process, but it is also "detective" in that the Failure Mode has been produced. Since it is a "process control", I put it in the Prevention Control column. However, it could also be placed in the Detection Control column.

Please See this thread where Rob Nix has begun a discussion of some of the shortcomings of the FMEA format. There are many - however, IMO, it is a good tool to document your assessments of various risks. The form itself is not the important part of the FMEA excersize but, in my experience, it is important that you have clear definitions of what constitutes a Failure Mode vs. a Failure Cause or you will go round and round trying to fill in the form.

Hope that helps a little.

 

[jay_m]

One post and I love this place already!

As a programmer, I know how to build data models and user interfaces. However it will take some effort for me to understand the implied relationships behind the sample FMEAs in the AIAG reference.

When I review the sample DFMEA on page 26 (3rd edition; table 1. design fmea) it appears that:

[Recommended actions, controls detection, and controls prevention] relate to [potential cause(s)/mechanism(s) of failure] (1:N)

In other words, for each cause there are i prevention and j detection entries, followed by k recommended actions. The cause relates to the effects of the failure mode, and the controls and actions refer to the cause.

Is this a correct assumption?

 

[Jim Wynne]

As a programmer, I know how to build data models and user interfaces. However it will take some effort for me to understand the implied relationships behind the sample FMEAs in the AIAG reference.

When you do get to understand the AIAG manual, I hope you'll share your insights, as you will probably be the first to achieve that level of comprehension .

When I review the sample DFMEA on page 26 (3rd edition; table 1. design fmea) it appears that:

[Recommended actions, controls detection, and controls prevention] relate to [potential cause(s)/mechanism(s) of failure] (1:N)

In other words, for each cause there are i prevention and j detection entries, followed by k recommended actions. The cause relates to the effects of the failure mode, and the controls and actions refer to the cause.

Is this a correct assumption?

Although I've just discovered that someone has once again absconded with my FMEA manual , I think the previous responses here have been made under the assumption that it was a process FMEA you were referring to. The expectations for a DFMEA are a little different. One of the changes embodied in the 3rd Edition of the manual was the bifurcation of the "Current Process Controls" column, and imo it was a mistake to split the DFMEA column into Prevention and Detection categories, because there's little that can be done in a product design process to facilitate detection, and it's also not clear, as you've discovered, exactly what "detection" means in this context. The goal should be to design the product in such a way that defects (effects especially) don't happen; the causes of design defects are inherent in the design process itself (rather than in the product) so adding the "detection" column sets up an endless loop of sorts. My advice is to disregard the manual and do what makes sense when the manual doesn't make sense.

 

[jay_m]

Thanks for the input.

It's starting to look like I should consider the data from Cause->Controls->Actions as a set, rather than a sequence.

It visually implies a sequence, but in fact the Detection Controls are an independent list, the Prevention Controls another, and the Actions are yet another but unlike the previous two Action maintains a subset of properties tied to it (responsibility, actions taken, sev, occ, det, RPN)

 

[Jaco]

Hello Bill,
Just have 1 information and 1 comment for your post,

Welcome to the Cove, Jay

I can only respond from my experience with our automotive customers. The Detection Control should rate your ability to "catch" a nonconformance with the assumption that the nonconformance has occurred. Therefore it is tied directly to the Failure Mode - nothing to do with the Failure Cause.

The new FMEA manual of Ford has been released already, there is one sentence in PFMEA section clearly explained the meaning of detection, I do not remember exact words in the manual, but I am sure it says dectection should be the capability to catch the failure mode or failure cause.

As a simplistic example: Our die cast machines have a "bad shot alarm" which programs the extractor robot to place the shot into a scrap tub. One of the Failure Modes produced by a "bad shot" is nonfills on the part(s). The scrapping of the shot is "preventative" in the sense that the part is automatically taken out of the process, but it is also "detective" in that the Failure Mode has been produced. Since it is a "process control", I put it in the Prevention Control column. However, it could also be placed in the Detection Control column.

From my understanding "scrapping of the shot by robot" is a detection, to find out the preventative control, you need to analyse what is reason that might cause the bad shot, the preventative control should be taken to eliminate the causes of bad shot

pls correct me if i am wrong on this point, thanks!

 

[Bill Ryan - 2007]

Hello Bill,
Just have 1 information and 1 comment for your post,



The new FMEA manual of Ford has been released already, there is one sentence in PFMEA section clearly explained the meaning of detection, I do not remember exact words in the manual, but I am sure it says dectection should be the capability to catch the failure mode or failure cause.


From my understanding "scrapping of the shot by robot" is a detection, to find out the preventative control, you need to analyse what is reason that might cause the bad shot, the preventative control should be taken to eliminate the causes of bad shot

pls correct me if i am wrong on this point, thanks!

Jaco - the part you quoted from my post explains that it depends on how you wish to treat the "auto scrapping" of the part. In the die casting process there are many interactive, as well as "primary", process failures (causes). As stated, in one sense it is preventive because it stops the part from being shipped (and that is how we have decided to present it). You are correct that it is a detective control using the definition that the failure has manfested itself into the product (perhaps). Because the bad shot alarm "catches", and disposes of, many potential failure modes of the product, we put it in the Prevention Control column and then, also, have a Detection Control of visual (or some other means) inspection. The approach may not be perfect in regards to format but, as Jim has mentioned in a couple of recent threads, how you get there is not nearly as important as getting there. I enjoy "discussions" with SQEs more concerned with format than content

Regarding the Ford FMEA handbook, if, in fact, they state that a Detection Control should catch either a Mode or a Cause, they are muddying the waters with regard to every one of my customers. The Detection Control is the ability to catch the Mode once it has been processed/produced for suppliers to any other automotive customer. (But then again, if there was agreement between the B3 there couldn't be any CSRs could there?)

Here's the bottom line from my perspective: You pick a methodology that works for you and you defend it. The North American automotive world is far from perfect and no one has the "Golden Egg" designed yet. I will always listen to different ideas and weigh them against my current practice(s). Sometimes an idea makes sense. But when I get the "my way or the highway" attitude with no "intelligent" conversation/discussion, I like to say "See ya".

 

[Jim Wynne]

Here's the bottom line from my perspective: You pick a methodology that works for you and you defend it. The North American automotive world is far from perfect and no one has the "Golden Egg" designed yet. I will always listen to different ideas and weigh them against my current practice(s). Sometimes an idea makes sense. But when I get the "my way or the highway" attitude with no "intelligent" conversation/discussion, I like to say "See ya".

Well said!

 

[Helmut Jilling]

Hello all, first timer here.

I am new to FMEA and have a question about cause, detection/prevention and actions.

For a given cause, I realize I can have multiple detection controls, and multiple prevention controls.

But what is the relationship between detection and prevention? are they just independent lists of controls or does the presence of one require/influence the other (e.g. 1:1, 1:N, etc).

I am trying to build a template for this and these rules are important to understand.

thanks in advance!

ALSO - if there is a good reference for these types of "linkage" questions please let me know and I might stop asking dumb questions faster

There may be cases where there is a relation between Prevention Control Methods and Detection Methods, but don't worry yourself trying to link them.

Either control is acceptable, but logically, a prevention is better than mere detection, because it reduces loss and waste. For some, the only control you can develop is detection. But, prevention is better. The purpose for the two columns is if there is two much white space in your prevent column, it graphically demonstrates you should try hard to develop preventions.

The additional recommended actions columns are for those line items, where the score is very high, suggesting you should roll up your sleeves and do more. It is not expected to be used on every line item, just the most significant ones.

Don't overwork this, the format is just a worksheet to help you clarify and document your thinking. Of course, it has to be kept as a PPAP record.
Hope this helps.