SAP’s big RISE announcement this month was billed as a watershed event, and indeed it was. Moving big enterprises dependent on old technology onto modern cloud platforms that support modern processes is a laudable goal, to say the least. That the vendor wants to take direct responsibility for customer success and offer a streamlined contracting process is also laudable. And adding new technology to make all of that more efficient is… laudable too.
In short, RISE is a good start, but it’s not enough. Despite the best of intentions, a well-laid plan, and some new leadership firmly behind the program, there’s a big problem. Actually, several big problems: Deloitte, Accenture, Cognizant, E&Y, to name just a few of them. And there’s more – Wipro, Infosys. Basically it’s a long list. My beef: these global SIs tend to muck up projects, incur delays, habitually overcharge and underdeliver, and when a project fails to deliver, walk away without any real consequences.
That’s the partner side of the problem. Another other side of the problem is a focus on migrating customers to S/4HANA instead of a focus on migrating customers to a game-changing digital future, whether S/4HANA is at the core of the digital transformation or just one of many core elements. That single-minded S/4HANA focus tends to perpetuate the “all roads to the Intelligent Enterprise pass through S/4HANA” mantra, which isn’t what every customer wants or needs, however much SAP wishes that were the case.
One more problem: How does a customer with valuable customizations in their old SAP system figure out how finesse the timing of a move to S/4HANA when it’s unclear when or if those particular customizations will become standard functions (and therefore unnecessary) in a future release of S/4HANA? And if they put a lot of effort into maintaining their old systems and running new or upgraded custom code on SAP’s Business Technology Platform, why should they bother to upgrade ECC in anything resembling the short term? Indeed, under that scenario, after they’ve migrated the old ABAP code and built the new processes should they be paying SAP For maintenance for the old system or move it over to a cheaper third party provider? How does RISE reconcile that contradiction?
To be clear, none of these problems mean RISE is DOA, far from it. But it does mean that RISE, which the new RISE boss Brian Duffy took pains to describe to analysts as a “movement,” will need to keep moving to get things right and do right by the customers. (I have some good company here in pushing the movement to get moving, among others my friends at Diginomica have been burning the pixels writing about the topic.)
The partner problem is the biggest, and the one that may be easiest to fix. It’s no secret I don’t love most of the global SIs, mainly due to their track record of egregious serial project failures in the industry and their uncanny ability to eschew accepting any blame for those failures. (Fun parlor game: search “Deloitte SAP project failure” and see what happens.)
At least the GSIs treat screwing over customers without bias to any particular vendor: SAP is hardly alone in having projects scuppered by GSI partners, who then quietly slink off the stage while the vendor takes the heat.
There is absolutely no reason to believe that RISE innately changes anything regarding these companies’ devotion to profits over quality. Just recently Deloitte hit the news (again!) when it was revealed that the company allegedly stole IP and used it on a sole-sourced contract to burn through $44 million in taxpayer money creating a vaccine tracking app that was largely dead on arrival. What also hasn’t changed – and I will need some strong evidence that RISE has some hidden capabilities SAP has so far been unable to articulate – is that SAP has no real ability to control how these companies behave or misbehave in their engagements with SAP’s customers.
Unfortunately, as far as I can tell RISE does not have any particular guardrails or processes for ensuring that projects will be done without the usual inattention to ongoing problems. SAP does have a lot of services, including its Activate methodology and Cloud ALM, among others, that systematize implementations and identify checkpoints for partners and customers to use to ensure everyone is on track. While they weren’t called out explicitly in RISE, these and other tools are a good start and should be given more air play in the continuing evolution of RISE.
Activate and CALM notwithstanding, while SAP’s role in RISE is to be the “one throat to choke”, if SAP can’t in turn grab a GSI by the nape of the neck and do a little choking of their own then the control that SAP claims to be able to exercise will be more of a janitor cleaning up someone else’s mess than a stern project manager holding all parties accountable. I remain convinced – though very open to be proven wrong – that SAP is at risk of not having the project transparency and accountability needed to police the GSIs in anything resembling an effective way. The means to achieve true transparency and accountability exist. And I’m not just talking the lip service, “let’s do a Qualtrix survey to figure this out” band aid kind. Real transparency and accountability are more than feasible, it’s just the political and cultural will that are lacking. (Scott Russell, are you listening? My line is open any time you want to talk.)
The other reason the partner problem is easy to fix is that there exists a healthy ecosystem of smaller, often regional implementation and managed services partners who can do much if not all the work needed to accomplish RISE’s primary goal of migrating all but the very largest ECC customers and their customizations into the digital future. SAP needs to quickly and credibly reach out to these companies and give them a very visible seat at the table. Customers want this kind of choice – I’ve been speaking to a lot of customers lately who would rather not engage a GSI if they can find a good boutique SI to work with. If SAP is really dedicated to customer success then meeting this need will be easy, and I’m sure many of the smaller partners will eat up the chance to prove they can handle RISE and provide SAP with a set of partners much more amenable to the oversight I think RISE needs to be truly successful.
On to my second problem with RISE: SAP has begun to acknowledge the heterogeneity of its customer base, and that refocus has been evident in several conversations I’ve had with SAP’s senior leadership. But I think RISE’s lack of an explicit message about supporting heterogeneity was a missed opportunity: RISE could have been a great launching point for a dedicated program to embrace the use of non-SAP applications and technology on the road to the Intelligent Enterprise. Customers want this acknowledgement, badly. They feel marooned on an SAP-only island in the middle of an archipelago of other products their companies also depend on. It actually makes these internal influencers’ jobs even harder by having SAP’s message be so S/4HANA centric.
RISE should embrace heterogeneity, not ignore it or sweep it under the rug. Instead RISE for now seems focused mostly on ERP and S/4HANA, with basically no mention of competitors like Salesforce and Workday, despite the fact that many of the very companies SAP is trying to wean off ECC have integrated processes that connect these apps to ECC. If those apps aren’t embraced by RISE, the ECC influencers will be forced into a rearguard fight to “prove” that RISE applies to these heterogeneous apps. (To be fair, there wasn’t a whole lot about the rest of SAP’s cloud assets either, another lacuna.)
It’s sort of hard to imagine achieving RISE’s goals without taking into account a big tent view of the integrated processes customers run today. That’s another problem that is easy to fix – the capabilities are there to build and support integrated business processes that span heterogeneous environments. SAP just has to put a little effort into promoting this bigger picture of what an Intelligent Enterprise can be.
My third problem is about the roadmap for industry-specific capabilities in S/4HANA and how that will factor into the build/buy/migrate decision companies that seek a rapid path to digital transformation will need to take. This interplay between what the customer needs today and what SAP can provide now versus some time down the road is crucial to many of the decisions customers are trying to make regarding their legacy SAP systems and the custom code they’ve encumbered themselves with.
Right now this old vs. new analysis is hard to undertake. I recently looked at SAP’s roadmap tool on behalf of a client in order to try to answer a question along these lines and found that a particular feature would be available in Q4 2021 in the on-premise version of S/4HANA. But the details were sparse, too sparse for my client to make a determination that this feature would cover their requirements and obviate the need to migrate some custom ABAP code from ECC to do the same job. That sparsity is understandable, even though the roadmap is behind a firewall SAP probably doesn’t want to give out too much specific detail for the obvious competitive reasons. But at least in our case the client and I decided that counting on Q4 for the possible release of a feature that might possibly meet their needs (though we can’t know until we’ve seen it) wasn’t a good idea.
Most probably we’ll be tapping a boutique shop to build a new version of the custom feature if and when a migration to S/4HANA is approved and underway. Now that RISE is here the client is definitely interested in seeing what that means for their project and the boutique firm they usually use for these projects. So, in that regard RISE is meeting its goal of galvanizing customers to move their migration strategies forward. I told my client to talk to their rep and see.
Before I forget, let me opine on two other components of RISE. Business Networks: I’m a huge fan of this concept, and I’m happy it’s part of RISE, though I think it may be more of a distraction than an easy upsell. Companies doing RISE may be unwilling to look into the amount of change management a full embrace of Business Networks may entail. While much of the concept is based on Ariba’s procurement processes, a familiar starting point for many, the rest of the Business Networks plan involves looking at core business processes very differently than ever before. But giving Business Networks more visibility is a very positive move. If only there was more information about Business Networks on the RISE landing page. Actually any information at all would be an improvement.
The other offer is Teams, which I’m deeply concerned about. Microsoft took Teams on a wild innovation ride in the last year, and in the process broke a lot of dishes and revealed some major shortcomings, which as far as I could tell were allowed to fester while a pile-on of new features overwhelmed users. I’ve been using Teams for a while – long before C19 – and it quickly became so unusable I took the app off my desktop and only used it on a browser. One of the main problems was identity management – Microsoft last spring basically made one of its own conferences unusable not just by attendees but by its presenters because of its identity management overreach. Teams also doesn’t play well with users who are on multiple teams and want to share content or calendars between different teams. At least you can log in and out of different identities now – they just fixed that after about 18 months of begging from aggrieved users. Ironically for RISE, the ability to work on multiple teams simultaneously is a core requirement for SI and services teams – experts often jump back and forth between projects, and right now Teams only handles this with a messy little kludge.
I know Microsoft will eventually stabilize Teams and fix – hopefully – some of the problems it has in serving users who live and work in multiple teams simultaneously. But I would have left Teams out of the conversation about RISE until Microsoft bullet-proofs the software a little more. (I watched Teams crash during a recent demo by a SuccessFactors partner demoing the very integration RISE is meant to support. The partner blamed the demo gods, which is fair enough, but, IMO that crash was par for the course when it comes to Teams.)
To conclude this admittedly long-winded post, there’s a lot I like about RISE and a lot I think needs to be improved. RISE is definitely responding to a real need in the SAP customer ecosystem to move to the cloud at a pace that works for the customer, and the fact that the pacing will be largely up to the customer is brilliant. So with this as a starting point, as long as RISE keeps being fine-tuned appropriately it can eventually start realizing its lofty goals. How much, how fast, and how soon remain to be seen.
A good post which raises all the right questions.
Here is my instant reaction since we clarified without a doubt that the RISE contract covers hyperscaler and a range of SAP tech/services but *not* the SI, which is a separate contract. Therefore, two contracts are needed for RISE.
Now that this is clarified, a couple of points:
1. SAP public relations. SAP leadership, in public and private briefings, needs to be more rigorous about explaining what I just wrote. Many experienced SAP watchers missed this point and described RISE inaccurately, which points to a definite need for painstaking clarity on this. Next: SAP has occasionally used phrases like “one handshake” in the context of RISE. SAP needs to stop doing that, as no matter how much this may simplify some aspects (e.g. hyperscaler relations), as long as there is an SI involved, there are two handshakes.
I have heard customers referring to “one throat to choke” in the context of RISE based on this misunderstanding. That needs to be corrected when it is described in that way. Obviously, in a specific customer example where there is no SI, only SAP, then this could be described as “one handshake” as long as the difference was pointed out.
2. With this clarity on RISE, it points to new pros and cons. Here is a partial list:
PROS:
– customers would have more freedom to select their own RISE SI, since there won’t need to be a formal revenue/margin share agreement on RISE in place with SAP.
– customers would potentially get a better financial deal going direct to the SI. True or not, they can at least negotiate their own KPIs with the SI which may be desirable.
CONS:
– This makes the job of SAP imposing more project accountability on global SIs, one of the top issues in my opinion for SAP, more difficult. You’ve covered this off well in your post.
There are more pros and cons of RISE to consider, but those are two changes that jump out. Meantime, I don’t believe this changes the need for SAP to position smaller SIs and niche/industry expert service providers as important to these projects. If anything it increases the need to do so quickly, as soon as these partners can align with RISE goals and methods.
Some of them already are.
Finally, I think the reaction to this news development shows SAP that there is a real desire to see the SIs brought into a different accountability, or, in a more positive way, a shared collective stake in SAP project success. I think it would be interesting for SAP to talk to a couple of trusted partners, perhaps one larger and one midmarket, to see if they *could* potentially offer the option of a “one contract/one handshake” approach to RISE. It seems to me from my talks with customers so far there is an appetite for this. Perhaps it could prove a differentiator for both SAP and the firms in question. In this way, the misunderstandings on this important issue could be turned into a longer term gain.
Excellent, thanks Jon. Saved me the trouble of redacting my post
To the last point: the desired accountability isn’t just up to SAP, or the GSIs, though if they’re serious about customer success they’ll get on board. I think senior leadership at SAP believes in its customer success mission, but it’s struggling to make the cultural changes needed to push this into the field. IMO the customers and the user groups need to push transparency and accountability hard, otherwise vendors and SIs will assume transparency and accountability aren’t important enough to the customers to make a change. And please don’t tell me all it needs is a Qualtrix survey. But I digress…
Bingo….. “the user groups need to push transparency and accountability hard, otherwise vendors and SIs will assume transparency and accountability aren’t important enough to the customers to make a change.” I believe it matters greatly. And I will point out the in the enterprise cloud applications industry, a very different type of consulting is expected, with a much smaller ratio of services to software cost than a classic ERP project. Beyond that, the consulting is expected to center around industry advisory/benchmarking and customer success.
What I am getting at here is that disruption has already come in many flavors to the enterprise consulting market. SAP should get out in front of this because it’s coming either way, and I believe from my talks with SAP customers they want the kind of transparency, accountability, and “skin in the game” you are describing.
Thanks to both of you for cogent points. I think the overall C19 environment is causing a closer look at the overall GSI value proposition and delivery. SAP has a unique window of circumstance to make a significant change in partner relations that could benefit their customer base and enhance the long term outlook. Will they sizes this window of opportunity?