When assigning reasons to downtime events, downtime reporting is more consistent and more useful with a smaller list of down reasons.
We recommend that manufacturers optimize their downtime reason codes to the smallest set of reasons that are truly actionable. If your team is spending more time focusing on capturing downtime reasons than taking action, there's a good chance that they're stuck in a 'data trap'. Downtime can be the ultimate data trap because people often feel that their existing data never quite explains ‘what went wrong’. The trap comes when you say "if we just capture more data, then we will take better action".
If you want to reduce downtime, define a small number of down reasons that equip you to have the right conversation with the right person. Have that conversation. And then take action.
Attempting to capture a large number of down reasons places a burden on operators, requires more managerial analysis, and can paradoxically reduce the ability of teams to take action. A smaller number of reasons makes it easier for operators, engineers, and managers to focus on the machine and reason that most needs their attention.
Five highly effective strategies for optimizing downtime reasons are:
We recommend capturing up to 25 down reasons (even if you have the capability to capture more reasons). There are two big benefits to categorizing a relatively small number of down reasons:
In the Pareto chart example below, this plant has defined a large number of down reasons. As a result their down losses are spread across all the available reasons, and there isn’t a clear indication for where they should focus:
In the Pareto chart example below, the plant has defined a much smaller list of reasons. As a result it’s very clear that they should be engaging the team to discuss “Module 1 Electrical” issues:
To reduce the number of down reasons, capture detailed down reasons at the constraint. Do not attempt to create reasons for every machine. Instead, capture a single reason code for each non-constraint machine. Consider this process with four machines:
If a machine that’s not the constraint is causing the constraint to stop, temporarily add a couple of reason codes at this machine to track the problem until it is fixed.
By focusing on the constraint you reduce the number of down reasons, and focus the team on the machine that has the biggest impact to productivity.
Many engineers want to capture the root cause of machine stops. Unfortunately very few operators can consistently and correctly identify the root cause of a machine stop, which in turn creates poor data.
Aim to consistently capture the most common symptoms for the machine stopping. Symptoms broadly describe the area of the machine that has the problem. For example: Infeed Problem, Material Jam.
By focusing on symptoms you reduce the number of reasons and improve the probability of an operator selecting the correct reason for a machine stop.
When defining your downtime reasons, here are some additional best practices to help you create best practice reason codes:
The ability to capture downtime reasons without operator involvement saves time and enables your operators to focus on the job at hand. Many machines are run by PLC’s that flag fault codes when the machine stops. It is entirely possible to capture these PLC fault codes as downtime reasons without operator involvement. If you’re interested in capturing down reasons from your PLC consider:
The Vorne XL Productivity Appliance™ tracks downtime, and automatically identifies top down reasons with built-in Top Losses reporting. With XL you can: