For Rise with SAP, the company fielded its CEO, CTO, and executive board head of product engineering for a live media and analyst Q&A. How did they get on and what can we learn?
Before getting into the meat of what was and wasn't said, it would be remiss of me to avoid congratulating SAP for fielding questions from a relatively tough crowd and with no questions submitted in advance. In one sense that did not surprise me since I knew that most of the folk on the call had been pre-briefed. Even so, the question quality was up there with past sessions.
It's all business process and business first
Reflecting on the call content, it struck me that SAP's CEO Christian Klein directed his answers at a business audience with an emphasis on process. For example, when discussing process simplification, he used his own example of the time he was COO and questioning SAP's CFO Luka Mucic about why there were some 20 process variations for the record to report in financials, arguing that IFRS requirements are the same across most countries. As Klein correctly pointed out, variations lead to complexity and cost.
Boiled down to its essence, I defy anyone managing financials across multiple businesses with the same business model to convince me that their method of getting from record to report amounts to their being a special snowflake.
That's not to say that all business processes are universal. There are plenty of industry-specific requirements. But once you get inside an organization that is doing basically the same thing regardless of the territory then at a high level at least, they should all look, feel, and behave in the same. manner. In a reference to the processing mining and discovery capabilities of Signavio Klein said:
I would make a bet. And I have seen this so many times. When you're looking at an ECC system and older versions of our ERP. and you look at the modifications to the system, I would say with business process intelligence, we could probably figure out that 88 to 90% of the modifications are not needed anymore because the standard is so good and mature.
This was always the promise of S/4HANA but SAP now has a way to prove the point directly. It will not however be that easy to persuade business process owners of the need for simplification. When you're wedded to a specific way of doing things, it is remarkably difficult to make changes. Alongside, such simplification will have immediate consequences for internal development and support. Klein alluded to the way this can be usefully tackled; simply ask the question 'why' until an answer emerges that makes sense. And if it doesn't then you've got a use case for simplification.
However, Klein acknowledges that this is not always straightforward. Referring to Simens and their transition projects he said:
We won't deploy them right away 100% standard in the public cloud, but we take them and then over time, move them step by step certain business processes over to the public cloud until they also have a very agile system landscape.
The pace at which that happens is open to debate and it is clear from hearing DSAG's replies that it will be a tough ask for many customers. In its press release, DSAG said:
SAP and its partners must highlight the ways in which they want to transfer highly customized systems and processes to S/4HANA cloud environments and provide information on the kind of support required on the customer side. The same goes for the transformation of complex in-house developments and third-party systems that were built in ways that are not "cloud compatible", but that nevertheless exist in many customer systems and are still needed. This is not a technical migration; it's a transformation that really necessitates taking a closer look at a the customer's specific requirements and context and having a holistic view of the system landscape.
In my view, this is starting from the wrong position. I can't count the number of ways that I've heard a variation of: 'We can't migrate to S/4HANA because we've customized R/3-ECC to an extent that's not supported by S/4HANA.' Klein's remarks challenge that dogma from the rare position of experience and open the door for a better discussion about the place modifications and customizations occupy in SAP landscapes. It is long overdue but I suspect will be a long journey.
Non-SAP systems and accountability
Lindsay Clark asked two interesting questions. The first covered the topic of non-SAP systems that Signavio can interrogate. Here, Klein kind of ducked it saying that SAP will adhere to customer requirements and that while SAP is naturally interested in end-to-end processes, the data is owned by the customer. Well, process mining is less concerned about data than it is by examining the processes themselves. SAP could think in terms of extending the RISE offering to include Salesforce - one of the systems with which Signavio works. Whether that's even possible is open to much debate but if SAP is serious about playing a central role in cloud landscapes then that is a logical consideration.
Clark's second question was intriguing. He asked:
What credible contractual means will SAP use to demonstrate accountability and risk-sharing with customers taking up the rise offer?
Klein confirmed that with RISE, SAP is accountable 'end to end' regardless of where problems arise. What is less clear is how that works in the context of an SLA operated by SAP. Today, the systems integrators have sophisticated operations and AIOps capability that includes contractual relationships with the same hyperscalers that SAP uses. And while Klein is keen to see many of those same organizations join RISE, the company is very clear that it will run a certification program, presumably to ensure that it can cover its own legal position. This sets up a competitive position which we will discuss in the more general RISE analysis but you can be certain that there will be casualties among at least the Tier 2 SIs.
On pricing, Klein talked about the flexibility of SAP's licensing model and made several references to pay-as-you-go subscription models but he ducked specifics, preferring to address how RISE removes complexity from the variety of contracts that comprise a cloud-based systems landscape. When pressed on this, Klein said that as part of the offering, SAP is providing credits that can be used towards non-SAP extensions but that again, customers will be offered pay-as-you-go or a subscription. I'm not sure that gets us very far except to say that SAP to SAP extensions will come free on the business technology platform.
I asked about the future of Solution Manager. This is a topic that came up in many back-channel conversations. My question:
What happens to Solution Manager now that Signavio starts to replace a bunch of tools?
The answer came from Thomas Sauerresig:
Solution Manager is definitely used in our case for build and run processes to have some documentation in the system connected with the configuration, especially with our on-premise systems and infrastructure. As you also know, we have the Cloud Application Lifecycle Management, which we fully build on the Business Technology Platform for the cloud. And that's for sure, tightly connected together with the Business Process Intelligence layer, which we have. We also ensure that the business process monitoring KPIs, which we already delivered hundreds of KPIs now get integrated with Signavio and the BPI and diverse bits we have. So basically, we complement each other in the best of both worlds. So this will be a complimentary offer.
Further down the track, SAP plans to infuse BPI with experience data since there are circumstances where that matters, the example given being quote to cash. I found SAP's response disappointing. Everyone I speak with Solution Manager to the point where one important customer told me:
I'll throw a party when that shitty elephant is killed off,
Or, as my colleague Jon Reed said to me in a phone call:
You need to be a Jimi Hendrix to make that thing dance and I don't know too many of them.
Leonardo 2.0 and HEC 2.0?
For his part, Reed asked:
The skepticism from some sap watchers about RISE boils down to this. This is Leonardo 2.0 or HEC 2.0. How would you respond?
Klein took this on the chin saying:
We can take some criticism regarding Leonardo for sure, it was AI but AI developed on the platform for certain scenarios, but not in the context of the business process but not really embedded in our application. HEC was in infrastructure as a service offering really for those who only want to do a technical migration but this offering is one that includes business process intelligence that leads to a business transformation.
Sauerresig added that while this is a single offering, the idea is that transformation is a journey and not a destination, and therefore you need, among other things data across many customers in order to discover benchmarks so that processes can be improved over time.
Skepticism among SAP watchers is understandable. Despite what SAP says, it is late to the cloud party and really isn't there. What's more and as John Appleby pointed out, it is the hyperscalers who own the infrastructure layer, initially with AWS but in the current SAP world, it is Microsoft and then Google. SAP knows where to pick its battles and has pretty much given up on providing data center and infrastructure services.
As for the Leonardo barb, I think this is wrong-headed of SAP watchers. For me, Leonardo was always a bag of bits that you couldn't really define. RISE is a set of services that are clearly defined. What's not clear though is how this will be negotiated and how customers will be able to sense test their TCO against current costings. SAP pointed out that managing hyperscaler costs is something customers have found complex but that SAP is taking that complexity away. Is it? We shall see. I would have preferred to hear more from the SAP executives that address cost directly because that will be the first thing on customers' minds.
I have cherry-picked what was a packed one-hour Q&A session but the above represents for me the more important parts of the overall discussion. Overall, the executives gave a competent set of answers but as we know with SAP, the devil is always in the detail. We don't know for example whether accountability equates to responsibility. Neither do we know the extent to which Signavio impacts the overall tooling direction for SAP. Perhaps the bigger question though is whether the answers given will encourage more customers to accelerate their S/4HANA projects.