If you walked away from SAP’s recent SAPPHIRE event scratching your head about which version of S/4 HANA your company should deploy, you’re not alone. There seems to be a fair amount of confusion about the differences between S/4 HANA On-premise/Private Cloud and S/4 HANA Public Cloud. And that confusion threatens to derail the growing momentum around the company’s flagship cloud products.
The problem is that SAP is trying to get S/4 HANA Cloud to punch above its weight class by claiming it can meet the needs of a large enterprise, and in the process the company is setting the stage for some serious customer confusion about which version of S/4 HANA is the right one for the job. The irony of these efforts is that in sowing this confusion SAP fails to see that the very thing they’re trying to hide by overselling S/4 HANA Cloud is the very thing that actually imbues the overall S/4 HANA product line with the exact attributes that customers need.
Unfortunately, SAP only has itself to blame for the confusion. The official messaging, to be perfectly honest, seems designed to obfuscate rather than enlighten. I had to go three rounds with SAP to get the story straight, and at times it felt like I was deposing a reluctant witness, rather than having a forthright conversation about what will always be a complicated decision for SAP’s customers.
Here’s the gist of the problem. SAP’s official storyline is that S/4 HANA Cloud is as well-suited to run a large, global enterprise as the on-premise and private cloud versions. This is due to the simple fact, SAP officially maintains, that the on-premise and private cloud editions of S/4 HANA are built off the same code line as S/4 HANA Public Cloud, which means that a customer can chose either one for their upgrade or migration because they are functionally equivalent.
Those italicized words, however many times SAP executives repeat them – and they were repeated to me more than once — won’t be true for quite a while, if ever. It’s kind of like saying that a Honda Fit is functionally equivalent to a Honda McClaren Formula 1 race car. Both have tires and engines and transmissions, etc., and both can transport you from here to there. But if you’re going compete on a Grand Prix track, you might want to leave the Honda Fit at home. And if you’re trying to take your kids to the water park or need to hop to the grocery store for a gallon of milk, I’m pretty sure a carbon-fibre, 220 mph Formula 1 race car wouldn’t be the right choice.
Similarly, if you want to run a global company using a standardized set of business processes, S/4 HANA Cloud is your Honda Fit. But if you want to do something more – run an industry solution like Retail, or a fully-functional warehouse management system, or run the fully functional versions of GRC or GTS, for instance – you’re going to need that race car, and that means running S/4 HANA on-premise and either managing it yourself or having a service provider run it for you in a private cloud.
Notice the deliberate use of the words “fully functional.” Read this carefully: the public and private cloud editions are different, the scope of what they can offer is different, and there are very different deployment use cases depending on what your business goals are. The two products’ roadmaps promise a good deal of convergence in the coming years, and the similarities at some point may outweigh the differences. But it’s highly unlikely they will ever be functionally equivalent: the market demand for some industry solutions may never be big enough to move that part of the code line to the public cloud. We shall see.
What I’m baffled about is the thought that SAP thinks there’s something wrong with this kind of full disclosure. From where I sit this is a huge strategic advantage, particularly because of S/4 HANA’s secret weapon: code equivalence. Both versions do spring from the same code line, which means that any of the “fit to standard” functionality that a customer deploys today in S/4 HANA Private Cloud can be moved, pretty much seamlessly, to S/4 HANA Public Cloud any time the customer wishes. Of course, the above bells and whistles like GRC or EWM – said facetiously: these are hugely important pieces of functionality for some of SAP’s biggest customers – might have to stay in private cloud mode. But, that’s what SAP Cloud Platform is for, right?
This ability to keep the strategically advantageous parts of the S/4 product line in a private cloud and move the rest of the company to a public cloud version while running a single code line is something one other company can do. Who? Well, it’s certainly not Oracle, which possesses one of the best examples of cloud code sprawl in the industry. And the rest of the major competitors are cloud-only companies, no private cloud options available.
Only Microsoft can do something similar, to the extent that the Azure Stack offering allows a company to run a complete version of Azure in a private cloud, meaning that its cloud ERP product, Dynamic 365 for Operations, can also run in said private cloud. But I’m not sure there would a business case for splitting a company into pure cloud and Azure Stack versions of Dynamics 365, certainly nothing similar to the mixed S/4 HANA scenario above.
A further advantage of the SAP approach is that a single code line means process equivalence. This means, for instance, that a new “fit to standard” business process in S/4 HANA, version whatever, could be stress-tested and perfected in one location – say in your offshore subsidiary – and then moved around to world to your other locations in a way that would vastly simplify the change management issues inherent in any new process change. Are these other entities running S/4 HANA on prem or in the cloud? Who cares? If it’s available as “fit to standard”, an identical configuration of the one you’ve created for one line of business can be deployed anywhere pretty much as-is.
In other words, SAP customers can separate the strategic decision to go with a migration or upgrade to the S/4 HANA family from the deployment question of cloud or on-premise, at least for a significant percent of their needs. Start with the real questions about managing the technical and business changes needed to thrive in the coming years, look carefully at what customizations need to move to the new platform, and then figure out what has to run where and how: Cloud vs on-premise, migration versus upgrade, cohabitation of ECC and S/4 HANA vs. HEC, etc. etc. If you’re like most large companies – and many smaller ones – you’re probably going to have to mix it up. Or maybe not. These are hard questions to answer, but they’re much easier to deal with once the more salient business and customization issues have been sorted out.
Ironically, underneath this functional equivalence stuff, SAP overall has pretty much has these goals in mind: Leading customers down a decision path that starts with “what do you want to accomplish” and leaving out the issues of which version can meet their functional needs until the time for such a decision is ripe. To help out, SAP has some pretty robust tools, such as S/4 HANA Readiness Check and the Transformation Navigator, both of which can help customers make careful choices dictated by their particular IT and business realities rather than blindly follow some overreaching marketeering that is clearly intended to push SAP’s cloud market status as much as possible, and to hell with the consequences.
If only SAP would stop pretending that all roads lead to S/4 HANA Cloud. SAP should instead embrace the strength and depth of its offerings and stop claiming that this diverse set of offerings is somehow functionally equivalent, before it gets into hot water with its customers. Pretty much every vendor/customer dispute can be boiled down a couple of simple problems, one of the most important of which is mismanaged expectations. Overselling, underdelivering, obfuscation, confusion – these are the paths to customer dissatisfaction and competitive disadvantage. In this case, this functional equivalence concept is made all the more useless by the fact that what SAP is trying to hide – a product line, based on a single code line, as diverse as the customers it’s trying to serve – just happens to be its biggest strength.
Just tell the truth, the whole truth, and nothing but the truth. It’s really that simple..