Ask most manufacturing executives what a smart factory initiative involves and they'll describe the visible parts: IoT sensors on equipment, real-time dashboards, predictive maintenance, maybe an AI copilot for engineers. Ask the engineers actually running the project six months in, and you'll get a different answer. They'll tell you the real project — the one that consumed most of the time and budget — was getting data out of a dozen disconnected systems and into a shape where any of the visible parts could actually work.
This is the pattern behind a surprising number of stalled or underwhelming smart factory initiatives. The technology on the roadmap wasn't wrong. The data problem underneath it was never properly scoped.
Why the Data Problem Stays Hidden Until It Isn't
The data problem is easy to underestimate for a specific reason: most of a plant's data already "exists." There's an ERP system tracking orders and inventory, an MES tracking production, historian databases logging sensor readings, a PLM system holding design and quality records, and probably a quality management system with its own inspection data. On paper, the data a smart factory initiative needs is already being captured somewhere.
The problem shows up once someone tries to actually connect it:
It's fragmented across systems that don't share a common schema. A part number in the ERP system might not match the identifier used in the MES for the same part. Equipment IDs in the historian database might not correspond cleanly to the asset records in a maintenance system. None of this is unusual — it's the normal byproduct of systems bought at different times from different vendors, often integrated only loosely if at all.
It's inconsistent at the point of entry. Free-text fields, inconsistent units, operators recording the same event differently depending on shift or plant, and years of accumulated exceptions to whatever standard once existed. Data that looks structured in a database schema is often, functionally, half-structured at best.
It has different update frequencies and formats. Historian data streams in continuously at high frequency. ERP transactions post in batches. Quality inspection records might be entered manually, hours after the actual event. Any initiative that wants to correlate these — to say "this quality issue happened during this production run, on this equipment, sourced from this supplier lot" — has to reconcile timing and format mismatches that aren't visible until someone tries to do it.
Historical data quality often doesn't match current expectations. A predictive maintenance model needs years of historical sensor and failure data to train on. That historical data was often captured under looser standards than current data governance would allow, which means a chunk of it needs to be cleaned, re-labeled, or discarded before it's usable.
Where This Bites Hardest
A few smart factory use cases make this problem impossible to ignore, because they simply don't function without solving it first:
Predictive maintenance. Requires reliably joining sensor data, maintenance history, and failure events across systems that were never designed to be joined. Projects frequently discover, midway through, that the historical failure labels needed to train a model are inconsistent or incomplete.
Cross-system quality traceability. Tracing a defect back to a specific supplier lot, production run, and machine setting requires data from quality, MES, and ERP systems to line up on shared identifiers — which is often the first time anyone has tried to actually connect them.
Any generative AI application grounded in plant data. This is where the data problem intersects directly with the current wave of interest in Generative AI in Manufacturing. A natural language search tool, a design assistant, or an anomaly explanation system is only as good as the data it's grounded in — and if that data is fragmented, inconsistent, or poorly labeled across source systems, the AI layer inherits every one of those problems, just with a more articulate way of getting the answer wrong.
The Work That Actually Fixes This
Solving the hidden data problem isn't glamorous, and it rarely shows up as a headline feature in a smart factory pitch deck, but it's the work that determines whether everything built on top of it actually functions.
A canonical data model across systems. Establishing a single, agreed-upon way to identify equipment, parts, and processes across ERP, MES, PLM, and quality systems — even if the underlying systems keep their own internal identifiers — so downstream analytics and AI tools have something consistent to join on.
An integration layer, not a pile of point-to-point connections. Middleware (iPaaS platforms, custom ETL pipelines, or an enterprise service bus) that normalizes data as it moves between systems, rather than each new initiative building its own bespoke connection to each source system.
Data governance that survives contact with the shop floor. Standards for how new data gets entered, labeled, and validated going forward — because fixing historical data without addressing how new data gets created just recreates the same problem in a few years.
Honest historical data audits before committing to a timeline. Knowing, before a project is scoped, how much historical data is actually usable versus how much needs cleanup or is simply not salvageable, changes what's realistic to promise stakeholders.
Why ERP Sits at the Center of This More Often Than Expected
A lot of smart factory data problems trace back to the ERP system, not because ERP is poorly built, but because it's usually the system of record for the identifiers — part numbers, work orders, supplier records — that everything else needs to reference to make sense. When ERP data is inconsistent, poorly integrated with MES and quality systems, or simply hasn't been configured to support the level of granularity a smart factory initiative needs, that gap surfaces in every downstream project that tries to build on top of it.
This is a large part of why ERP Consulting for Manufacturers so often turns out to be the unglamorous but decisive piece of a smart factory roadmap. It's rarely framed that way at the outset — most initiatives start with a conversation about sensors, dashboards, or AI — but the projects that go smoothly are consistently the ones where the ERP data foundation and its integration points with MES, PLM, and quality systems were addressed early, rather than discovered as a blocker partway through a pilot.
What This Means for Planning the Next Initiative
A few practical implications for anyone scoping a smart factory project:
- Budget real time and money for data integration and cleanup, not as a footnote to the technology rollout but as a comparable-sized workstream in its own right.
- Audit the ERP and MES data foundation before committing to an ambitious AI or analytics roadmap. The visible technology is rarely the constraint; the data underneath it usually is.
- Start with a use case narrow enough to reveal the data problem without betting the whole initiative on solving it perfectly first. A contained pilot exposes fragmentation and inconsistency issues faster and more cheaply than a broad rollout.
- Treat data governance as ongoing, not a one-time cleanup. Without standards for how new data gets captured, the fragmentation returns.
The smart factory initiatives that deliver on their promise are rarely the ones with the most ambitious technology stack. They're the ones that took the unglamorous data foundation seriously before building on top of it — because every dashboard, every predictive model, and every AI assistant is ultimately only as reliable as the data feeding it.
