PFMEA (Process FMEA) issue about lower RPN - AIAG 3rd edition page 55

[LI Yan]

Hi, I have a question about FMEA manual(AIAG, 3rd edition), in P55, as following
"To reduce the probability of occurrence, process and/or
design revisions are required. An action-oriented study
of the process using statistical methods could be implemented
with an ongoing feedback of information to the
appropriate operations for continuous improvement and
defect prevention.
• Only a design and/or process revision can bring about a
reduction in the severity ranking."

1. Can somebody explain why "design" and "process" in different sequence to lower "S" and "O"?
2. Can only "process revision" lower "S"? I have heard from somebody, said no.

 

[D.Scott]

Re: PFMEA issue about lower RPN

Hi, I have a question about FMEA manual(AIAG, 3rd edition), in P55, as following
"To reduce the probability of occurrence, process and/or
design revisions are required. An action-oriented study
of the process using statistical methods could be implemented
with an ongoing feedback of information to the
appropriate operations for continuous improvement and
defect prevention.
• Only a design and/or process revision can bring about a
reduction in the severity ranking."

1. Can somebody explain why "design" and "process" in different sequence to lower "S" and "O"?
2. Can only "process revision" lower "S"? I have heard from somebody, said no.

1) I think the easiest explanation comes by way of looking at the process of packing a parachute. The severity assigned to a parachute failure to open would be 10 because failure would result in some one's death. The only way to change the severity would be to redesign the parachute so it wouldn't matter if it didn't open. Nothing you do in your packing process will effect the severity. You can, by improving the process, lower the number of times the chute is packed wrong. This would reduce the "O" (occurrence) RPN. Detection ("D") can also be improved in your packing process and reduce the RPN.

2) I don't like to say "only" but in most cases the severity ("S") has to be reduced through re-design of the product, not the process. I suppose it is possible for a process revision to lower the severity RPN but I sure can't think of an example.

I hope this addresses your question.

Dave

 

[LI Yan]

Thank Dave's quick answer. I also cannot imagine what examples can demonstrate a process revision can lower severity. But the reference manual mentions "Only a design and/or process revision can bring about a
reduction in the severity ranking." . That mearns both design and process revision could reduce S alone, not MUST be coperated to use?
I also want clearify a Engilish grammar:
Can expression "A and/ or B" disassemble to "A+B" or "A alone" or "B alone"?

 

[harry]

I also want clearify a Engilish grammar:
Can expression "A and/ or B" disassemble to "A+B" or "A alone" or "B alone"?

Yes, you are right.

 

[LI Yan]

This question puzzle me several years. Years ago, I attended a training presented by a TS training company (so well known ) the trainer explained this grammar like this: "A and/or B" = "A+B"; or "A alone". Has any body know it?

 

[LI Yan]

For this case, "only Design and /or process revision can lower S" means "design and process revision can lower S" or "only design revision can lower S", but process revision cannot lower S. If so, very reasonable!

But precondition(grammar) is not correct, right?

 

[Bill Ryan - 2007]

I think we may be getting hung up on the Failure Mode being Product related. In that case, I agree that the "only" way to reduce the Severity ranking is through a design change.

If the Failure Mode is Process related (a parameter of some sort), then it seems a change made to the process could reduce the ranking. For instance: if my process has a high severity for hold time in the machine and I performed a DOE which showed I could change a less critical parameter which would lessen the impact of hold time, I would then reduce the severity ranking for that Failure Mode.

Does that help any????

 

[LI Yan]

Maybe you are right. But still I cannot got whole picture of your example. I also think you maybe lowered the ocurence ranking, not severity ranking. Your detailed example will be appreciated.

 

[Miner]

Bill is on the right track. Try another example where the effect of the failure mode was tooling damage and days of downtime to repair the tooling. You might redesign the process itself in such a way that the same failure mode no longer causes tooling damage. This would reduce the Severity rating through the process.

If the effect is on the product instead , only a design change can reduce the Severity rating.

 

[Jim Wynne]

Bill is on the right track. Try another example where the effect of the failure mode was tooling damage and days of downtime to repair the tooling. You might redesign the process itself in such a way that the same failure mode no longer causes tooling damage. This would reduce the Severity rating through the process.

If the effect is on the product instead , only a design change can reduce the Severity rating.

When we're dealing with process failures--as opposed to product defects--as failure modes, there will be times when the process fails but there is no impact on whether the product meets specifications. For example, unscheduled down time is a process failure that probably doesn't result in defective product. Nonetheless, it's still a process failure, and still has the potential to result in unhappiness. So when we characterize failure modes as process failures, there is the potential for high severity that doesn't necessarily impact the physical condition of the product, and the severity RPN factor can change without a concomitant change in the design of the product.

It's important to remember that the AIAG-style FMEA began its life as strictly design-oriented, and only later was it co-opted to address post-design processes. The application to processes was not well thought out, imo, and was generally intended to apply to captive processes, where there was a natural flow from the DFMEA to the PFMEA. Such is not the case, of course, in job shops, where access to DFMEAs is often nonexistent, and where it might not be known if the customer has done a good job of translating DFMEA output into the specifications received by the company that actually makes the parts.

For these reasons, I always urge suppliers to start out with the assumption that the customer's specifications are the result of a conscientious design process, and to further assume that if the product is made to meet the specifications, everyone will be happy. Given those assumptions, it just makes sense to have the PFMEA process concentrate on process control. That is to say, defining failure modes as ways the process might fail, with part defects (or other bad things) being the effects.