THE FUTURE OF CONSULTING IN SERVICE AND ASSET MANAGEMENT
AI-enabled SAP consulting for Enterprise Asset Management
From configuring applications to designing an end-to-end system for Asset Management.
Contents
- Executive summary
- 1. The distinction that matters
- 2. Why EAM needs a systems perspective
- 3. What AI removes – and what it makes more valuable
- 4. The future value proposition: end-to-end EAM system design
- 5. Implications for S/4HANA, APM, and FSA consulting
- 6. Onshore delivery and critical infrastructure
- 7. The consulting operating model of 2030
- 8. What will remain difficult
- 9. A practical roadmap
- Conclusion
- References
- Appendix A
- Appendix B
Executive summary
Artificial intelligence will change SAP consulting in Enterprise Asset Management (EAM) in two distinct ways. First, AI can be embedded in the customer’s operating model: it can support maintenance planning, diagnosis, scheduling, risk assessment and other Asset Management decisions. Second — and more immediately material for the consulting industry — AI will change how SAP consulting itself is delivered.
This paper focuses on the second change. It argues that AI will substantially reduce the effort required for research, documentation, specification writing, coding, test creation, data analysis, configuration support and knowledge retrieval. The principal consequence is not merely faster delivery of traditional projects. It is a structural change in the consulting model.
The winning consultant will increasingly be the professional who can design an end-to-end system for Asset Management: a coherent combination of business outcomes, operating processes, S/4HANA and public cloud applications, integrations, data, rules, people, controls and — where applicable — AI capabilities. The consultant’s value will shift from producing configuration artefacts to making sound design choices across the entire system.
This shift matters especially in EAM. Asset Management is inherently cross-functional and information-intensive. Its outcomes depend on the interaction of technical asset structures, maintenance strategies, work management, planning and scheduling, materials, field execution, condition data, engineering knowledge, safety obligations and financial priorities; in short: people, processes, and assets. No isolated application configuration can optimize that system on its own.
As AI absorbs more implementation production work, highly experienced onshore consultants can apply more of their time to architecture, customer discovery, design trade-offs, assurance, adoption and value realization. The traditional pyramid — few senior consultants directing a larger layer of junior or offshore analysts, developers and documentation resources — will become less economically compelling for many work packages. That has particular significance for customers in critical infrastructure, regulated sectors and security-sensitive environments, where local presence, language, contextual understanding, trusted personnel, and controlled delivery are essential.
The proposition is therefore not “AI replaces SAP consultants.” It is:
AI reduces the volume of consulting production work and raises the value of experienced consultants who can design, govern and continuously improve end-to-end business systems.
In other words: AI makes the experienced consultants more efficient while reducing the need for inexperienced consultants or a large volume of offshore work. This poses a particular challenge for consulting companies that are largely based on offshore capacity.
THE WORKING TOOLS
The EAM AI Governance Field Kit
The checklists behind Appendices A and B, built to be used in a workshop rather than read.
- Authority envelope — the six questions, with space to answer them per process
- Oversight allocation table — decision categories mapped to required controls
- Six-layer reference model — blank, for your own architecture
PART 01
The distinction that matters
Any discussion of AI and SAP EAM should distinguish two different, although related, subjects.
1.1AI in Asset Management
This is the use of AI within the customer’s operational environment. Examples include:
- recommending a maintenance action from condition data and work history;
- extracting failure information from unstructured technician reports;
- identifying asset risk patterns;
- preparing a maintenance order or service visit proposal;
- assisting planners with prioritization and material availability;
- supporting technicians with relevant instructions, safety information, and troubleshooting knowledge.
These use cases can be strategically valuable. They may be implemented through SAP capabilities, SAP Business AI Platform services, specialist reliability platforms, industrial IoT solutions or customer-specific AI components.
However, they are not the primary subject of this paper. They are covered in sections 4.3 and 4.4 insofar as designing AI-enabled Asset Management processes becomes part of the consultant’s work — and therefore of the qualification a consultant needs.
1.2AI for SAP consulting
This is the use of AI by consultants and delivery organizations while analyzing, designing, building, testing, documenting, deploying and improving SAP solutions.
Typical applications include:
- synthesizing discovery material, interviews, process documents, and workshop notes;
- searching and interpreting SAP documentation, release information, notes, APIs, and configuration guidance;
- drafting requirements, fit-to-standard decisions, functional specifications, and design documents;
- comparing legacy processes, custom developments, and target-standard processes;
- generating or reviewing code, integration mappings, data transformations and test scripts;
- creating training material, user documentation, cutover plans and operational runbooks;
- analyzing tickets, defects, support history and test evidence;
- creating first drafts of customer-facing content while retaining expert review and accountability.
This second category changes the economics and organization of consulting. It can affect every project irrespective of whether the final customer solution itself includes advanced AI.
A maintenance organization may initially run conventional S/4HANA maintenance processes, with little or no agentic automation in production. Its implementation program can nevertheless be delivered very differently: faster discovery, better-quality documentation, less manual coding, more systematic test coverage, and a smaller delivery pyramid.
1.3The practical rule
The two dimensions should be treated separately in every client conversation:
| Question | AI in service and Asset Management | AI for SAP consulting |
|---|---|---|
| Primary objective | Improve operational Asset Management decisions and execution | Improve the quality, speed and economics of consulting delivery |
| Main beneficiary | Maintenance, reliability, operations, and field-service teams | Customer project teams, SAP partners, and internal IT organizations |
| Core design concern | Decision quality, safety, accountability and operational adoption | Consulting productivity, quality assurance, knowledge reuse, and delivery governance |
| Typical output | Recommendation, alert, prioritization or controlled transaction | Design artefact, configuration proposal, code, test case, document or analysis |
| Key risk | Unsafe or incorrect operational action | Incorrect design, insecure change, fabricated evidence or unmanaged quality risk |
Table 1. The two dimensions should be treated separately in every client conversation.
The consultant of the future must understand both. But a consulting strategy should not make its own productivity transformation dependent on the customer’s readiness to deploy AI in maintenance operations.
PART 02
Why EAM needs a systems perspective
Traditional SAP projects often divide work by application and workstream: maintenance, materials management, finance, integration, mobility, analytics and development. This remains necessary for delivery control, but it is not how Asset Management outcomes are created.
An asset owner does not ultimately buy a configured maintenance notification, a work order type or a mobile screen. The organization seeks outcomes such as:
- safe and compliant operation;
- higher asset availability and predictable production capability;
- lower risk of asset failure;
- appropriate maintenance cost and labor productivity;
- improved field service responsiveness;
- more reliable maintenance planning;
- credible asset performance insight;
- controlled capital and lifecycle decisions.
These outcomes emerge from an end-to-end Asset Management system — in the sense of ISO 55000/55001, a management system for Asset Management [1] — that is supported by an end-to-end EAM system, i.e. an IT system. The system comprises more than applications:
Terminology note
The distinction carrying this section is between two different kinds of thing. The Asset Management system is a management system in the ISO 55001 sense. The EAM system is the IT system that supports it. What ISO certifies is the governance apparatus, not the lifecycle work.
- Business outcomes and decision rights: What must improve? Who may decide, approve, defer or override?
- Operating processes: How is work identified, assessed, planned, scheduled, executed, confirmed, and improved?
- Business capabilities and applications: What belongs in S/4HANA, Asset Performance Management (APM), Field Service and Asset Management (FSA, fka FSM), Business Network Asset Collaboration (BNAC, fka AIN), SAP Service and Asset Manager (SSAM), SAP Business AI Platform (BAIP, consolidating Business Technology Platform, Business Data Cloud and SAP Business AI), SAP Analytics Cloud (SAC) or a non-SAP specialist system?
- Data and knowledge: Are asset hierarchies, bills of material, task lists, catalogues, failure data, condition information, documents and history trustworthy and accessible?
- Integration and orchestration: How do operational technology (OT), GIS, document systems, procurement, workforce systems, and enterprise applications work together?
- People and adoption: Do planners, technicians, engineers, supervisors and managers have usable roles, information, and incentives?
- Controls and assurance: How are safety, segregation of duties, cybersecurity, auditability, service levels, and regulatory obligations managed?
- Continuous improvement: How does experience from execution alter plans, strategies, data quality, and investment decisions?
The future SAP EAM consultant is therefore not merely a configurator of application features. The role is closer to an EAM system designer: someone who uses SAP applications and surrounding technology to create an operating system for asset-intensive decisions and operations.
The role, restated
This does not diminish the importance of detailed S/4HANA, APM or FSA expertise. It makes that expertise more valuable when it is applied in a broader architecture and value context.
PART 03
What AI removes – and what it makes more valuable
AI will not eliminate all delivery work. It will, however, materially reduce the time spent producing first drafts, locating information, translating between artefact types, and repeating familiar patterns.
3.1Work that will be increasingly AI-assisted
| Consulting activity | Likely AI contribution | Continuing human responsibility |
|---|---|---|
| Discovery preparation | Summarize documents, identify themes, prepare interview questions | Validate stakeholder context, uncover unstated constraints and establish trust |
| Requirements and process documentation | Draft process narratives, requirements, decisions and traceability matrices | Make trade-offs, resolve conflicts and secure customer commitment |
| SAP knowledge research | Retrieve and synthesize documentation, APIs, notes and release information | Confirm applicability, release status, contractual scope and technical correctness |
| Functional specifications | Produce initial drafts, mappings, scenarios and acceptance criteria | Ensure semantic correctness, exception handling, controls and maintainability |
| Development | Generate code scaffolding, tests, explanations and review suggestions | Define architecture, security, performance, clean-core compliance and production suitability |
| Integration | Draft mappings, interface contracts and error scenarios | Decide canonical semantics, ownership, resilience and operational support model |
| Testing | Generate test cases, test data proposals and regression scenarios | Prioritize risk, assess evidence and approve release readiness |
| Documentation and training | Create tailored drafts, role-based guides and change material | Ensure accuracy, usability, organizational fit and accountable sign-off |
| Support analysis | Cluster incidents, retrieve similar cases and propose hypotheses | Diagnose ambiguous causes, manage major incidents and decide corrective action |
Table 2. Every row keeps a named human on the right-hand side. That column is the profession.
The key phrase is AI-assisted, not “AI-uncontrolled”. Particularly in enterprise software, a persuasive draft is not evidence that a design is right. AI may accelerate production of artefacts; it does not remove the need for expert judgement, customer accountability, security review or formal approval.
3.2The consulting production layer shrinks
The traditional delivery model has often depended on a large production layer. Solution architects, principal and senior consultants establish direction; analysts collect and transform information; offshore teams prepare documentation, build components, run repetitive tests and create deliverables; more experienced staff review and correct the output.
AI compresses several of these activities:
- A workshop recording can become a structured decision log, process draft and open-issue list in hours rather than days.
- A qualified consultant can create an initial functional design, test pack and training outline from a shared process model instead of commissioning multiple rounds of manual preparation.
- Existing code, configuration evidence and incident history can be analyzed in bulk before a solution architect begins targeted review.
- A standard integration or extension pattern can be drafted, checked and documented faster, leaving more time for the exceptional aspects that actually determine project risk.
The result is not automatically fewer people in every project. A customer may choose to reinvest productivity gains in broader scope, better data remediation, more robust testing or stronger adoption. But the economic need for a large, lower-cost delivery base declines where work is highly structured, knowledge-intensive, and review-heavy.
The evidence
These effects are not merely anecdotal. In a field experiment with 758 consultants of the Boston Consulting Group, participants using GPT-4 on tasks within the AI’s capabilities completed 12.2% more tasks, 25.1% faster and at more than 40% higher quality than a control group. On a task deliberately chosen to lie outside those capabilities, however, consultants using AI were 19 percentage points less likely to reach a correct solution [2]. Both findings matter here: the first supports the productivity argument, the second the case for experienced judgement made in section 3.3. Our own project experience is consistent with both.
3.3Experience becomes more — not less — valuable
AI makes experienced consultants more productive because it amplifies their ability to:
- ask the right questions;
- recognize when a plausible answer is wrong;
- distinguish a generic best practice from an unsafe or unsuitable one;
- identify hidden cross-process dependencies;
- decide what must remain simple, deterministic and governed;
- challenge customer assumptions constructively;
- translate between operations, engineering, IT, finance, and executive stakeholders;
- make design decisions that preserve maintainability over years rather than merely achieve a project milestone.
3.4The talent pipeline
If AI absorbs much of the production work through which consultants have traditionally gained experience, where will the next generation of EAM system designers come from? This is probably the most serious long-term question raised by the argument of this paper.
Junior talent will still be needed, but its development model changes. Rather than spending years on document formatting, repetitive test execution or simple specification drafting, it should learn to validate AI output, work with structured knowledge, understand process semantics and build progressively deeper domain judgement.
We expect the overall number of consultants to decline and the entry bar to rise. Those who progress will be the ones who learn fastest by working with AI: validating and challenging its output, and using it to access the body of knowledge that experienced practitioners have captured in the firm’s methods, patterns and knowledge bases (see section 7.2). Firms that want to grow senior talent can therefore no longer rely on years of production work to create experience as a by-product. They need deliberate apprenticeship models — pairing junior and senior consultants in customer-facing work, rotating juniors through validation and assurance roles, and making knowledge capture an explicit part of every engagement.
PART 04
The future value proposition: end-to-end EAM system design
The central transition can be expressed simply:
From configuring individual processes in an application to establishing a governed, end-to-end EAM system that enables Asset Management outcomes, i.e. that helps the organization realize value from its assets.
This changes both the conversation with the customer and the deliverables of the consultant.
4.1A different starting point
The conventional starting question is often:
“How should this maintenance process be configured in S/4HANA?”
The future starting question is:
“What end-to-end capability must the organization establish to manage asset risk, work, information, and decisions effectively — and what role should each system, person and automation play?”
For example, “improve corrective maintenance” is not a PM configuration topic alone. It may require:
- clear failure reporting standards;
- relevant technical object structures;
- mobile execution capabilities;
- access to current technical documents;
- triage and prioritization rules;
- spare parts visibility;
- planner and supervisor workflows;
- integration with condition or operational data;
- a feedback loop from work completion into reliability improvement;
- metrics that measure not only order closure but repeat failure and risk reduction.
S/4HANA, APM, and FSA each contribute to such a system, but none is the system by itself.
4.2A reference model for the system
A practical consulting framework can use six layers:
| Layer | Design question | Example Asset Management concerns |
|---|---|---|
| Value and outcomes | What business, risk and service outcome is targeted? | Availability, safety, response time, backlog quality, lifecycle cost |
| Operating model | Who does what, at what point, with what authority? | Technician, planner, reliability engineer, contractor, supervisor, central support |
| End-to-end process | How does a signal become a controlled action and a learning loop? | Detect, report, assess, plan, execute, confirm, analyze, improve |
| Application and automation | Which application, workflow, rule, skill or agent performs each capability? | S/4HANA maintenance and work management, APM risk insight, FSA dispatch, BAIP extension |
| Data, knowledge and integration | What context is needed, where is it mastered and how is it exchanged? | Asset master, documents, sensor data, GIS, materials, qualifications, work history |
| Governance and assurance | What must be controlled, explainable, auditable and reversible? | Safety, access control, approvals, audit trail, cybersecurity, retention |
Table 3. The framework holds whether the customer uses conventional automation, embedded analytics, generative AI, predictive methods or agentic workflows.
This framework remains valuable whether the customer uses conventional automation, embedded analytics, generative AI, predictive methods or agentic workflows. It protects the program from treating AI as an isolated feature rather than a component in a managed operating model.
4.3A controlled use of AI in the target system
Where customers do introduce AI into Asset Management, a useful design principle is to separate three automation classes:
- Deterministic automation: Rules, workflows and validations with known inputs and predictable outputs. These should remain the default for high-volume, stable and safety-relevant transactions.
- AI-assisted work: AI prepares summaries, classifications, recommendations or documents; a responsible person decides or confirms.
- Controlled agentic execution: An AI-enabled component coordinates multiple tools and can execute limited actions within explicit authority, approval and audit boundaries.
The most mature design does not maximize autonomy. It allocates autonomy where it is safe, economically worthwhile and operationally understandable.
SAP’s current direction around Joule, skills, agents and Joule Studio is relevant because it provides a path for connecting business context, automation, and SAP/non-SAP tools. SAP describes Joule Studio as a capability in SAP Build for creating Joule agents and skills, distinguishing skills that execute predefined, rule-based operations from agents that plan and reason dynamically [3]. This makes architectural judgement essential: an agent should be used only where its additional reasoning and orchestration capabilities produce a clear benefit over a rule, workflow or conventional integration.
4.4Human oversight by design
AI-enabled EAM systems must be designed around explicit human decision rights, not around the maximum technically possible degree of automation. The relevant question is not whether a system can act autonomously, but whether it should do so in a specific operational, safety and regulatory context.
Human oversight can take three forms — human in the loop, human on the loop and human in command [4]. Appendix A defines them and maps them to typical EAM decision categories.
The required degree of oversight depends on the impact of the decision, the criticality of the asset, the reversibility of the action, the quality and completeness of evidence, the level of autonomy and the consequence of error. The same nominal use case may require different controls in different environments: an automatically generated work order proposal for a low-criticality building asset is not equivalent to one affecting a safety-critical component in an electricity, water, transport or process-industry environment.
Regulatory anchor
Effective human oversight is more than a review button. The designated person must understand the system’s purpose and relevant limitations, receive intelligible evidence, recognize anomalous behavior, have sufficient time and authority to intervene, and be able to override, reverse or safely stop the AI-enabled process. For high-risk AI systems, Article 14 of the EU AI Act requires systems to enable effective human oversight during operation in order to minimize risks to health, safety and fundamental rights [5].
In EAM, an AI tool may summarize maintenance history or propose a failure classification with proportionate oversight. By contrast, a recommendation to defer safety-critical maintenance, change a maintenance strategy, prioritize work on critical infrastructure or trigger a physical operational action should require defined human approval and complete, auditable evidence.
For every AI-enabled process, the consultant should also define an explicit authority envelope: which data and systems the AI component may access, which actions it may propose, prepare or execute, within which thresholds, and when it must escalate to a human. Appendix B provides a checklist and an example.
Evidence, intervention and controlled learning
A meaningful human decision requires more than a generic AI recommendation. The decision interface should provide relevant asset criticality, operating context, source documents, historical cases, condition data, missing or conflicting information, alternative options and the reasons for escalation. This is necessary to reduce automation bias: the tendency to place excessive trust in an automated recommendation. Article 14 guidance for high-risk systems explicitly addresses the need for oversight personnel to understand system capabilities and limitations, correctly interpret outputs, detect anomalies and avoid over-reliance [5].
The system must also support intervention. A user with the appropriate authority must be able to reject or modify an outcome, withdraw or reverse a generated transaction where technically possible, pause an agent, disable access to individual tools or interfaces, route cases to a manual exception queue and move the process to a safe state.
The rule that is easiest to get wrong
Finally, human corrections should not automatically become permanent system learning. The operating model must distinguish a one-off local exception from a repeatable pattern, a formal rule change, a change in maintenance strategy, a data-quality remediation requirement or a controlled model/prompt/agent update. Otherwise, isolated exceptions can silently alter operational behavior without proper governance.
All of this requires comprehensive industry- and domain-specific experience of the consultant advising the client.
PART 05
Implications for S/4HANA, APM, and FSA consulting
5.1S/4HANA: the transactional backbone, not the whole answer
S/4HANA remains central to core Asset Management transactions: technical objects, notifications, work orders, maintenance plans, material demand, confirmations, financial and cost implications as well as governance of operational work.
The future consulting task is not limited to configuring these objects correctly. It includes deciding how the S/4HANA backbone participates in the complete EAM system:
- Which events or data should trigger assessment and planning?
- Which decisions belong in standard business rules, and which need human assessment?
- Which information should be brought into the planner’s and technician’s moment of work?
- Which actions must be posted in S/4HANA, and which can be coordinated externally?
- How are extensions kept clean-core compatible and sustainable?
- How is execution feedback transformed into actionable and maintainable asset knowledge?
For existing S/4HANA or ECC-derived landscapes, AI can significantly accelerate discovery of custom code, legacy documentation, support history, variants, interfaces and local workarounds. Yet this increases the need for senior judgement: a system can describe what it does without revealing why it was designed that way, whether the rule is still needed or whether the practice is safe to standardize.
5.2Public cloud: fit-to-standard becomes a design discipline
Public-cloud solutions — and, to a lesser degree, private-cloud solutions — move more responsibility toward process standardization, configuration discipline, APIs and lifecycle-aware extensions; Clean Core applies as a design principle across all deployment options. The consultant’s contribution therefore becomes less about reproducing every historical variation and more about helping the customer make explicit choices:
- What should be standardized globally?
- Which variations reflect legal, safety or operational necessity rather than habit?
- Which capabilities should be built through approved extensibility mechanisms?
- Where should a customer adopt an external specialist capability rather than replicate it?
- How will quarterly change and feature adoption be governed?
AI can make fit-to-standard work more effective by comparing local process documents against reference models, generating structured gap inventories and preparing change-impact material. It cannot decide whether a local deviation reflects a critical safety practice, a contractual obligation or simply an inherited preference.
Fit-to-standard, honestly described
5.3APM and FSA: part of an outcome architecture
APM and FSA should be positioned not as adjacent products to be “implemented,” but as capability components in a broader EAM architecture.
- APM can contribute risk, condition, performance and maintenance strategy insight that informs work prioritization and operational decisions.
- FSA can contribute to dispatching, mobile execution, scheduling, and customer or field interaction capabilities.
- S/4HANA provides controlled enterprise transactions, core asset and work information, materials and financial integration.
- BAIP and integration services can provide orchestration, extension, event handling, analytics, and connections to external systems.
The consultant’s task is to define the operational hand-offs and closed loops. If APM identifies elevated risk, how does that influence a work request, a maintenance plan, a planner’s prioritization, a field-service schedule or a capital decision? If FSA reports a finding from the field, how is it validated, translated into decisions about the asset, and used to improve future maintenance strategies?
This is where the end-to-end system-design role becomes commercially and professionally distinctive.
PART 06
Onshore delivery and critical infrastructure
AI changes the onshore/offshore equation most materially where customers have strong requirements for trust, security, local understanding, onsite presence, and controlled access.
6.1Why the conventional delivery model is under pressure
Offshore delivery has traditionally offered scale and lower unit cost for activities such as documentation, development, test execution, data preparation, and production support. Yet its effectiveness depends on handovers, detailed instructions, stable requirements and the ability to share data and system access.
AI reduces the advantage of distributing some of this work to large remote teams because a smaller local team can produce and validate many of the same artefacts more quickly. It also removes some communication loss between a principal consultant, an intermediate analyst, and an offshore production team.
For work with substantial customer-specific knowledge, this matters. A local, experienced consultant who participates directly in workshops can use AI to turn contextual understanding into structured outputs immediately. That may be superior to transferring incomplete context through several delivery layers.
An obvious objection is that offshore-heavy providers will adopt AI as well, and could offer AI-amplified senior offshore teams or onshore front-ends with cleared staff at lower rates. They will — and for some work, such as large-scale regression testing, bulk data migration or follow-the-sun application management, scale and unit cost will remain decisive. Where context matters, however, the economics shift in favor of the onshore model. The saving from labor-cost arbitrage is, roughly, the rate difference multiplied by the production hours that can be relocated. As AI reduces those hours, the arbitrage pool shrinks, while the costs of coordination, handovers and lost context remain. At the same time, customer intimacy has always required an onshore presence, and many providers have already reduced it to the minimum. An experienced onshore team supported by AI no longer needs a large offshore production layer behind it.
6.2Why critical infrastructure is a special case
Energy, water, transport, industrial operations and other critical-infrastructure environments commonly impose heightened expectations around security, sovereignty, operational safety, resilience, personnel trust and incident response. In Europe, AI systems intended as safety components in the management or operation of certain critical infrastructure — including the supply of water, gas, heating or electricity — may be classified as high risk under the EU AI Act. High-risk obligations include risk management, data quality, logging, technical documentation, human oversight, robustness and cybersecurity; following the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), these obligations apply from 2 December 2027 to the high-risk use cases listed in Annex III, which include critical infrastructure [6]. Further requirements arise from resilience and cybersecurity regulation such as the NIS2 Directive and the Critical Entities Resilience (CER) Directive in Europe, the NERC CIP standards for the North American power sector and the Security of Critical Infrastructure (SOCI) Act 2018 in Australia — or simply from the need for resilient operations and the associated liability.
The distinction that protects you
Not every AI tool used during an SAP project will be a high-risk operational AI system. The distinction is essential. A consultant using an approved internal tool to draft a workshop summary is not equivalent to an AI component controlling a safety-relevant operating decision. Nevertheless, critical-infrastructure customers may impose their own stringent requirements even for project-delivery tooling:
- approved hosting and data-residency models;
- restrictions on sending project or operational information to external models;
- identity, access and audit requirements;
- local or cleared personnel requirements;
- segregation of sensitive environments;
- documented review and human approval of generated outputs;
- cyber-resilience and incident-management expectations.
A consulting firm that can combine strong EAM expertise, AI-enabled productivity, and credible onshore controlled delivery has an increasingly differentiated proposition in these markets.
6.3The new economic proposition
The value proposition should not be framed as “replace offshore with expensive onshore experts.” It is to use AI to give a smaller number of experienced, trusted consultants the productive capacity previously associated with a larger delivery pyramid — while improving context retention, quality control and customer proximity.
This model is particularly compelling when the cost of misunderstood requirements, weak documentation, insecure access or an incorrect process design is greater than the apparent saving from low-cost execution capacity.
North American and Australian customers may have different legal frameworks from Europe, but many asset-intensive industries share the same practical drivers: critical operations, cyber risk, service continuity, regulated assets, labor constraints and the need for accountable local expertise. The exact delivery model should therefore be adapted by jurisdiction and customer policy, but the underlying economic shift is portable.
SEE IT RUNNING
We don't just talk about it. We show you.
The arguments here are design arguments. The Grove is where they are standing up and running — on a fully configured SAP system, walked through live rather than described.
PART 07
The consulting operating model of 2030
A future-oriented SAP EAM consulting practice should build around four mutually reinforcing capabilities.
7.1Senior-led, AI-amplified delivery
Senior consultants remain directly engaged in discovery, architecture, critical design decisions, stakeholder alignment and quality assurance. AI serves as a structured production partner, not as an unsupervised substitute.
A practical workflow could be:
- Conduct a workshop with the relevant operational and IT stakeholders.
- Capture inputs in an approved environment.
- Use AI to create a draft process model, decision log, issue register, requirements baseline and follow-up questions.
- Have the lead consultant validate the substance with the stakeholders in the light of SAP Best Practices, industry good practice and Clean Core principles while the context is still fresh.
- Generate linked design, test, and change artefacts from the validated baseline.
- Maintain traceability from business outcome through process, configuration, integration, test, and operational procedure.
The result is not simply faster documentation. It is better continuity between conversation, decision, and delivery.
7.2Reusable EAM knowledge assets
The practice should develop reusable intellectual property in a controlled form:
- EAM capability maps;
- process reference models;
- design decision libraries;
- standard work management patterns;
- APM-to-work-management closed-loop patterns;
- FSA hand-off patterns;
- data-quality rules and semantic models;
- integration and event patterns;
- test libraries;
- controlled prompt and agent templates;
- governance checklists for AI-enabled solutions.
These are not generic slideware. They are the structured knowledge base from which consultants and AI tools can produce customer-specific work faster without losing professional discipline.
7.3AI delivery assurance
Every consulting organization using AI needs an internal assurance model. At a minimum it should define:
- permitted and prohibited information classes;
- approved models, tenants, and tools;
- rules for customer consent and contractual transparency;
- mandatory human review points;
- source and evidence requirements;
- handling of confidential data and personal data;
- retention and deletion requirements;
- intellectual-property treatment;
- quality and security controls for generated code;
- escalation procedures when AI output is uncertain or conflicts with expert judgement.
The higher the operational criticality of the customer environment, the more important it is to demonstrate that AI-enabled consulting increases control rather than weakening it.
Assurance as a sales argument
7.4Outcome-based commercial models
As routine production work becomes cheaper, traditional time-and-materials pricing based on effort volume may become harder to defend. Consulting firms can increasingly price for:
- a defined capability design;
- a target operating model;
- an EAM architecture and roadmap;
- a fit-to-standard decision package;
- a controlled implementation outcome;
- measurable improvements in planning quality, backlog health, field execution or asset information quality;
- managed continuous improvement.
This does not mean promising business outcomes beyond the consultant’s control. It means making the commercial unit of value closer to the customer’s intended capability and less dependent on the number of documents or development hours produced.
Questions that are still open
Several questions remain open and will determine how quickly such models are adopted: how a credible baseline is set when the delivery method itself is changing; how risk and reward are shared when outcomes also depend on the customer’s data, decisions and organization; and who carries liability for deliverables produced with AI assistance. Because outcome-based models lack the ceteris-paribus conditions that effort-based pricing implicitly assumes, we expect them to mature through practice — starting with fixed-price decision packages and capability designs, and moving only gradually toward shared-outcome arrangements.
PART 08
What will remain difficult
A credible paper should be clear about what AI does not solve.
8.1Ambiguity and competing objectives
Asset Management often involves legitimate conflicts: safety versus availability, standardization versus local necessity, preventive work versus production access, repair versus replacement, central governance versus field autonomy. These are not information-retrieval problems. They require judgement, negotiation and accountable decision-making.
8.2Weak data and weak operating discipline
AI can reveal inconsistent technical objects, incomplete failure coding, duplicate materials, outdated documents or poorly closed work orders. It cannot make those issues disappear. In some cases, AI will make poor data more visible — and therefore make foundational remediation more urgent.
8.3Trust and adoption
Technicians, planners, and engineers must understand how a new system affects their work. If an AI-generated recommendation is opaque, inaccurate or imposed without regard to practical conditions, adoption will fail. Good consulting remains human-centered: it designs for the practitioner’s moment of decision and makes accountability explicit.
8.4Accountability
In high-consequence environments, a system must answer: Who is responsible for this recommendation, this work priority, this release decision or this executed transaction? AI does not remove that question; it makes the answer more important.
PART 09
A practical roadmap
A consulting firm or independent practice can move toward this model in four stages.
Stage 1: AI-assisted personal productivity
- Adopt approved tools for research, drafting, code support, analysis and documentation.
- Establish basic quality, confidentiality and human-review rules.
- Measure time saved and quality improvements in real delivery work.
- Build individual capability without overclaiming autonomy.
Stage 2: AI-enabled delivery methods
- Standardize discovery-to-design workflows.
- Create reusable EAM templates, process models, test packs, and decision libraries.
- Introduce traceable, reviewed generation of specifications, test assets, and training content.
- Reduce handovers and improve senior-consultant leverage.
Stage 3: End-to-end system design offers
- Sell capability assessments rather than isolated module reviews.
- Position S/4HANA, APM, FSA, BAIP, and third-party platforms as components of an integrated EAM system.
- Create reference architectures for priority industries such as utilities, energy, transport, and industrial services.
- Embed data, integration, operating-model and governance design from the outset.
Stage 4: Controlled AI in customer operations
- Identify limited, high-value operational use cases.
- Begin with AI assistance and explicit human control.
- Define evidence, decision thresholds, authority limits and audit trails.
- Progress to controlled automation only where benefits, data quality, and governance are mature.
The sequence matters. A practice should first become excellent at using AI to improve its own work. It will then be more credible when advising customers on AI-enabled Asset Management operations.
Conclusion
AI will reduce the cost and time of many traditional SAP consulting activities.
For EAM consulting, the strategic response should not be to defend the old model of selling configuration capacity. It should be to move decisively toward the higher-value role of end-to-end EAM (and potentially Asset Management) system designer.
That role combines deep SAP knowledge with Asset Management expertise, data and integration architecture, operating-model design, governance and the ability to make difficult trade-offs with customers. It uses AI to remove low-value production work and to keep experienced consultants close to the decisions where their knowledge creates the greatest value.
The role also designs the boundary between human accountability, deterministic automation, and machine-assisted judgement. In AI-enabled EAM, human oversight is not a late compliance feature; it is a core part of process, operating-model and system architecture.
This creates a particularly strong opportunity in Europe, North America, and Australia for asset-intensive and regulated customers. In such environments, smaller AI-amplified teams of experienced onshore consultants can be commercially competitive while offering advantages that a conventional offshore-heavy delivery model cannot easily replicate (see section 6).
The consultant of 2030 will still configure systems when needed. But the defining contribution will be different:
Designing the connected, governed and continuously improving EAM system that supports an organization’s Asset Management system end to end.
References
[1] ISO 55000:2024 Asset management — Vocabulary, overview and principles; ISO 55001:2024 Asset management — Asset management system — Requirements. Geneva: International Organization for Standardization, 2024.
[2] Dell’Acqua, F., McFowland III, E., Mollick, E., Lifshitz-Assaf, H., Kellogg, K. C., Rajendran, S., Krayer, L., Candelon, F., Lakhani, K. R. (2023): Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School Working Paper 24-013, 22 September 2023.
[3] SAP SE: What is Joule Studio? https://www.sap.com/products/artificial-intelligence/joule-studio.html (accessed 15 October 2026).
[4] High-Level Expert Group on Artificial Intelligence (2019): Ethics Guidelines for Trustworthy AI. Brussels: European Commission, 8 April 2019.
[5] Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Article 14 — Human oversight. OJ L, 12 July 2024.
[6] Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulation (EU) 2024/1689 (Digital Omnibus on AI). OJ L, 24 July 2026; in force since 27 July 2026.
Appendix A – Human oversight models and autonomy levels
This appendix details the oversight models referred to in section 4.4 and maps them to typical EAM decision categories.
Table A.1 — Oversight models
| Oversight model | Meaning | Typical use | Design implications |
|---|---|---|---|
| Human in the loop | An authorized person must review and approve a recommendation or action before execution | Changing a maintenance strategy, deferring safety- or compliance-relevant work, approving work on critical assets, approving an intervention recommendation | The AI may prepare analysis and evidence, but execution requires documented human approval |
| Human on the loop | The system acts within pre-defined boundaries while a responsible person monitors, can intervene and can stop it | Completing low-risk notification data, creating non-critical follow-up work, dispatch proposals within rules, material proposals below defined limits | Monitoring, meaningful alerts, exception queues, audit trail, override and safe-stop capability are mandatory |
| Human in command | Accountable business and technical owners set purpose, policy, authority boundaries and suspension conditions | Governing an EAM agent, defining risk thresholds, assigning roles, approving changes to autonomy | Named accountable owners, policy and version control, access governance, periodic effectiveness reviews and kill/suspend authority |
Table A.2 — A practical autonomy model for EAM decisions
| Decision category | Example | Appropriate oversight | Minimum controls |
|---|---|---|---|
| Information and knowledge support | Summarizing work history, retrieving manuals, extracting findings from free text | User verification (human on the loop) | Source references, AI-result labelling, access and privacy controls |
| Low-impact proposal | Classifying a standard notification, suggesting catalogue data, drafting a work instruction | Human on the loop or human in the loop, depending on data quality and consequence | Confidence thresholds, sampling review, exception handling and audit trail |
| Prioritization or resource decision | Recommending backlog priority, technician assignment or material disposition | Human in the loop for material business, risk or safety implications; otherwise bounded human on the loop | Explainable recommendation, qualification and safety checks, override, monitoring of adverse prioritization |
| Safety-, risk- or compliance-relevant change | Changing a maintenance interval, inspection program or strategy for critical equipment | Human in the loop | Authorized subject-matter approval, evidence record, formal change control and, where appropriate, four-eyes review |
| High-consequence physical or operational action | Shutdown recommendation, operational release or safety-relevant permit decision | Human in the loop; in some contexts, no autonomous AI execution | Positive approval, technical interlocks, safe-state design, competency validation and complete logging |
How human in command applies
Human in command applies as the governance layer to all decision categories: accountable owners define purpose, authority boundaries and suspension conditions for every AI-enabled process, irrespective of the oversight model used in day-to-day operation.
Appendix B – Designing the authority envelope
For every AI-enabled process, the consultant should define an explicit authority envelope:
- Which data, documents and systems may the AI component access?
- Which actions may it propose, prepare or execute?
- Which asset classes, locations, countries, risk levels and monetary thresholds are within scope?
- Which conditions trigger mandatory human escalation?
- Who can approve, reject, override, suspend or reconfigure the system?
- How are actions reversed, exceptions handled and system behavior logged?
For example, a maintenance-triage agent might classify notifications and prepare work-order drafts for low- and medium-criticality assets. For high-criticality assets it may only compile the evidence pack, identify anomalies and recommend a priority; a qualified planner, reliability engineer or operations authority must then decide whether to create, release, defer or escalate work.
SEE IT RUNNING
We don't just talk about it. We show you.
The arguments here are design arguments. The Grove is where they are standing up and running — on a fully configured SAP system, walked through live rather than described.
Dr.-Ing. Achim Krüger
Achim works on Service and Asset Management strategy, architecture and SAP solution design at AlphaOak. This is a discussion paper: it states a position in order to invite argument with it. Counter-arguments are welcome.
MORE FROM ALPHAOAK
Other papers
Audit traceability in the agentic SAP landscape
When an AI agent posts to SAP, can you explain who decided what? A business-control framework for tracing human and autonomous agent transactions from intent to SAP document.
Read the paper: Audit traceability in the agentic SAP landscape