- What do the numbers mean?
- How does the business case make sense?
In SAP's defense, the answers to both those questions have been available, they've just been hard to tease out in a coherent manner. So it was with that in mind that I was given the opportunity to discuss these points directly with Markus Schwartz, SVP and general manager, S/4 HANA.
We spent a good amount of time on the numbers and the following is what I was told.
Implementations rather than sales
Schwartz starts from the point of view that implementations and go lives are the most important indicators but we cannot avoid discussing the top line sales numbers that are announced during earnings calls. So, to re-iterate on those: total S/4 HANA deals stood at 3,200 at 30th June, which includes 500 adds in the quarter.
SAP says that 40% of deals are coming from net-new customers which SAP defines as those who did not have a previous SAP, ERP implementation. We can confirm from conversations at SAPPHIRE and field inquiries that there are a surprising number of what I would term SMBs picking up S/4. These are not global companies who made their vendor choice many years ago.
My sense is these new finds are companies that believe they would otherwise outgrow BusinessOne or Business ByDesign relatively quickly so are making their decision for the very long term.
On to the types of deal and implementation. Here Schwartz said:
When we say S/4 HANA deployment what we refer to is customers that either implement the complete S/4 HANA suite which is, I would say the equivalent of ECC, what we call enterprise management, or it could be customers that use Suite on HANA but they are deploying the final S/4 HANA finance component, so either/or.
From a counting perspective, this means that even though what WE see in the market is much more evidence of Suite on HANA than S/4 HANA, SAP is counting those that include an S/4 component, regardless of whether they are green field new, transitioning from ECC or from Suite on HANA.
Some will struggle with this on the principle that this amounts to double counting but that is nitpicking in the absence of the numbers to which I will now come.
On the earnings call, SAP announced 1,200 projects. That breaks down to 60% S/4 Finance and 40% S/4 Suite. To contextualize this last number, Schwartz said:
...that includes manufacturing materials management assets, the whole thing, a scope that expands significantly beyond finance. Essentially those customers implement this enterprise management component. To give you a view on the momentum, at the beginning of this year it was more 90/10 (Finance v Suite) because with the enterprise management, as you know in November, customers don't start projects at Christmas. They get going usually the middle of Q1 so this number of full deployments, or 1511 (release) as we call the deployment, has caught up in a significant way and I expect in one or two months it will overtake the pure financial deployments.
Here is a graphical way to better understand this:
Remember that this graph only shows the proportional mix, it does not represent the actual numbers at any one point in time.
Now to Suite on HANA. Here the number of current projects ongoing are said to be a similar (and therefore pose tally confusing) 1,200. The total of all such projects was not provided but the number live is quoted at 800 so you can deduce from that that the total Suite on HANA number stands at 2,000. Once again, remember this stands independently of S/4 HANA numbers.
Who is implementing?
During our conversation, I said to Schwartz that it was great to see so many well known brand logos turning up on the S/4 sales ticket but how does this translate into adoption and implementation? The answer is paradoxical but goes something like this:
The largest customers with whom SAP has a long standing relationship will buy into S/4 the same way they have bought into other offerings in the past. Those customers will tend to run small pilots, proofs of concept for limited processes and so on, as a way of gaining knowledge of the new capabilities. The timetable for those large customers to start flipping the S/4 switch in earnest will be measured in years even though they have bought the solution.
SMBs on the other hand are adopting and implementing much faster and to a greater extent. We saw something of that at SAPPHIRE.
That creates something of an odd situation. It means that the user case studies we are currently seeing are largely from names that may not be (mostly) globally familiar but which are getting early benefit across the whole of their business. Asian Paints is an outlier from that perspective but then they've been enthusiastic about HANA since the early days.
Where's the business case content?
Now we come to the thorny problem of which route to take. As I have repeatedly observed and said, the majority of cases we see are Suite on HANA first. Given the numbers and the fact this solution has been in market for three to four years, we should not be overly surprised.
It is at this point we should reflect on what Bill McDermott said at SAPPHIRE 2016 when he acknowledged that shortly before this year's event, SAP got a wake up call from customers and had to scramble for fresh messaging that would better align SAP's stated trajectory with customer value. In various board meetings, I was shown blueprints and roadmaps that set out how SAP believes customers should be viewing the road to S/4.
That's all very well but as I pointed out to Schwartz and others, it is extraordinarily difficult to go to a single place and follow a coherent path that adequately explains what S/4 HANA delivers. Here are some resource references that give a flavor of what I mean:
- Central Page on SAP.com as Launchpad: http://go.sap.com/product/enterprise-management/s4hana-erp.html
- customer stories
- flipbook link your path to s4 http://www.saps4hanahub.com/i/675945-choosing-your-path-to-sap-s-4hana - last page list of links
- Simplification list
- Business Scenario Recommendations – see sample report
- Link to Innovation discovery – review S4 innovations in detail
- link to http://go.sap.com/services/transition-to-s4hana.html (bottom of page: very detailed info regarding transition
- link to Wieland Schreiner blog on SCN
- Solution explorer: https://solutionexplorer.sap.com/solexp/ui/vlm/is_s4hana_onpremise/vlm/is_s4hana_onpremise-ind-is_s4hana_onpremise - set filter S4
I don't know about you but even this seasoned SAP watcher gets a headache trying to make sense of it all.
I wanted to get from Schwartz something better than the 'speeds and feeds' story that characterizes the perception SAP has created over the years. He came back with a story I can buy and which makes much more sense at a high level when thinking about product maturity.
We have not built up a new product from the ground up. We have built a new product by completely re-architecting the Business Suite. This means that we could achieve more than 100 percent coverage of business processes already with the first three weeks. That is, I think, what is not deeply understood in the market.
I sometimes hear comparisons to ECC and S/4 HANA. When you look at what we did with regards to, for example, adding stock that was not part of ECC already with the first three weeks. Like embedding all of the processes in enterprise management that, for example, come from the manufacturing industry, that come from the media industry, MRO, just in time processing, which basically were part of a separate installation in the past. All these things that speak to manufacturing, the scope of S/4, of the 1511 release is in some aspects bigger than what ECC used to be.
In short, SAP took the opportunity to rationalize the older processes, and, in a number of cases, embedding processes that previously sat as virtual 'add-ons,' removing or deprecating processes that are redundant and then introducing new functionality that will be needed for the 21st century business.
Viewed another way, SAP isn't going to re-invent debits and credits although it has significantly enhanced performance but it has changed Suite functionality to provide better TCO and time to value based upon modern process definitions. To make the point, Schwartz gave an example from automotive:
For example, the automotive industry where there are large bins of material with different variants, what usually happened is that goods issues for components and raw materials were posted at the time in the system when the final end product was booked into the inventory. We called that a back-flushing process and it was booked at night. It was booked, actually days or sometimes a week later than the actual withdrawal happened on the shop floor because of, again, compute limitations and blockings.
That constraint has now been removed with S/4 HANA. What companies can now do is to post in material postings actually when the real withdrawals or the real material movement happen on the shop floor and they also don't need to aggregate it anymore, but they actually can do it piece by piece.
When you look at trends of internet of things and industry 4.0, where it's all about smaller load sizes, segment of one, what does it help if you equip your whole shop floor with sensors and even your trucks and everything if then at the end you have a significant aggregation and a significant latency in the system? All that good stuff doesn't help you then.
And that's what S/4 HANA is doing where you actually with an enterprise system that can digest the granularity and without getting latency. That allows us to do a process that is in place for 30 or 40 years, goods receipt/goods issue with all this good stuff in a completely different way. In a completely different way with additional functionality that allows you to increase your customer service and that also allows you to move to a real time and to reduce safety stock. That's one super old process that still exists that we've done in a significant different way and it cannot be done that way in Suite on HANA, by the way.
Put in those terms it should be easy to see the value S/4 HANA delivers. Schwartz claims it is working up cases where the numbers supporting value are available to customers but it is early days and despite the number of go lives the number of publicly available cases is very small. Time will fix this.
Mile wide inch deep?
The lack of depth in referencable cases for SAP S/4 HANA speaks to another problem; that of industry specific coverage. Schwartz says that later this year, SAP expects to have FULL functional coverage for all its 25 verticals with the exception of media. If that sounds ambitious then you'd not be alone but again this is something where care is needed in ensuring you understand the definitional differences SAP applies.
SAP faces a problem of infinite diversity. On the one hand SAP has internal process coverage for 25 industries. On the other hand, every SAP implementation is unique. Getting customers to evaluate their landscape against the S/4 HANA capabilities is no easy task when customers have spent years assembling systems in a compute constrained world.
The rationalization of the suite to which Schwartz refers ought to be an incentive in its own right but then there is the question of what add-ons or customizations exist that can be readily tacked into or absorbed into the S/4 landscape. That in itself is a significant change management issue and one that will test both SAP and partner consultants in running the various functional tick boxes for both old/must-have functionality, and new functionality that renders some processes redundant. The bottom line here is that customers will have to review on a case by case basis.
SAP says that it now has tools that help customers and partners. For this there are three strands:
- SAP has an extensive training program in place where they expect to have more than 10,000 partner consultants trained by the end of this year among the top 40 SIs.
- In addition, SAP has trained some 4,000 consultants on what it terms 'general business for implementation.' These are people who are more closely aligned to the end users rather than technical consultants.
- Partner enablement including access to tools for custom code check and tools landscape simplification.
These components are critical because the one thing SAP must avoid is a repeat of the way things were done in the past where the emphasis was very much upon technical product building with scant regard for end users. Schwartz claims that the new Fiori apps should go a long way towards solving that adoption blocking issue but I still think customers will be wary of change.
My conversation with Schwartz ran way past our allotted 60 minutes and could have continued further but I came away having a clearer understanding of how the numbers should be better viewed along with a simpler understanding of how the business case for S/4 HANA makes sense in the context of a changed system that has been both rationalized and improved.
While SAP will continue to make the case for a straight leap to S/4 rather than the Suite on HANA route, I think it remains comparatively weak when weighed against the background of customer experience on multi-year projects. In this, SAP needs to do a better job of presenting a de-risked proposal rather than assuming that similarity with past adoption patterns will follow a similar implementation patterns. That's just not the way of the world in 2016.
It is not enough that SAP joins in the chorus of those calling for new applications that address 21st century buzzword bingo. Its customers face multiple challenges which, in many cases, they believe are best solved by taking a piecemeal approach.
Ultimately though, McDermott's recognition of the importance of spending more time listening to customer concerns and then aligning what is available functionally needs to be pushed harder, even if that means forgoing sales today.
But for me the key comes in drawing end user champions into the fold. This is the part that differentiates the modern cloud players from companies like SAP. Yes, that technical case still has to be made but users will no longer tolerate screens that require painful workarounds or presentations that are long on 'marchitecture' and short of tangible benefit. To that extent, I believe McDermott's mantra of 'customer empathy' needs supplementing with another phrase - 'customer relevance.'