If you spend enough time talking to people who’ve actually deployed AI on a factory floor, you start to notice something. The conversation almost never stays on the AI part for very long. Ask someone what made their predictive maintenance rollout succeed, or why their quality inspection system fell flat, and within a few minutes you’re talking about ERP data, system integration, and whose job it was to keep the master data clean. Nobody planned for the conversation to go there. It just does, because that’s usually where the real story is.
The uncomfortable truth is that the “AI-powered factory” concept people get excited about isn’t really about the AI. It’s about whether the enterprise backbone underneath it can actually support what the AI needs to do its job.
What “Backbone” Actually Means Here
It’s a slightly vague word, so let’s be specific. The backbone is the combination of systems — ERP mostly, but also PLM, MES, and whatever historian database is tracking sensor data — that holds the actual facts about your operation. Inventory levels. Order status. Equipment maintenance history. Bill of materials. Every AI application on a factory floor, no matter how sophisticated, is ultimately just doing something useful with that underlying information. If the information itself is slow, fragmented, or unreliable, no amount of clever modeling fixes that.
This is easy to say and somewhat harder to internalize, because it’s much more fun to talk about the AI capability than the unglamorous plumbing underneath it. But the plumbing is genuinely where most of the difference between success and disappointment gets decided.
Where This Gets Real: Generative Design
Take generative design, which is probably one of the more exciting applications people bring up when they talk about Generative AI in Manufacturing. The pitch is compelling — describe your constraints, get back design candidates that meet them, iterate faster than a human engineer could alone. And it genuinely works, when it has what it needs.
What it needs, though, is a continuous, accurate feed of CAD history, past simulation results, and the specific material and cost constraints your team has learned the hard way over years of production. That data has to be current and it has to be trustworthy. If your PLM system’s revision history is inconsistent, or your ERP’s cost data lags reality by a quarter, the generative design tool is going to confidently produce recommendations built on outdated assumptions. It’ll still generate something. It just won’t be something you can actually trust enough to build.
This is the pattern that repeats across basically every AI use case people get excited about in manufacturing. The AI itself, more often than not, is doing a perfectly reasonable job. The backbone feeding it is what determines whether that job translates into something useful.
Why This Backbone Question Gets Skipped
I think there are a few honest reasons this doesn’t get enough attention early on, and none of them are really anyone’s fault.
For one, it’s just not exciting. Nobody gets energized in a planning meeting talking about ERP data governance. Talking about a new AI capability that could cut defect rates in half is a much better use of everyone’s enthusiasm, understandably.
For another, a lot of AI vendors, reasonably enough, focus their pitch on what their tool can do rather than what your systems need to look like to support it. That’s not dishonest, it’s just not their job to audit your ERP. But it means someone internally needs to be asking that question, and often nobody quite owns it.
And finally, the backbone question often just looks like an implementation detail rather than a strategic one at the point when decisions are getting made. It’s easy to assume “IT will handle the integration” without really interrogating what that integration actually requires, until you’re six months into a project and discovering it requires a lot more than anyone budgeted for.
Building the Backbone Deliberately
The factories that actually get value out of AI tend to treat the backbone question as something worth solving deliberately, rather than something to patch together as problems come up.
Practically, that usually starts with an honest look at what your current systems can actually deliver — not what the ERP vendor’s documentation claims, but what actually happens when you try to pull real-time data out of it today. A lot of manufacturers are surprised to learn how much manual reconciliation is quietly happening behind the scenes to keep numbers looking consistent across systems.
From there, it usually means treating the integration work as its own real project, with its own timeline and budget, rather than something absorbed silently into whatever AI initiative it’s supporting. And often it means bringing in people who specialize specifically in this gap, because it’s a genuinely different skill set than either AI implementation or general IT support. This is where ERP Consulting for Manufacturers tends to be worth the investment — not because you need someone to sell you new software, but because you need someone who can look at your specific, messy, real-world systems and tell you honestly what it would take to get them ready to support real AI applications, before you’ve already committed budget and credibility to a project built on assumptions that don’t hold.
What This Looks Like When It Goes Right
The factories where this actually works tend to look almost boring from the outside, at least on the systems side. Data flows between ERP, MES, and PLM without a lot of manual intervention. Master data — part numbers, equipment IDs, supplier records — is consistent across systems rather than drifting apart the way it does when nobody’s paying close attention. And when a new AI capability gets introduced, the conversation is mostly about the use case itself, not about a scramble to figure out how to get the data it needs.
That kind of quiet reliability doesn’t happen by accident. It’s the result of treating the backbone as a real priority rather than an afterthought, well before the exciting AI project shows up to depend on it.
The Bottom Line
If there’s one thing worth taking from all this, it’s a small mental shift: stop asking “which AI tool should we deploy” as the first question, and start asking “can our systems actually support what that tool needs to do its job well.” The second question is less fun to sit with, but it’s the one that actually predicts whether a factory’s AI investment turns into something durable or into another quietly disappointing pilot. The backbone doesn’t get the credit. It just determines whether everything built on top of it actually works.
About the Contributor
Nishkam Batta Editor-in-Chief, HonestAI Magazine | AI Consultant, GrayCyan AI Solutions
Nish leads an applied AI company that helps manufacturing and related companies automate operations with human-in-the-loop AI that integrates into ERPs, WMS, CRMs, and other enterprise tools, with an emphasis on no black box AI (explainable AI), clear audit trails, driving efficiency, and measurable outcomes. His team builds agentic ERP systems that execute multi-step tasks inside approved guardrails so humans keep accountability, approvals, and override control.
Book a Consultation | LinkedIn
