In Short: What Is Hard About Manufacturing Data?
Getting operations and finance to agree. MES counts production events, finance counts what was invoiced, and scrap, rework, downtime classification and shift boundaries are defined differently in each. Joining the systems is engineering; making the numbers reconcile is a definitional exercise that has to happen first. High-frequency machine data is a separate problem, and mostly one of restraint.
Why OEE Never Matches Finance
Ask a plant manager and a finance director for last month's output and you will get two numbers. Both are correct by their own definitions, and neither will accept the other's.
The causes are consistent across manufacturers:
Different events. MES records what was produced. Finance records what was invoiced. Between them sit scrap, rework, samples, goods in transit and stock movements - each handled by a rule that exists somewhere and is written down nowhere.
Different time boundaries. A shift crossing midnight, a production day starting at 6am, and a finance period ending on the last calendar day are three different calendars. Any comparison across them needs an explicit rule.
Different identities. The product code in MES is not always the SKU in ERP. Work order numbering diverges. A batch in quality is not the batch in production.
This is why manufacturing reporting projects that start with dashboards fail. The joining is the project, and it is a conforming problem before it is a visualisation one.
The Conforming Layer Is the Work
In a Fabric medallion architecture, raw MES, ERP, quality and maintenance data lands in Bronze. The Silver layer is where a work order in one system becomes the same work order in another, where product hierarchies reconcile, and where time is normalised to a defined production calendar.
Budget for this properly. In our experience it is the majority of the effort in a manufacturing platform, and it is invisible in a demo - which is exactly why it gets underestimated.
Two rules that save rework:
Write the definitions down before building. What counts as downtime, how rework is treated, when a unit is "produced". Get operations and finance to sign the same document. This meeting is uncomfortable and it is the highest-value hour in the project.
Assume multiple sites. Site becomes a dimension carried through every layer from the beginning. Retrofitting multi-site after building for one plant is painful, common, and entirely avoidable.
High-Frequency Data: Mostly a Restraint Problem
Modern plants generate enormous volumes of sensor and machine data, and the instinct is to land all of it because storage is cheap.
Storage is cheap; capacity is not. Processing and querying full-resolution telemetry consumes compute continuously, and most of it answers no question anybody is asking.
A more useful default:
- Aggregate at the edge or in the historian. Land minute or shift-level summaries rather than every reading.
- Keep raw data only where a requirement justifies it - a specific quality investigation, a model being trained.
- Use Real-Time Intelligence where operations genuinely act on live data - line stoppage alerts, andon boards - not as a default for reporting.
Our capacity sizing guide covers the consumption side. The short version: telemetry volume is one of the fastest ways to outgrow a SKU without gaining anything.
What to Build First
Production performance reconciled to finance. It is the argument that recurs most often, it forces the definitional work early, and it produces a number both functions accept - which is the thing that makes everything afterwards easier.
Not predictive maintenance. It is the most interesting option and the worst first project. It needs historical depth you may not have cleanly, model validation time, and - critically - trust in the underlying data that has not been established yet. A predictive model built on unreconciled data produces confident predictions nobody believes. Come back to it in phase three.
Keep Your Operational Systems
Worth stating plainly, because it occasionally gets muddled: MES, SCADA and historian systems run the plant. They should keep running it.
Fabric consumes from them downstream. Nothing about an analytics platform requires touching the systems that keep production moving, and any proposal that does is a far larger and riskier programme than the one you scoped.
Where Solv Systems Comes In
We build Fabric platforms for manufacturers, and the pattern is consistent: the engineering is tractable, the definitions are the project.
We run the operations-and-finance conversation early and write down what is agreed, build the conforming layer properly so work orders and products mean one thing, and design for multiple sites from the first plant. Then reporting on top - production performance that reconciles, with the interesting analytics arriving once the foundation is trusted.
Sources and Further Reading
Frequently asked
Because they measure different things from different sources and nobody has reconciled the definitions. MES counts production events; finance counts what was invoiced. Scrap, rework, downtime classification and shift boundaries are all defined differently in each. The fix is a definitional exercise before it is a technical one.
Yes, though not every stream belongs in your analytics platform. Real-Time Intelligence handles genuine streaming where operations need it. For most reporting, aggregating at the edge or in the historian and landing summarised data is cheaper and just as useful - full-resolution sensor data rarely earns its capacity cost.
Through a conforming layer. The two systems disagree about products, work orders and time boundaries, so the Silver layer of a medallion lakehouse is where a work order in MES becomes the same work order in ERP. That mapping is the project's real content.
Usually production performance reconciled to finance - it is the argument that recurs most often and the one that proves the platform. Predictive maintenance is more interesting and a worse first project, because it needs history and trust you have not yet established.
No. Those systems run the plant and should keep doing so. Fabric consumes from them downstream. Anyone proposing to replace operational systems as part of an analytics project is proposing a much larger and riskier programme than the one you asked for.
Assume it from the start rather than retrofitting. Site becomes a dimension carried through every layer, and each site's systems land through their own ingestion path into a common conformed model. Retrofitting multi-site after building for one plant is painful and common.
