AI in Manufacturing ERP - The Four Questions Executives Ask First

John Hannan

1 day ago

9 min read

Selecting an ERP this year? If you lead a multi-site or regulated company and need a full selection program - requirements, RFP, scripted demos, decision - rather than a quick answer, see how our ERP software selection program works, or talk to John.

What should an executive ask about AI in an ERP?

When executives ask me about AI in ERP, the conversation usually comes back to four questions. Is our data secure? Can we trust the transactions and communications it produces? What happens if we start depending on it and it stops working? And what will it cost to operate?

Those are reasonable questions, and they need answers before a company makes AI part of a business process. The answers depend on what the tool will do, what information it can reach, and who remains responsible for the result.

Manufacturers do not need to replace a working system simply because a vendor has introduced an AI feature. They do need to understand where AI could help their business and what would be required to use it. Starting with a manageable application gives the team experience it can use when considering more demanding work.

Rewritten in October 2026. This post replaces a January 2024 roundup of vendor AI roadmaps that is now out of date.

What I See in Client Companies

Much of our work takes place while companies are selecting an ERP, implementing one, or deciding what to improve in the system they already own. AI is becoming part of those conversations because it offers another way to address work that has been manual or difficult to support.

One manufacturer began looking at cash application after an accounts receivable vacancy. Its executives had already been discussing AI, and the vacancy gave them a specific process to evaluate. We worked through the use cases, security needs, customer experience, and what the ERP could support. The proposed design included human approval before a customer communication was sent or a transaction posted to the ledger.

Another manufacturer was considering a separate warranty application. The AI opportunity was to bring claim information to the customer service representative during a call, reducing the research and follow-up needed to answer the customer. That is a useful objective, but the case for the investment still depends on the information available and the results of testing.

A supplier evaluating inbound customer inquiries took a similar approach. Order status and delivery questions often require information already held in the ERP. The proposed agent would prepare responses for a person to review, with exceptions handled by the customer service team. Any reduction in review should follow evidence from actual use.

Management reporting is another practical example. For 20 years ERP dashboards have been a joke of the industry - impressive in the sales cycle, rarely implemented in practice, because the standard presentation seldom answers the questions a manager actually has. AI offers a way to bring information together and explain it in a more useful form. I use AI to help prepare a weekly report for my own firm from business communications, calendar commitments, and financial information. Reconciliation and review remain part of the process.

These examples start with recognizable work. That makes it easier to agree what the tool needs to do and how the company will know whether it is helping.

1. Is our data secure if we allow AI to access it?

Security needs to be evaluated for the particular product and connection. A general statement that a vendor's AI is secure does not tell you whether a customer service agent can see payroll, whether uploaded files are retained, or who can retrieve information from the system.

I would ask the provider to explain what data leaves the ERP, where it is processed and stored, who can access it, and whether it is used to train models. The answers should cover the actual subscription and configuration being proposed.

The access granted should match the job. An agent preparing an order-status response needs the relevant customer and order information. It should not receive broad access simply because that is easier to configure. Reading a record and changing it are different permissions and should be considered separately.

For a first application, I would favor a limited process with clearly defined access and an approval step before consequential actions. Have the people responsible for security review the design before connecting production data.

2. How accurate will the transactions and communications be?

Ask what acceptable performance means for the process. An internal draft that a manager can correct has different consequences from an incorrect shipment promise or a cash receipt applied to the wrong account.

I would test against representative examples from the company's own work, including exceptions and incomplete information. For cash application, that might include partial payments, deductions, and receipts covering several invoices. For customer inquiries, it might include an order that has changed since the customer's last message.

A confidence percentage is not proof that the answer is correct. Review the results against the underlying records and measure the errors that matter to the business.

The design also needs a clear response when the information is insufficient. The agent should be able to leave the item for a person instead of supplying an unsupported answer. Human approval is useful only if the reviewer can see enough evidence to check the output.

I would reduce review only after the team has demonstrated acceptable performance for the specific task. A period of successful use should inform that decision, with continued checks as data and processes change.

3. What happens if we depend on the agent and it stops?

An AI application needs an operating owner just as any other business application does. Someone has to know when work has failed, decide what to do with the backlog, and coordinate support.

Before relying on it, I would ask how failures are detected and reported. What happens if the connection to the ERP is unavailable? Where do unfinished items go? How does the team resume processing without losing work or repeating a transaction?

The company should retain a workable fallback. That may be the existing manual process, a queue for staff to resolve, or another agreed way to keep the operation moving. Test that fallback before the agent becomes essential.

The support arrangement also needs to identify responsibility for the AI service, the integration, and the ERP. If three providers are involved, the client still needs someone accountable for coordinating resolution. Changes to the model or connected systems should trigger appropriate checks before the team assumes performance is unchanged.

4. Will token costs make it too expensive?

The first question is how the proposed service is priced. Some products charge by user, some by usage, and some include an allowance before additional charges apply. Ask what is included and what happens when activity exceeds it.

