Key takeaways
Most factory floors have plenty of data. PLCs publish tag values on a sub-second cycle. SCADA aggregates and visualises them. ERPs receive production counts and consumption. Where things break down is between those layers: a stop on the line generates a tag transition at the PLC, becomes a "downtime event" in SCADA, gets summarised as "lost production" in the ERP, and none of those three representations agree on what the event was, when it started, or which asset it belongs to.
The result is that nobody can answer simple operational questions cleanly. "How much downtime did asset L3-PKG-02 cause yesterday?" has three different answers depending on which system you ask. The OEE tool, the CMMS and the ERP each have their own definitions, and bridging them by hand is what eats the maintenance manager's mornings.
The common temptation, especially in projects sold as "Industry 4.0 integration," is to pipe PLC data into the ERP. It looks like a simple integration. It almost always fails for three reasons.
PLCs emit thousands of tag transitions per minute. ERPs are designed to receive a few hundred records per day per plant. Pumping raw PLC data into an ERP either drowns the database or forces aggressive aggregation at the edge, and that aggregation is what destroys the resolution OEE and CMMS need.
The PLC knows tags. The ERP knows cost centres. Neither knows the asset hierarchy in the way maintenance does (line → station → asset → component). Without an explicit hierarchy in between, you cannot answer "which asset caused this stop" from ERP records.
PLC events are millisecond-precise. ERP events are usually day-precise. A stop that started at 14:03:22 and ended at 14:08:45 becomes "5 minutes of downtime on June 27" by the time the ERP sees it. That precision loss is the reason most ERP-based OEE reports are useless.
The fix is to insert one layer between the PLC/SCADA tier and the ERP. The layer has four jobs.
Every event, start, stop, reject, changeover, gets the same name in the same form everywhere. This is where the loss-class taxonomy from the article on manufacturing KPIs lives in practice. Without it, downstream analytics never stabilise.
The operational layer is the single source of truth for "what is an asset." Lines, stations, assets and components are defined here, mapped to PLC tags on one side and ERP cost centres on the other. When maintenance creates a work order, it points at an asset in this hierarchy, not at a tag and not at a cost centre.
Every event the layer stores is timestamped to one clock, usually UTC at the millisecond level, regardless of which PLC, SCADA system or operator interface produced it. Time-zone and drift issues are killed at ingest, not in dashboards.
The ERP gets the rolled-up, financially-shaped picture: shift production, scrap, downtime by reason, on a daily or shift cadence. The high-resolution detail stays in the operational layer where OEE, CMMS and root-cause analysis need it. See the related piece on root cause analysis for why that detail is the part that drives improvement.
A typical mid-market reference architecture:
The reason the operational layer needs to host both OEE and CMMS is that the asset hierarchy is shared. If OEE lives in one tool with its own hierarchy and the CMMS lives in another tool with a different hierarchy, the layer's whole point, one source of truth, is lost. A unified work-order management system sitting on the same data as the OEE engine avoids that drift by default.
The mistake plants make is starting with the ERP integration because it feels like the "real" deliverable. The right sequence is the opposite.
Starting with the ERP integration first guarantees rework, because the operational definitions are still in flux and every ERP record needs to be re-emitted as those definitions stabilise.
The operational data layer described above is exactly what Fabrico is: a single platform that hosts the asset hierarchy, the OEE event stream and the CMMS work orders against the same database, with edge connectors for the PLC side and scheduled exports for the ERP side. The reason we ship as a unified product rather than two separate ones is that the OT/IT gap collapses when OEE and CMMS share a hierarchy, and stays open when they do not. To see how it would look against your own line data, book a demo.
No. The operational data layer sits on top of the existing OT stack via an edge connector. The PLC/SCADA tier keeps doing what it does; the new layer just adds a normalised view above it.
A data lake without an operational data layer holds high-resolution tag data with no event semantics. You can build dashboards over it, but you cannot drive work orders, OEE calculations or root-cause analysis without first reconstructing the event vocabulary and asset hierarchy, which is exactly what the operational layer does. Skipping it just defers the problem.
If a plant already has an MES, the MES often holds part of the operational data layer's job, particularly the event vocabulary. The architecture works the same way: the MES feeds the operational data layer (or is the operational data layer, if it covers OEE and CMMS), which then rolls up to the ERP.
By the plant team that knows the assets, not by IT. The operational layer needs to make the hierarchy editable by maintenance and production engineers without a developer in the loop, or it drifts out of date within a quarter.
The event vocabulary. If the loss classes are not stable across lines, every analytic and every rule downstream is unreliable. Spend more time than feels reasonable on the taxonomy in week one.
Login
Blog
