How to Optimize Manufacturing Downtime Reasons

Downtime Reason Codes

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 Great Strategies for Downtime Reason Optimization

Five highly effective strategies for optimizing downtime reasons are:

1. No More Than 25 Downtime Reasons
2. Focus on the Constraint
3. Focus on Symptoms
4. Create Meaningful Downtime Reasons
5. Automate Downtime Reason Capture

1. No More Than 25 Downtime Reasons

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:

• Consistency: It’s easier for operators to capture the correct reason when they have fewer to choose from. When presented with hundreds of reasons, we find that most people select the most convenient reason (so that they get back to running the machine), rather than the correct reason (which may require leafing through pages of reasons).
• Analysis: A smaller list makes it easier to quickly identify which common cause of downtime needs to be the top priority.

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 of 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:

2. Focus on the Constraint

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:

• Each machine has ten down reasons. Total = 40 down reasons.
• Create ten down reasons on the constraint. Create one generic reason for each additional machine. Total = 13 down reasons.

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.

3. Focus on Symptoms

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.

4. Create Meaningful Downtime Reasons

When defining your downtime reasons, here are some additional best practices to help you create best practice reason codes:

• All Other Losses: Include “All Other Losses” as one reason. When this loss is your Top Loss, break it apart and replace an existing reason with a new reason.
• Differentiated: Each reason should be mutually exclusive to your other reasons. It should be impossible for three different people to select a different reason for the same stop.
• Understandable: Choose reasons that are easily understood by your operators. This may mean providing them in a second language.
• Machine Focused: Avoid assigning reasons to people (such as “Waiting for Engineer”). Personnel-based reasons are rarely accurate and rarely create a positive working environment.
• Reviewed: Regularly review your down reasons. Remove reasons that aren't frequently used, and add reasons to ensure that ‘All Other Losses’ is not in the top ten losses.

5. Automate Downtime Reason Capture

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 PLCs 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:

• Faults vs Reasons: PLCs generate fault codes and multiple fault codes can be activated when the machine stops. For example: An operator opens a guard to prevent a material jam. The PLC might record a fault for “Machine Stop” and another for “Guards Open”. However, the down reason you want to capture is “Material Jam”. Review how your PLC tracks machine fault codes, and identify the extent to which fault codes need to be combined into reasons.
• Cost: The PLC is specifically designed to run the machine, not to create reports. Capturing fault codes from the PLC typically requires additional software to export the information to a reporting system, and your PLC engineer may need to amend the PLC code to create useful down reasons.
• Consistency: If you have different machines, or machines with different PLCs, it might be difficult to consistently capture PLC reasons across every process.
• Operator Engagement: With PLC data capture operators are less invested in tracking why the machine is stopped. When your operator selects a down reason, they own the problem and the data.

Reduce Downtime With XL

The Vorne XL Productivity Appliance™ tracks downtime, and automatically identifies top down reasons with built-in Top Losses reporting. With XL you can:

• Automatically Track Downtime: XL automatically tracks downtime using a single input from your equipment.
• Simplify Downtime Reason Recording: XL makes it easy to optimize and record your downtime reasons. Type your barcodes into the XL interface and the XL automatically generates a barcode sheet. Your operators can easily record the reason for each down event.
• Analyze Downtime: Use XL reporting tools such as the Downtime Pareto and Total Production Timeline™ to easily see your top down reasons and how they impact your productivity.
• Attack Largest Sources of Downtime: Use information in the Top Losses report to systematically attack your downtime.

TRY XL FOR 90 DAYS