The Bad Actor Report: How are decisions made in your organization?

Continuing with The Bad Actor Report series, in this article we’ll go into the importance of how decisions are made with failure data and the impact it can make in your facility.

If you missed my first or second post, you can check it out here ⤵ 

Some organizations want the CMMS to help them make better decisions regarding repair/replace, maintenance strategies, understanding which sensors to use, perform risk management, and identify recurring failures. Asset management also involves people, process and roles. With so much to worry about, it is critically important that stakeholders do the right work at the right time using the right staff. And when there is more work to do than resources allow, it is imperative to manage by exception.

This is where failure data can help. Below are the most common ways these decisions are made in order from least to most effective.  

1. Decisions can be Subjective – Ignoring the CMMS and its Failure Data: In this instance, leadership only wants a basic work order tracking system. Some organizations never intended the CMMS to do anything more than open/close work orders, record actual hours, and capture cost. The software also generates preventive maintenance tickets from the CMMS. However, they have no interest in capturing any meaningful failure data. This means they plan to perform subjective analysis which is based on emotions and best guess – which is better than nothing. 
2. Leadership Requires a Work Order Problem Description: Many user communities require service requests to clearly state the problem – called a problem description. Unfortunately, this data field might be limited to 80 characters or less. Some products however allow a longer explanation to be stored. Expanded problem descriptions help the planners and maintenance staff have a better idea as to what the issue is before arriving on site, as in the case of reactive maintenance. And it certainly helps the planning staff – if they exist. Note: that this process assumes the work order is linked to the asset/location. 

3. The Working Level Decides to Capture Actions Performed: Oddly enough, in this scenario, the maintenance staff decides on their own to store failure history. In this context, failure history means “actions performed”. The leadership team may not have asked them to do this, but they did it anyway. Why? Their reasoning is that this information helps them diagnose problems and fix things faster by reviewing history from previous work. This failure history could even be stored outside the CMMS (as in Excel or Access), or, it could be stored inside the CMMS with text fields. Either way, the maintenance staff sees value in having this information. 
4. The O&M Technician Indicates a Functional Failure has Occurred: Not every repair activity performed against a work order addresses a functional failure. In some cases, the technician could just be applying paint. Therefore, it is important that every repair work order have a way to flag when a true functional failure has occurred. If this field says “Yes” then the entry of failure data is mandatory at job completion (by the technician). As to who should enter this value, it could be the operator who is requesting repair because he has an asset that either is not working or it is functioning below expected performance. But of the operator missed this categorization, then anyone else in the process could apply it (e.g., planner/scheduler, maintenance supervisor, or maintenance technician). 
5. Leadership Mandates Capture of Asset Problem Code: The asset problem code is useful in that it can be used to identify duplicate work. The CMMS can flag any new submittal as a duplicate if the combination of asset identifier and asset problem code are identical. The user then has a chance to continue saving the record or canceling the request. Because the asset problem code is a validated entry (i.e., selected from a dropdown list) it can be used in analytical reports. Unfortunately, if this is the only failure data, the reliability engineers can glean little information from this work order. 

Note that some CMMS products require a failure class and problem code as part of hierarchy. This means that every asset would need to be first categorized by a failure class, and then the specific problems for that failure class. But with or without a hierarchy, you can run a SQL query for all problem codes against one asset - with their counts.

Figure 5 - SQL Group-by For Problem Codes 
 

6. The Working Level Enters a Cause Code: This is where it gets complicated. The technician performs the repair and knows the component he replaced, but he may not know the exact cause for the failure. Is the cause the component he replaced or was the rotating part not lubricated properly? The technician could ask for help from the maintenance supervisor or reliability engineer, and then enter the cause code. But again, this depends if the cause code value exists in the failure code hierarchy. It could be of four possibilities: component, various failure mechanisms, human factors and specific workmanship factors.

Why is the cause code so important? Answer: Without the cause the asset could be repaired but fail again in 3 months because we never addressed the cause. However, there will be times that the cause is never truly known. 

Figure 6 - Cause Code Field

7. Use Foundation Data in Selection and Sort Metrics: The asset record has several fields which can be used for selection-and-sorting by the bad actor report. Example filters include critical assets, specific manufacturer, asset class, and replacement cost. 
8. RCM analysis Capturing the RCM 3-piece Failure Mode: RCM analysis identifies maintenance strategies and failure modes. The latter consists of a failed component, component problem and cause code. By comparing RCM analysis results to work order failure mode, stakeholders can continually improve maintenance strategies. 
9. Reliability Team Runs Bad Actor Report to find Worst Offenders: When the reliability team runs the bad actor report they will see a list of assets sorted by whatever sort-metric and filter they apply. They might run the report a second time sorted by a different metric. With each different sort-metric they might focus on the top 2-3 assets. 

10. Reliability Team Drills Down on 3-Piece Failure Mode: Once they select a single asset from this list, they can optionally then drilldown on a 3-piece failure mode. The requester might see a pie chart (or tabular list) showing all of the failed components for this selected asset as captured on the work orders by descending count. The user can then dynamically select one of those failed components, and see all of the (component) problem codes reported on work orders by descending count. Lastly, this same process is repeated for cause codes. Imagine the wealth of information extracted from the CMMS by the reliability team.