What’s your strategy for getting through a maze? What if, when you chose a path, you could know ahead of time that it wasn’t a dead end and that you’d get your cheese? What if you could know, at every decision point, that each move was the right move? Is that cheating? Well, maybe, if you’re purely dealing with mazes.  But when we’re talking about maximizing the energy you put into your FMEA effort by gaining insight into your product/process risk  and increasing your chances of coming out the other end with your cheese, it’s called methodology.

How to Cheat at Mazes and Get Away with It

By closely following some basic methodology guidelines with our APIS IQ-Software, we can be confident knowing we are going to get the cheese – we have an analysis that is on point, thorough, complete, and consistent, we got everything possible out of the effort, we understand our product/process risk and we have a solid plan to engage in mitigating that risk where necessary.

When we enter the maze, we need to take great care when building our FMEA model. Defining the structure and then the functions, failures, requirements, and characteristics that go inside it. Finally, we need to relate this data together in a meaningful way lest it just be data and not knowledge. These data relationships are what set the IQ-Software approach apart from the pack.

Structure Tree

Made up of a hierarchically interconnected group of system elements, the structure tree provides the organizational foundation for our FMEA. It helps us to visualize the components of our system. We aren’t bound to this structure, we are instead aided by its organization as we create functions and failures and link them together.

Functions, Failures, Requirements, and Characteristics

Defining the functions doesn’t come so easily. In my opinion, it’s the most challenging aspect of an FMEA. Like writing a short speech or building a short presentation, it takes more time to make them short and concise than it does to let them ramble too long and off point.

Let’s take a look at an example where the functional understanding was not on target. The original analysis described things like this:

 System Element: Pump Retainer
Function: Material shall ensure resistance against fluid and temperature under operating conditions
 Failure: Material does not ensure resistance against fluid and temperature under operating conditions
 Function: Shall hold pump in place in all directions
 Failure: Does not hold pump in place in all directions

What do we have here? The device is supposed to hold a pump in place. It appears that there might be some requirements related to the operating environment but they are being confused with the function. Worse yet, the material failures (causes to the fastening failure) are being confused as being failure modes. Let’s go for the cheese here and try a different direction…

 Function: Shall hold pump in place in all directions
Requirement: Ensure product is resistant to fluids (specification here)
Requirement: Ensure product maintains holding under temperature extremes (specification: -40 < temp < +40)
 Failure: Pump not held securely
 Failure cause (Product characteristic failure): Material not resistant to fluids
 Failure cause (Product characteristic failure): Material not temperature resistant

This is how we find the cheese. With the clarity arrived at through careful thinking of the function, requirements, and failures, we’ve boiled it down to a single function with a single failure. If you expand this through your whole FMEA, you can imagine how it can be boiled down to the core. When this happens, we get the Cheese! In other words, we get the opportunity to see the FMEA deliver real value. Carry on!

Find us on:
&