Prior to SapphireNow 2015, I anticipated that SAP S/4HANA would dominate the event. Due to scheduling conflicts I arrived late, but from what I can tell, so did S/4HANA. Of course it did make its way onto the main stage later on in the opening keynote, but not with the fanfare expected for “the biggest product launch in the history of the company.”
Formally announced in February 2015, SAP S/4HANA is described by SAP as follows:
What is SAP S/4HANA?
SAP S/4HANA is a new product fully built on the most advanced in-memory platform – SAP HANA – and modern design principles with SAP Fiori User Experience (UX). SAP S/4HANA delivers massive simplifications (customer adoption, data model, user experience, decision making, business processes and models) and innovations (Internet of Things, Big Data, business networks, and mobile-first) to help businesses run simple in a digital and networked economy.
The SAP Business Suite is SAP S/4HANA’s predecessor. The Business Suite is just that: a suite of separate (integrated) products including ERP, CRM, SRM, SCM and PLM. Like the SAP Business Suite, SAP S/4HANA is designed for the large enterprise, but unlike the SAP Business Suite, all these separate products will be merged into a single product, SAP S/4HANA, eliminating any redundancy of data and the resultant synchronization or data passing. Both will play well with certain SAP cloud offerings including SuccessFactors (HCM) and the Ariba [supplier] network.
Also in February, Hasso Plattner announced that it would eventually satisfy the requirements of the same 26 industries SAP has spent decades building out, implying customers should be patient because this would indeed take time. After all, SAP had over 400 million lines of code to rewrite.
To get a better sense for the similarities and differences between the Business Suite and SAP S/4HANA, I would suggest you take a moment and read SAP S/4HANA: Simple, Fast, Different. That post concluded with “…the devil is in the details.” There were still many lingering questions over how both new customers and existing SAP customers would make the transition. Many industry observers were clamoring for more details on plans, roadmaps and specific status of different functions for different deployment options.
Some of those observers are still clamoring, some quite loudly. And as you might expect, they aren’t shouting SAP’s praises from the rooftops. They are looking for detailed roadmaps. But roadmaps for what? And where are they looking? I know SAP is preaching “Simple.” It is a commendable goal to try to simplify the implementation for any one customer. But where these customers are now is anything but simple.
Taken en mass, the “typical” SAP customer just doesn’t exist. The sheer number of different products, versions, databases, hardware platforms and configurations is staggering. Customers (or pundits) are not going to find all the answers and a road map wrapped up in a nice bow on a website. Each customer (and prospect) needs to engage one-on-one with SAP. And quite frankly, which customers raise their hands and express interest can and should impact the sequence in which SAP will deliver pieces of the puzzle.
If SAP publishes a timetable and sticks with it, come hell or high water, it runs the risk of not satisfying real demand. On the other hand if SAP publishes said timetable and then adjusts it according to actual demand, the industry observers without any skin in the game will cry foul. SAP will be damned if they do, damned if they don’t. There is a lot of moving parts here folks, and the more fluid and responsive SAP can be, the better for its customers.
That is not to say that SAP can afford to take its time and wait. But it is not waiting. While Hasso may have implied it would take time to bring those 26 different industries over to S/4HANA, indeed they are all there today – kind of. There was some disbelief expressed in the Executive Q&A when Bernd Leukert (member of the Executive Board and the Global Managing Board of SAP with global responsibility for development and delivery of all products across SAP’s product portfolio) announced they were all there. No, the development team did not rewrite all that code in the last 3 months, but it did make sure that the code supporting these industries was compatible with SAP S/4HANA. This is just the first stage in the full transition (rewrite) of code, but a necessary one if customers want to start making the move to SAP S/4HANA today as it is still progressing.
Customers starting on the SAP S/4HANA journey today will be running a mix of code that has been converted (to HANA) to be compatible and code that has been optimized. Customers that have not started the journey might need some help in seeing the (vast) potential benefits for doing so. Typically this assistance comes from other customers that already had an idea. Seeing those customers on stage is one of the reasons customers come to an event like SapphireNow.
But SAP S/4HANA is really too new for that. Or is it? SAP did have customers on stage, but they were more likely to be customers who had gathered experience through SAP Business Suite on HANA. So the stories tended to be more about HANA than S/4HANA. And as Jon Reed pointed out, “Surprisingly, the business potential of the HANA platform is rarely factored into the initial HANA use case.”
I actually don’t find that surprising at all. First of all, for the first several years SAP itself had been talking about HANA as break-through technology in search of a problem. In recent years it has tried to shift the discussion to the business value, but that transition is hard because many SAP-ers and most industry influencers talk in “tech-speak.” Even those that insist they are talking about the impact on the business often litter the rhetoric with phrases like nearline storage, dynamic tiering, multi-tenant database containers, expansion in virtualization, publishing of objects, etc. ..along with a whole host of alphabet soup (SOAP, REST, HTML5, XML, etc.)
News Flash: business folks don’t know or care about these tech terms.
Those business users do care about speed of reporting. They care about getting answers to questions and knowing which questions to ask. And they care about reduced database size when you equate that to the cost of storage. They do care about being able to inventory and assess prior customizations that built barriers to into taking advantage of innovation and growth opportunities. They care about flexibility and agility in terms of the business as their organizations grow and restructure.
The real questions should be:
- Can SAP S/4HANA deliver all these business benefits?
- Can SAP deliver innovation to SAP S/4HANA that will help prospects and customers respond to real-world business changes?
The HANA platform is critical to delivering on the promise of the first question. In order to satisfy the second question, SAP needs to start delivering innovation faster than it has ever done so in the past. And the bar continues to rise on this. Its competitors that deliver only a single multi-tenant SaaS solution have a leg up in that they only have to maintain a single line of code. Others that continue to offer both cloud and on-premise solutions are forced to maintain multiple versions and also often offer a choice of operating system and database. For every hour they spend innovating, they must spend a multiple of that hour making sure it works across the entire spectrum of choice offered, in any possible combination.
In offering multiple deployment options for SAP S/4HANA is SAP putting itself at the tactical disadvantage of having to maintain different lines of code? SAP says no. While SAP has committed to delivering annual updates to on-premise customers, it pledges to deliver innovation on a quarterly basis in the cloud. And yet it claims to only maintain a single line of code, and delivers different configurations, updates and extensions through more sophisticated packaging of all these elements. This implies the core code base never changes, but all innovation is managed separately and then packaged with the base. I myself am a little unclear on the technical details here, but the goal is spot on. Business users will have to trust SAP on this for the moment. Time will tell if this approach is indeed sustainable and manageable.
The future of SAP S/4HANA depends on it.