Ask a new manufacturing engineer to explain OEE, SPC, or the ISA-95 model, and most can give you a decent answer within their first year on the job. Ask them to explain master data management, and you’ll usually get a blank look. Nobody covers it in school. Few plants have a formal onboarding module for it. And yet almost every expensive, embarrassing failure in an MES rollout, ERP integration, or AI analytics pilot traces back to the same root cause: the data describing what you make and how you make it was never actually agreed upon in the first place.
That’s master data management, or MDM. It’s not a system you buy. It’s a discipline — the ongoing practice of deciding who owns which piece of data, keeping that data consistent across every system that touches it, and reconciling it when systems inevitably disagree. In 2026, with plants racing to bolt AI copilots and Unified Namespace architectures onto their MES and ERP stacks, MDM has quietly become the single biggest predictor of whether those projects succeed.
What “master data” actually means on a shop floor
Master data is the relatively stable, foundational information that transactional systems reference over and over. It’s different from transactional data — a work order, a scrap event, a sensor reading — which is generated constantly and describes what happened. Master data describes what exists. In a manufacturing context, the core domains are:
- Item master: every part, material, and finished good, with a unique identifier, description, unit of measure, and classification.
- Bill of materials (BOM): what components go into an assembly, in what quantities.
- Routing: the sequence of operations, work centers, and standard times required to build something.
- Equipment and asset IDs: the machines, lines, and work centers themselves, and how they’re named and hierarchically organized.
- Location and plant hierarchy: sites, areas, lines, cells — the structure that everything else hangs off of.
Here’s the uncomfortable part: almost every plant already has all of this data. The problem is that it exists in three or four places at once — ERP, MES, CAD/PLM, a spreadsheet someone built in 2014 that half of quality still uses — and those copies drift apart. Nobody drifts them apart on purpose. It happens one change order, one system upgrade, one “quick fix” at a time.
Why this is suddenly the bottleneck, not a side issue
Most of what’s being sold in MES buying cycles right now — AI copilots that answer natural-language questions about production, Unified Namespace (UNS) architectures built on MQTT Sparkplug B or OPC UA that publish plant data as consumable “data products,” native analytics layers promising real-time OEE and genealogy — all of it makes one silent assumption: that the underlying master data is accurate, unique, and consistently referenced across systems.
An AI copilot that answers “why did line 3’s changeover time increase” is only as good as the routing and equipment data behind it. If the same work center has three different names in ERP, MES, and the historian, the copilot either fails silently or, worse, gives a confident wrong answer. A UNS is only a coherent “namespace” if the naming convention behind it — site/area/line/machine — maps to a single agreed hierarchy, not four competing ones. Analytics dashboards built on duplicated item numbers will double-count inventory or silently drop volume. None of these are AI problems. They’re MDM problems wearing an AI costume.
Who should own what: a domain ownership model that actually works
The reason master data rots is usually not incompetence — it’s ambiguous ownership. Multiple functions can edit the same record, none of them is accountable for its accuracy, and nobody reconciles conflicts until an integration project forces the issue. A workable ownership split looks like this:
- Engineering owns the item master structure, BOM content, and engineering change process. If a part number’s definition changes, engineering is the source of truth.
- Manufacturing/industrial engineering owns routings and standard times — the “how we build it” data — in coordination with engineering’s “what it’s made of” data.
- Quality owns inspection specs, characteristic data, and any master data tied to compliance or traceability requirements.
- Planning/scheduling owns work center capacity data and calendar/shift master data, since that’s what drives their scheduling logic.
- Plant IT or a dedicated data steward owns the equipment/asset hierarchy and naming conventions that everything else references — this is the connective tissue, and it needs one accountable owner, not a committee.
The point isn’t the exact org chart — plants vary. The point is that every domain needs exactly one accountable owner, documented, with a defined process for how changes propagate to the other systems that consume that data. If two people can independently edit a routing without triggering a reconciliation step, you don’t have a routing — you have a rumor.
Reconciling ERP and MES when they disagree
This is where most engineers actually encounter MDM for the first time: staring at a discrepancy between an ERP item master and an MES equivalent, with a go-live date looming. A practical reconciliation approach:
- Export both sides. Pull the full item master, BOM, and routing tables from ERP and from MES (or the historian/SCADA config if equipment IDs are the issue). Don’t sample — export everything.
- Match on a stable key, not a description. Descriptions drift (“Weld Fixture A” vs. “weld fixture-A (rev2)”). Match on part number or a system-assigned unique ID, and flag anything that doesn’t match cleanly.
- Classify the mismatches. Some are true duplicates (same item, two IDs). Some are stale records (retired parts still active in one system). Some are genuine conflicts (different BOM quantities, different routing sequences). Each type needs a different fix — you can’t bulk-resolve them the same way.
- Pick a system of record per domain, not per project. ERP is usually system of record for the item master and BOM; MES is usually system of record for real-time routing execution state and equipment status. Document this once, and make every future integration honor it.
- Build the sync mechanism before go-live, not after. Whether it’s a batch interface, an ISA-95 B2MML exchange, or a middleware layer, decide how corrections in the system of record propagate downstream — and who gets notified when they don’t.
A first-90-days checklist for any MES/ERP project or renewal
If you’re walking into a new implementation, a renewal, or an AI/UNS pilot, treat the first ninety days as a data audit, not a configuration sprint:
- Inventory every system that currently holds item master, BOM, routing, or equipment data — including the shadow spreadsheets nobody admits to.
- Assign a named, accountable owner to each data domain, and get that ownership acknowledged in writing by their manager.
- Run the ERP-to-MES reconciliation exercise above on at least one full product line before scaling further.
- Document a naming convention for equipment and location hierarchy that aligns with ISA-95 levels, and freeze it before any UNS or MQTT topic structure gets built on top of it.
- Establish a change-control process: who approves a new part number, a routing revision, or an equipment rename, and how that change reaches every downstream system.
- Pick one measurable data-quality metric — duplicate rate in the item master, or percentage of routings with a validated owner — and recheck it monthly, not just at project kickoff.
None of this is glamorous. It won’t show up in a vendor demo, and it doesn’t generate a dashboard anyone gets excited about. But every AI copilot, every UNS rollout, every slick analytics layer being pitched this renewal season is standing on top of exactly this foundation. Get the master data right first, and those tools actually deliver what they promise. Skip it, and you’ve just built a much faster, much more confident way to be wrong.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
