Why Every Department Has Its Own Version of the Truth

The data has always been in your plant. What changed is the cost of finally pulling it into one place — and what that newly affordable consolidation makes possible.

When the numbers don't agree

Every plant has the conversation. Operations says first-pass yield was 94.2% last week. Finance has it as 91.8%. Both can show their work. Both are pulling from different systems, defined slightly differently, refreshed on different cadences. Neither is wrong. They're computing different things and calling them the same thing.

That conversation is a symptom. The underlying problem is that the plant's data lives in seven systems that don't talk to each other — a historian, an MES, an ERP, a quality module, a maintenance ticket system, a few spreadsheets, and an OPC server that one of the night engineers cobbled together in 2019. Each one is the source of truth for someone. None of them is the source of truth for everyone.

This piece is about what changed in the last three years that finally makes this fixable — and about what most plants get wrong when they try.

What "modern data platform" actually means

The jargon hasn't done this category any favors. Cloud data warehouse. Lakehouse. Unified analytics platform. Data fabric. By the time the slides come out, the actual concept has been buried under terminology meant to differentiate one vendor from another.

Strip it down. A modern data platform is a single destination where every operational data source in your plant lands, gets cleaned and standardized, and becomes available to anyone who needs to ask a question of it. The historian, the MES, the ERP, the operator-entry forms, the OPC servers, the maintenance system. All of them, in one place, in formats that talk to each other.

That single destination is what Microsoft Fabric is — for plants already in the Microsoft ecosystem. It's also what AWS, Databricks, and Snowflake offer for plants in those ecosystems. The platform is, at this point, a commodity decision. The work that determines whether it's worth doing isn't about which platform you pick.

What changed (and why now)

Three things have made plant data consolidation dramatically more feasible than it was five years ago.

The platforms collapsed in cost. The data warehouse build that cost a multi-plant manufacturer three to seven million dollars and twelve to eighteen months in 2019 is, today, a four-to-six month effort at a fraction of the licensing and infrastructure cost. The expensive parts — the storage, the compute, the ETL tooling — have all consolidated into integrated services. The cost gravity has moved from infrastructure to people and outcomes.

The connectors caught up. Historian-to-cloud, MES-to-lake, OPC-to-anything used to require months of custom development. Today there are well-trodden patterns and supported connectors for every major OT data source. You're no longer building the bridge; you're crossing it.

The reporting layer stopped being a separate project. Power BI in the Microsoft stack, equivalent tools in others — the dashboards, the alerts, the ad-hoc exploration — all consume from the same platform without their own pipelines. The 2018 architecture had a separate BI project after the data warehouse went live. The 2026 architecture doesn't.

Why most plants still get this wrong

Cheaper doesn't mean easier. The plants that haven't made the transition successfully have done so for predictable reasons.

They pick the platform before they pick the question. A consolidated data platform is not a project. It's an enabler. Without a specific decision the platform is meant to inform — yield improvement on a specific line, energy cost per unit, schedule adherence, OEE benchmarking across sites — the project becomes a tooling install with no destination. Twelve months later there's a lake, dashboards nobody opens, and a bill nobody can defend.

They underestimate the cleanup. Plant data is not warehouse data. Timestamps drift. Tags get renamed. Sensors get swapped and the new device reports in different units. The historian quality code that says "Good" today meant something different in 2014. Consolidating this material into a platform that produces trustworthy answers is real engineering work — the cost of the data quality layer is usually larger than the cost of the platform itself.

They forget governance. A unified platform without owned data definitions becomes a unified platform with conflicting answers. The "first-pass yield" tile on the operations dashboard and the "first-pass yield" line on the finance report still don't match — they just now both live in Fabric. The decision rights about what each metric means, where it comes from, and who can change it have to be agreed before the platform produces value. Most plants treat this as a phase-two concern. Most plants regret it.

The pattern that works

The successful Fabric implementations we've seen share a recognizable shape.

They start with one decision. Not "consolidate plant data." A specific operational decision that's hard to make today because the relevant data is fragmented — and a willingness to be measured against whether the new platform makes that decision easier. The platform follows the use case.

They sequence the data sources by value, not by ease. The temptation is to start with the data that's easiest to get out — usually the ERP. The plants that ship start with the data that matters most to the use case, even when it's the hardest to extract. Solving the hard one first means the platform delivers value early; the easy ones get added later because the team has built the muscle.

They build the governance and ownership at week one, not month six. Every metric that shows up in the platform has a documented definition and an accountable owner. Every data source has a steward whose job it is to know when something changes upstream. Plants that defer this work end up with a platform that produces faster answers and the same disagreements.

What an executive should ask

Three questions worth asking before approving a data platform investment.

"What decision can't we make today because the data is in too many places?" If the answer is "we'd like to know more," the project doesn't have a destination. If the answer is "we can't trust our weekly yield numbers across sites," there's a real outcome to engineer toward — and a clear way to know if the project worked.

"Who owns the definition of our top ten metrics a year from now?" First-pass yield, OEE, scrap rate, energy per unit, on-time-in-full. If nobody can answer, the platform will produce faster disagreements, not better answers. The right answer involves a named human and a written definition.

"What is our partner doing in months one through three?" If the answer is "installing the platform," the work is in the wrong order. If the answer is "scoping the use case and surveying the data sources," the project is on the pattern that ships.

Where this is going

For most of the last decade, the question for plants was whether a unified data platform was worth the cost. The answer was often "not yet" — and given the economics at the time, that was a defensible position.

The economics have changed. The platforms have matured, the connectors are commoditized, and the projects that get done well are predictable in their shape. The question is no longer whether to do this. It's whether to do it before the next budget cycle or the one after.

The plants that figure this out first don't get a magical operating advantage. They get something more durable: a single set of numbers everyone agrees on, decisions that move from quarterly to weekly because the data finally supports them, and an analytics layer that compounds in value as the plant adds use cases on top of it.

If you're staring at a Fabric proposal and trying to figure out whether to start with platform or use case, that's the conversation we like having. Talk to us →