Maintaining accurate CMMS/EAM data is a major challenge for the industry today. Collecting and maintaining quality data requires disciplined work processes that ensure accurate, complete, and pertinent information is captured in the CMMS/EAM system. Proper estimation of metrics like downtime and availability from CMMS/EAM maintenance records is often difficult as open and close dates on work orders are frequently inaccurate. In many cases, maintenance records have the same open and close dates, or are left open for years before being closed. Such maintenance record inaccuracies skew the validity when evaluating reliability metrics and benchmarking performance.
The advent of process historians and other machine-to-machine (M2M) data collection tools allows companies to create a virtuous data improvement cycle. In addition to providing more accurate estimates of metric values, we can improve the value of maintenance record data by using complementary information from multiple sources to identify areas where CMMS/EAM data can be improved as well as verify the thoroughness of the CMMS/EAM work processes’ compliance.
Inaccuracies in maintenance record data may stem from various sources. Some of these include:
The dates in the maintenance records are pulled from the work order and might not indicate the true start and finish dates due to the delays in entering data into the work order.
In some cases, due to the lack of a maintenance completion date field in the CMMS/EAM system, the work order closure date might be assumed as the maintenance completion date. But due to delays in receiving material bills and contractor hours, there might be significant delays in closing work orders, indicating a higher downtime than in reality.
The collection of the event start, maintenance start, and maintenance completion dates might be poor and there may be a high percentage of work orders missing these dates.
The work order equipment in-service and out-of-service dates are left blank. Because these dates are left blank, the out-of-service date are often substituted with the maintenance completion date.
The maintenance start date doesn’t always reflect the date the equipment was taken out of service because maintenance might start with some pre-work, such as building scaffolding. During this pre-work the equipment might still be running.
Without an explicit indicator in CMMS/EAM, it is hard to determine if an equipment required shut down for maintenance or if the work was performed while equipment was online.
The following table shows an example of discrepancies between the historian and the recorded CMMS/EAM downtime dates for critical centrifugal pumps at a refining site. (We define the CMMS/EAM downtime as “Maintenance Completion Date – Maintenance Start Date” and the historian downtime as “Historian Start – Historian Stop”).
An emergency repair was done to plug a hole in the seal flush line and the equipment was shut down to make the repair. Four days later the work request and work order was created and no attention was given to the actual dates because the process did not demand having these dates. The CMMS/EAM downtime is 0 hours while the historian downtime is 5 hours.
A repair was made on a valve but the valve did not go out of service when the repair was made. However, the technician records on his time sheet when the maintenance started and ended. The CMMS/EAM downtime is 11 months while the historian downtime is 0 months.
A low priority leak was detected and the planner decided to make the repair at the next planned shutdown scheduled for more than a year later. The planner forgot to set the maintenance start date on the work order to the start date of the planned shutdown. The CMMS/EAM downtime is 21 months while the historian downtime is 11 days.
A pipe is leaking in a hard to reach location and scaffolding needs to be built to get to it and install a clamp. Building the scaffolding starts a week before operations has the opportunity to shut down the leaking pipe. The CMMS/EAM downtime is 7 days while the historian downtime is 9 hours.
There is a severe water leak on a pump that needs to be fixed immediately by the on-call crew. A paper work order is written that is entered the next day into the CMMS/EAM system. The clerk entering the work order does not bother to enter the maintenance start and completion dates. The CMMS/EAM downtime is unknown while the historian downtime is 3 hours.
Available data from multiple sources can be used to improve data quality by identifying inconsistencies. We plot the relationship between CMMS/EAM downtime and historian downtime in Figure 1 for different repair events on critical centrifugal pumps at one site over a 5 year period of time.
The graph highlights different regions that describe different types of relationships between downtime estimates from the different data sources. The green region identifies repair events where the two downtimes are congruent, while the red and yellow regions identify events where the CMMS/EAM data needs to be rechecked for accuracy. The repairs in the red region correspond to work processes where entering data into the CMMS/EAM system is fundamentally flawed such as in cases 2 and 4 above. The repairs in the highlighted red regions correspond to events where the CMMS downtime is zero but the equipment is down such as cases 1 and 5. The repairs in the yellow region correspond to random mistakes such as described in case 3.
Many data quality problems stem from inadequate CMMS/EAM implementation or from not following CMMS/EAM work processes precisely. Some companies have succeeded in improving data quality by putting various checks and balances in their CMMS/EAM systems such as not allowing work order closure until all required fields are filled out, or requiring the work order to be reviewed by a reliability engineer before closure. Using M2M data to help automate this process will improve data quality, which in turn will improve metric accuracy and lead to more informed decisions, increased profit, and a safer work environment.
*Note Disclosure: The data shown in this blog post has been simulated to protect potentially sensitive customer information.
Standardize the collection, integration, modeling, and analysis of disparate data into a single, unified view.
Achieve less unplanned downtime by predicting equipment issues before they occur.
Develop asset strategies to optimize across availability, reliability, and costs.