When organizations wonder why their CMMS system contains poor failure data, lacks analytical capabilities, and is devoid of any form of failure analysis process, it’s because the implementation team assumed the software itself would magically assemble meaningful data to identify worst offenders.
Some seem to think failure analysis is just a conversation, talking to the O&M technicians and rooting through work-order failure history files (text fields). In fact, this seems to be the first complaint by any reliability engineer when asked about failure data in the CMMS: “There’s nothing there of real value analytically, so we normally just rely on people-to-people conversations.”
Although possible, it surely would not be efficient. Tribal knowledge is great, but has a way of disappearing. And it could take months of labor to root through a year’s worth of work orders looking at text fields to find the exact cause of failure.
A maintenance reliability program can be broken into five pillars, one of which includes failure analysis. The CMMS software is a small subset of this program. A successful maintenance reliability program has strong capabilities across all five pillars (see Figure 1). Root cause analysis (RCA) is great, but 40-60% of maintenance repair costs can be caused by chronic/recurring failures. I refer to the latter as basic failure analysis.
Real analysis is needed for recurring failures. For whatever reason, many organizations are overlooking the ability of the CMMS to manage this data. And without failure data in your CMMS, all you have is an expensive work-order ticket system.
If basic failure analysis as a process doesn’t exist, who’s at fault? What are the reasons for this oversight? Possible answers include:
- The CMMS implementation team didn’t think they needed to have a reliability engineer on the team.
- The Reliability Engineer didn’t offer his or her services.
- A Reliability Engineer isn’t on staff.
- No one is familiar with basic failure analysis.
Let’s assume there’s a Reliability Engineer (or Reliability Team) involved. There still needs to be a solid understanding of the end game. A Pareto-style, failure analytic (report) design needs to be developed and implemented that helps the decision-makers manage by exception. Once the design is locked in, then discussion can begin on the necessary process, roles, and screen configurations to capture accurate failure data.
Don’t assume the CMMS has this report. This output would help the organization drill-down through failure modes dynamically to discover true cause. With the following report in place, the Technician can tell what the failed component was – and its problem code. The Maintenance Supervisor or Engineer might be needed to identify the exact cause of the component failure.
The language of RCM is tied deeply to the failure mode. Unfortunately for most CMMS products, this term isn’t emphasized. The failure mode has a three-part formula and is shown here:
The ideal design would be to capture these three fields individually, and then concatenate them together as opposed to a prebuilt list. This approach dramatically increases the number of combinations, but with little (software) setup.
Every CMMS can be configured once you know the design requirements. Of course, you may need to add fields to the screen. And these fields might need a choice list to ensure validated data. Plus, you must train the staff on how and why this data is important.
Figure 2 shows how to use your CMMS to solve two puzzles: (1) Provide storage for a build-as-you-go RCM Analysis result set, and (2) facilitate basic failure analysis. This innovative design permits easy comparison of work-order failure mode to RCM Analysis failure mode along with validation of maintenance strategy.