OEE Data Governance: The Definition Sheet for Comparable Cross-Plant Numbers

Everyone agrees plants should use the same OEE definitions. Almost nobody says what those definitions should be. The advice stops at "agree with your team", which is where the argument starts rather than ends. Four choices decide whether two plants' numbers can be compared at all: whether planned production time includes breaks and shift handover, whether the quality input counts rework or only scrap, how the ideal cycle time is established, and how many machine states you recognise. This is the definition sheet: a recommended answer for each, what that answer costs you, and a one-page standard you can publish.

OEE data governance is the set of four definitional boundary decisions—planned production time scope, quality input basis, ideal cycle time method, and machine state count—that must be standardised before cross-plant OEE numbers can be compared at all.

The definition sheet at a glance

Planned production time: breaks and handover

Recommended: exclude scheduled breaks, include shift handover and start-up.

Planned production time is the denominator of availability, so every judgement about what belongs in it moves every OEE figure downstream. Existing guidance, including Guidewheel's own material on standardizing uptime and OEE across sites, correctly says the boundary must be agreed. It does not say where to draw it. Here is a defensible answer and what it costs.

Scheduled breaks: exclude. A break that appears on the shift pattern is not time the plant intended to produce, and counting it against availability produces a number that penalises a plant for its own working agreements. Exclude it and availability reflects the time you actually planned to run.

What this costs you: the OEE figure no longer answers "what fraction of the clock did we convert", which is sometimes what a finance audience wants. If that question matters, report calendar-based utilisation alongside, as a separate metric with a separate name. Do not blend them.

Shift handover and start-up: include. This is the more contested call and the more important one. Handover loss is controllable. Overlapping crews, staggering the changeover, starting the line before the full team is present: these are decisions, and excluding handover from planned production time makes the loss invisible to the metric that drives improvement. Guidewheel's 2026 Factory Uptime Report describes shift-to-shift variability of 57% on the same changeover with the same crew, which is precisely the kind of variation that only shows up if the time is inside the denominator.

What this costs you: availability reads lower than at plants that exclude it, and your number will look worse against an external benchmark computed differently. Accept that. An internally honest metric beats a flattering one.

Planned maintenance windows: exclude, and report separately. Excluding them is conventional. The risk is that maintenance burden then disappears from view entirely, so make the separate report a standing item rather than an appendix nobody opens.

The quality input: scrap only, or scrap plus rework

Recommended: count scrap plus rework as defective, provided you can capture rework. If you cannot, use scrap only and label the metric accordingly.

The quality factor is good units divided by total units produced. The whole question is what "good" means, and the two defensible answers give materially different numbers.

Scrap only treats a part that was reworked into conformance as good, because it eventually shipped. This is easy to capture, because scrap is usually already counted for material accounting.

Scrap plus rework treats it as defective, because the first pass did not produce a conforming part. This is the truer reading of what OEE measures, which is the effectiveness of the process as it ran, not the effectiveness of the process plus the repair activity afterwards.

The argument for including rework is that excluding it hides real cost. Rework consumes labour, machine time, energy and often a second setup, and none of that appears anywhere in an OEE figure computed on scrap alone. A plant can improve its rework rate substantially and see no movement in OEE, which teaches the organisation that OEE does not care about rework.

What the recommended choice costs you: you need rework capture at the machine or the line, which many plants do not have. Building it is a real project. If you cannot, do not fudge it. Use scrap only, name the metric "OEE (scrap basis)" in every report, and record the limitation in the standard. A clearly labelled narrower metric is far better than an unlabelled one that different sites compute differently.

The rule that matters more than the choice: every site must use the same basis. Two plants, one counting rework and one not, produce OEE figures that cannot be compared at all, and the difference will be read as a performance gap.

Ideal cycle time: validating rather than asserting

Recommended: a validated stable-run observation, per product and machine, reviewed on a fixed cadence and owned by a named role.

This article governs the agreed value. How to choose the baseline in the first place is a separate discipline covered in ideal versus actual cycle time, and Guidewheel's cycle time optimization guide covers the underlying formulas. What matters here is what happens after a number is chosen.

