---
title: "Your AI Strategy Is About to Meet 20 Years of ERP Customisation"
date: "2026-09-22"
summary: "ERP customisation was often a rational business decision. But as AI agents move deeper into operational systems, decades of custom code, exceptions and undocumented processes could become a major constraint. CIOs now need to distinguish between complexity that still creates competitive advantage and complexity that merely preserves history."
canonical: "https://thepragmaticcio.net/articles/your-ai-strategy-is-about-to-meet-20-years-of-erp-customisation/"
tags: "Artificial Intelligence, ERP, CIO, Enterprise AI, SAP, Technical Debt, AI Strategy, Enterprise Architecture, Digital Transformation, Technology Strategy"
---

# Your AI Strategy Is About to Meet 20 Years of ERP Customisation

ERP customisation was often a rational business decision. But as AI agents move deeper into operational systems, decades of custom code, exceptions and undocumented processes could become a major constraint. CIOs now need to distinguish between complexity that still creates competitive advantage and complexity that merely preserves history.

![AI doesn’t inherit a clean enterprise. It inherits decades of decisions, exceptions and customisation.](ai-erp-customisation.png "AI doesn’t inherit a clean enterprise. It inherits decades of decisions, exceptions and customisation.")

Your AI strategy is about to collide with decisions your company made twenty years ago.

Not about AI. About ERP.

For years, customisation was often entirely rational. When the standard system couldn't accommodate something that genuinely differentiated the business, we changed the system.

The mistake wasn't necessarily customising it.

**The mistake was allowing twenty years of customisation to accumulate without continually asking whether it still created competitive advantage — or merely preserved history.**

AI is about to force that question.

## We didn't customise ERP because we were stupid

There is a danger in looking back at heavily customised ERP environments with the benefit of hindsight and concluding that previous generations of CIOs simply got it wrong.

They didn't.

I have worked with ERP environments across manufacturing, retail and e-commerce, and there were perfectly legitimate reasons for changing them. Businesses acquired other businesses. Countries had different requirements. Factories operated differently. Products were configured differently. Customers had particular contractual needs. Standard functionality sometimes simply wasn't good enough.

And, particularly twenty years ago, the architectural choices available to us were very different.

If the ERP didn't do what the business required, we customised it.

Some of those customisations created genuine competitive advantage. Others solved regulatory requirements. Some allowed businesses to operate in ways the vendor had never anticipated.

But something else happened along the way.

Customisation became accumulation.

One change became ten. Ten became hundreds. Interfaces multiplied. Reports were added. Local exceptions became permanent. Temporary workarounds somehow survived three CIOs and two ERP upgrades.

Eventually, nobody could quite remember why some of it existed.

But everybody knew you shouldn't touch it.

That is how business logic gradually becomes archaeology.

## Humans have been hiding the complexity

For years, this was manageable partly because humans sat between the systems and the decisions.

Someone in finance knew that a particular report wasn't quite right and adjusted the spreadsheet.

Someone in supply chain knew that one plant handled a transaction differently.

Someone in customer service knew that a particular field meant something different in Germany than it did in the US.

Someone in IT knew about the interface that occasionally failed and simply restarted it.

None of that appeared on an architecture diagram.

It existed as organisational knowledge.

And humans are remarkably good at compensating for inconsistent systems.

AI agents are rather less forgiving.

If we want AI to do more than summarise documents and generate emails, it eventually has to interact with the operational systems that actually run the company.

That means orders.

Inventory.

Procurement.

Production.

Pricing.

Finance.

Customers.

Suppliers.

And sooner or later, the AI arrives at the ERP.

At that point, the quality of the model may become considerably less important than the quality of the environment we are asking it to understand.

## AI doesn't remove complexity. It can scale it.

Angela Maragkopoulou, Chief Information and Digital Officer at Sunlight Group Energy Storage Systems, recently described the problem rather neatly:

