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.
Think of the number of organizations that were too scared to perform a RCM Analysis or couldn’t justify the initial cost. And, think of those organizations that started the RCM initiative but never finished. With a build-as-you-go approach, now any size organization can afford to begin optimizing its PM/PdM maintenance library with minor configuration and process improvement.
In summary, I recommend the following
- Involve the Reliability Engineer in the CMMS implementation. Ask what he or she wants out of the system, specifically the failure analytic. Once that is drawn up, make sure those data fields are actually being captured. Note: there can also be a situation in which the field is there, but the O&M staff doesn’t enter the data (maybe click count is too high).
- Even if implementation is over, it's never too late to get the input of the Reliability Engineer(s).
- If the Reliability Engineer doesn't have any suggestions or shows lack of interest, then a different tactic is needed. You may need to perform a benchmarking/training/discovery session by inviting a RCM Practitioner/CMMS consultant to the site.