FMEA - Any Alternatives?

[Stephen McKelvey]

We have tried using FMEA as part of our design process. Done properly
(assembling teams of experts, exhaustively considering all the failure
modes, documenting the findings, etc.) we find that it can be an
expensive process that does not often yield any useful design
improvements. Does anyone have any suggestions for streamlining the
process or alternative techniques?

[Herb Fritatta]

Nothing beats common sense. Unless you're an automotive supplier or for
some other reason you're tied to the AIAG/SAE abomination, there's no
reason for you to cleave to that particular method. You don't mention
what it is you're designing, so I have no idea what level of complexity
you're dealing with, or how variables might interact, but it's really
pretty simple if you allow it to be. You're trying to determine how a
given product (could be top-level, or a sub-assembly) might fail, what
might happen if it *does* fail, and whether it's worth it to worry about
it or not. Be thorough in your data collection, and make sure of the
integrity of the data. In other words, make well-informed decisions.
Make sure that the appropriate actions are taken. Document what you've
done.

[Matti Vuori]

stephen....@uwggroup.com (Stephen McKelvey) wrote in
news:3e5d7e96.04082...@posting.google.com:

> We have tried using FMEA as part of our design process. Done properly
> (assembling teams of experts, exhaustively considering all the failure
> modes, documenting the findings, etc.) we find that it can be an
> expensive process that does not often yield any useful design
> improvements.

Be happy about that - you obviously do your design properly. Don't consider
FMEA to be a design tool, but a tool for risk analysis. The fewer problems
and improvements you find, the better.

--
Matti Vuori
http://sivut.koti.soon.fi/mvuori

[rickto...@sbcglobal.net]

"Matti Vuori" <mvu...@koti.soon.fi> wrote in message
news:cgjvj1$fjj$1...@phys-news1.kolumbus.fi...

Control Plans and Process Mapping are the compliment to the FMEAs, so much
so that the Third Edition FMEA adds a new column for the Method of Control
(measurement methods).
Why your organization is looking for a substitute for an active FMEA
activity, try pushing Control Plans before presenting the FMEA.
It's a reversed planning process, but if your administration recoils from
FMEA, CPs are easier to understand and digest...

A robust AQP order:

Contract Reviews
Feasibility Analysis
Process Mapping
FMEA
Control Plan (and pre-Launch CPs)
Inprocess Inspection and Testing (potentially with SPC)
PPAP / First Article (Ppk, Cpk, MSA)
Launch part production...

Hope this helps, it's the most effective model I've found.
Does anyone have the experience with Process Mapping, in conjunction with
the FMEA?

rt, illinois

[Herb Fritatta]

I think you're a little confused. The 3rd Edition of the AIAG FMEA
manual (and its SAE counterpart) added a second column for control
methods in order to make the important distinction between preventive
controls and detection controls.

I don't see much sense in putting the cart before the horse; doing a
control plan prior to FMEA is bound to be counter-productive. I've
personally reviewed *thousands* of supplier PPAP submissions and if
there's one thing that stands out it's that no one seems to understand
that a process control plan is not supposed to be an inspection plan.
There are two columns on the PCP form for "characteristics"; one for
part characteristics and one for process characteristics. In the vast
majority of the control plans I've seen, the Process Characteristics
field has been left totally blank or contains entries that indicate
that the supplier doesn't understand what's meant by "process
characteristic." And the whole idea should be to understand the process
well enough that parts don't have to be measured, or part measurement is
kept to an absolute minimum. "Mass inspection" as Dr. Deming called it,
is a sure sign of inadequate process control. And in order to achieve
an optimum level of process control, some form of FMEA is essential.

Note that I said, "*some form* of FMEA." What we commonly refer to as
FMEA, especially PFMEA, uses a convenient form for recording the results
of a process. The filled-out FMEA form *is not* the FMEA itself. Don't
confuse the container for the thing contained. The actual FMEA consists
in the attempt to anticipate and prevent failures. To that extent,
*everyone* does FMEA whether they realize or not, and whether or not the
results are recorded.

So the OP should determine whether it's worthwhile to formalize and
standardize a process that's already happening in one form or another.
Just because you don't use the AIAG form doesn't mean that FMEA isn't
happening.

[George B]

