SAP Transformation Needs a Toolbox, Not a Hammer 

We are at an inflection point in the SAP ecosystem. What began as a technical modernization conversation around S/4HANA is quickly becoming 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 using operating models designed for the past or models designed for how enterprise software is evolving.

IT leaders today are caught between a CEO and the business “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, viewed by some as technical debt and by 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 marry new breeds of agentic capabilities that promise to unleash a myriad of benefits – or threaten to unleash new competitors into existing markets.

See also: SAP Strengthens S/4HANA for the Midmarket

The GSI Dilemma

Naturally, what many CIOs do is reach out to their trusted global systems integrator (GSI) partner. For context, these partners typically have very 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 GSI’s also often have very complex P&L structures that don’t foster collaboration. They can also have huge numbers of employees distributed around the world, driven and measured by “grubby” KPIs like utilization and gross margin.

And, 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.

See also: SAP Keynote: The Future-Proof Imperative

The Devil is in the Details

I have seen another pattern emerging among the large GSIs. They are hunting large greenfield migrations that can 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 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 they have a revenue goal to hit, you should not expect them to drive a transformation that eradicates the very services they provide. 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 healthcare 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 percent.  

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-elated 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 everyone should be hit with the same hammer or even the same tool!