Exploring failure hierarchies

by Arne Oas

Often overlooked but critically important to achieving maximum return on your CMMS investment is the requirement for a company to develop failure hierarchies that promote efficient analysis of repair information.

Today’s CMMS products are designed to support multiple-level failure reporting, making the implementation process more difficult. However, the effective design and reporting of the failure hierarchy is the keystone for root cause analysis, Reliability-Centered Maintenance and reliability analysis.

When developing failure hierarchies, you must first determine and get agreement on what makes up a piece of equipment or Maintenance Unit (MU). An MU is essentially the system or group of components that makes up the item called equipment. You have to decide what makes sense for your operation.  A 100-horsepower motor may be something that requires individual tracking in a small or medium-sized business, but a larger operation, such as a steel mill, may consider it a replaceable item or part and therefore not require complex hierarchies to determine which area of the motor failed.

Taking time to create a logical structure for your Maintenance Units up front will make the process of creating failure hierarchies, preventive and predictive maintenance, location hierarchies, bill of material requirements and parent/child relationships much easier and, ultimately, make your analysis more reliable.

After you establish the Maintenance Units, the next thing required is problem identification. The approach I employ is to determine Work Units (WU).  A Work Unit is a logical approach to breaking down the components of a machine into workable groups. In some cases, these are assemblies, and in others, these are systems. You then need to identify what could possibly fail.

Ideally, this should be done in conjunction with a machine inspection so you don’t overlook failure points. The Work Unit becomes the first filter of the problem identification. A pump, for example, might have the following WU:

Maintenance Unit = Pump
Pump Work Units
• Drive
• Transmission
• Pump
• Piping and valves
• Electrical

The second identifier of the problem is what could go wrong on the WU. A drive may stop because of motor failure, interlock operation, tripped circuit breakers, etc., or covers may be missing or loose. When completed and rearranged, the first- and second-tier problems become essentially a single Problem Code (PC). In the pump example, some PCs could be:

• Leaks —casing
• Leaks — seal; and,
• Leaks — piping and valves

You will need to develop “Causes” for each PC. These are the things that cause the problem to happen. For instance, if you have missing covers on a unit, the cause is probably human error. Someone either didn’t install them or didn’t install them correctly the last time the unit was worked on.

With causes identified, you now need to determine the “Remedy,” or Action Codes. These codes detail what you did to correct the problem. I suggest keeping the remedies simple — for example, repaired, replaced, adjusted, cleaned, trained, etc. Any more detailed information is hard to capture and, if needed, can usually be looked up in the long description of the problem (or if a part was used from the inventory module).

By following this methodology, you will be able to create more specific and beneficial reports which will provide better understanding of failures, and how to prevent and predict future failures. Modern CMMS packages allow users to build solution trees relating to equipment and subassembly failures. When the same problem is found in the future, users are directed down the fault tree to potential solutions.

Arne Oas is the senior maintenance consultant at Management Resources Group. If you have a maintenance management software question, contact Coach Oas at 215-918-2165, or e-mail oasa@mrginc.net.

This article appeared in the June/July 2002 issue of MRO Today magazine. Copyright 2002.

Back to top Back to MRO Coach archives