Strategy to Outcomes – Article  Series -2- AI in ERP. Compensatory Control or Design Intelligence?

Central thesis

AI has a legitimate role in ERP-enabled enterprises, but not always where it is first positioned. When AI agents are used to absorb messy supplier communications, missing information, unclear requests, manual coordination, part searches, dispatch conflicts or exception handling, they can recover time and reduce pain. That can be valuable. But it does not automatically prove that the underlying cost structure has changed, the root cause has been removed, or the ERP operating model has improved.

AI is valuable when it reduces irreducible ambiguity. It becomes compensatory control when it industrialises avoidable complexity.

Standard ERP functionality should own the deterministic core. Humans should own feedback and redesign once tolerances are breached. AI should support design, scanning, evidence gathering and exception interpretation. It should not become a permanent buffer that protects poor process design from being fixed.

Risk management reality

Before this becomes a software discussion, it should be treated as a risk-management discussion. In any complex operating system, overload is not solved by pushing more signals to the user or by inserting another automation layer to absorb the noise. Good control design reduces avoidable variation, sets tolerances, clarifies decision rights and escalates only what requires judgement.

That is the same design challenge now appearing in ERP and AI. If AI is used only to absorb supplier noise, missing information, unclear requests, parts searches and operational ambiguity, it may reduce visible workload while leaving the risk architecture unchanged. The organisation has not necessarily improved control. It may have created a more efficient compensating layer.

The better question is not "can AI handle the overload?" It is "what risk is the operating model creating, and should that risk be removed, bounded, monitored or escalated?" This is more than selling software. It is an accountability question about system design, tolerance breach, human governance and redeployment into the ERP control layer.

In Strategy to Outcomes terms, AI should help move compensatory control into system control. It can support environmental scanning, internal scanning, exception classification and design analysis. But once signal tolerances are breached, the feedback response is a human risk-management activity. Understand the cause, decide the control response, update the design repository, test the ERP change and redeploy.

AI can accelerate risk visibility. It should not become the hidden control that makes unmanaged risk operationally tolerable.

1. Why this must be vendor-neutral

Recent anecdotal commentary around enterprise AI agents has focused on rapid deployment, recovered hours, operational efficiency and faster handling of manual work. Those claims may be directionally useful, but they are not sufficient as a value case on their own.

A claim that an AI agent recovered time does not, by itself, prove that the business has changed the cost structure. It may simply show that the organisation has moved work from visible manual effort into a new metered operating layer. It also may not show whether the root cause of the work has been removed.

That is why this article avoids naming vendors, customers or public case examples. The issue is not one company or one product. The issue is an emerging pattern in ERP: AI is being positioned as an operational coordination layer before the business has always proven whether the work should be redesigned, configured or governed through standard ERP capability first.

2. What anecdotal commentary supports - and what it does not

Anecdotal commentary often describes situations such as supplier confirmations being handled manually, technicians searching for parts, field teams needing knowledge at the point of service, planners resolving dispatch conflicts, or finance teams dealing with invoice exceptions. These are credible pain points. AI can help users interpret information, assemble context, draft communications and reduce coordination effort.

But the same commentary often leaves the most important design questions unanswered:

Was the manual work caused by genuinely unstructured information?

Was the cause weak master data, weak planning parameters or incomplete workflow design?

Was standard ERP functionality available but not configured, adopted or governed?

Was the supplier, technician, planner or buyer compensating for a design gap?

Did the AI remove the cause of the work, or simply process the symptom faster?

Recovered hours are useful evidence. They are not proof that the underlying operating model has improved.

3. Compensatory control versus regulatory control

The core distinction is between compensatory control and regulatory control.

AI becomes compensatory control when it repeatedly reads the email, searches for the part, interprets the exception, drafts the follow-up and keeps the work moving without causing the operating model to improve.

AI contributes to regulatory control only when it helps humans detect the signal, assemble evidence, classify recurring patterns and support redesign through the ERP design repository.

AI can expose the signal. Humans must decide what the signal means.

4. Standard ERP functionality first

For repeatable ERP processes, the design obligation is to use standard ERP functionality to manage the stable core. In many core scenarios, the work is deterministic: approved supplier, item master, purchase agreement, approval authority, cost centre, delivery site, tax code, payment terms, inventory rule, work order logic, audit trail and segregation of duties.

That core should not be handed to AI simply because AI can interact with it. If the ERP can execute the stable scenario deterministically, the first task is to configure, govern, test and redeploy the ERP process.

A useful rule is the 80 percent principle. The ERP should handle the known, repeatable core. The remaining 20 percent should not automatically become the AI domain. It should first be treated as feedback evidence: what has the organisation not yet designed, governed or regulated?

ERP handles the known core. Humans expose the unresolved edge.  

The design repository converts repeatable exceptions into tested ERP capability. AI supports the analysis; it does not own the feedback loop.

5. Manual intervention is a sensor, not only waste

Manual intervention is often treated as inefficiency. In a governed ERP operating model, it is also a sensor. It tells the organisation that a scenario was not fully designed, a rule is missing, master data is weak, supplier behaviour is recurring, an approval path is unclear, a planning parameter is wrong, or a workflow is incomplete.

