The Customer Takes Back the Transformation
SAP's Joule ecosystem is converging into one integrated transformation platform — and shifting the balance of power from system integrators toward customers.
Chapter 5 of 7 in the joint white paper "BPM: Where Are We Headed? The Reinvention of Process Management in the Age of Agentic AI," written by BPM&O and bpExperts.
Key Message: Integrated platforms such as SAP's Joule ecosystem make AI-driven transformation concrete—and shift the balance of power in the customer's favor. Those who combine these new technical capabilities with their own governance and continuous organizational development turn transformation capability into a core competency.
5.1 The Technological Dimension: The Integrated SAP Platform Centered on Joule
The BT Brain described in the previous chapter is deliberately platform-neutral as a concept. For the many customers whose transformation agenda is shaped by SAP, one thing is decisive: SAP itself is currently making massive efforts to provide exactly such an integrated platform. The building blocks are visibly converging—SAP HANA as the data and memory layer (including as a persistent long-term memory for agents), SAP Signavio for process models, process mining, and the process-based 'company memory,' SAP LeanIX for enterprise architecture and—with the AI Agent Hub built on top of it—for governing the AI agents themselves, plus SAP Cloud ALM for transformation and operational lifecycle management, including telemetry and traceability of agent activity. On top of this sits Joule (including Joule Studio as a development and runtime environment for custom agents, with agent-to-agent interoperability)—the agentic layer that makes these building blocks accessible to humans and agents alike.
As with the BT Brain, this platform's repository spans all transformation artifacts—not just process models, but also requirements, solution concepts, test cases and test logs, training and instructional materials, architecture decisions, and project artifacts. It is precisely this breadth that lets agents support the transformation end to end: from the fit-to-standard decision through configuration to test coverage and training—with full traceability.
One component of immediate relevance to projects is SAP Joule for Consultants: it supports functional and development consultants across the entire Activate lifecycle—with best-practice-compliant configuration guidance, interpretation of (legacy) ABAP code, generation of test scenarios traceable back to the fit-to-standard decisions, and the automated creation of role-based documentation and training content directly from the approved process designs. This promises very substantial efficiency gains, both in configuration and in development—for tasks that have traditionally been among the most time-consuming and expensive line items of any SAP project.
Some perspective is due, however: significant parts of the platform are still under development. Many building blocks have only been announced, or have only recently become generally available, and references from productive large-scale rollouts are still scarce. Anyone planning today should clearly distinguish between available functionality and roadmap promises. There is no doubt about the direction, however—and the impact on collaboration between customers and system integrators is profound.
5.2 The Market Shift: The Customer's New Sovereignty
Profound enough that the classic business model of system integrators (SIs) is itself affected. That model rested on a structural dependency: the customer had neither the methodological nor the technical expertise to take responsibility for configuration, development, testing, and project management themselves—and so bought this capacity in at scale, billed by effort. This incentive structure had an uncomfortable consequence: delayed or failed projects were often even financially advantageous for the SI—more effort, more revenue—while the customer was left holding the bag. Given the notoriously high failure rate of large ERP transformations, this is not a marginal phenomenon but a systemic problem of the industry.
AI shifts this balance of power fundamentally—in the customer's favor, on two levels. First, on governance: with AI-supported tools, the customer can set up and run its own end-to-end transformation governance—from process architecture through IT architecture to requirements, test, and project management. Requirements stay traceably linked to solution concepts and test cases, scope decisions are documented and retrievable, and deviations become visible before they get expensive. The customer is no longer dependent on taking the integrator's status report on faith—it can interrogate the state of its own transformation directly.
Second, on delivery: through citizen development and AI assistance, business units and internal IT can take on tasks that previously had to be carried out at great expense by external specialists—from best-practice-based configuration to producing test cases and training materials, through to extensions within the Clean Core guardrails. The internal knowledge about the organization's own processes—which previously had to be laboriously 'documented away' to outsiders—stays inside the organization and becomes productive there.
For the consulting role, this does not mean elimination, but redefinition: away from selling capacity by the person-day, toward enabling the customer—to build its own governance, its own meta-model, and its own hybrid teams of humans and agents. The transformation belongs, once again, to the one it should always have belonged to: the customer.
5.3 The Organizational Dimension: Transformation as a Capability
Large transformation projects such as ERP projects are organizational projects. They require not only adapting technology, business processes, and roles, but also the way people collaborate and the corporate culture. Typical examples are the shift toward cross-functional collaboration instead of clinging to siloed power structures, learning from mistakes instead of declaring infallibility, and openness to change instead of clinging to tried-and-true methods. The success of transformation projects therefore inevitably also depends on transforming the rules of the organization's social system.
Traditionally, large-scale projects such as an SAP rollout were planned in a rigid waterfall model ('design-then-deploy'): processes were designed once, coded over months, and then rolled out across the board—often resulting in a new system that, by go-live day, no longer met the operational requirements that had since changed, with the organization's social system running headlong into a technology it could no longer connect with.
We counter this with a process-oriented approach that keeps continuous work going on the process model—the organization's operating system—and makes the social system's rules of the game open for discussion: transformation projects are accompanied by methods of systemic organizational development, through which the organization's next development steps are explored and decided in an agile, iterative way. With appreciation for what already exists and has been achieved, acceptance-building, participatory, and dialogic formats form the foundation of the change architecture.
With this approach, process management enables transformation initiatives to be implemented within the social system via the process model—the organization's operating system. This is how value-creation potential actually gets realized.
Want the rest of the argument now instead of waiting for next week's chapter? The full white paper — written jointly by BPM&O and bpExperts — is available on request. Write to sales@bpexperts.de and we'll send it straight over.
