How to use FMEA for Complaint Investigation

Other, related QDD posts that you may be interested in:

Getting Started with FMEA: It All Begins with a Plan

Choosing a Confidence Level for Test using FMEA

How Many Controls do we Need to Reduce Risk?

Remaking Risk-Based Decisions: Allowing Ourselves to Change our Minds

Episode Transcript

We’re new to a product line. And our team is asking for our help in addressing field complaints. They’ve identified a trend and want our recommendations on what to do to fix it, but we don’t know the history of the product, and we’re barely familiar with all the bells and whistles. It contains we do. We start more after this brief introduction.

Hello, and welcome to quality during design the place to use quality thinking to create products others love for less. My name is Dianna. I’m a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation at qualityduringdesign.com,

FMEA or failure mode and effects analysis is a tool we can use to help us investigate complaints from the field or field events, even if it was done during design and not touched since we can use it. It’s the collective team knowledge about the risks of this product. So it’s a valuable source in our investigation about what’s going on in the field. We’ve got a problem. We might have several problems. The first thing that we do is we consider, do we have data about the problem, or do we have complaint data about a symptom is our complaint team giving us trends of data that are really symptoms. Symptoms are signals that something’s wrong. It’s what we notice is wrong. Having an ache in our shoulder is a symptom. The problem may be any one of several things that we’ve damaged the rotator cuff or we’re developing arthritis in the joint, or maybe we just pulled a muscle.

The staff that is investigating complaints and trends may be trending based on symptoms. In which case we may have several different problems that are contributing to one symptom. If this is the case, then we can get a start on our investigation by using the FMEA that’s on file for the product. We’ll want to check the FMEA for the symptom that’s happening, likely they’ll be in the effects column, where we find the effect listed. What are the types of failures associated with it? We’ll still need to do further investigation into the complaint data, or hopefully we have some product that we can look at, study or test that’s getting to the problem. If our complaint handling staff is performing investigations to determine the cause of the complaint and they’re trending on the problems, then we’re likely going to be able to look at the FMEA from its failure column.

We match up the FMEA failure with what the complaint team is finding as the problem and ensure the effect column on the FMEA matches up with the details of the complaint from the effects and failures. We can then start looking at the causes. We’re casting a net with the causes, but then we’re going to use the FMEA more to whittle down the likely culprit. What causes listed had the highest occurrence rating. This will indicate whether the FMEA team thought this cause was likely to happen or nearly impossible. Then we can look at what cause was listed under multiple failures. This would indicate that there could be a weak link with our product. We can start to narrow in, on what could be the cause of our problem, and then start doing some further investigations. We may be able to test product to verify a cause in the FMEA controls column.

There should be a list of what prevention controls are in place like machine settings. If there were prevention controls, we can look into some manufacturing records to ensure those controls were functioning properly. Maybe we’ll notice there was a non-routine maintenance performed on equipment that made the product. What was that about? Was it done properly or did it cause something to shift also in the FMEA controls column, there should be a list of detection controls in place like inspections performed, pull some of the records from quality assurance. Was there anything noted there were there defects found, and what was done about it just from considering what someone is telling us is happening in the field. We can use an FMEA to help guide us to next steps for finding out the true culprit or root cause. Now, how much of a priority is this complaint?

Do we need to recall product again? This is where FMEA may help this analysis was done during a time when there were cool heads, people were rational and realistic when the FMEA was done, oh, we can assume we can check its reports or notes for how the team made decisions about ratings. Was it the most likely what was the most severe and so on? So how bad is this complaint? Look up the ratings and how it was ranked in the FMEA. Does it still make sense after the complaint is resolved? Ensure you go back to the FMEA and make updates after all you’ve now made discoveries about the product. Your discovery might be that the information in the FMEA is still accurate. And does it need to be changed, or you might discover that a failure cause combination is happening more often, or your team decided that the controls that we had in place like machine settings or inspections, weren’t good enough.

And you decided to add another control. Then you can add that control to the FMEA. Now when the next new engineer is assigned to that product line, they’ll have the FMEA to get started just like you did. What’s today’s insight to action. We talked today about how to use an FMEA to help us investigate a field failure of our product. Having talked through this, my wish is that we see how we can also use it during development. I’ve seen a lot of posts on social networks about how the risk index is just outdated. That’s the green, yellow, red matrix of severity and occurrence. Really. It’s just one small way of evaluating FMEA data and not even a necessary one. Your team may choose not to use it at all. You can use FMEA, like we did today, evaluate the chain of events, examine causes, check controls, turn that information into knowledge, and then innovate.

If you like the content in this episode, visit quality during design.com, where you can subscribe to the weekly newsletter to keep in touch. This has been a production of Deeney Enterprises. Thanks for listening!