The six big losses framework is older than most of the software now used to track it, born out of Total Productive Maintenance in Japanese manufacturing decades before a machine could report its own state over a network. It’s held up remarkably well, because it’s really a taxonomy of the same three OEE factors, availability, performance, and quality, broken into six specific, recognizable failure patterns. What’s changed is how much of it a system can now catch on its own, and how much still needs a person to explain what happened.
The six losses, grouped by the factor they hit
1. Breakdowns
An unplanned stop where the machine can’t run: a fault, a mechanical failure, a fixture that broke. This is the easiest loss for modern monitoring to catch completely, a control or a sensor watching run state sees the stop the instant it happens, with an exact start and end time, no memory involved. What it usually can’t tell you on its own is why. A stop is a stop to a sensor. The failure mode, a broken tool versus a hydraulic fault versus an electrical fault, still needs a person to tag it, which is the entire argument for a short, well-chosen reason code list rather than a sensor trying to guess a cause it never directly observed.
2. Setup and adjustment
Changeover time: the machine stopped to switch from one product to another. Automated monitoring catches the stop itself precisely, and increasingly it can catch more than that. If a system knows what product ran before a stop and what product ran after it, it can identify the stop as a changeover automatically, without anyone tagging it, and even flag the specific product-to-product transition that’s driving the cost instead of lumping it into “changeover” as a generic bucket. What it still can’t do is tell you why a particular changeover ran long, a missing fixture, a program that needed debugging, a part that didn’t fit right the first try. That’s floor knowledge, and it’s exactly the layer changeover reduction work depends on once the pattern’s been surfaced.
3. Idling and minor stops
This is the loss automated monitoring changed the most. A ninety second pause four times an hour never gets written on a clipboard, because it never rises to the level of something worth walking over and logging. It’s not dramatic, it’s not a phone call to maintenance, it’s just a small gap that repeats all shift. A control watching run state every second catches every one of these, whether or not a person ever noticed. This is also usually where a first automated reading drops hardest compared to a hand-tracked number, because minor stops are, by definition, the losses nobody was counting before.
4. Reduced speed
Running slower than the ideal cycle time, without stopping. This is one of the hardest losses to catch by eye, because the machine looks like it’s working the whole time, and a cycle time that’s crept up two percent over three months is invisible day to day but costs a full shift of capacity by the end of a quarter. Automated monitoring catches this cleanly, comparing actual cycle time against the ideal every cycle, as long as the ideal cycle time itself is real. A padded standard hides this loss just as effectively as a person glancing at a running machine does. The measurement only works if what it’s measuring against is real.
5. Process defects
Scrap and rework caught during steady-state production. Whether monitoring catches this automatically depends entirely on where the check happens. If quality gets logged at the machine, at the point a part is made, an automated system captures it in real time, tied to the exact cycle and conditions that produced it. If quality only gets caught at final inspection or by a customer downstream, the loss is real but invisible to the machine, no sensor at the CNC knows a part shipped three stations later failed. This is why a clipboard quality number is so often optimistic. It was never measuring what happened at the machine, it was measuring what happened to survive the rest of the process.
6. Reduced yield, startup losses
Scrap concentrated in the warmup period after a startup or a changeover, before the process has stabilized: the first few parts off a fresh setup, running warm-up cycles until dimensions settle in. Automated monitoring can flag the pattern, a cluster of scrap immediately following a changeover or a startup event, distinct from scrap scattered randomly through a run, which is a meaningfully different signal. Whether that startup scrap is expected and budgeted for, or a sign a setup process needs work, is still a judgment call for a person looking at the pattern, not something a sensor decides on its own.
What still needs a human
Laying all six out this way makes the actual split clear: modern monitoring is excellent at detecting that something happened and precisely when, and much weaker at knowing why on its own. A stop, a slow cycle, a scrap part, all of that shows up automatically the moment it happens. The cause behind it, a broken tool versus a bad program versus a material issue, still comes from someone who was there or who investigates after the fact.
That’s not a shortcoming to apologize for, it’s the correct division of labor. A system that tried to guess causes automatically would be inventing explanations for events it never actually witnessed, and an invented cause is worse than a plain “uncoded” stop waiting for a person to tag it. The downtime reason codes guide covers how to build a code list short enough that people actually use it to fill that gap, rather than defaulting to a meaningless catch-all.
Why the framework still holds up
It would be reasonable to expect a taxonomy built for manual TPM audits in the 1970s to feel dated once machines started reporting their own state automatically. It hasn’t, and the reason is that the six losses were never really about the measurement method, they were about naming six distinct ways a process loses capacity, in a way specific enough that each one points at a different fix. Automation changed how completely each loss gets captured, and how fast, not what the losses fundamentally are. A breakdown is still a breakdown whether a person wrote it down an hour later or a sensor logged it to the second. What automation adds is coverage, catching the four losses that a clipboard structurally couldn’t see well, minor stops, speed drift, unlogged startup scrap, and precise changeover timing, without changing the underlying six-way split those losses have always fit into.
Quick recap
- The six big losses split the same three OEE factors, availability, performance, quality, into six named, recognizable patterns
- Breakdowns and changeovers are caught precisely by a control watching run state, the cause still needs a human tag
- Minor stops are usually where an automated reading drops hardest compared to a hand-tracked number, because nobody was counting them before
- Reduced speed only gets caught accurately if the ideal cycle time it’s measured against is real, not padded
- Quality losses are only visible to a machine if they’re logged there, not caught downstream at final inspection
- Startup yield loss is a pattern a system can flag, distinguishing it from ordinary scrap, judgment calls the reason still needs a person