Resources / Guide
Reduce Unplanned Downtime, Step by Step
Downtime is the loss everyone feels and few plants fully see. This playbook turns a noisy stop log into decisions: measure every minute honestly, categorize the losses, rank them by dollar impact, put one owner on each fix, and verify the before and after against a baseline finance will sign.
The loop in five steps
Downtime is the easiest loss to feel and one of the hardest to fix, because most plants never see the whole of it. The dramatic breakdowns get logged. The thirty-second jams, the slow-cycle minutes, and the waiting-on-material gaps quietly add up to more lost output than any single failure. A playbook works because it forces every one of those minutes into the open, then routes it to a decision.
This is the loop we run with design partners. It is deliberately boring and repeatable: run it on one line this month and the rest of the plant next quarter.
- Measure honestly: put every minute into a state, including the small stops most logs miss.
- Categorize: map each stop to a reason code so the losses add up cleanly.
- Rank by dollar impact: sort by money at risk, not by how often a stop happens.
- Assign: one loss, one owner, one countermeasure, one due date.
- Verify: prove the before and after against a normalized baseline.
Step 1: Measure downtime honestly
You cannot rank what you cannot see, and you cannot see what you do not capture. Start by giving every minute of the day a state: running, planned stop, unplanned stop, or idle with no demand. When the states are exhaustive, the arithmetic closes and there is nowhere for lost time to hide.
Two distinctions do most of the work here:
- Planned vs unplanned. Planned downtime covers changeovers, preventive maintenance, and no-schedule time. Unplanned downtime covers breakdowns, jams, sensor faults, and material starvation. Reducing unplanned downtime is where the fast money is; planned downtime is a scheduling and SMED problem.
- Big stops vs micro-stops. A micro-stop of a minute or two rarely gets logged by hand, yet in aggregate these are often the single largest loss on a line. Capturing them reliably means pulling state changes straight from the PLC, historian, or SCADA rather than trusting a clipboard.
Add two reliability numbers per asset and you can tell the failure modes apart. MTBF (mean time between failures) tells you how often a line goes down; MTTR (mean time to repair) tells you how long it stays down. Availability rises when you push MTBF up or pull MTTR down, and those two levers call for different fixes.
One honesty check before you move on: do not shrink the denominator. The fastest way to fake progress is to reclassify stops as not scheduled so they fall outside planned time. Our OEE and TEEP guide walks through why an honest definition of planned time is the foundation the whole number rests on.
Step 2: Categorize losses so they add up
A pile of timestamps is not information. The next step is a reason-code taxonomy that every stop maps to, so that when you sum the minutes they tell a story instead of a mess. The Six Big Losses give a proven starting frame: breakdowns and setup fall under availability, minor stops and reduced speed under performance, process defects and startup rejects under quality.
With clean codes you can build a Pareto of downtime, and a Pareto almost always bites: a small handful of causes accounts for most of the lost minutes. That chart tells you where the time goes, which is necessary but not sufficient, because minutes are not yet money.
Two failure modes to watch while categorizing:
- The miscellaneous bucket. If other is one of your top causes, your codes are too coarse to act on. Split it until each code points to a specific, fixable thing.
- Cause vs symptom. Line stopped is a symptom. Infeed conveyor photo-eye fouled by dust is a cause. Code the cause, or the Pareto will rank symptoms you cannot assign to anyone.
Step 3: Rank by dollar impact, not frequency
This is the step most downtime programs skip, and it is the one that decides whether the work pays. Ranking by frequency or by raw minutes feels objective, but it quietly points you at the wrong problems. A jam that trips fifty times a shift can matter less than one rare long failure, and downtime on a line that is not your constraint may cost nothing at all.
Weight each loss by the output it actually costs you:
- Throughput at risk times contribution margin per unit, so a stop is valued in money, not minutes.
- Constraint position. Under the Theory of Constraints, an hour lost at the bottleneck is an hour lost for the whole plant, while an hour lost on a non-constraint with buffer ahead of it may cost nothing. Rank accordingly.
- Confidence. Some estimates are metered and solid; others are educated guesses. A high-value, low-confidence item is worth an investigation, not yet a capital request.
Doing this by hand across dozens of lines and thousands of stops is where spreadsheets fall over. It is also exactly what the KaizenFlow platform is built to do: an ensemble of nine AI specialists scores every opportunity by dollar impact and confidence, so the top of the list is the money, not the noise.
Step 4: Assign one owner and one action
A ranked list changes nothing until each line on it has a name against it. The rule that keeps momentum is simple: one loss, one owner, one countermeasure, one due date. Shared ownership reliably becomes no ownership, and a countermeasure without a date is a wish.
Before you write the action, get past the symptom to the cause. A few rounds of why, or a fishbone for the messier ones, usually separates the immediate fix from the systemic one. Both matter: the immediate fix restores output today, the systemic countermeasure stops the loss from coming back.
Match the countermeasure to the loss type:
- Changeover and setup losses: standard work and SMED to convert internal setup to external.
- Breakdowns: condition monitoring and a real preventive-maintenance interval, informed by MTBF.
- Minor stops: fix the mechanical or sensor nuisance at its source rather than resetting it each time.
- Defect and startup losses: poka-yoke and first-piece checks so bad parts cannot pass unnoticed.
Put the actions on a board everyone can see and review them at a fixed cadence. Visibility plus a standing meeting does more for closure rates than any tool.
Step 5: Verify the before and after
The last step is the one that earns trust, and the one most programs fake. It is easy to declare victory on a slide; it is hard, and far more valuable, to prove the saving survived contact with the P&L. Verification starts before you touch anything, by fixing a normalized baseline: the same product mix and run conditions you will measure against later. Skip that and an ordinary dip in demand will read as a win.
After the countermeasure lands, measure the same way, then hold the gain. A fix that is not written into standard work drifts back within weeks, so the countermeasure is not done until it is the new default way the line runs.
This is the gap KaizenFlow is built to close. It reconciles each result against that normalized baseline and rolls verified figures into a savings ledger the customer's own finance team signs, so a downtime win is an audited number rather than an estimate. Across the design-partner program the modeled target range is an 8 to 18 percent reduction in unplanned downtime; we frame that as a modeled range, not a promised result, because the honest number is the one your finance lead will stand behind.
When you are ready to run this loop against your own line, book a walkthrough and we will start from your real downtime log.
Frequently asked
What is the fastest way to reduce unplanned downtime? Start by capturing every stop, including the micro-stops most logs miss, then rank the losses by dollar impact rather than frequency. The fast money is usually a small set of high-value causes on your constraint equipment, not the stops that happen most often.
What is the difference between planned and unplanned downtime? Planned downtime is time you scheduled out of production: changeovers, preventive maintenance, and no-demand periods. Unplanned downtime is unscheduled loss such as breakdowns, jams, sensor faults, and material starvation. Reducing unplanned downtime is usually the quickest source of recovered output.
Why rank downtime by dollar impact instead of frequency? Because minutes are not money. A frequent short jam can cost less than a rare long failure, and downtime on a non-constraint line with buffer may not reduce plant output at all. Weighting each loss by throughput at risk and contribution margin points the work at the money.
What are MTBF and MTTR? MTBF (mean time between failures) measures how often equipment goes down; MTTR (mean time to repair) measures how long it stays down once it does. Availability improves when you raise MTBF or lower MTTR, and the two point to different countermeasures.
How do you verify that downtime actually went down? Fix a normalized baseline before you change anything, measure the same way afterward, and reconcile the difference against the same conditions so a demand swing cannot masquerade as a saving. KaizenFlow rolls verified results into a savings ledger the customer's finance team signs.
Run the loop on your line
Turn your downtime log into a ranked, verified plan
Bring one line and one week of stops. We will show you the losses ranked by dollar impact, the owners and actions behind each fix, and how the result gets verified against a finance-signed baseline.