Start out by using brainstorming to identify the most critical to quality
characteristics. Perform the FMEA on these first and then add the other
characteristics. A good FMEA will have a wide range of rpn's and the higher
rpn's will lead to "action items". Probably the best advice I can offer
though is that FMEA is a tool. Like all tools it takes, time and practice
to develop the skills needed to use the tool effectively and efficiently.
FMEA takes more time than simple tools like brainstorming and multivoting.
This is why I suggest starting the FMEA by using some simpler tools first.
www.connectorconsultants.com

"Stephen McKelvey" <stephen....@uwggroup.com> wrote in message
news:3e5d7e96.04082...@posting.google.com...

[Herb Fritatta]

George B wrote:
> Start out by using brainstorming to identify the most critical to quality
> characteristics. Perform the FMEA on these first and then add the other
> characteristics. A good FMEA will have a wide range of rpn's and the higher
> rpn's will lead to "action items". Probably the best advice I can offer
> though is that FMEA is a tool. Like all tools it takes, time and practice
> to develop the skills needed to use the tool effectively and efficiently.
> FMEA takes more time than simple tools like brainstorming and multivoting.
> This is why I suggest starting the FMEA by using some simpler tools first.
> www.connectorconsultants.com

You seem to be making the same fundamental error as the OP, who is hung
up on the idea that the finished piece of paper is the FMEA. It's not;
it's just a record. Brainstorming is not a separate tool; it's an
integral part of the process. Anticipation of potential failures can't
happen without it. Here again it's possible to get hung up on the
"orthodox" view of brainstorming--a bunch of people doing
stream-of-consciousness without criticism. In fact, although I don't
recommend it, brainstorming can be a solitary activity.

My own view of the AIAG/SAE PFMEA model is that it's fatally flawed, and
contrary to its stated purpose, it actually *inhibits* prevention
efforts. The reason for this is that it was mistakenly based on the
original DFMEA strategy that calls for identification of part or
part-function problems as potential failure modes. When this view is
taken in a PFMEA process you're automatically led in the direction of
detection. Try this the next time you're looking at a finished PFMEA
form: Take the potential failure modes and move them to the "effects"
column. In the "Potential Failure Mode" column, enter what had been in
the "Cause" fields. The result should be that you have identified ways
in which the *process* might fail, the specific potential effects (part
defects) of those failures, and now, for potential causes, it becomes
necessary to identify and address ways that the *process* might fail,
which by definition is a prevention-oriented strategy. Monitor the
process--not the parts.

[George B]

Completely agree with you Herb. You have said it better than I did. Forms
are records and brainstorming is part of the FMEA. Focus on the form is
sometimes and inhibitor to exploration and progress. Another good example
is the 8-D form which people sometimes mistake for the Team Oriented Problem
Solving process. Both FMEA and 8-D require training and practice and
patience from the participants and their management. What do you think?
"Herb Fritatta" <He...@dontspam.com> wrote in message
news:10jvep7...@corp.supernews.com...

[Herb Fritatta]

People don't need training in order to use common sense--they just need
permission.

[hitesh....@gmail.com]

Hi, I have 5 years of experience working on FMEA over Process Maps

[Christian Ferrer]

It is now starting to be widely accepted that the FMEA in its original form is obsolete as a tool. The utility of the FMEA is limited since it is highly based on opinions. The use of the RPN distorts the assessment of risk by creating a pseudo-scale with little meaning and inconsistency from user to user. Firstly, the detection factor is not part of the definition of risk and therefore its use is not coherent in the risk calculation. Secondly, during the definition of risk, it is not very meaningful to multiply the severity score and the probability of occurrence together because it masks the actual scores that we are trying to understand. Furthermore, it seems there is no universally recognized, scientifically reproducible numeric scale for risk. Instead, the scores should be presented as polar coordinates to more clearly represent the matrix of risk magnitude, similar to how is done by reliability engineers in criticality analysis. However, since risk cannot be truly quantified, a given criticality matrix will most likely need boundary calibration based on a combination of context analysis, expert judgement and distributed cognition. This insights come from highly respected sources such as G. Watson and D. Snowden, whom I highly recommend.

Feel free to use the FMEA in its classical form but only as a consultative brainstorming tool. However, better would be to arrive at a more coherent criticality ranking and instead of asking the question of detection, just focus on actually determining a mitigation strategy or control for those items with high criticality.