The Machine Is the Same. The Data Is Not: Why Manufacturing Excellence Needs One Record of the Asset, Not Five
A single machine on your floor lives in at least five systems, and in most mid-size manufacturers each system holds its own version of it. The MES knows its runtime, the CMMS knows its maintenance history, the ERP knows its cost and capacity, the quality system knows its defect record, and the CPQ quotes lead times based on an assumption about all four. The gap between those versions is where improvement programs quietly fail. OEE initiatives, predictive maintenance, quote accuracy, and now AI on the shop floor are all data-quality gates, and a plant whose systems disagree about the same asset fails every one of them. You do not fix this by buying a sixth system. You fix it by making the five you have agree on one record of the machine.
Where does a machine's data actually live?
Follow one CNC cell, one press, or one packaging line through a week and count the systems that hold a fact about it.
| System | What it holds about the machine | What typically drifts | Who feels it first |
|---|---|---|---|
| MES or line controls | Runtime, cycle counts, stops, output | Stop reasons coded differently by shift; downtime that never reaches the CMMS | Production supervisors |
| CMMS | Work orders, maintenance history, spare parts | Asset names that do not match the ERP; completed work closed without failure codes | Maintenance |
| ERP | Asset cost, capacity, standard rates, BOM links | Capacity that reflects the plant on paper, not the plant this month | Planning, finance |
| Quality system | Defects, holds, inspection results | Defects tied to a part number, not to the machine that produced it | Quality, then customers |
| CPQ and order promising | Lead times, routings, cost assumptions | Quotes built on capacity and cost that the floor has already contradicted | Sales, then operations |
| Spreadsheets and email | Everything that does not fit the above | The only place the whole picture exists, owned by one person | Everyone, eventually |
The last column is the one that matters. Every drift lands on a specific desk, and in most plants it is the same handful of people reconciling the same machine against itself every month.
Why do the versions drift?
The causes are structural, not careless.
- Each system was bought to do one job well. The MES vendor, the CMMS vendor, and the ERP vendor each own their record of the asset. None of them owns the relationships between the records, which is where the machine actually lives.
- Asset identity is not shared. The press is "PRS-04" in the CMMS, "Press Line 4 East" in the MES, and a fixed-asset number in the ERP. Without one identifier, every integration starts with a lookup table that someone maintains by hand.
- Codes mean different things. A downtime reason, a failure code, and a defect code are three vocabularies describing one event. Nobody decided this; it accreted as each system was configured.
- Spreadsheets become the integration layer. When two systems do not talk, a spreadsheet talks for them. It works until the person who built it is promoted, or until a second plant is added.
The result is a plant that knows a great deal about every machine and cannot answer a simple question, such as what this machine's true cost per good part was last month, without a meeting.
What does drift cost a manufacturing excellence program?
Three programs, and the gate each one fails.
OEE and downtime reduction. OEE is only as good as the stop reasons behind it. When the MES codes a stop one way, the CMMS records the repair another way, and the two never meet, the Pareto chart that drives the improvement plan is built on a guess. Teams attack the wrong losses with great discipline.
Predictive maintenance. Every predictive program needs the maintenance history and the runtime history joined to the same asset. If the CMMS and the MES disagree on which machine is which, the model learns noise. This is the quiet reason so many predictive pilots end as dashboards nobody trusts.
Quote accuracy and delivery promises. The CPQ quotes a lead time from a routing and a capacity figure that live in the ERP. If the floor's real capacity is lower because of unrecorded downtime, sales promises what operations cannot deliver, and the customer meets the drift before anyone in the plant does. We have written about CPQ for manufacturers separately; the short version is that quote accuracy is a plant-data problem wearing a sales costume.
Is this the same problem Palantir is selling the answer to?
Yes, at a different scale and price. Palantir's pitch this year is built on one idea: a governed record of a company's operations that AI can work from without the company surrendering its data. Its CEO's Q2 2026 statement put it as customers wanting maximal control over their operations, data, and decisions, and never letting their competitive advantage become training data for future models. That is the right instinct, and large enterprises are paying a great deal for it.
A mid-size manufacturer does not need an enterprise platform to get the same property. It needs one record of the asset, built on the systems it already runs, with the plant's own vocabulary mapped once, permissions set per system, and a governed way for people and, later, AI to read from it. The difference is that the record is assembled from your MES, CMMS, ERP, and quality data rather than replacing them, which is also what keeps it affordable. The sovereignty part is simply a rule: the record is yours, it stays in your environment, and any model that reads it does so through permissions you set and logs you keep.
How do you build one record of the machine without ripping anything out?
In practice the work has four steps, and the first one is not technical.
- Decide the identity. One asset identifier, written down, mapped to every system's name for the same machine. This document outlives every tool.
- Map the vocabularies. Downtime reasons, failure codes, and defect codes mapped to one set of definitions, with an owner for each. This is the step plants skip and the step that decides everything after it.
- Build the join, not a new system. A lightweight integration layer that reads from each system through its own interface and assembles the record, with the ERP remaining the system of record for cost and the CMMS for maintenance. Where a system cannot be read, that is a configuration or vendor conversation, not a reason to replace it.
- Give the record one governed door. People, dashboards, and AI tools read the assembled record through permissions set once. For the AI case, this is exactly where a protocol such as MCP earns its place, because it lets a model query the record safely rather than being handed exports; we covered the design in what is an MCP server.
When is this the wrong project?
Honest exclusions. A single-line plant with one CMMS and no ERP integration has nothing to join yet; spend the money on the CMMS and good failure codes. A plant mid-way through an ERP migration should finish it first, because the asset identity will change underneath you. And a plant whose real problem is that nobody closes work orders with a failure code will not be helped by an integration layer; that is a discipline problem, and a cheap one to solve.
The number the plant is really judging
It is not the number of dashboards. It is how long it takes to answer one question about one machine with one answer. When OEE, maintenance, cost, quality, and lead time all point at the same asset and agree, improvement programs start compounding instead of restarting. That is what one record of the machine buys. The rest is tooling.
We build the integration layer and the governed data record for manufacturers on the MES, CMMS, ERP, and CPQ systems they already run, and we will say plainly when a plant does not need one yet.
Sources: Palantir, Q2 2026 letter to shareholders (August 3, 2026) and Q2 2026 earnings release, for the sovereignty framing. All manufacturing observations are category-level from our delivery experience; no client is named.
Related reading: What is a CMMS? · CMMS software cost · CPQ for manufacturers · MCP for connecting business systems to AI · CMMS and maintenance software
