By R. P. Singh, Founder, ERPClimb
AI can now read legacy code, map custom objects and draft remediation in minutes. What it cannot do is own the consequences. This article offers CIOs and enterprise architects a four-lens framework for deciding which AI suggestions to accept, which to review, and which to reserve for human architecture decisions.
ERP modernization has a new accelerator. Generative AI tools can scan thousands of custom objects, explain decades-old code, propose replacements for deprecated tables and draft test cases. For programmes facing fixed deadlines, such as the end of mainstream maintenance for legacy SAP ECC releases, that speed is welcome.
But speed has created a quiet risk. When a tool produces a confident, well-formatted recommendation in seconds, teams start treating it as a decision rather than an input. In ERP landscapes, where one change can touch finance close, tax, logistics and a dozen interfaces, that shift is expensive. The question for leadership is no longer whether to use AI in modernization. It is which decisions AI may make, and which must stay with accountable architects.
Where AI genuinely helps
AI earns its place in the parts of modernization that are large, repetitive and verifiable. In these areas, a wrong answer is cheap to detect and cheap to fix:
• Discovery and inventory. Classifying custom objects, finding unused code and grouping similar enhancements.
• Code explanation. Summarising what an undocumented report or user exit actually does, in plain language.
• Mechanical remediation. Proposing syntax changes for deprecated statements, obsolete tables or changed data types.
• Test scaffolding. Drafting test cases and data scenarios from existing logic.
• Documentation. Producing first-draft functional and technical specifications for review.
The common thread is that a qualified person can check the output quickly. AI shortens the work; it does not change who is accountable for it.
Why the hard decisions remain architectural
The decisions that shape a modernized ERP are rarely about code. They are about tradeoffs that depend on context an AI model does not see.
Consider a custom ageing report that reads open items directly from legacy tables. An AI tool may correctly propose switching to a compatibility view. The code compiles, unit tests pass and user acceptance testing succeeds on a small data set. Then month-end close runs on production volumes, and the report times out. The suggestion was syntactically right and architecturally wrong. The real answer, such as a redesigned data model, a standard report or a different extraction pattern, required knowing how finance actually closes the books.
This pattern repeats across programmes:
• AI optimises locally. It fixes the object in front of it, not the landscape around it.
• AI lacks business context. It cannot know that a field feeds a regulatory return, or that a warehouse runs a night shift.
• AI is confident by default. Output reads the same whether it is certain or guessing, including references to notes or documentation that may not exist.
• AI does not carry accountability. When a payment run fails or an audit finding lands, the decision belongs to a person.
None of this argues against AI. It argues for a clear line between AI-generated options and human-owned decisions.
A four-lens framework for assessing AI suggestions
Every AI recommendation in a modernization programme can be tested against four lenses. Each asks a question the model cannot answer on its own.
|
Lens |
The question to ask |
Warning signs in an AI suggestion |
|
Integration risk |
What else reads, writes or depends on this object? |
Changes to shared tables, interface structures, IDocs, APIs or batch jobs consumed by other systems |
|
Security and compliance |
Does this change who can see or do what, or where data goes? |
Altered authorisation checks, new data flows to external services, changes touching personal or financial data |
|
Business process criticality |
What breaks, and for whom, if this is wrong? |
Logic in order-to-cash, procure-to-pay, record-to-report, payroll, tax or period-end close |
|
Upgrade resilience |
Will this survive the next release, or become new technical debt? |
Modifications to standard code, unreleased APIs, direct table access where released interfaces exist |
Integration risk. ERP objects rarely live alone. A field length change can break a middleware mapping; a renamed structure can silently stop a downstream feed. AI tools usually analyse one object at a time, so architects must map the dependency chain before accepting the change.
Security and compliance. AI-generated code can remove an authorisation check as “redundant” or route data to a service outside approved boundaries. Any suggestion that changes access, data movement or logging needs security sign-off, regardless of how small it looks.
Business process criticality. The same technical change carries very different risk in a rarely used report and in the payment run. Criticality, not code complexity, should set the level of review.
Upgrade resilience. Clean-core principles favour extensions through released interfaces over modifications. AI may propose the fastest fix rather than the most durable one. Architects should ask whether the change keeps the system upgradeable for the next five years, not just compiling today.
Routing AI suggestions: a practical decision rule
Score each suggestion Low, Medium or High on the four lenses. The highest score decides who owns the decision.
Figure 1. One high score on any lens sends the suggestion to an architect, however small the change looks.
|
Highest lens score |
Typical examples |
Who decides |
Required evidence |
|
Low on all four |
Syntax updates, comments, unused-code removal in isolated reports |
Developer accepts after review |
Code review and automated tests |
|
Medium on any lens |
Changed data access in a shared report, new test data, modified job logic |
Lead developer or functional lead |
Peer review, regression test on realistic data volumes |
|
High on any lens |
Interface changes, authorisation logic, period-end processes, modifications to standard objects |
Solution or enterprise architect |
Design decision record, impact analysis, security review, business sign-off |
Two rules keep the model honest. First, a suggestion inherits the highest score of any lens; a low-risk syntax fix inside the payment run is still a high-criticality change. Second, any external reference the AI cites, such as a vendor note, an API or a configuration path, must be verified against the source before it enters a design document.
A governance model for CIOs
The framework only works if it is built into how the programme runs. Five practices make the difference:
1. Label AI-generated work. Every AI-assisted change should be marked in the transport, pull request or change record, so reviewers know what they are checking.
2. Keep an architecture decision log. High-scoring changes need a short record: the options considered, the AI suggestion, the decision and the reason. Auditors and future teams will ask.
3. Test at production scale. Many AI-assisted changes pass functional tests and fail on volume. Include realistic data volumes in regression testing for anything that touches period-end or high-frequency processes.
4. Set data boundaries for AI tools. Decide which code, configuration and business data may be sent to external AI services, and under what contract terms, before teams start using them.
5. Measure outcomes, not output. Track defects, rework and post-go-live incidents traced to AI-assisted changes, not just the number of objects remediated. Speed that returns as production defects is not speed.
Conclusion
AI is changing the economics of ERP modernization. It removes much of the slow, repetitive analysis that once consumed months. That is exactly why the remaining decisions matter more, not less.
The organisations that gain most will not be those that automate the most decisions. They will be those that are clearest about which decisions must stay human: integration design, security boundaries, process-critical logic and long-term upgradeability. Let AI generate the options. Let accountable architects choose.
|
|
ABOUT THE AUTHOR R. P. Singh · Founder, ERPClimb R. P. Singh is the founder of ERPClimb (erpclimb.com), an independent SAP learning and technical knowledge platform developed with experienced SAP architects. ERPClimb helps SAP consultants and architects prepare for S/4HANA projects and resolve real production issues. |
