Narrowing down FMEA input variables
- February 12, 2009 at 3:33 pm #51849
I would like to know if there are any techniques to narrow down the input variables (trivial many x’s) on my process FMEA (Failue Mode Effects Analysis).
The last meeting I had with my group, we went on for about 2 hours trying to evaluate all the x’s that could affect the y and their severity of impact. The conversations were sounding like this “Well the grinding wheel can fail THIS way and it has an RPN number of this… but it could also fail THIS way and, OR THIS way… and what if a meteor hits? that’s an RPN of THIS” They just seemed to be getting a little TOO involved.
What I have considered for soulutions to this kind of “paralysis by analysis” is narrowing down the x’s from the Ishikawa diagram and then creating a Cause and Effect Matrix to further highlight the critical few. THEN I would take the top performers from these Root Cause Analysis tools and put them into the FMEA. My only concern is that I’m being TOO general and might be missing some critical factors. Are my fears valid or should I stick with “Just the fact’s ma’am?”0February 16, 2009 at 6:04 am #181214
My thoughts-do a XY matrix on all the trivial X’s to get narrow with vital X’s. These vital’s shorten the list from which you may pick further with your team.Involve team members using forms such as fill in the blank or 5 points more ;after fixed minutes/form discussions, so that you get sure progress. Discussions are always healthy in fishbone’s but there’s always a time constraint for you to deliver.You are spot on- start with the Ishikawa and follow through like you planned.
0February 16, 2009 at 9:46 am #181216
Chris SeiderParticipant@cseider Include @cseider in your post and this person will
be notified via email.
Don’t approach the FMEA from the perspective you gave…use some of VIPin’s approach. Be wary of the XY matrix–it’s usually based on gut feel. If the team knew the factors for sure, the problem wouldn’t exist.
1. Follow your process step by step and only look the failure modes (defects) of what output fails in the step and document the effect of that failure mode on the customer. Do NOT focus on X’s or else you will have long winded conversations as you found. Concentrate on the defects of each step and the X’s will come out.
2. Consider using the XY or other tool to narrow down the process to “steps of focus” initially to prevent doing an FMEA on all the process steps. Use the FMEA to drive results and then use it as a control plan document later.
3. If you characterize your inputs (C, P, N) as some advocate, do NOT make the mistake of dismissing a potential risk to be identified if the input affecting the process defect is noise. This is wholly inappropriate to ignore inputs because they might be outside of your immediate control OR because the input did not show up as one of the top ones of your XY matrix.
Good luck.0February 16, 2009 at 1:01 pm #181220
Customer issue: FMEA produce “paralysis by analysis”
My Thoughts: A two hour meeting for an FMEA is too long. There are four major reasons an FMEA is done: (1) Customer driven, (2) audit driven, (3) management driven have to get it done, or (4) product quality team driven. Since the meeting lasted two hours, I expect that one of the first three reasons is why the FMEA was performed. If the FMEA meeting was called for any of the first three reasons, most team member will attend the meeting with the idea of making the product better. On the other hand, the underlying attitude and procedure is likely to produce results that do not capture all the critical to quality issues.
The purpose of the FMEA is to capture all potential failure modes. If you create the Ishikawa diagram and narrow the failure modes to what you believe are the CTQ issues, then you might as well do most of the FMEA yourself. You have removed the reason why teams are formed Diversity.
Like other teams, the FMEA team goes through four stages: forming, storming, norming, and performing. Because most FMEA teams are formed and disbanded very quickly they seldom become truly effective at performing. Consequently, CTQ issues are missed. This adds to the attitude of many managers that FMEA are of little value.
Solution: The best solution given the constraints of the six sigma discussion forum and reasons 1, 2, and 3 for performing an FMEA is to break the FMEA meeting into three 40 minutes sessions held over a two week period. Break sharply at 40 minutes or less.
Expected Results: The three 40 minute meeting forces the team to move faster; consequently, a two hour meeting with a team that performs better. For a product with little complexity, you will have done a pretty good job. For products with a large degree of complexity, you will have added to the belief the FMEA have little value.
Question: What was your reason for doing the FMEA?0February 16, 2009 at 1:57 pm #181224
Rick’s message is a good example why blogs are not very good places to get “expert advice”. FMEAs are excellent tools when done properly. I have used Design and Process FMEAs and found them to be very helpful. Sometimes we may have spent 4 hours on an FMEA, sometimes 4 days. It all depends on the topic to be covered.
As far as your team getting stuck on determining severity of x’s, let the RPN number determine which ones are addressed. In the case of a meteor, the severity may be a 10, yet the occurrence would only be .5 giving it a low RPN.
Good Luck!0February 16, 2009 at 2:34 pm #181227
KluttzMember@Union-of-Conjoined-Scientists Include @Union-of-Conjoined-Scientists in your post and this person will
be notified via email.
I would be extremely hesitant to label a 2-hour FMEA meeting as “too long”. The best FMEA I’ve ever been involved with was 21 hours long spaced over 2 days. I’d also be hesistant to assume that any company had the luxury to space a two hour meeting over 2 weeks. Sometimes, lessons learned in the classroom don’t always translate to the real world.
In my experience, there are a few things that you can do to make the FMEA process easier;
Develop Severity, Occurrence & Detectability scoring criteria specific to your particular process BEFORE you start. The better defined your scoring criteria, the less wiggle room your team has to spend hours debating whether something is a 4 or a 6.
Define your decision-making process before you begin. Scoring should be based on actual performance data if you have it (MTBF, MTTR, warranty data, etc). But if it’s not, establish time limits on discussion for each failure mode then decide on how you’re going to reach concensus (averaging out individual scores, multi-voting, SME rules, etc). Whatever the decision-making process is, make sure you have one and make sure everyone understands it.
Define & communicate your project scope. Its real easy to spend a half hour on a failure mode before realizing that its not even a part of your project. Scope discipline is vital to keeping things on track.
Define team roles & responsibilities. Know your role as the team leader. Its your room, so make sure you own the outcome. If debate is going on too long, wrap it up and cut it off. If you’re not comfortable leading the team, you’re going to have drift.
There are definitely some things you can do to limit your x’s (some mentioned earlier), but from my experience, the above factors play a bigger role in the efficiency & effectiveness of the FMEA process.0
The forum ‘General’ is closed to new topics and replies.