Printed Circuit Board Assembly & PCB Design Forum

SMT electronics assembly manufacturing forum.

SMTnet
»
Electronics Forum
»
Failure Mode Effects Analysis (FMEA)

Failure Mode Effects Analysis (FMEA)

Subscribe to Thread

I am part of a software company looking for electronic indus... - Apr 19, 2002 by

While our group is not involved in product FMEA, periodicall... - Apr 19, 2002 by davef

Hi, a did a study on a FMEA for a government project, and... - Apr 22, 2002 by ianchan

FMEA, when used correctly, is an excellent tool. The best th... - May 01, 2002 by Peterson

Hi, I agree that professional-role accountability (QA, Pr... - May 01, 2002 by ianchan

Steve Bondarewski

#19588

Failure Mode Effects Analysis (FMEA) | 19 April, 2002

I am part of a software company looking for electronic industry feedback for the perfect FMEA software tool. Understanding how boring FMEA studies can be, how can FMEA software be improved to reduce liability and increase innovation? Basically, I want you to rant and complain !!

reply »

davef

#19597

Failure Mode Effects Analysis (FMEA) | 19 April, 2002

While our group is not involved in product FMEA, periodically we get dragged, kicking and screaming, into a FMEA for: * Quoting the assembly or test of products. * Evaluating the potential purchase of process equipment. * Assessing the potential impact of process changes.

We do not use software. Use grids. We do not like doing these things because they're stupid. The drone facilitator doesn't have a clue of how to do a process FMEA and neither do we. [We have a well-written procedure that defines all the stuff and grids to fill-out. This issue is not the actual mashing of the stuff.] It's the up-front decision making. For instance, we need to: * Define all the failure modes. [There are only about 3 bazillion potential failure modes.] * Rate the seriousness of the effect. [Sounds good, but there�s no baseline and the definitions don�t play.] * Estimate of the probability that a failure mode will occur during the intended life of the product or process. [Sounds good, but there�s no baseline and the definitions don�t play.] * Rate the probability that a failure mode will be detected before having an impact on the product or process. [Sounds good, but there�s no baseline and the definitions don�t play.]

This all end-up being a lot of guessing that: * Makes everyone feel uncomfortable * Gets everyone pissed-off at each other

... and accomplishes nothing, except the skirts over in QA get a folder to put in the file cabinet that they can show those other skirts that come around once a year.

reply »

ianchan

#19621

Failure Mode Effects Analysis (FMEA) | 22 April, 2002

Hi,

a did a study on a FMEA for a government project, and I do not relish going thru that S**T again!

Aye laddie, as a QA skirt i must protest! its called a kilt, not a skirt! *grinz* and we dun keep FMEAs in the folder cabinet, there's only room for the tea-bags, cookies, thermos, sugar, spoons, errmmm....

anwayz, if someone is very interested to build the infrastructure for a realistic FMEA software, approach the government skirts whose primary assignment is to chase honest hard-working types for paper mountains of data, words and mess. semi-government functions, such as Land & Transportation Ministry (made that up, but you all get the point) departments that oversee the mechanical and electrical systems can be of great help too. From the experiences of my frens swimming in that particular arena, i gain the very strong impression that FMEA requirement is mandatory. staff there are prone to using fine-tooth combs to cover their arses... oh yes, FMEA is a very in thing for the aerospace market too. try your luck there.

reply »

Peterson

#19745

Failure Mode Effects Analysis (FMEA) | 1 May, 2002

FMEA, when used correctly, is an excellent tool. The best thing about it is that it holds INDIVIDUALS accountable. The meeting cannot be closed until specific people (usually process types like me!) are assigned specific duties. I agree with Dave that much of the "data" is speculative...but if nothing else, it gets people (QA,Process, Manufacturing, Materials, etc) in the same room...forget that they are pointing fingers and yelling...As far as the format, we use a simple Excel Template.

reply »

ianchan

#19746

Failure Mode Effects Analysis (FMEA) | 1 May, 2002

Hi,

I agree that professional-role accountability (QA, Process, Manufacturing, Materials, etc...) is of paramount importance.

in fact nothing yielding results, gets to be done without followup in continual improvement action unless individuals are held accountable for their department actions (or lack of action). Cheers for your remarkable powers of observation!

Just as a point, we get much better results in using a simple Excel tabulation format, used in conjunction with the fish-bone diagram and paerto charts (occassionally backed up by the process C-charts, etc...).

we yield faster "paper conceptulation into engineering action" turn around times. we spend less time in the conference room scribing words/numbers on the white boards, and more time working in the factory floor. time spent in the conference room is confined to reporting back what we did (based on last discussion action plan requirements) and what were the results.

A) Good results? implement and monitor for further improvements. we can alt. focus on next highest reject mode.

B) Lousy results? what went wrong? determine root cause, was it :

1) manpower understanding of instruction?

2) methodology of physical working condition?

3) method of data collection and conditions' monitoring?

4) direct/indirect materials flaws (eg. oxidized leads, or slumpy solder paste)?

5) machine conditions? (performance limit in machine capability?)

6) environment? (eg. plastic injection moulding find higher rejects during cold weathers). we also group method ergonomics here.

Feel free to add onto your list. the people to ask during brainstorm sessions are the folks directly doing the jobs everyday. dun just ask/focus on the folks who sit in the meetings all day. Many times we find something that is not theory-wise supposed to happen, just happens... *murphy's law*.

Bottom line, work smart not hard.(no shortcuts in process control).

quality *customer acceptance of delivery* results are what count; not how many hours we clock into the payroll system nor how well the documentation files looks. we learnt it all the hard way. good luck if you dun learn from others.

reply »