> "If you bolt AI onto a heavily customized landscape, you don't get intelligence."

Her conclusion is that you instead scale the complexity already present in the landscape.

I think that's an important distinction.

We talk constantly about hallucinations, model accuracy, guardrails and AI governance. All matter.

But imagine an AI agent trying to optimise procurement when three business units follow different purchasing processes for reasons nobody can adequately explain.

Or an agent attempting production planning when master data means slightly different things across factories.

Or an AI system reconciling financial information where years of custom reports contain embedded business rules that never made it into formal documentation.

The model isn't necessarily the problem.

**The enterprise is giving it conflicting versions of reality.**

Humans have spent decades navigating those inconsistencies because we understand context, exceptions and organisational history.

An autonomous system cannot rely on somebody called Klaus who has worked in finance for twenty-seven years knowing that *"we don't use that field for what SAP says it means."*

That knowledge has to exist somewhere the machine can understand.

And suddenly an old ERP problem becomes an AI problem.

## But I don't buy the clean-core argument completely

This is where I part company with some of the current ERP narrative.

The obvious answer is standardisation.

SAP's own clean-core strategy explicitly advocates keeping the underlying ERP standard and upgrade-stable while allowing business differentiation through controlled extensions. SAP argues this reduces technical debt, simplifies upgrades and makes it easier to consume new innovations, including AI. [SAP](https://news.sap.com/2025/08/extend-sap-s4hana-cloud-right-way-clean-clear/)

Architecturally, there is a lot to like about that.

Commercially, however, CIOs should retain a healthy amount of scepticism.

ERP vendors have an obvious interest in customers moving onto their newest platforms, adopting their preferred architectures and consuming the AI capabilities sitting on top of them.

Sometimes that will absolutely be the right decision.

But **"our AI works better if you buy our newest ERP platform"** should not automatically become an enterprise strategy.

The CIO's responsibility is not to produce the cleanest possible SAP system.

It is to produce the best technology architecture for the business.

Those are not necessarily the same thing.

## Standardisation has a cost too

There is another problem with treating standardisation as the universal answer.

Businesses are not standard.

Nor should they necessarily aspire to be.

If every manufacturer operated exactly the same production processes, every retailer followed the same pricing model and every distributor managed customers identically, technology would cease to provide much differentiation at all.

Sometimes the awkward customisation inside an ERP exists because the business genuinely does something differently.

That difference may be valuable.

So the question shouldn't be:

**How do we remove customisation?**

It should be:

**Which complexity are we willing to continue paying for?**

That's a very different conversation.

A custom process that gives customers something competitors cannot easily replicate may deserve to survive.

A custom process created in 2008 because somebody disliked the standard SAP screen probably doesn't.

A bespoke product configurator that encodes genuinely distinctive engineering knowledge might be strategically important.

Seventeen custom reports replicating functionality now available in the standard product probably aren't.

The difficulty is that many enterprises have never systematically separated the two.

AI gives CIOs a very good reason to start.

## Technical debt is about to appear in the AI business case

This isn't merely an architectural concern.

It becomes financial surprisingly quickly.

Recent IBM Institute for Business Value research found that organisations fully accounting for technical-debt remediation in their AI business cases project **29% higher ROI** than organisations that don't. IBM also estimates that ignoring technical debt can reduce expected AI returns by **18% to 29%**, while 69% of executives in its research said technical debt could make some AI initiatives financially untenable by extending delivery timelines. [IBM](https://www.ibm.com/think/insights/reduce-technical-debt)

That matters because boards are currently being shown enormous numbers of AI business cases.

Productivity improvements.

Automation.

Faster decision-making.

Reduced operating costs.

Better forecasting.

But how many include the cost of fixing the systems underneath them?

If an AI initiative requires six months of master-data remediation, three obsolete interfaces to be replaced, business processes harmonised across four countries and fifteen years of custom code understood before the agent can safely execute a transaction, those aren't separate ERP costs.

