What If AI Didn’t Have to Fix Your ERP First?
TL;DR
This article builds on a previously published story about a question I keep coming back to: what if AI didn’t have to fix your ERP first? ACPC 2026 gave that idea new weight. People are not tired of AI, they are tired of being told they need AI to compensate for workflows that should have been sophisticated from the start. This piece looks at what becomes possible when intelligence inherits connected transactions, operational context, and a workflow that already knows what it is doing.
I just got back from ACPC 2026, and as usual, it was a phenomenal show. I say that every year, and every year somehow it gets better.
There was a lot to talk about. A lot of technology. A lot of AI. A lot of people trying to figure out what actually matters and what is simply the next thing they are being told they need.
And somewhere between Friday and Tuesday, through a lot of conversations with operators, suppliers, repair shops and people living inside these systems every day, one thing became very clear to me:
People are not tired of AI. They're tired of being told they need AI before anybody explains what problem the AI is actually solving.
That distinction matters.
Because there is a world of difference between using intelligence to make a sophisticated operation smarter and using intelligence to compensate for workflows that were never sophisticated enough to begin with.
Both can be valuable.
Only one really changes the ceiling.
Before We Talk About Intelligent ERP, We Should Probably Talk About ERP
Imagine a normal transaction.
An RFQ comes in. Someone reads it, enters the customer, enters the parts, checks inventory, looks somewhere else for pricing history, opens another screen for customer history, maybe sends procurement a message, maybe checks a marketplace, maybe waits for an approval, maybe goes back and forth between two or three places before finally sending a quote.
Nothing about that sounds extraordinary.
That is exactly the problem.
Businesses have spent years getting incredibly good at working around mediocre workflows. People know where the real information lives. They know which screen can be trusted. They know which spreadsheet matters. They know who has to approve something even though the system says somebody else should. They know which process requires four pages and three handoffs because nobody has questioned it in years.
Eventually familiarity gets confused with sophistication.
Then AI arrives.
And suddenly the AI can read the email, parse the RFQ, find the customer, move the data, reconstruct history, summarize activity, remind somebody what needs to happen next, maybe even connect a few systems together.
Useful? Absolutely.
But look at what the intelligence is spending its time doing.
It's cleaning up the process.
It's reconnecting context.
It's making the broken pieces easier to live with.
That's still value. Sometimes enormous value. But there is an important difference between intelligence that advances the operation and intelligence that compensates for the architecture.
A lot of people I spoke with at ACPC already understand that difference, even if they would not necessarily describe it that way. They know they don't want to buy AI just so their ERP can finally behave like the ERP they thought they were buying in the first place.
That is a very different starting point.
The Most Important Question Is What the AI Gets to Inherit
I have always looked at software from the transaction outward.
Not: does it have purchasing?
Not: does it have an RFQ module?
Not: does it have inventory, repairs, receiving, CRM, reporting or shipping?
Those things matter, but the more interesting question is what each of those things knows about everything around it.
A quote knowing an RFQ existed is useful. A sales order knowing what was quoted, against what inventory, with what sourcing activity, for which customer and under what conditions is much more useful.
A purchase order existing is not particularly interesting. A purchase order understanding why it exists, which demand created it, what customer or repair depends on it, how the vendor has historically performed and what downstream commitment is now attached to that decision is far more meaningful.
Receiving shouldn't begin with the dock asking the business to explain the transaction again. The system already knows what was purchased, from whom, against what requirement, with what documentation expectations and in what condition.
That context should travel with the work.
This is what sophisticated workflows actually do.
They carry knowledge forward.
The transaction does not keep forgetting itself.
And once you start looking at ERP this way, AI becomes much more interesting because it no longer has to spend its first move reconstructing what the previous transaction already knew.
It gets to reason across it.
What Happens When Intelligence Doesn't Have to Rebuild the Past?
If intelligence already inherits the customer, the part, transaction history, inventory, vendor activity, purchasing history, pricing behavior, repair status, documentation requirements and everything surrounding the work, it no longer needs to begin with:
“What's happening here?”
It can begin with:
“Given everything happening here, what matters?”
That is a much higher-value question.
Finding the last five prices paid for a part is useful.
Understanding that the current price is outside the normal range, another transaction is competing for the same inventory, one vendor has recently underperformed, and the customer receiving the quote behaves differently at this margin is something else entirely.
That's not search.
That is reasoning across relationships.
I saw people react to this very clearly at ACPC when they watched intelligence sitting inside the transaction instead of beside it. They did not want a chatbot where they had to type, “Tell me who bought this part.”
They wanted the intelligence to already understand why they were looking at the part.
They wanted to know whether the vendor they were considering was approved. How that vendor performs. Whether there is a problem in the history. Whether the customer asking for the quote has sent hundreds of requests without ever buying anything. Whether something about the transaction should change the decision before the person makes it.
That's where AI stops being a better search interface and starts becoming operational intelligence.
The Best Intelligence May Be the Intelligence You Stop Thinking About
There's a strange assumption forming around business AI that intelligence needs somewhere separate to live.
Open the AI. Ask the question. Wait for the answer. Interpret the answer. Then return to the transaction where the real work was happening before you left.
I understand why we started there. Conversational AI made the capability visible. It gave people an easy way to understand that something new was happening.
But visibility is not maturity.
If the person is quoting a customer and the system already understands the customer, the part, the inventory, previous pricing, sourcing activity, current demand and historical behavior, why should the person have to know the perfect question before the intelligence becomes useful?
If a vendor shouldn't be used, a customer has a history that matters, an inventory conflict is forming, or a transaction carries unusual risk, the system should be able to surface that because the transaction itself created the context.
That's a very different architecture.
And it avoids another problem that came up repeatedly in conversations at the show: people are increasingly aware that they do not want another place where their data has to go just so somebody can tell them something their operating system should already know.
Another portal.
Another synchronization.
Another copy of the truth.
Another layer trying to understand the operation from outside the operation.
We have spent years trying to eliminate silos.
It would be ironic if AI simply gave us smarter ones.
Intelligence Has to Survive Contact With the Workflow
A recommendation is not an outcome.
Suppose the intelligence identifies the better supplier, recognizes that a quote deserves attention, sees that a repair is drifting toward a delay or notices a pattern nobody on the team had seen.
Now what?
If the person receiving that insight still has to leave the transaction, rebuild the sourcing request, re-enter the context, notify another department, create another record and manually coordinate the response, the intelligence may have become dramatically smarter while the operation barely moved.
That exposes a much harder question:
When the system understands what should happen next, can the business safely make it happen without rebuilding everything the intelligence already understood?
That doesn't mean removing people from the process.
Some actions should remain recommendations. Some should require approval. Some repetitive, bounded actions may be safe to execute automatically. Some decisions should always remain under human control.
The sophistication is not measured by how many people you remove.
It's measured by whether the technology knows enough to put human judgment where human judgment actually belongs and remove the unnecessary work around it.
That thinking is a big part of what shaped ELIA, our Embedded Layer of Intelligence in Aviation.
The point was never to build another place where somebody goes to ask the ERP a question. The point was to place intelligence close enough to the operational transaction that everything the system already knows can become part of the reasoning.
That's also why ELIA stood out so strongly in the conversations I had at ACPC.
The important word is embedded.
Because intelligence inside the transaction does not have to ask the operation to explain itself again.
Before You Ask What the AI Can Do, Ask What It Is Standing On
We are going to hear increasingly impressive AI claims inside ERP. More agents. More automation. More natural-language interaction. More predictive capability.
Some of it will be exceptional.
Some of it will be an exceptional way to compensate for architecture that was already struggling.
From a demo, those approaches may look surprisingly similar.
That's why I think the better first question is no longer simply:
“What can your AI do?”
It's:
“What does your AI inherit?”
Does it inherit connected transactions, or does it have to rebuild those relationships every time somebody asks a question?
Does purchasing know why the demand exists?
Does receiving already understand what is supposed to arrive?
Does the repair understand the material, sourcing, cost and customer commitments around the job?
Does the intelligence inherit enough operational context to reason about consequence, or is it spending most of its energy rebuilding a story the ERP should already understand?
That was probably the most encouraging part of ACPC for me this year.
People are asking better questions.
They know they do not want AI because somebody told them they need AI. They know they do not want intelligence simply because their workflow is broken. They want the process, the platform and the ecosystem underneath it to already work, and then they want to see what intelligence can do when it is finally given that foundation.
That's where the opportunity gets much bigger.
Build the workflow so the operation already makes sense. Connect the transactions so context survives. Let the system understand why the work exists, not simply where the record sits.
Then give intelligence something worth reasoning across.
What if AI didn’t have to fix your ERP first?
What could it finally do if all of that intelligence were available for the business instead?
ACPC made one thing very clear. The market is getting smarter about AI, and the real question is shifting from “What can it do?” to “What is it standing on?”
If you want to see what the business case could look like for your operation, fill out the contact form. If you’re ready to dig in, complete the business case form here: https://erpinsider.net/business-case
