Where Should OEE Data Live: SCADA, Historian, MES, or BI?

Stop asking which platform should own OEE and assign ownership field by field. The argument recurs because both sides are partly right: a historian genuinely holds better time-series depth, an MES genuinely owns order and genealogy context, and a visibility layer genuinely produces machine state without manual entry. The useful question is narrower. For each field the business reports on, which system is authoritative, and which systems merely display a copy? Answer that once, write it down, and most of the cross-site reporting disputes disappear. This article supplies the matrix, then the minimum viable architecture it implies.

OEE data should not live in one platform. Each underlying field — control tags, machine state, order context, rollups — needs one authoritative owner, with every other system deriving from it and labelling itself as derived.

The ownership question at a glance

Why "which platform" is the wrong question

Because two systems can both be correct about different fields, and the platform framing makes that impossible to express.

The usual version of this debate is MES against IIoT platform, and it has been argued well elsewhere, including in Guidewheel's own MES versus IIoT platform comparison. That piece sets out the functional split clearly: an IIoT platform owns real-time machine state such as uptime, downtime, cycle time and production, while an MES owns work orders, scheduling, recipes and traceability. This article is not going to relitigate that. If the platform question is what you came for, read that one.

What that comparison does not provide, and what almost no vendor material provides, is a field-by-field ownership matrix or a rule for reconciling the fields both systems can plausibly claim. It draws the functional boundary and stops short of the governance one.

That gap is where the actual disputes live. Nobody argues about whether the MES should hold work orders. They argue about downtime: the MES has a downtime field, the historian has state changes, the monitoring platform has measured stops, and three different numbers reach three different reports. Each system is behaving correctly. The organisation never said which one was authoritative.

The same happens with counts, with cycle time, and with the published OEE figure itself. The platform question cannot resolve any of them, because the answer is not one platform. It is one owner per field, written down.

So the useful exercise is to enumerate the fields and assign them.

The five field classes

Group your fields into five classes before assigning anything. Most ownership arguments dissolve once the class is named, because the natural owner becomes obvious.

1. Raw control tags and setpoints. What the control system holds at source: valve positions, setpoints, drive states, process values. Owner: the control system. The failure when owned elsewhere is a duplicated tag model that drifts, so that two systems disagree about a value neither of them originated.

2. Long-horizon time series. The same signals retained at resolution over months or years for trending and analysis. Owner: a historian, where one exists. The failure is asking a dashboard tool to be an archive, which works until someone needs eighteen months of data at one-second resolution.

3. Machine state and production context. Run, idle, down, stop duration, stop frequency, downtime reason, cycle counts. Owner: the visibility layer, because these are produced automatically from the machine signal rather than entered by a person. This is Guidewheel's scope and nothing beyond it. The failure when owned elsewhere is manual entry, which produces a number nobody defends in a meeting.

4. Order, job, quality and genealogy records. Which job, which lot, which inspection result, which disposition. Owner: MES or the quality system. The failure is inferring job context from machine signals, which produces plausible and wrong attribution.

5. Management reporting and rollups. The OEE figure that reaches the board pack, cross-site comparisons, trend reporting. Owner: BI, reading from the owners above rather than recalculating from raw inputs. The failure is every system publishing its own OEE, which is how an organisation ends up with four numbers and no answer.

The classes are clean. The trouble is that a handful of fields sit near a boundary.

Reconciling overlaps

Four fields are genuinely contested. Settle them with one rule: one system is authoritative, every other system derives and labels itself as derived.

Part counts. The control system may count, the monitoring platform may infer cycles, the MES may hold reported production, and the ERP may hold what was booked. Make the authoritative source the one closest to a verified good part, which is usually the MES or the quality-gated count, and let the others be operational indicators rather than the reported figure.

Downtime duration. Monitoring measures it from machine state; the CMMS records it from work orders; the MES may have a field somebody fills in. Monitoring should be authoritative, because it is the only one measured rather than recalled. The CMMS keeps the maintenance record without claiming to be the downtime total.

Cycle time. Both the control system and the monitoring layer can produce it. Pick by use: if it feeds a process decision, the control system; if it feeds OEE performance, the monitoring layer, using the ideal cycle time governed under your definition standard.

The published OEE number. Only one system computes and publishes it. Everything else displays that value or displays nothing. This is the single most valuable line in the matrix, and the one most often left unassigned.

Write the rule down in this form: field, authoritative system, derived systems, reconciliation frequency, owner of the dispute. The last column matters. When two numbers disagree in month three, someone has to decide, and naming that person in advance turns a credibility crisis into a five-minute conversation.

With ownership settled, the architecture largely designs itself.

Minimum viable architecture

Two versions, because the right answer changes with site count.

One plant. You need less than most vendors will propose. The control system holds its tags. A visibility layer produces machine state, downtime and reasons across every asset including the unintegrated ones. The ERP or MES holds the plan and the order context. One reporting surface reads from those and publishes the OEE figure. A historian is genuinely optional at this scale unless you have a process requiring long-horizon trending at resolution, and buying one before you need it is a common and expensive reflex.

Many plants. The additions are governance rather than technology. The same field-ownership matrix applies at every site, which is the point. What changes is that the definitions behind the fields must be identical, or the rollup is arithmetic performed on incomparable inputs. That is a separate discipline, covered in the OEE data governance definition sheet, and Guidewheel's guidance on standardizing uptime and OEE across sites covers the surrounding rollout considerations.

Two rules keep a multi-site architecture honest. First, no site may publish a metric using a local definition; if a site needs a local variant, it gets a differently named metric. Second, the rollup reads from the same authoritative field at every site, not from each site's local report. Rollups built on local reports inherit every local deviation invisibly.

For the ERP edge of this, connecting shop-floor data to ERP covers the integration patterns.

What remains is to be precise about the one box in the diagram this article is qualified to speak for.

Where Guidewheel sits

One box: machine state, downtime reason and the operating metrics derived from them, on every powered asset.

That is the whole scope, and being precise about it is more useful than claiming more. Guidewheel is not a historian and should not be asked to retain process signals at resolution for years. It is not an MES: no work orders, no scheduling, no recipes, no genealogy. It is not a BI tool, and a mature organisation will read its outputs into whatever reporting surface the business already uses. It holds no process tags and has no control authority.

What it is good for in this architecture is the field class that is otherwise produced by hand. In most plants, machine state and downtime reason are the only inputs to OEE that get typed in rather than measured, which is precisely why the resulting number is the one people argue about. Moving that class to automatic capture removes the largest single source of variance in the calculation, and it does so without a controls project, because the sensor reads the power conductor rather than the control system. Pricing starts at $15,000 per year including the first 10 machines.

The honest limit is worth restating: automatic capture fixes the measurement, not the definitions. Two plants can both measure machine state perfectly and still produce incomparable OEE if they disagree about whether breaks count as planned production time. Software does not settle that, and no vendor should tell you otherwise.

One practical consequence of that scope: if your matrix assigns machine state to a system that gets it from manual entry, the matrix is describing an ownership arrangement rather than a measurement improvement, and the downstream numbers will not become more trustworthy.

For the product scope in full, see the FactoryOps overview.

Frequently asked questions

About the author