We are at an inflection point in the SAP ecosystem. What began as a technical modernization conversation around S/4HANA is quickly evolving into something broader: How organizations create a foundation for continuous simplification, continuous innovation and ultimately, AI-enabled business processes.
The challenge at hand is not whether transformation will happen; it is whether it will be approached with operating models designed for the past or for how enterprise software is evolving.
IT leaders today are caught between a CEO and the business’s wanting AI’ and SAP modernizing its platform, which, in the longer term, has the potential to enable said AI. The challenge is that, in the interim, the business needs to run SAP environments that have been around for a while and typically work quite well. These systems often include extensive customizations, which some view as technical debt and others as technical innovation, yet they remain reliable and continue to operate effectively.
Of course, the flip side is that they are often complex and overly tightly coupled with other systems, and documentation regarding that complexity is often forgotten. At face value, these systems are not easy to integrate with emerging agentic capabilities that promise to unleash a myriad of benefits — or threaten to unleash new competitors into existing markets.
The GSI Dilemma
Naturally, what many CIOs do is reach out to their trusted GSI partner. For context, these partners typically have exceptionally large SAP practices (with tens of thousands of consultants) and large BPO-related contracts aimed at labor arbitrage (ultimately a low-tech solution for automating a process) and IT outsourcing. These GSIs also often have very complex P&L structures that don’t foster collaboration. They can also have substantial numbers of employees distributed around the world, driven and measured by ‘grubby’ KPIs such as utilization and gross margin.
Quite frankly, they have everything to lose by adopting a more modern approach to the journey to a modern ERP that includes the end state, which drives agentic capabilities.
If you’ve been in this space long enough, you’ve seen traditional IT providers run SAP in the cloud much the same way they ran it on premises. A common example is large, global oil and gas companies experiencing repeated outages because GSIs apply data-center-centric operating models, driven by their own P&L structures, to cloud environments.
These same organizations are also accustomed to paying millions of dollars to GSIs for SAP upgrades every few years. They have been conditioned to accept this model, and GSIs’ forecasting and earnings often depend on it. This means the same institutional thinking and habits are being applied to SAP modernization, with historical run-rate spend for the GSI being a driving design tenet for the solution.
The Devil is in the Details
I have seen another pattern emerging among the large GSIs. They are pursuing large greenfield migrations that may take years and cost hundreds of millions, or even billions, of dollars. These projects have a pattern of delays and scope creep, resulting in several high-profile cases that have resulted in GSIs being exited and CIOs ‘gently disappearing’.
Much of the time, despite the client spending millions of dollars on phase-zero activities, the devil is literally in the details. Without a forensic view under the covers, deep into multiple layers of the business process hierarchy, the gotchas still remain. When looking at customers with hundreds of thousands of custom developments and thousands of interfaces, even the best, smartest consultants in the world can miss things — and they do. This likely explains why there are so many greenfield migrations with thousands of custom developments lifted and shifted into them.
When the Business Model Becomes the Design
The conflict of interest here is clear. If you have a large GSI to whom you pay millions of dollars to perform BPO-type work and/or that has a revenue goal to hit, you should not expect it to drive a transformation that eradicates the very services it provides. Partners with significant benches of functional consultants can be reassuring, but bear in mind they ‘will’ want to keep their huge bench of resources busy.
As an example, a large health care company recently brought us in to help them take a more modern approach to discovery, as-is mapping, documentation and disposition recommendations. The customer confirmed this approach allowed them to reduce the effort from 12 months to three months and the associated costs by an estimated 90%.
In another example, we ran our accelerator tooling on an SAP landscape that had already performed a classic phase zero with a large GSI, no doubt costing millions of dollars. The AI-related tooling found significant gaps across the estate related to custom code (remember the devil lurking in the detail) that still needed to be addressed.
It’s not ‘Hammer Time’
This is where Maslow’s Hammer comes into play. This bias, articulated by Abraham Maslow as “If the only tool you have is a hammer, you tend to see every problem as a nail,” explains why large transformations so often default to familiar delivery models, even when they’re not the best fit.
To avoid this, break the discovery and scoping of the transformation away from the functional partner. Use modern tools (such as the SAP BTM toolset) to map the as-is and to-be states and then use said tools and smaller partners without a horse in the race. The GSIs clearly need to be part of this journey, often bringing unique industry knowledge for a subset of the ERP platform, so find a means to use these skills without handing them the keys completely.
In transformations of this scale, there are clearly a lot of nails that need to be hit. But remember, not every nail should be hit with the same hammer — or even the same tool.
