3 Day Long Experiments That Show the Power of Downtime Context

3 Day Long Experiments That Show the Power of Downtime Context

If you’re a performance specialist whose job it is to take the manufacturing and packaging sector to new heights using continuous improvement (CI) methodologies, approaches and tools, you’re in for a tough slog.

Stymied by cultural issues, paper based tracking, or a belief that existing software systems give a factory everything they need, the barriers are enormous when it comes to pushing a performance improvement project through. The pain is common, whether you’re a plant manager, CI lead, automation supplier, equipment manufacturer, or contractor.

The reality is, most systems and processes in a factory have been designed to make root cause analysis tough, and without good context, it’s extremely difficult to identify root causes to build out performance improvement projects.

If the genesis of your CI project is a downtime or efficiency issue, you can probably sympathize. Sure, fault and error code notifications are retrievable, but you’re missing context to help you get to the root causes of issues, as software providers over the last twenty years have completely underestimated the power of context and root cause identification.

Look no further than your organization, relying on your operators or supervisors commitment to walk to a personal computer to enter information on root causes of downtime events, long after they occur. The screens they interact with were designed as an afterthought, simply streaming data in with text boxes for data entry. Very little appreciation has been given to user experience affecting adoptability of the systems, and dramatically impacting the context you get from system users.

Here are a few hypothesis you can test and challenges you can take to explore the power of a discrete, context-first system, which ultimately will challenge how you get to the root causes of downtime in your operation using new approaches.

1. Ignore Your Normal Workflow to Explore the Power of a Context-First Approach

Test our hypothesis that it’s worth putting a resource onto a time-bound, scoped out project, solely to collect root cause data associated with potential issues in your factory. Use a semi-automated system that is web enabled to collect critical information on context and events.

The goal here is to collect more powerful diagnostic data than you can by aggregating fault codes like you usually do, allowing you to get to the root of your problems effectively and rapidly, without having to leverage your existing cumbersome systems.

Remember, this is a moment-in-time experiment, to prove the power of the context so that you can make changes to your existing systems and internal processes. You’ll be out the labour cost of the resource you dedicate to your project, and a little bit of your time, but, you can usually get an automation supplier to support such an effort for free.

You may even find that your natural inclination to rush to connect all of your disparate machine based systems with software doesn’t make sense after you try this. There are times where a mobile-based system to retrieve better context on events that lead to factory issues will lead to integration with that system at a later date if possible, streaming machine data into the contextual system and not the other way around.

2. Put in a Context-First System to Trial New Equipment

Test our hypothesis that you can work with your original equipment manufacturers (OEM’s) and automation suppliers to get real-time access to trial related data, including quantified outputs from the trial on the value created by new equipment or consumables you may be buying.

With a context-first system for trials, you can define success criteria before you begin a pilot and build this into your tracking efforts of the trial on site. This includes defining how long a trial will run, what objectives define a successful pilot, and what parameters will be measured throughout the pilot to gauge movement towards meeting those objectives.

Mobile devices can be configured so that it’s clear what information field based partners or on-site employees at a plant need to collect throughout the trial period. Then, you can receive real-time diagnostics from the floor. With an appropriately configured system and a powerful reporting engine, you’ll have all the intelligence you need to share successful pilot or trial results with plant management, procurement, and other decision makers.

If the trial was borne out of downtime issues, the power of context-first downtime tracking will be immediately evident.

3. Picking Your Own Context-First Project and Calculating the Financial Impact to Change How You Track Downtime

This one is simple. Pick a simple project to address an issue that you know is costing you money (think downtime or rework), given a lack of context. Deploy a discrete system to help you collect data, and review the data at the end of the project relative to the project goals. Now calculate the financial impact of what you’ve learned. Test our hypothesis that putting context ahead of a system driving only machine data, isn’t always a “garbage-in” and “garbage-out” scenario. One of our partners just did exactly this, to the tune of identifying $2.5M+ in unknown issues in 1 day.

To learn more about how mobile-based performance improvement systems designed with context in mind, click here.

Mobile Apps That Can Justify $1M+ in CAPEX in a Day

 Mobile Apps That Can Justify $1M+ in CAPEX in a Day
Unplanned factory downtime is frustrating, and identifying the root cause of it is even more frustrating.

Often, understanding the root causes of downtime can help identify the need for, and justify large capital expenditures, which ultimately can improve your operation by addressing a core issue.

If only management could get to that root cause.

The reality of any factory manager or supervisors week just doesn’t make this easy. Consider for a moment, what the end of their week is typically like. Management is finally getting around to reviewing reports, including those on unplanned factory downtime, only to find out that there were huge issues on a production line and they didn’t know why.An issue with something at the end of the packaging line perhaps. It caused a half a day of downtime, and management wasn’t notified. The operators simply fixed it, and kept running.

When teams are asked about the issue, they point the finger, and management gets five different explanations about the root cause. All they’ve really got to go on is week old, barely legible paper note with a few thoughts on the cause. This is commonplace in the packaging sector, but it doesn’t have to be.

The root causes of unplanned factory downtime can be logged effectively as the downtime event is occurring, or immediately after by leveraging modern mobile applications, just like the ones you use in your personal life. This information can be shared either in real-time, or immediately after on a web-enabled dashboard, and annotated as appropriate after the fact by supervisors and managers who review the factory downtime events.

The better your data is on downtime events, and the more timely the context and resolution, the more likely it might be that you can make a case to justify a significant investment in new processes, or equipment, so that the root causes are addressed appropriately.

Consider how customers are using mobile apps to address downtime issues and ultimately CAPEX problems when it comes to well used, less sophisticated machinery at the end of their packaging lines.

The progressive automation suppliers and packaging organizations have mobile apps configured to track unplanned, unidentified factory downtime over the course of a shift, leading to the identification of specific, measurable performance improvement projects that can be applied globally across an organization.

For the uninitiated, specific pieces of equipment can lead to significant unknown, and unplanned downtime and can be a major source of frustration for operations personnel at the end of a production line.

In one of our customers cases, they were running efficiently upstream, and they had a small piece of technology that continually under-performed, often randomly. If you’ve experienced bottlenecks or downtime at the end of a packaging line, you know what’s next.

Usually, rework, while employees manually tape boxes, product spilling off the line, and costly unplanned downtime while you fix the head and reinstall anything that’s broken (with fingers crossed that you can fix the problem internally).

Management wasn’t notified in the aforementioned case, and technical employees on the floor simply fixed the problem as quickly as they could, without logging the impact of the problem. It wasn’t malicious, but, they weren’t trained to track these events as downtime events and didn’t make the link between CAPEX approaches to solving the problem permanently.

To get a clear indication of how often this particular asset was failing, and the factory downtime costs associated with it, management decied to use a mobile device over the course of an eight hour shift, clearly documenting the unplanned factory downtime and the root causes of the issues in real-time.

Consider the power of tracking metrics like case throughput rates, number of cases run, quantity of incorrectly taped cases, reasons for downtime, and the time to correct rework over the course of a shift, relative to a problem asset or process.

By combining this data with known financial values associated with the cost of downtime per minute, they made a case within a day to part ways with existing factory technology, replace it, and ultimately reduce downtime and rework to the tune of $1M+ in one factory as a result of a future CAPEX.

The lessons were applicable broadly, throughout the organization in multiple factories, which amplifies the potential value creation substantively.

All for the investment in a mobile application, and a days worth of a technicians time.