Two plants can post the same OEE number for the exact same machine running the exact same schedule, and mean different things by it, because one of them counts changeover as downtime and the other counts it as scheduled non-production time that never touches the availability calculation at all. Neither plant is lying. They drew the planned versus unplanned line in a different place, and that one decision moved the number before anyone looked at a single stopwatch.
Getting this line right matters more than most of the numbers built on top of it, because everything downstream, availability, the Pareto, the maintenance backlog, inherits whichever choice got made here.
What the distinction is actually for
Unplanned downtime is a failure to investigate. Something broke, something jammed, something ran out, and none of it was on the schedule. Planned downtime is a decision already made in advance: a changeover between products, a preventive maintenance window, a scheduled break. The distinction exists because the two categories deserve completely different management attention. A breakdown gets root-caused. A changeover gets its setup process improved instead, because the changeover was not a failure to begin with. It was the plan working as designed.
Where changeovers belong
A changeover is planned downtime almost everywhere it’s counted seriously, because it’s a deliberate stop, decided in advance, to switch a machine from one product to another. Treating it as an unplanned failure to investigate misses the point of what it is, and treating it as invisible, excluded from every number entirely because “it’s just changeover,” misses the point just as badly in the other direction, because a changeover running long still costs real capacity whether or not anyone’s calling it a failure.
The right place for a changeover is inside the downtime accounting, coded like any other reason, but tracked and analyzed on its own terms: median duration, how consistent it is, whether it’s trending better or worse, compared against a routing’s setup-time standard. That keeps it visible in the numbers everyone’s already watching without pretending it’s the same kind of problem as a bearing failure. Changeover Time You Can Actually Cut covers measuring and improving it directly.
Where PM windows belong
Preventive maintenance is planned by definition, a component serviced on a schedule before it fails, and the work itself belongs in its own due list, separate from the downtime queue that’s driven by actual stops. That separation matters because the two lists answer different questions. A downtime queue full of real stops needing a reason is a reactive list, work discovered by something going wrong. A preventive task list is proactive, work scheduled regardless of whether anything’s currently broken, and mixing the two makes both harder to manage, a tech can’t tell at a glance whether they’re looking at something that needs fixing now or something that’s just due on the calendar.
Whether a PM window itself counts against a machine’s downtime total is a policy choice worth making explicitly instead of by default. Some shops exclude scheduled PM time entirely, treating it the same as a planned non-production window. Others count it, on the logic that a machine down for maintenance is still a machine not producing, and the schedule should reflect that cost either way. Either choice is defensible. What’s not defensible is leaving it undecided, so half the plant assumes PM time is excluded and the other half assumes it’s counted, and the OEE number means something different depending on who’s reading it.
Where breaks belong
Scheduled breaks, lunch, shift changeover time, a planned line stop for a safety meeting, sit outside the availability calculation entirely on most floors, treated as non-production time the machine was never expected to be running during in the first place. That’s a reasonable default: counting a lunch break as downtime makes every OEE number look artificially worse for no useful reason, since nobody was ever planning to run during that window.
The trap is letting that same logic absorb time that shouldn’t get the same pass, a little more each month. A quick meeting that runs fifteen minutes over deserves to show up somewhere as lost run time even if it started as a scheduled break, and a shop that never revisits which windows count as “break” risks a slow inflation of excluded time that flatters the availability number without reflecting an actual improvement on the floor.
A common trap: reclassifying to flatter the number
Every plant eventually faces the temptation to move a stop from unplanned into planned after the fact, because the availability number looks better that way. A breakdown that keeps happening on the same machine gets rebranded “planned maintenance” on the report, even though nobody scheduled it, nobody planned it, and it’s exactly the same failure mode as last month’s. That move makes the OEE slide look better for one meeting and makes the underlying problem invisible for every meeting after it.
The tell is usually in the timing. A stop classified as planned before it happens, sitting on a calendar or a work order in advance, is legitimately planned. A stop reclassified as planned after the fact, once someone’s decided the unplanned number looks bad, is a soft 85% wearing a real number’s clothes, the same failure mode covered in Is My OEE Good or Bad? applied to the planned versus unplanned line specifically instead of the standard behind performance. A number built that way tells you less than a plainly ugly one would have.
Why the line has to be documented, not assumed
The actual damage from an inconsistent planned versus unplanned line rarely shows up as one dramatic error. It shows up as a slow erosion of trust in the numbers, because two people looking at the same OEE report and getting different answers to “is this good” stop believing the report is measuring anything consistent. A plant comparing this month’s availability to last year’s needs the classification rules to have stayed the same in between, or the comparison is measuring a policy change dressed up as a performance change.
The fix costs almost nothing: write the rule down. What counts as planned, what counts as unplanned, and where the shift-break window starts and ends, stated once, applied the same way every time a stop gets coded, and revisited on a set schedule instead of whenever someone happens to notice a discrepancy. A downtime reason list that’s already been trimmed to be usable, the discipline covered in Downtime Reason Codes Operators Will Actually Use, is the natural place to encode this, tagging each reason as planned or unplanned once at the source instead of leaving it to individual judgment every time a stop gets coded.
Quick recap
- Unplanned downtime is a failure to investigate. Planned downtime is a decision already made, and it needs a different kind of attention.
- Changeover belongs inside the downtime numbers, coded like any other reason, tracked on its own terms instead of root-caused like a failure.
- PM work belongs on its own due list, separate from the reactive downtime queue, and whether it counts against availability should be a stated policy, not an assumption.
- Scheduled breaks sit outside availability by default. Watch for that exclusion slowly absorbing time that should actually count.
- Write the planned versus unplanned rule down once, tag it at the reason-code level, and keep it stable so comparisons across time actually mean something.