AI-Ready Manufacturing Data Is Not a Cleanup Project

An agent gets a simple question: how many units of part 4471-B are committed to open work orders this week. It answers in under a second, confidently, and it is wrong. That part is 4471-B in the PLM system, 004471B in the ERP, and PN-4471 Rev B on the line. That is 3 IDs for one physical part, and nothing in the stack tells the agent those rows describe the same object. The model did not hallucinate. It answered the only question it was actually able to ask.

That is the whole of the AI-readiness problem in manufacturing, and it is not a data-quality problem. It is an identity problem, which makes it a Master Data Management (MDM) problem, and the standard advice tends to make it worse.

The preparation frame is why AI-ready keeps slipping

The common prescription runs as a sequence: inventory what you have, write governance policy, deduplicate and enrich, centralize into a warehouse, wire up connectivity, apply metadata labels, then build and maintain the pipelines that feed everything downstream. Every step is defensible on its own. The sequence still fails, and it fails for a structural reason rather than an execution one.

Each stage produces a snapshot, and the systems underneath keep changing while you work through the next stage. A plant renames a material group in week 3. An acquisition brings a second ERP in month one. A supplier consolidates 2 legal entities into one. By the time the governance layer is live, the deduplication output it governs describes an estate that no longer exists. Teams read that as a discipline failure and buy more discipline. It is not a discipline failure. It is what happens when readiness lives in an artifact instead of in the query.

So the useful question is narrower and much harder to dodge. When an agent asks about a part, a supplier, a work order or a batch right now, can this stack determine which real-world object is meant, and state how confident it is? If yes, the data is AI-ready even while it is messy. If no, it is not AI-ready, whatever the cleanup backlog says.

How to make ERP, PLM and MES data AI-ready

The short version: stop trying to make the records identical and make their identities resolvable. In practice that means 4 things, and usually only the first one is anywhere close to in place.

1. 1One resolvable identity per real-world object, spanning every system that holds a version of it: the part, the supplier, the work order, the batch, the location.
2. 2A confidence signal attached to each of those identities, so an agent can tell a certain match from a probable one and escalate instead of guessing.
3. 3Resolution that keeps updating as the sources drift, rather than a merge that was correct on the day it ran.
4. 4A governed record the agent reads from and acts through, so its writes land against validated master data instead of raw conflicting tables.

Nothing in that list requires moving your data, and nothing in it requires the source systems to agree with each other. It requires knowing, with a stated confidence, which rows are the same thing.

The identity failures that break manufacturing agents

In manufacturing these failures are specific and repeatable. They are worth naming, because an agent grounded on any one of them produces answers that are fluent, internally consistent, and unusable.

Part and BOM identity

Design files in the PLM system carry one part-numbering convention. The ERP procurement catalog carries another, usually shaped by whoever set up the material master years ago. The line carries a third, often with a revision suffix the ERP never sees. Planners reconcile parent-child hierarchies in Excel, and mismatched revisions or materials surface on the assembly line rather than in a report. An agent reading across those conventions sees a fragmented Bill of Materials, and it will tell you a component is unsourced while the component sits in a bin under a different ID.

Supplier and vendor master identity

One supplier routinely sits under a different ID in every regional ERP an acquisition brought in, plus another in the quality system and another in the spend tool. Roll spend up across those and you underreport concentration risk on your largest vendor, because it presents as 5 medium ones. This failure gets described as a deduplication problem, which is accurate about the symptom and wrong about the fix. Those records are not duplicates to be collapsed. They are one entity seen from 5 systems that each have a legitimate reason for their own key.

Work order, batch and lot identity

Traceability crosses the widest gap. A batch has a lot number in the quality system, a production order in the ERP, and a run identifier on the line. Genealogy questions, meaning which finished goods contain material from this lot, need all 3 to resolve to one object. Where they do not, recall scope becomes a manual exercise carried out under time pressure.

Unit of measure and location identity

The quietest failure, and the one that produces the most confident wrong numbers. Cases against eaches. A plant code against a site name against a shipping address. An agent that sums across these without resolving them returns a figure in no unit at all, and it will not flag the problem, because nothing in the data marks it as one.

Master data is not telemetry, and conflating them is why pilots stall

This is where AI-readiness advice for manufacturing quietly overreaches. Mastering identity across ERP, PLM, MES and the quality system is a master-data problem. Knowing what a machine is doing right now, which is what SCADA and the PLCs underneath it exist to tell you, is a telemetry problem. Different systems, different latencies, different projects.

Be specific about the boundary, because the buyer will be. A Golden Record answers which part, which supplier, which order, and which of several conflicting values is the trustworthy one. It does not report live line status, and it does not read SCADA tags or PLC signals. Master data across connected sources refreshes on a daily cycle, which is the right cadence for identity and the wrong cadence for a machine fault. Any vendor offering you both in a single layer is describing 2 products.

