There are Different Ways to Capture Failure Data

Maintenance Driven Reliability, called MDR, for short

ODR and Autonomous Maintenance are important?concepts that promote operator involvement in asset reliability. As they say, reliability is everyone’s responsibility. And with that mindset, wouldn’t it be great if we could also emphasize the importance of accurate failure data. Maybe there should be a new acronym called MDR (Maintenance Driven Reliability) or FDM (Failure Data Matters).

Operations staff originates the work request and maintenance performs the work. And the CMMS grudgingly gets updated along the way. But how accurate is this update? Are we even capturing the right failure data? And is the update process considered more of a chore than a critical requirement?

The CMMS captures Asset Problem Codes but lacks Component Problem Codes

There is a difference between a asset problem code and a component problem code.?Maintenance repairs or replaces the failed component. But the CMMS administrators never configured the WO screen to accommodate component data capture because …. no one ever told them to. But if you ever looked at a RCM analysis spreadsheet you would see this level of granularity.

Leadership Never Really Thought the Process Through

The CMMS implementation team spent a lot of time creating failure code hierarchies but never built the failure analytic or established a reliability team. Others just assumed the CMMS (out-of-the-box) would have a decent failure analytic. Overall, leadership shows a general lack of knowledge regarding chronic failure analysis, and the only metric they end up using is work order counts (i.e. which asset had the most repair work performed).

Tip: Upload the RCM Analysis spreadsheet to a new CMMS power app for ready access/reference.

Failure Mode and Failure Analysis

Failure Mode is the language of RCM and should be captured on the work order at job completion (for all functional failures). The RCM guide, SAE JA-1011, provides plenty of failure mode examples.

Failure analysis, depending on the organization involved, may have multiple definitions. Here are 3 methods which DON'T WORK.

Method #1 prefers to just talk to people and may not believe the CMMS should be used in any capacity to perform failure analysis since the techs are focused on performing work and don't have time for extensive updates other than actual manhours, Method #2 stores actions performed as a narrative inside the WO text fields so that staff can read these comments. Method #3 performs primitive analysis using failure code hierarchies which are often too high a level or incomplete at best.

Over-Thinking the Solution - Method 4

The vendor R&D group thinks they can create a fancy program that reads text fields to glean the failure mode. This assumes the maintenance staff enter adequate failure details in the text. This approach requires a synonym database (or crosswalk) containing components, problems, and causes. Plus, they need a way to accommodate abbreviations and misspellings. And once in place, then each grouping requires a "primary word". The time to set this up requires many man-months (by consultants) and it may never complete. [And, you still don't have the failure analytic].

A more Common Sense Solution is a Straight Forward Approach

The shortest path to value is to set up an RCM 3-part failure mode. These new fields would be added to the work order screen for component, component problem and cause code as validated fields. Note that the failed component field would contain every possible component and asset has. Although this would be a large data set, by applying a "type-ahead buffer" such as used by Google, the search is rather quick.

At this point, we design the bad actor report and apply a sort metric. Once the bad actors are selected, the reliability team can then choose any asset and drill-down on the individual pieces of the failure mode. In addition, by having the RCM analysis results inside the CMMS you can automate a comparison of failure mode to failure mode.

In Summary

You now have a reliability management system with the CMMS as a primary component. And by having the RCM results application inside the CMMS, you now have a living program for RCM analysis. Lastly, you can link every PM-jobplan back to a failure mode in the RCM app to create a defendable library. So, when the AI guys show up and ask what new sensors you want, you can tell them where to focus (on what assets) and what failure modes to focus on.

The above book can be purchased from ReliabilityWeb bookstore.