What Manufacturers Get Wrong About AI and ERP Integration

Most manufacturers evaluating AI and ERP integration are asking the wrong question. They’re asking whether the technology works. It usually does, in the narrow conditions where it was demonstrated. The harder question is architectural: where does it attach to your enterprise resource planning (ERP) stack, what does it need from the systems around it and who keeps it running once the project team disbands?

That gap is why so many AI initiatives stall after a promising pilot. Nobody was wrong about the capability. They were wrong about what it would take to run it in production.

When a slide says AI-powered, it’s worth finding out which of several very different things is on offer, because they carry different costs, different risks and different timelines.

In practice, what gets shown falls into a handful of categories:

• embedded features already shipping in the product, generally available and supported
• features on the roadmap, demonstrated in a preview environment
• a platform capability you can build on, with the building left to you
• a partner product resold alongside the ERP, integrated to a degree worth verifying
• statistical forecasting that predates the current terminology and was renamed

None of those is dishonest. But the first and the third produce completely different project plans, and you can’t tell them apart from the demo alone. Ask which release the capability ships in, whether it’s generally available today, whether it carries an additional license and how many production customers are using it in your industry. ERP Vendor Demos Are Designed to Sell Software, Not Reveal Operational Reality covers the wider discipline of controlling what a demo actually proves.

It helps to stop treating AI as one thing you buy and start treating it as three distinct attachment points in your stack. Each one has a different owner, a different risk profile and a different payback horizon.

Inside the transaction

This is AI embedded in the ERP itself: suggested lead times, anomaly detection on invoices, demand signals feeding the planning run. It’s the lowest-friction option because the vendor owns the data path and the support model. It’s also the least differentiating, since your competitors on the same platform get the same thing.

Beside the transaction

Here a separate service reads ERP data, produces a recommendation and writes something back or surfaces it to a user. Most quoting, forecasting and maintenance use cases live here. This is where integration work is real: you need reliable interfaces, a defined refresh cadence and a clear rule for what happens when the service is unavailable.

Around the transaction

Document handling, supplier correspondence, internal search across specifications and procedures. These touch ERP data but rarely write to it, which makes them the safest place to start and the easiest to abandon if the value isn’t there.

Where AI attaches determines who owns it, not just what it costs.

Every attachment point above assumes the records underneath are trustworthy and consistent. That assumption is where most manufacturing AI programs quietly break, and it’s a large enough subject that we treated it separately in AI and ERP: Why Data Integrity Decides Whether AI Delivers.

Treat that as the prerequisite, not the project. The architectural point here is narrower: your integration design should assume the data will be imperfect and make the failure visible rather than silent. That means defining what the service does when a required field is missing, how a low-confidence recommendation is flagged and who gets told when the output stops making sense.

Systems that fail loudly get fixed. Systems that fail quietly get trusted for a while, then abandoned all at once.

Most mid-market manufacturers face three honest options for any given use case, and the right answer varies by use case rather than by company.

Buying from your ERP vendor is the lowest-effort path. You inherit their roadmap, their support and their pace. Building gives you differentiation and control, and it commits you to maintaining a model, a data pipeline and the skills to run both. Waiting is a legitimate strategy that almost nobody states out loud, and it’s often correct when the capability is on a roadmap you’re already paying for.

A few questions usually settle it:

• is this use case genuinely specific to how you operate, or common across your industry
• will your ERP vendor ship something comparable within your planning horizon
• do you have someone who can own a model after the consultants leave
• what does the process cost you today, measured rather than estimated
• what happens operationally if the AI output is wrong on a Tuesday afternoon

You may be thinking, ‘waiting means falling behind.’ Sometimes. But building something your vendor releases eighteen months later is a worse outcome than waiting, and it’s a more common one. AI Consulting Services work often starts by sorting a long wish list into these three buckets.

Traditional ERP functionality is stable. You configure a pricing rule and it behaves the same way in three years. Predictive functionality doesn’t work like that. Its accuracy drifts as your product mix, supplier base and demand patterns change.

So an AI capability creates an ongoing operational responsibility that a configuration change does not. Someone has to monitor whether the output is still good, decide when it needs retraining or retuning and hold the authority to switch it off. In most mid-market manufacturers, that role isn’t in anyone’s job description at the time of purchase.

Answer these before you sign, not after:

• who reviews accuracy, and how often
• what the fallback process is when the capability is unavailable
• who has the authority to override a recommendation, and whether that gets logged
• how a user tells the difference between a system recommendation and a system fact

That last one matters more than it looks. When a screen shows a suggested delivery date next to a confirmed one with no visual distinction, planners eventually stop distinguishing between them too.

The most useful thing an executive team can do early is agree on what success looks like in operational terms. Not ‘improved forecast accuracy.’ Something a planner would recognize: fewer expedites in a month, less time building the weekly plan, quotes returned within a day instead of a week.

Then pick one use case, at one attachment point, with a named owner and a measurable baseline. Prove it in production, not in a sandbox, and let the second use case be chosen by what you learned from the first.

That sequence sounds slow. It’s considerably faster than the alternative, which is a broad AI program that produces interesting pilots and no operating change. We often guide our clients to treat AI the way they should treat any ERP capability: as an operational transformation rather than an IT project, with the same discipline about ownership, process and measurement.