Tim Wintrip, CEO, Lemongrass, says rethinking SAP transformation through the lens of Maslow’s Hammer will help organisations modernise ERP without repeating legacy mistakes.
We are at an inflection point in the SAP ecosystem. What began as a technical modernisation conversation around S/4HANA is quickly becoming something broader: how organisations 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 modernising its platform which, in the longer term, has 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 customisations, 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.
The GSI dilemma
Naturally, what many CIOs do is reach out to their trusted 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 labour arbitrage, ultimately a low-tech solution for automating a process and IT outsourcing.
These GSIs also often have very complex P and L structures that do not foster collaboration. They can also have huge numbers of employees distributed around the world, driven and measured by ‘grubby’ KPIs like utilisation 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 have been in this space long enough, you have 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 centre–centric operating models, driven by their own P and L structures, to cloud environments.
These same organisations 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 modernisation, 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 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%.
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 are 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 clearly are 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.