For text-based models, tokens are units used to measure the text processed and generated. A business does not need to manage an AI initiative around token terminology, but it does need a realistic estimate of usage.

I would ask the provider to price the expected monthly workload and a busy period, including longer documents, exceptions, and repeated attempts. Then compare that estimate with what the pilot actually consumes.

The operating budget should also include the connection to the ERP, support, monitoring, and the staff time needed to review results. A low processing charge does not establish a low total cost. Agree spending limits or alerts where the service supports them, and assign someone to review usage.

The useful comparison is the total cost of completing the work at an acceptable standard, measured against the current process and its results.

Why the First Application Takes More Work

The first project often includes decisions the company has not made before. The team needs to select a provider, approve data access, establish support, and agree how performance will be evaluated.

Some of that work can be reused. A second application using the same approved tools and data connections may be easier to introduce. The first project also gives employees a clearer understanding of what AI can and cannot do in their own environment.

That does not mean every subsequent agent is a small addition. A different data source, more authority to post transactions, or a regulated process can introduce substantial new work. Before expanding, agree who can approve new applications and who will support them.

Where I Would Be More Cautious

In pharmaceutical manufacturing, the intended use matters. Preparing a draft for review is different from making a quality decision or changing a record used to release product.

The FDA and EMA's January 2026 guiding principles of good AI practice in drug development include manufacturing and call for validation and oversight proportionate to the use and risk. They do not establish blanket approval for an ERP application.

I would involve the quality and validation teams early when the proposed use affects regulated records or decisions. Establish what evidence is needed, how changes will be controlled, and who is responsible for approval. A similar assessment is needed for food manufacturing under its applicable requirements. Keeping an application away from inventory, by itself, does not settle those questions.

What This Means for an ERP Selection

In a manufacturing ERP selection, start with the business requirement. If an available AI feature materially improves an important process, evaluate it against that requirement and ask the vendor to demonstrate it using your scenarios. Give roadmap commitments different treatment from functionality that can be implemented now.

The ERP still has to support the company's planning, costing, inventory, production, quality, and customer requirements. An impressive AI presentation should not outweigh a poor fit in those areas.

I would ask each vendor which capabilities are operating at comparable customers, what data they require, how they are priced, and what support is available. Ask what happens to the process and the company's data if the AI feature is disabled. Include the ongoing operating cost in the proposal comparison.

Timing should follow readiness. A bounded application that supports a clear go-live requirement may belong in the initial scope. If the core process and data are still being established, a later phase may be more practical. Define that later phase well enough that it remains an actionable plan.

We also use AI to support the selection work itself. Where recordings and transcripts are authorized and available, they can help prepare draft requirements for process owners to correct. AI can organize committee scorecards and prepare comparisons for review. The process owners validate the requirements, evaluators supply the judgments, and the committee makes the decision. We remain responsible for the material sent to vendors.

When a Different Approach Deserves Consideration

One client came to us with a proposed AI-based alternative to a conventional ERP implementation. It wanted an assessment of that approach rather than a new selection. We reviewed the proposal, saw a path worth pursuing, and took on the project management role.

The proposed commercial terms made the option worth examining. That experience does not establish a general cost advantage for AI-based platforms, and the purchase price is only part of the decision.

For an approach like this, I would assess how the business will test the system, retain access to its data, obtain support, and move to another solution if necessary. Those questions matter before the operation becomes dependent on the platform.

Our role as ERP selection consultants is to help the client make and carry out a sound decision. That can mean selecting a conventional ERP, improving the system already in place, or carefully evaluating another approach.

Start With Work the Business Understands

The executives best positioned to sponsor an AI project understand enough about the process to ask useful questions and judge the result. They do not need to become developers.

Choose a problem the team can describe, establish the current effort and outcome, and agree what the first application should improve. A focused project gives the company a practical way to learn while keeping responsibility clear.

If you are deciding what to ask vendors about AI, or whether the system you run can carry it, talk to John about your ERP program.

Frequently Asked Questions

Should AI be a requirement in an ERP selection?

Include the business outcome you need. If an AI capability can meet it, evaluate its availability, performance, controls, and cost alongside other ways to meet the requirement. A vendor's AI roadmap should not receive the same weight as proven functionality.

Is AI a reason to replace our ERP?

It can be part of the case, but it should not decide the question on its own. Assess the current system's data quality, access options, process fit, and supportability. Improving data or adding an integration may be sufficient. Replacement needs a broader business case.

Which AI use cases should manufacturers consider first?

Cash application support, customer inquiry drafts, warranty information retrieval, and management reporting are examples from our client discussions and our own work. Choose based on the actual workload, data available, consequences of errors, and ability to measure a benefit.

Does AI belong in Phase 2 of an ERP implementation?

Often it can wait until the relevant processes and data are stable. A limited, proven application may fit the initial phase if it supports an important requirement and the team can deliver and support it. Decide the scope and timing for the specific use case.

Why can the first AI application cost more?

It may include provider selection, security review, data connections, and operating procedures that later applications can reuse. Each new use still needs its own assessment, testing, and support plan.