They are part of the AI business case.

Ignoring them doesn't make them disappear.

It simply makes the expected AI return fictional.

## There is also a danger in going the other way

Some organisations will understandably decide not to touch the ERP.

Instead, they will build around it.

Put an orchestration layer above the legacy landscape. Expose APIs. Add a semantic layer. Give agents controlled access to existing systems. Let AI compensate for some of the complexity underneath.

In some environments, I think that will be exactly the right answer.

A twenty-year-old ERP system does not suddenly become worthless because somebody invented an AI agent.

If it is stable, understood, economically sensible and continues to run the business reliably, replacing it purely because the vendor has attached an AI story to the latest release could be an extraordinarily expensive way of solving the wrong problem.

But wrapping the legacy environment isn't free either.

Done badly, we simply create another generation of technical debt.

The old ERP remains.

The customisation remains.

Then we add APIs.

Then integration platforms.

Then data layers.

Then vector databases.

Then AI orchestration.

Then agents.

Eventually the supposedly modern architecture begins to resemble an archaeological site built on top of another archaeological site.

The objective cannot simply be to hide complexity from the AI.

It has to be to understand which complexity deserves to exist.

## Perhaps AI gives us the excuse ERP needed

There is an irony here.

For years, CIOs have struggled to justify ERP simplification programmes.

"Let's spend millions removing old customisations so upgrades become easier" isn't always the easiest board conversation.

The benefits are real, but they're frequently defensive.

Lower maintenance.

Reduced technical debt.

Simpler upgrades.

Less operational risk.

AI changes the economics of that conversation because simplification can now enable something the business actively wants.

Not just cleaner IT.

Better automation.

More reliable agents.

Faster experimentation.

Better access to enterprise data.

More trustworthy decisions.

The ERP clean-up programme stops being merely technical housekeeping and becomes part of the organisation's ability to exploit AI.

That may finally give CIOs the business case they have been missing.

But we shouldn't waste the opportunity by turning it into a giant de-customisation exercise.

## I would start with four questions

Before spending millions cleaning an ERP landscape in the name of AI, I would want four things answered.

**Does this customisation still create business value?**

Not *did* it create value when it was built. Does it create value today?

**Would we build it again?**

If we were implementing the ERP tomorrow, knowing what we know now, would anyone deliberately recreate this process?

**Can a machine understand it?**

Are the rules, data definitions, exceptions and ownership explicit enough that an AI system could interact with the process safely?

**What happens if we remove it?**

Not technically. Commercially. Operationally. For customers. If nobody can identify a meaningful consequence, we may have discovered complexity we're simply paying to preserve.

I would add one more question when AI enters the discussion:

**Who owns the decision when the AI gets it wrong?**

Because simplifying the technology does not remove business accountability.

These questions won't produce a perfectly clean ERP.

That's not the objective.

They should produce something much more useful:

**intentional complexity.**

## The Pragmatic View

ERP customisation isn't the villain of this story.

Much of it helped businesses grow, differentiate, acquire companies, enter markets and operate in ways standard software couldn't support.

The problem is that customisation has a half-life.

What differentiated the business in 2006 may be standard functionality in 2026.

What solved an urgent operational problem ten years ago may now exist simply because nobody has been brave enough to remove it.

AI is exposing that accumulated history.

And I suspect that as enterprises move from copilots that advise humans towards agents that actually interact with operational systems, the distinction will become increasingly important.

The winners won't necessarily be the companies with the cleanest ERP.

Nor will they automatically be those running the newest version of SAP or Oracle.

They will be the organisations that know **why their complexity exists**.

Keep the customisation that genuinely differentiates the business.

Modernise what prevents change.

Remove what exists only because it has always existed.

And don't spend millions teaching AI to navigate twenty years of decisions that your organisation would never make again.

**AI may finally force us to clean up the ERP.**

**Just don't accidentally clean out the competitive advantage with it.**
