There’s a lot to unpack from SAP’s S4 HANA announcement of last week, but if I could only highlight the essence of what the announcement means for SAP and its customers, it’s this: SAP needs to make sure every customer understands how the versions of SAP they are running today will lead them to S4 HANA, in what time frame and at what cost. And SAP has to make sure every new customer understands what it means to run existing processes at significantly greater speed, as well as run net new processes they never were able to run before, before they’re asked to sign on.
If it wasn’t for these very customer-centric issues – in other words, if the exigencies of the real world didn’t exist – then I would say unequivocally that S4 HANA is at least as monumental a moment in the evolution of enterprise software as R/3 was back when it was released in 1992, and that’s saying a lot.
But much has changed in the ensuing 22 years, and things will have to be very different before it would be safe to give S4 HANA the kind of odds of raging success that R/3 had in its day. The old days of moribund mainframe systems and antediluvian mainframe software, a pending Y2K hoax, the lure of client/server computing, a desperate need for CIO’s to recapture control before the distributed data center obviates their power and budgets, and a consulting/SI channel equally desperate for something real to sell alongside the business process re-engineering hype of the early 1990s – none of these are around to give S4 HANA the kind of tail winds that R/3 enjoyed.
Which means that SAP is in charge of the tailwind, as well as the sail, the rigging, and everything else required to get S4 HANA the attention, and uptake, that it, at least on paper, deserves.
Of course, SAP is a vastly different company than it was 22 years ago: bigger, more complex, more embedded in the global economy, more of pretty much everything. Which augurs as well for S4 HANA as SAP could hope with such a monumental new offering. But there are still a fair number of issues that will conspire to make S4 HANA as challenging as it is promising for SAP.
Software then and now: Back in the R/3 days, SAP’s competition, to be blunt, sucked. Old, tired, unintegrated, mainframe-dependent, the enterprise software of the 1990s was a field ripe for disruption. And while R/3 had its share of issues, the bar was set pretty low for a successor to the likes of D&B Software and Cullinet.
Today, S4 HANA has to compete against a wide range of worthy opponents – Salesforce.com, Workday, Microsoft AX, Infor 10X, Oracle – that are setting the bar pretty high for success. These companies also enjoy significant incumbency benefits in their installed bases, which SAP has to attack vigorously at the same time that SAP has to defend its installed base from the enemy. The implicit ROI of incumbency means that proving that S4 HANA is a better choice than any of these companies’ offering makes SAP’s job all the more difficult.
Platforms then and now: There were really two platforms available at the time of the R/3 launch – the dominant mainframe platform of IBM, and the up and coming platform defined by Unix and client/server computing. The latter had a particular characteristic that almost made it the un-platform: open standards for hardware and software, implemented as an explicit challenge to the lock-in of IBM’s mainframe systems, made the platform switching costs between the upstarts systems relatively low, at least in theory. Vendor lock-in, so the smoke and mirrors of the time went, was IBM’s bailiwick. The openness and standards of Unix and client/server were the domains of the new guys in town.
Today, platform vendors, and every one of SAP’s erstwhile competitors is selling a platform strategy, are paying lip-service to openness, but no one is fooled as they were in the 1990s. A platform is the key to the IT budget for many years to come, as well as a way to not-so-surreptitiously guide and influence customer behavior. C-level execs are a lot more savvy about this issue than they were in the days of R/3, and that means SAP has to make the case that S4 HANA is both the very best long-term choice for a platform shift, as well as the most open choice for continuing to leverage other platform investments that can’t be just summarily decommissioned.
Databases then and now: Along with the Unix and client/server openness myth came the myth of database choice. Again, decoupling the database from the mainframe and its operating system, and thereby decoupling enterprise software from writing directly to either of these two systems, was a virtue that propelled IT budgets across the industry. SAP embraced database openness by effectively making all databases equal – and thereby marginalizing performance equally – in a way that the market embraced willingly. If a company was a DB2, Oracle, or SQL Server shop – and the keepers of these database standards in the enterprise were a powerful lot – nothing had to change in order to embrace R/3. And there was much rejoicing in IT land.
The end of that embrace is perhaps the biggest change in S4 HANA. By writing directly to the database, not a least-common-denominator layer, S4 HANA gets even more functionality out of one of the fastest transactional/analytical systems on the market today. This is great for the business user, whose applications can now do things applications could never do before. And this is good for the conscientious CIO who sees an opportunity to limit the oversized influence that the relational database keepers continue to wield. But doing so, ironically, means that SAP must both tout the superiority of HANA at the same time that it says that the database layer is no longer relevant, precisely because it is no longer a separate “layer”, but part and parcel of the applications that impart the true value of S4 HANA to the enterprise.
If that sounds a little confusing, you get the point. The End of the Database may be a little too much for SAP’s next slogan, and The database is dead, long live HANA is a bit of a stretch as well. But it’s going to take a lot of market education to overcome a few decades of open database thinking and RDBMS hegemony before the HANA part of S4 HANA reaches its apogee.
SIs then and now: R/3 rode in on a wave of SI hype called BPR, for business process re-engineering, which I at one point re-christened “bad practice repair”, which was what was really going on in a lot of companies. The SIs loved BPR because it gave them an entrée into the CEO’s office to talk strategy and CIO’s office to implement new software. SAP was all about both kinds of BPR, and it was the start of a beautiful friendship.
Today, the SIs are scrambling to understand what S4 HANA, particularly its implementation-light, cloud-base functionality, means for the implementation side of the SI business. No SI in the SAP partner world is laboring under the misapprehension that S4 HANA is anything but bad for the implementation side of the equation. While they all pay homage to the conceit that their real value lies in strategic services, they’re secretly waging a Sisyphean battle against the erosion of a core revenue stream for them. Which means, quite simply, that the SIs won’t carry SAP’s water the way they did in the 1990s. All the more so because there’s no great Y2K hoax to galvanize ignorant execs into doing a lot of new implementations in order to make sure the world doesn’t come to an end. (Though, have you read the news lately? I’m beginning to wonder….)
What can SAP do about this? I’ll publish my suggestion in my next post on Wednesday.
I did not quite get why S/4 is not great for SIs. S/4 means all types of consulting work. The list of things that are required to migrate to S/4 and to HANA is quite long. I would love it if the author would expand on why he said what he did on SIs backing SAP.
And because the data is stored once, not only is there is a massive reduction in complexity, you also have the ability to report across all of your systems simply, and, if you want to, in real-time.