That boundary matters for AI readiness because most stalled manufacturing pilots did not fail on latency. They failed because the agent could not tell which supplier it was looking at. Fix identity first. Telemetry is a separate problem, and a more tractable one once identity holds, because a SCADA tag history is only interpretable if the asset it came from resolves to one identity across the EAM, the ERP and the line. That resolution is the master-data job, and it is the part nobody can skip.

The questions to ask before you point an agent at your ERP

A short diagnostic, useful because every answer is checkable this week rather than after a program:

1. 1Pick your largest supplier by spend. How many IDs does it hold across every connected system, and does anything in the stack know they are the same company?
2. 2Take one active part number. Can you get from the PLM revision to the ERP material to the line identifier without a person in the middle?
3. 3When 2 systems disagree on a field, what decides which value is true, and can you show that rule to an auditor?
4. 4If the system is 70% confident that 2 records match, what happens next: a silent merge, a blocked action, or a decision queued for a human?
5. 5When a plant invents a new naming convention next quarter, does resolution adapt on its own, or does somebody edit a rule?

The fourth question is the one that separates an AI-ready stack from a merely clean one. Deterministic matching has no answer to it. A rule either matched or it did not, and neither outcome carries a confidence an agent can act on.

What resolving in place actually looks like

Traditional Master Data Management builds the hub first: pull the records out of the systems that hold them, model a central schema, run match-and-merge, then govern the result. That is a 6 to 18 month program in which the hub comes before the record, and it is the reason the preparation frame exists at all.

Next-Gen Master Data Management inverts the order. It is zero-copy: there is nothing to model and no copy. The records stay where they are and get reconciled in place. BonData reads metadata and hashed values across your connected sources, proposes the relationships it finds as Suggested Bonds, and scores each one with a confidence. You approve or reject from a queue, confirmed Bonds become the load-bearing links, and the whole set renders as a live Data Map you can inspect by entity or by system. Matching is exact or partial against a confidence threshold, and composite across several fields at once, so no single messy column sinks a match on its own.

That architecture has a name: it is zero-copy. Because nothing is copied out, there is no migration to sequence and no central schema to agree on first, which is why time to a live Golden Record is measured in roughly 24 hours rather than quarters. Zero-copy and the 24 hours are really one claim: the speed is only credible because there is nothing to move.

What the agent then works from is one trusted Golden Record per entity: the reconciled view of that part or that supplier across every system holding a version of it, with the confidence behind each link visible instead of buried. That is what bonding your systems produces, and it is a different object from a merged row in a central store.

The ERP pollution question, answered properly

Every manufacturing CIO asks a version of this, and it deserves a straight answer rather than a reassuring one. The fear is not writes. The fear is unvalidated writes landing in SAP tables and disturbing the ledger.

So, plainly: BonData does not take a copy of your records out, and it does act. Analyst mode is read-only, for querying, charting and exploring with no side effects. Agent mode builds workflows that create and update records, because a system that can only describe your data cannot fix it. The control is not an absence of writes. It is 3 things you can verify: you define explicitly which agents may act and on what, actions run against the governed Golden Record rather than raw conflicting tables, and any workflow can be simulated before it is allowed to run live.

On deployment, the honest claim is optionality rather than an absolute. BonData is deployable inside your own AWS account, operated through an IAM role you can revoke at any time, with customer-managed keys and customer-owned audit logs. Not every deployment is that one: proofs of concept and lower tiers run in BonData's cloud. Ask which model a quote is priced against.

What this does not fix

Resolving identity in place does not clean your source systems. A material master with 14 blank fields still has 14 blank fields; what changes is that you now know which real object those blanks belong to. It does not remove the need for people who understand the domain either, because approving a Bond between a part in PLM and a material in the ERP is a judgment about the business, not about strings. And it does not give you shop-floor visibility, for the reason above.

One more, because it is the kind of thing a vendor page leaves out: BonData's public manufacturing proof is anonymized, and the named logos on our site are technology and fintech companies rather than manufacturers. The manufacturing evidence is a global maker of high-precision industrial components whose supplier and distributor network ran on siloed spreadsheets. Bonding the partner data produced a 300% supply-chain productivity gain, a 30% reduction in operational cost, and partner onboarding in under 5 days instead of months. Their VP of Supply Chain Operations described the before state better than our marketing does:

Before BonData, our supply chain was a black box. We never knew if data was original or outdated. Now we have a transparent, distributed source of truth that virtually eliminated reconciliation toil.

The advice to make your data AI-ready before you deploy agents has the dependency backwards. You will not finish, because the finish line moves every time a plant, an acquisition or a supplier changes something. What you can do is make identity resolvable, attach a confidence to it, and keep it resolvable while the sources drift.

Clean data was a reasonable goal when the consumer was a quarterly report. The consumer is now something that acts on your behalf between refreshes, and it does not need your systems to agree. It needs to know, and to be able to say how sure it is, that those 3 rows are one part.