Equipment downtime is important to track because if the process isn’t running, you aren’t producing any product. When collecting downtime data, there are several keys to ensure you are producing useful information.
Automate Downtime Tracking and Monitoring
It is possible to track downtime manually, but manual data is usually not accurate and it is difficult to use in a timely manner. For example, operators aren’t good time keepers. They are busy trying to resolve the problem and get the machine running, so the downtime duration is a guess that is often inaccurate. It is easy to think you were down for an hour when maybe it was only half an hour. How many times have you been at work and thought it must be almost lunch time, and when you look at the clock it was only 10 a.m.?
Additionally, manual data can get incorrectly transcribed or lost and it can be difficult to compile accurately. When events go unassigned it is difficult to know what to work on, but inaccurate data can be even worse. An operator might also document an inaccurate time on purpose to hide excessive downtime.
Don’t get us wrong, operator involvement is critical. An operator can explain what really happened, but an automated data collection system should be relied on to collect the data before operators help turn it into information. Automation also frees up the operator so they can spend more time operating and less time documenting.
Create Meaningful Events
Ultimately, you want to know if your machine is running or not, but it is helpful to subdivide downtime and capture additional machine states. The key states are:
- Running – the machine is producing product
- Down – the machine is not producing product because of an unplanned issue
- Unscheduled – the machine is not producing product because it is not scheduled to run
- Starved – the machine is not producing product because an upstream machine is down
- Blocked – the machine is not producing product because a downstream machine is down
Ideally, the states would be determined by the machine control system, but it can also be done with calculations in the downtime tracking software. Downtime events can then be triggered by the machine state, and a start time and end time are recorded.
It is also a good idea to divide downtime into major and minor stops. Most people consider minor stops to be downtime events that are less than five minutes that don’t require maintenance. Minor stops could include events such as jams, blocked sensors, or minor adjustments. Downtime events that are greater than 5 minutes are considered major stops and should be identified as either breakdowns or changeovers.
Assign Downtime Reasons
After a downtime event is created, a reason needs to be identified and assigned because knowing why the machine went down is essential for problem solving. Some systems can automatically assign a reason based on the error code from the machine. Operators can verify automatically generated reasons or select the appropriate downtime reason from a pre-determined list of common causes. Some companies even build the reason picking functionality directly into the machine controls and require the operator to select a reason prior to starting the equipment back up. This is a way to guarantee all downtime events get a reason assigned to them, but be careful because it could cause inaccurate data or frustration because the operator just wants to get the machine started again.
You need to have an appropriate list of reasons to be successful. The reason list should be small and standardized for each equipment type. You cannot work on everything at the same time. Most likely you will prioritize and work on the top 3-5 downtime categories, so what benefit is there to having 30 reasons? However, you want the list large enough so most events will be assigned a reason and not be categorized as “Other.” A list with 10-12 reasons is usually sufficient. Also, don’t make the operator drill down too many levels into the reason tree to find the right reason. Just because the system has 4 levels, doesn’t mean you have to use them all.
Creating Reason Trees
When creating downtime reason trees, you should keep the following points in mind:
Reasons should be distinct. It should be obvious to operators which reason applies, so you don’t end up with some people selecting one reason and other people selecting a different reason for the same direct cause.
Reasons should be symptoms. The reason should describe a direct cause, not a root cause. You should not be asking operators to determine root cause without some problem solving activity. For example, the direct cause of the machine downtime might be a bearing failure. The root cause of the bearing failure might be lack of lubrication, which could ultimately mean a deficiency with the lubrication program in the facility.
Only include frequent reasons. Do not include reasons that do not occur often because that only makes it harder to find the right reason. If you use an “Other” reason, it should not be a top cause. New reasons should be added to the list so the true causes are captured.
Capture Downtime Event Attributes
There is additional data that you should consider collecting to help make the downtime data useful. The data collection should include:
- Process area or production line
- Machine name or number
- Product name or code
- Machine fault/error code
- Event duration
- Shift number
- Production date and time
- Operator comments (including any corrective actions)
Basically, you want to collect anything that can help identify who, what, when, where, why for every downtime event. Also, it is valuable to get operator comments describing the event and any corrective actions performed in their own words. You will get the most accurate comments at the time of the event and this also provides immediate communication. Reason categories can be used to identify top problems, but the operator comments can be invaluable when trying to identify the root cause. With practice and coaching you can start to get comments loaded with information.
Provide Real-Time information for Real-Time Problem Solving
The best time to collect information and solve a problem is when it is actually happening. After-the-fact reporting and problem solving is not as effective. How downtime data is viewed and by whom it is viewed is important for driving improvement. The data should be available continuously and not require complicated reports to be manually compiled after a long time has elapsed.
There are several ways to identify and react to the causes of downtime. Pareto charts are a common tool to visually show the top downtime reasons either in terms of time or event count in a given time period. It is a good practice to develop a process for systematically addressing the chronic problems near the top of the Pareto chart.
Trends and Gantt charts are also good visual tools that show a current timeline of downtime events.
For downtime information to be effective, data must be easy to collect, easy to understand, and must provide enough information for good problem solving. See how dataPARC can provide all of the tools you need to track and work on reducing downtime.
dataPARC empowers users with its intuitive, user-friendly, feature-rich analytical and troubleshooting modules that deliver on the promise of plant-wide data integration and utilization. Contact us to learn more.
OEE: The Complete Guide
A free guide to help implement, analyze, and improve Overall Equipment Effectiveness.