Once tolerances are breached, the feedback loop becomes a human governance activity. AI may detect, classify, summarise and recommend. But the design decision belongs to process owners, functional leads, operations, finance, procurement, service, supply chain and the ERP design authority.

This matters because if AI both absorbs the exception and adjusts the workaround, the organisation can create a closed compensatory loop: weak process, AI compensation, tolerance breach, AI-adjusted workaround, weak process remains.

A regulatory loop is different: weak process, signal detected, tolerance breached, human governance review, root cause identified, design repository updated, ERP solution redesigned, tested and redeployed.

AI is not the feedback loop. AI is an input to the feedback loop. The feedback loop is human governance acting through the design repository.

6. AI belongs in the unexpected places: design, feedback and scanning

This is the positive balance. The critique is not that AI has no value. The critique is that AI should not be used as a permanent compensating layer for avoidable process weakness.

AI may have stronger value in the unexpected places: high-level design, detailed design, feedback, environmental scanning and internal scanning.

AI belongs where the organisation is still learning, not where the organisation has already designed the rule.

7. Cost model: the midline case

The balanced cost argument should use a midline case, not a stress case. A routine controlled ERP-adjacent AI event should not be assumed by default to consume hundreds of thousands of tokens. That higher range is more appropriate for full-agentic, document-heavy or poorly bounded workflows.

For discussion purposes, use the following midline modelling assumptions:

The midline compute-only event cost is:

60,000 / 1,000,000 x A$9 = A$0.54 per business event

That is deliberately balanced. It does not claim that every AI event is expensive. It says the clean, bounded event cost can be modest. The risk is not one well-bounded event. The risk is repeated operational dependence, premium model routing, retrieval sprawl, accumulated context, retries, attachments, governance overhead and vendor-controlled pricing surfaces.

8. Simple A$1,000 manufacturing unit example

Use a simple manufacturing unit to make the economics visible.

If one midline AI-supported event is attached to the unit and labour is unchanged, the new contribution margin is:

A$1,000 - A$750 - A$0.54 = A$249.46

At 100,000 units per year, the new AI compute line is A$54,000, assuming one midline event per unit and no offsetting benefit. That is not catastrophic. But it is a new variable cost line. If AI-supported events are added across requisitions, supplier confirmations, order amendments, delivery changes, invoice exceptions, quality issues, dispatch exceptions and maintenance events, the variable cost line compounds.

The question is not whether one AI event is affordable. The question is whether the enterprise is turning recurring operational variation into a metered digital operating cost.

9. ERP configuration comparator

Assume a one-time ERP configuration, workflow or design improvement costs A$200,000 and supports 100,000 events per year. The year-one cost is A$2.00 per event. Over three years it falls to A$0.67 per event. Over five years it falls to A$0.40 per event, before considering maintenance or redesign.

AI can look economically attractive in year one, especially when it is bounded, targeted and used at the ambiguous edge. But ERP configuration creates a reusable deterministic process asset. The longer the process remains stable, the stronger the case for standard ERP functionality first.

10. Power analogy and commercial cost capture

The power analogy works as a governance analogy, not as a literal token-price forecast. A manufacturer understands that every machine cycle consumes energy. Power is metered, volume-sensitive and exposed to external pricing. AI compute has a similar operating-cost shape: business event x compute consumed x provider tariff = cost.

The point is not to predict that AI pricing will rise like electricity. Public AI prices may fall, split into tiers, move by model class, or shift through charges for search, retrieval, grounding, runtime, memory, priority, residency, observability or tools. The stronger point is that metered operational costs need unit-cost governance.

The commercial risk is cost capture. If an operating process becomes dependent on a proprietary AI layer, the business may become dependent on that layer for model routing, context management, retrieval behaviour, tool pricing, audit surfaces, governance features and future pricing schedules.

A manufacturer would not ignore kilowatt-hours per unit. An ERP-enabled enterprise should not ignore AI cost per business event.

11. Governance: when should AI be allowed to act?

The governance issue is not whether AI is allowed. The issue is where AI is allowed and what happens when its work reveals repeatable variation.

This turns AI from a hidden compensating buffer into a governed sensing and design support layer.

12. Conclusion

AI is not the enemy of ERP. AI is also not a substitute for design discipline.

When AI is used to absorb messy operational work, it may act as compensatory control. It can reduce pain, recover time and keep the system moving. But if the root cause remains, the enterprise may simply move cost from visible manual effort into a metered digital operating layer.

The better role for AI is more interesting. AI belongs in the unexpected places: design, feedback, environmental scanning and internal scanning. It can help humans see patterns, structure evidence, identify scenarios, test design hypotheses and improve the ERP control layer.

Standard ERP functionality first. Humans own feedback and redesign. AI supports design, scanning and evidence. Do not let AI become a buffer that protects poor design from being fixed.

#StrategyToOutcomes #ControlRegulators #ERP #ERPImplementation #ValueRealisation #BenefitsRealisation #AI #DigitalTransformation