iSixSigma

How to Reduce Subjectivity in FMEA?

Six Sigma – iSixSigma Forums General Forums Tools & Templates How to Reduce Subjectivity in FMEA?

This topic contains 10 replies, has 4 voices, and was last updated by  Chris Seider 1 month ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #238497

    STEF
    Participant

    How can I reduce the subjectivity in FMEA?

    0
    #238501

    Chris Seider
    Participant

    Use past history and process capability studies for the frequencies.

    1
    #238526

    Mike Carnell
    Participant

    @stef If you look at every tool in the Define and Measure Phase you can use that information in the FMEA. @cseider said you can use capability studies to do Frequency of Occurrence, MSA for Detection, Process Map for steps, etc. You can use the FMEA to synthesize all the information form the Design and Measure Phase.

    The RPN’s can be used to develop your priorities/plan for the Measure Phase and you can track the Measure Phase results in the actions recommended section to the right of the RPN’s.

    I will have to dig through some old files but I have a slide somewhere that details where you get data to fill in the FMEA rather than make it some kumbaya exercise

    0
    #238531

    Mike Carnell
    Participant

    @stef This is a pretty old slide. Just some thoughts from a long time ago.

    0
    #238533

    Mike Carnell
    Participant

    @stef I stuck this together so you could see what I was talking about. if you use the data from the Define and Measure phase to calculate the RPN then the RPN should create the information you need to set priorities for Analyze.

    The action plan (on the FMEA) is basically what you need to do in Analyze to sort out where the root cause(s) are. Everybody talks like RCA is different than DMAIC when DMAIC is actually RCA without all the kumbaya “analysis.”

    0
    #238534

    Mike Carnell
    Participant

    @stef The attachment I forgot to add to the previous post

    0
    #238573

    Strayer
    Participant

    An FMEA is a team exercise to identify and arrive at consensus on RPN factors. The result is probability based on the knowledge of participating experts. If you have the right people on your team, subjectivity shouldn’t be a big issue. Things tend to balance out. There are better tools, such as fault trees, for objective analysis but they aren’t good for prioritization, which is the reason we do an FMEA. In my experience an attempt to get all the data and do objective analysis turns FMEA into a project in itself, and the results are not better.

    1
    #238579

    Mike Carnell
    Participant

    @Straydog Absolutely no argument on this being a team exercise. Here is the issue I have with making this opinion based. There are facts based on the work you have done i.e. Frequency of Occurrence derived from a capability study. Now if I make this a team based decision and I have a capability number there are only one of 2 options 1. the number is correct 2 the number is incorrect but then so is the capability study so how do we get the two to match? Detection for MSA – same thing.

    You stated “An FMEA is a team exercise to identify and arrive at consensus on RPN factors.” I can use the data that the team generated in Design and Measure. Unless they disagree with the studies they are now facts. Why would you choose to insert opinion over fact? The Process Map for process steps is a fact. Just because someone doesn’t agree doesn’t make the exercise better it actually makes it worse unless the process map was done incorrectly.

    Just because these are not done in a “brainstorming” type environment does not mean they are not a team exercise.

    1
    #238589

    Strayer
    Participant

    I agree that for best results the FMEA team comes with data and aren’t just guessing or advocating based on prejudices. But I stand behind my previous comment that it’s about arriving at consensus. Each subject matter expert brings something to the table. If you do a rigorous FMEA following the AIAG manual, FMEA is a project, not an exercise. The results of the exercise approach, often done in just one day, can be very useful. But we should remember that the RPNs don’t mean that much unless there are very wide separations.

    1
    #238601

    Mike Carnell
    Participant

    @Straydog Just to be clear I am not trying to change your mind. I am comfortable with us differing on things. I am not a fan of mandatory consensus. I spent time in a computer manufacturing company in the early 90’s. I watched that mandatory consensus thing used by particular managers to kill very good ideas just by sending in people with explicit instruction to disagree.

    I have also never felt compelled to follow the AIAG manual or almost any other book and/or document (unless it affects safety). It is a great place to begin but if you look at Severity ranking created by an automotive group they are probably not adequate for a group that manufactured Depends or rubber grommets for shock absorbers. We tell people to “think outside the box” which is defined as “Think in an original or creative way” then following a manual or even mandatory consensus is a “box.”

    In terms of RPN separation I have seen people truncate the scale to force separation. Same thing with an I/O matrix. I am not sure that them being close is as much a problem as why people don’t see a difference unless of course they don’t see a difference in anything.

    Here is the issue I see with a FMEA as a “project.” Projects have beginnings and ends. An FMEA by design is meant to be a living document. I worked with a person who actually used an FMEA to manage his factory. He folded it in half and carried it in his shirt pocket so he definitely had the appearance of an engineer. If you went to speak to him about something you were working on, you would have to pause while he found it on the FMEA. He would use the RPN to decide if you were doing something to move the factory forward. If you were working on something with a low RPN then he would ask you why you were doing what you were doing. Basically if you thought it was important then the FMEA was wrong and you were to correct it. If you fixed something you updated it. It took about 60 days to get people to recognize that the accuracy of the RPN was more than some esoteric exercise. It was the priority system for improving the factory and it worked.

    So we have a difference of opinion and we have both made our case. Doesn’t either of us right or wrong just different. I know you have significant practical experience so I respect your opinion. I am good with that.

    Regards,
    Mike

    1
    #238608

    Chris Seider
    Participant

    I recognize some of those snippets from @mike-carnell :)

    1
Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.