Factory downtime. You have it, and you think you’re tracking it. You’re counting the downtime minutes anyway, and you kind of know why things were down. Well, you know why things were down when you find out a week later. If in fact you believe the note you got on the downtime, which seems different than the explanation you got from two other departments.
Like most organizations in the packaging sector, you might point to one of three ways you log downtime, no doubt with a grimace on your face, recognizing that you’ve got an incomplete picture.
If it’s not an operator walking up to a human machine interface (HMI) or personal computer to log downtime reasons, you’re using handwritten forms and spreadsheets to document events, times and reasons. Short of that, you purport that your manufacturing execution software (MES) package is logging most of what you need, even though you know that’s not entirely true.
Sensor-based technology and software has made it much easier to “count” the minutes you’re down and where, but, advances to help you understand “why” and the root causes of downtime have been slow to evolve. With the advent of mobile technology and discrete software as it starts to eat the packaging sector, it’s possible to log the data required to truly get to the causes of downtime in a semi-automated fashion.
It’s not that the power of context has been underestimated over the last twenty years by equipment providers, but, the consequences of having operators or supervisors walk to a personal computer, HMI, or paper based station to enter information on downtime or other operational events hasn’t been appreciated by designers. (check out our previous blog
here titled “3 Day Long Experiments That Show the Power of Downtime Context)
It’s an approach that doesn’t suit their workflow, much less drive out real-time intelligence that management needs to understand downtime reasons.
Of course, it’s easy to place the blame on an operator for not logging downtime reasons effectively, but, consider the screens and log forms operators have to use, which were designed as an afterthought. Very little appreciation has been given to user experience by best in class designers in this market, dramatically affecting adoptability of any system to track downtime context, and ultimately impacting results you could get.
And with a lack of true downtime context, finger pointing starts, while management enjoys five different explanations about the root cause, and week old, barely legible paper notes 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 most progressive 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 project that can be applied globally across an organization, even in cases where sophisticated MES systems are deployed.
The good news is, there are cheap and cheerful ways to experiment with mobile solutions to improve the downtime context you receive today.
Here are a three simple experiments you can run to explore the power of a discrete, context-first system.
Ignore Your Existing Systems for Tracking Altogether
Test a hypothesis that you can deploy a discrete, semi-automated system that is web enabled and wirelessly connected, to collect critical information on context and events that create issues in your factory. The goal here is to collect more powerful diagnostic data than you can by aggregating fault codes or other data on an MES system, 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.
Put in a Context-First System and After it Works, Integrate (Not Before)
It’s natural to rush to connect all of your disparate systems, but don’t rush this time. Test a hypothesis that you can implement a system to retrieve better context on events that lead to factory issues, and that this data will be so powerful that you’d rather move forward with a “Context-First” system. After that, you’ll look to integrate with that system at a later date if possible, streaming machine data into the contextual system and not the other way around.
Pick a Context-First Project and Calculate the Financial Impact of It
This one is simple. Pick a 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.
TO FIND OUT MORE ABOUT HOW MOBILE APPLICATIONS CAN BE LEVERAGED TO PROVIDE DOWNTIME CONTEXT: