Controls Don’t Enter FMEA Immediately
When completing an FMEA, controls aren’t developed until rather late in the process. After you’ve determined the functions and associated requirements, deduced failure modes, and determined effects and causes, you are ready to discuss both prevention and detection controls.
Why Controls Are Important
Actually, developing a sound list of controls is one of the main reasons for doing any FMEA. FMEA studies teach you a great deal about product or process requirements, and they can alert you to failure scenarios through “cause-mode-effect” chains that you hadn’t thought about. You can also increase your general understanding of either a product design or a process flow through the development of FMEA studies.
- Of course, FMEA can also give you a semi-quantitative way to assess risk. But you can’t really understand the true nature of the risks that any project faces without planning and then executing a proper set of control activities. And that’s true for both design activities and for processes. You can read more about risk assessment here.
In short, controls are activities that allow you to recognize or identify the conditions that lead to specific causes or effects of a disrupted function (or a failure mode, to use the terminology of FMEA). And, there are two types of controls, prevention controls and detection controls. Here is a table that explains the difference controls for Design FMEA and Process FMEA:
How Does This Work on the FMEA Form?
If you know the cause-mode-effect chain, and you have derived that chain from a properly defined and constructed function statement, then any prevention control is a search for the cause in the chain, while any detection control is a search for the effect in the chain.
In any cause-mode-effect chain, something that happens before a function is disrupted must be a cause. As are result, you can imagine a number of possible causes, and, based on occurrence, you’ve selected one or two of the most likely causes for this chain. Each of these causes may or may not lead to a failure mode every time the cause arises, but the cause might, in some cases, lead to the failure mode at hand.
Because you have visualized (or imagined) these causes, you can now think about how you could possibly break the chain from cause to mode. You probably can’t prevent the cause from existing, but you can think about how you can react to the cause-mode link.
A Design Example: Prevention Controls
If you are designing a bolted joint, you will certainly have a function that is something like “bolt creates compression in component A” (and a similar function of “bolt creates compression in component B” to complete the joint). “Excessive compression” might be one of the ways the function could be disrupted. “Incorrect torque specification” is certainly one of the causes. At this point, we have a cause-mode link that says, “Incorrect torque specification leads to excess compression in component A.”
What can we do about this? We could certainly do a physical test, but a physical test won’t actually look at the torque specification directly. It would certainly lead to something that is wrong with the joint, but there are quite a few things (such as a defective bolt in the test, an error in torque reading in the test, or component A has a strength that is too low) that could happen in the test that could lead you astray.
Besides, we want to prevent any failures—including testing failures which cause project disruption—not just see them happen. To do this, you need to create a control that is based on thinking in some way, and does NOT depend on a test.
In this case, you could conduct a simple stress calculation based on bolted joint design—or do the same thing with finite element analysis. If the joint design is simple enough, you might even find tabulated values in a reference such as Machinery’s Handbook. Best of all, you can do these analyses at worst-case conditions (limits of specification for all relevant components), which is something that is quite difficult to do in testing.
You still may need to test a prototype to confirm the calculation, but you are much more likely to pass the test without trial and error efforts. And trial and error efforts take time and raise product development costs. In a world where faster-better-less cost is critical, this no small thing.
Now Consider the Same Function & Failure Mode in a Process Example
Again, we want to prevent failures. We don’t want to measure the joint after installing the bolt—not only would that be a detection control, but it would also lead to at least one defective process outcome. How can we avoid excessive torque?
To develop the most effective prevention control, you would certainly need to be very familiar with the production facility where the work would be done. That will lead you to the most likely cause. To show how a prevention control might work, let’s assume the most likely cause is that the torque gun is set too high.
Of course, is that a root cause or a superficial cause? So, let’s ask why the gun might be set too high. Let’s further assume that the gun is set high to speed up the operation. (The fact that higher torque might not really do that won’t stop some people from believing that!)
A relatively simple way to overcome this is to use a gun that has a torque limiting clutch. That’s a good prevention control—as long as the gun maintenance is done and the clutch is set to the correct maximum torque. Of course, it’s not a full jidoka control, which will stop production if excess torque is applied, but it’s a decent prevention control.
The fact that’s the torque limiting clutch isn’t a jidoka control means that the detection rating of this control will be lower than a full jidoka control. However, it’s quite a bit better than just putting up a sign that says, “Don’t change the torque setting.”
What About Detection Controls?
On the other side of the coin, detection controls are usually much easier to understand. For the design concern, you might be worried about “excessive bolt deformation” as the most severe effect. A test of prototype parts is certainly a valid detection control. Just remember that there are some statistical limits to what a test can tell you, and that is a result of not being able to do absolute tests at worst-case specification limits.
Similarly, you could check a finished joint in production to look for undue joint deformation due to excess torque. The actual effect might be “excess deflection of component A.” You wouldn’t know something had gone wrong until you found the defect in an inspection step, but at least you’d find it—at least as long as the excess deflection of component A was relatively easy to identify.
Both Prevention Controls and Detection Controls are important and are extremely important in control cost–both costs for product development processes as well as ongoing production costs. However, prevention controls are often more effective that detection controls, and they offer the added benefit of improving the speed of product development.