Tracking Equipment Downtime is Worth the Effort
Equipment downtime or unexpected equipment failures should be tracked in an effort to isolate and correct these destabilizing occurrences. This post focuses on using the report builder to generate powerful statistical analysis reports in seconds.
The Dangers of Ignoring Downtime Data
Unexpected equipment failures (downtime) lead to costly interruptions in the process flow, additional damage to expensive equipment and product losses. Downtime may also divert limited maintenance resources away from preventive maintenance (PM) duties. These consequences of downtime lead to expensive overtime hours and reduced preventive maintenance completion rates. In extreme cases, this can eventually lead to a chaotic “run-to-fail” cycle.
How to Collect Downtime Data
The best way to track equipment downtime is with a CMMS software system. Most CMMS systems do not have a dedicated downtime module but use the work order system to track downtime. This is sometimes adequate, however using a CMMS with a dedicated downtime module leads to better analysis and reporting of equipment problems and trends. It does not make sense to record an instance of equipment failure as work. Of course, a corresponding work order is usually created to correct the failure; however, an instance of work and an instance of failure should be kept as separate records.
When collecting downtime data it is important to determine how the downtime is logged. Are downtime cause fields user-defined and easy to understand? Some maintenance operations prefer a more general failure cause naming convention. Examples might be ‘Electrical’, ‘Mechanical’, ‘Operational’ and so on. Others managers might prefer more descriptive cause definitions such as ‘Blown Fuse(s)’, ‘Operator Error’ or ‘Water in Electrical’. Either way is fine if it suits the maintenance manager’s requirements. However, a more descriptive failure cause leads to a more accurate analysis of downtime later.
Logging the actual equipment time down is obviously important. But what about other losses attributed to this event? In many cases product losses due to equipment failures, remaking product, damage to associated equipment, production employee overtime and other company bottom line factors outweigh the direct maintenance costs for downtime. A good downtime tracking software system must consider all of these factors.
Downtime Analysis Training Video
Downtime Analysis Data Cubes Video
Benefits of Downtime Tracking
Equipment downtime data is valuable for multiple reasons. First, by understanding trends in downtime, corrective action is prioritized and implemented to prevent additional unexpected equipment failures. Selecting a CMMS that tracks downtime fields such as employee shift, maintenance shift, functional and geographical locations further empowers the maintenance manager in decision-making. Perhaps downtime is disproportionate during a certain production shift. This could be resolved with training and have nothing to do with maintenance efforts.
By tracking downtime, KPIs for tracking reliability, opportunity cost and overall equipment effectiveness (OEE) become possible. Additionally downtime data guides the maintenance manager in prioritizing preventive maintenance and equipment replacement. Justification of equipment replacement is now verifiable and simplified. Statistical analysis, reporting and charting of downtime history reveals equipment breakdown trends. These trends guide preventive and remedial efforts with real data that solves real problems. Tracking downtime has a profound effect on how, when and where maintenance resources are used. Time invested in logging equipment downtime is certainly justified by the time and money saving benefits to the maintenance department and the organization as a whole.
About the Author
Daniel Cook, Vice President of Development for MaintSmart CMMS Software, Inc. spent over twenty-five years in maintenance, the last fifteen years as a maintenance manager. Mr. Cook recognized the need for a CMMS solution that worked not only from the perspective of the maintenance manager, but also considered the bottom line of the organization served by maintenance. Working at a large commercial food-processing facility, his cross training in software engineering took place in the high-tech world of the Silicon Valley during the 1990’s.