Ideal cycle time is the single largest source of non-comparable OEE across sites, and it is the one least often governed. Two plants running identical machines on identical products will report different performance figures if one set its ideal from the machine nameplate and the other from observed capability. Neither is lying. Nobody wrote down which basis to use.

Three governance requirements:

Record the basis, not just the number. Every ideal cycle time in the system carries the method used to derive it, the date, the product and machine it applies to, and who approved it. A number without provenance will be challenged in the first review where the result is unwelcome.

Set a review cadence and a change trigger. Annually as a floor, plus a mandatory review whenever tooling changes, the material specification changes, or the machine is rebuilt. Without a trigger, ideals drift out of date silently and the performance factor slowly becomes fiction.

Require corporate sign-off on the method, not on each value. Plants set their own values; the centre governs how they are derived. Reversing that produces either a bottleneck or a rubber stamp.

What this costs you: real work up front, and a standing review obligation. The alternative is a performance factor that nobody defends, which in practice means an OEE number nobody uses.

Machine states beyond running, stopped and idle

Recommended: seven states. Running, idle, down, warm-up, setup and changeover, starved, blocked.

Three states are not enough to roll up meaningfully, and fifteen are too many to be completed accurately. Seven is a working compromise, and the additions each earn their place.

Warm-up separates energised-but-not-yet-producing from producing. Without it, thermal assets report production time they did not deliver, and the performance factor absorbs the error.

Setup and changeover is usually the largest controllable block in the plant. Folding it into general downtime makes the biggest improvement opportunity invisible, which is a strange thing for a measurement system to do.

Starved and blocked only exist on coupled lines, and they change the meaning of every machine-level number. A machine that is starved is available and not producing through no fault of its own. Counting that as idle attributes a line problem to an asset, and it is the most common reason a machine-level OEE figure misleads. The consequences for the unit of analysis are covered in machine-level versus line-level OEE.

The count is the constraint, not the concept. Every state you add costs completion accuracy at the point of capture, because someone has to distinguish them in a few seconds. Add an eighth only if you can name the decision it changes. If you cannot, it is a reporting preference rather than a state.

What this costs you: more configuration up front, and more training. What it buys is that "downtime" stops being one undifferentiated number that everyone interprets differently.

Note that reason codes are a separate layer sitting underneath these states, governed differently, and covered in standardized versus local downtime reason codes. States are the enterprise skeleton; reasons carry the local detail.

Publishing the standard

One page, one owner, one review cadence. If it runs longer than a page, plants will not read it, and a standard nobody reads is a suggestion.

What the page contains:

1. The four boundary decisions above, each stated as a rule with its exclusion.
2. The minimum stop duration that requires a reason.
3. The seven machine states with one-line definitions.
4. The quality basis, named explicitly in the metric label.
5. The ideal cycle time method, with the provenance fields required for each value.
6. The named owner of the standard, and the named owner of each metric definition.
7. The review cadence and the change triggers.
8. The escalation path when a plant disagrees.

Item eight is not optional. A site will object, usually with a legitimate process reason. Without a route to raise it, they will comply nominally and deviate quietly, which is worse than an open disagreement. The route should be able to produce one of three outcomes: the standard changes, the site gets a documented exception with its metrics labelled accordingly, or the site complies. All three are acceptable. Silence is not.

What this does and does not fix. It makes numbers comparable, which is the precondition for learning anything across sites. Penn Color's case study, where Guidewheel reports 30 to 35% higher equipment utilization across its U.S. plants alongside a 50% uptime increase on the pilot asset group, is the kind of cross-site result that only means something if the sites were measuring the same way to begin with.

What it does not fix is the underlying measurement. If machine state is still being typed in from memory, a definition standard governs the interpretation of unreliable inputs. Automatic state capture removes that variance, which is Guidewheel's scope and the limit of it. Definitions remain a human agreement, and no software settles one.

Frequently asked questions

About the author