Want to drive improvements to virtually every operational KPI? Start by focusing on our simple maxim: “Get it in run, keep it in run, at target speed.” Effective use of downtime reason codes can help you achieve this goal. Let's dive into some key concepts about your reasons for downtime that you might not have considered.
Understanding D1 vs. D2 Downtime Tracking
D1 (Unplanned Downtime): This state occurs when the crew is on the line, but the line isn't running. This is where most of your headaches will manifest.
D2 (Planned Downtime): This state is for downtimes when the line is not crewed, or the crew is in an indirect labor state (e.g., lunch break, clean-up, maintenance). Although this article focuses on D1, tracking D2 is also important to ensure scheduled downtime events are properly managed. We’ll cover this in another post.
The Three Types of D1 Downtimes
We believe there are 3 distinct types of D1s, each needing different analysis and corrective action:
1. Internal D1s
These are downtime events that are inherent in the process and cannot be avoided. Roll changes are a classic example of an internal D1.
D1s require well-defined standard work and training. The goal is to measure and improve the process capability, i.e., everyone does it the same way and in, roughly, the same amount of time. High variability in the downtime durations signals an “out of control” process.
The corrective action: reduce the variability by assessing your standard work, evaluating your training, and working directly with struggling employees.
MTBF [Mean Time Between Failures] (or average Run duration) is an excellent metric. It will never be longer than the intervals between internal D1 events. You know that going in so set your target accordingly.
2. External D1s
These are downtime events that are unrelated to the equipment, job, or crew. The classic external D1 is the machine is down waiting for something, materials being the most common culprit.
External D1s are typically avoidable and tend to be ‘low hanging fruit’. They need a deep dive into the conditions that cause them.
3. Break-fix D1s
As the name suggests, these are equipment breakdown events that often result in the need for Maintenance support.
There are two critical metrics to consider here:
How long: When they happen, how long does it take for the required resources to respond and fix the issue? If you don’t measure it, you can’t manage it.
How often: What frequency are you experiencing the same breakdown for any given piece of equipment?
If you repeatedly experience the same break-fix D1 on a given piece of equipment, FIX IT! These reason codes are an excellent source of ROI justification for capital investment. And here’s a hard saying that is worth emphasizing: if you are not using Flex data to find and fix your problems, what’s the point?
Effectively managing downtime in manufacturing is essential for maximizing profitability and operational excellence. Thinking about your downtime using this framework and selecting the reason codes that make sense for your operation will help you get the most out of your data.
My professional career has exposed me to a wide range of data-driven initiatives.
Prior to graduating from college, I had the pleasure of working as an engineering co-op student. I spent a summer working at the Naval Research Center in Bethesda, Maryland collecting sonar data on nuclear submarine runs.
This was the summer that Tom Clancy’s “Hunt for Red October” mega-best seller came out. I was thrilled to spend time on the USS Dallas, the submarine in the story that was showcased in the movie with Sean Connery as her captain.
My co-op job was working with a team of engineers to collect sonar data that allowed the Navy to ping the ocean and utilize advanced algorithms to identify sea vessels in the surrounding water based on their unique data “signature.”
The US Department of Defense paid significant amounts of money for teams of engineers and technicians to collect reams of data to create the visibility needed to accurately detect and respond to a range of potential threats at sea.
My first job after college was working as a fiber optics engineer. One project was to collect data from a strain gauge within a rotating shaft via optical transmission. There was valuable mechanical stress data that our customer needed for their product design team to leverage for higher reliability.
Magnetic Bearings Inc. (MBI) was perhaps the most advanced technology company I worked for during my career as an engineer. MBI developed electromagnetic bearings to levitate high-speed (15,000 RPM) rotors in turbines for applications such as pumps for natural gas pipelines.
There was a tremendous amount of detailed vibrational data collected at MBI through microcontrollers. This data was used to “tune” the bearing dynamically using algorithms that enabled machines to reach higher speeds than traditional oil bearings. Without a reliable feedback loop of highly accurate data collection, the magnetic bearing system would fail – sometimes catastrophically.
Close-up of a Flex-Metrics Direct Machine Interface (DMI) module with wired sensor connections for real-time manufacturing data collection and machine monitoring.
I have now spent the past 20+ years collecting data within manufacturing plants using a Direct Machine Interface [DMI] technology, like a Fitbit that attaches to manufacturing equipment. I’ve been deeply involved in developing data collection systems for production equipment ranging from printing presses to bottle fill lines to automotive assembly robots.
As a result of these career experiences, I can’t help but notice automated data collection systems that appear to be spreading at an exponential pace. For example, I was recently at a fast-food restaurant and noticed they had invested in a real-time data collection system for their drive-through lane to count cars and highlight current and average wait times at the window.
Even fast food has data automation and KPIs
Why do businesses spend various degrees of money on these types of data collection systems? As usual, it depends on what they seek to achieve, such as:
Real-time Visibility: Typically, stand-alone monitoring solutions. Provide a better “line of sight” to build a culture of ownership and accountability. Minimal change-management skills are required.
Process Improvements: These data systems require organizational change agents and sophisticated data users to generate a payback. Data-driven changes are typically focused on the process, product designs, or capital equipment. Requires highly trained decision-makers and disciplined internal processes to implement and sustain changes. A wide range of potential changes in human behavior may be required to realize a positive return on investment.
Automated Process Optimization: Historically, such data collection systems are coupled with advanced technology and capital equipment. Improved accuracy and timeliness of feedback loops drive optimization algorithms. Ideally self-optimizing systems based upon well-tuned feedback loops have minimal dependency on human behavior. Examples include automated count control and speed optimization algorithms.
Given the spectrum of complexity that follows these different levels of manufacturing data analytics systems, it is not surprising that many organizations tend to over-shoot when they realize they have fallen behind the competition when it comes to building a culture of data-driven decisions
Fast-food drive-through monitoring screen displaying real-time service time metrics and operational performance data.
Like the display at the fast-food drive-through, it’s hard to go wrong with a simple, real-time visibility solution. High performers like to keep score. Presenting accurate, real-time data in an intuitive format makes it easier for everyone to “stay in the game”. Real-time visibility enables practically anyone to be more productive immediately when there’s a line of sight on current performance results.
Flex-Metrics Shift Score Card from the Equipment Portal. **queue oohs and ahs**
Collecting data to make design changes to a product or process requires an entirely different level of data users’ skills over a longer time frame. This is the classic example of engineering, which is to apply math and science to make changes to create a Future State that is tangibly better than the Current State.
In the business of software development, there is a concept called a Maturity Model that explains how some software firms reach a Level 4 Maturity by following a proven process to release high-quality code that just works. Unfortunately, there are far more software businesses stuck at Level 0 “Ad-hoc” Maturity that brute force results every day. A key concept in the Maturity Model is that it’s impossible to jump levels.
I’ve seen the same concept play out with manufacturing sites that want to go from no data collection to full-blown Kaizen black belts in a single initiative. Instead, I would strongly advise starting slow and simple, then moving fast based upon “quick wins”. Walk before you run!
If your manufacturing site is not currently utilizing real-time visual factory displays on the shop floor, that is one of the easiest ways to start on the journey toward a data-driven culture of Operational Excellence. Once a team gets a taste of trustworthy data that makes it easier to win, with less stress, going to the next level of data maturity comes much more naturally.
