The problem with aggregate metrics
OEE is a useful metric. It tells you what share of planned production time was used productively. It captures availability, performance, and quality in a single number. It is widely understood and broadly comparable across facilities.
It is also, by design, an aggregate. And aggregation hides the things most worth seeing.
When a line scores 78% OEE, that number tells you something is wrong. It does not tell you which 22% of production time is being lost, in what pattern, at what frequency, or whether the losses are clustered in one machine area or distributed across the line. To find that out, you need to look further.
What ordinary reporting misses
The reporting layer most factories use is built around two categories of loss event:
Planned stops: scheduled maintenance, changeovers, breaks, and other events recorded in advance.
Alarm-level failures: unplanned downtime events significant enough to trigger a stop and an alarm record.
Both of these categories are well-handled by standard SCADA, MES, and ERP reporting. The problem is that a large share of production loss falls outside both categories — in events too small and too brief to trigger an alarm, too irregular to plan around, but frequent enough to accumulate into significant throughput reduction over a shift.
A machine that stops for 90 seconds, 40 times a shift, loses an hour of production. If each individual stop is below the alarm threshold, none of those stops appears in a failure report. The cumulative loss, however, is real.
This is the microstop problem.
Low-speed drift: the invisible second category
Microstops are one part of the picture. The other is speed loss that never registers as a stop at all.
A machine running at 85% of its rated speed is not stopped. It does not trigger an alarm. It appears in the production record as operational. But it is producing significantly less than it should be — and if that speed deviation has been present for three shifts, the accumulated loss is substantial.
Low-speed drift is harder to detect than microstops because it requires a comparison: actual speed against rated speed over time, at the machine level. Most reporting systems do not produce this comparison automatically. And without it, the loss stays invisible.
Why these losses are not fixed by better reporting alone
The answer is not simply to add more reports or lower alarm thresholds. Both approaches tend to produce alert fatigue and data overload without delivering actionable insight.
The question is not whether to log more events — it is whether the signal collection and analysis approach is designed to surface pattern-level losses rather than only event-level losses.
Microstops and low-speed drift are not one-time events. They are patterns. They tend to occur in clusters — at the same machine, in the same time window, under similar conditions. Surfacing them requires a different analytical approach than the one that identifies and records individual failure events.
What changes when you can see these patterns
The practical value of seeing microstop clusters and speed deviation patterns is not primarily in the numbers themselves — it is in the structure they provide for investigation.
When a factory team can see that 40% of their production loss on Line B comes from a specific microstop cluster that occurs in the first two hours of the night shift, they have a specific, investigable problem. When they can see that the speed deviation on Machine 7 began on a particular date and has been consistent since, they have a starting point for root cause analysis.
The loss was always there. The visibility changes what can be done about it.
---
Factory Cortex is designed to surface these patterns — bottleneck losses, microstop clusters, low-speed drift — using existing signal sources. The first step is always narrow: one line, one machine area, one well-defined loss pattern.