- Chip Hanna
- Reading Time: 7 minutes
Reservations about migrating your SAP workload to the public cloud are a thing of the past. Instead, those reservations have been replaced with confusion over the S/4HANA support ecosystem, especially with the introduction of RISE with SAP earlier this year. Specifically, organizations want to know what their support options are and what other organizations are finding to be most successful.
As they plan to migrate their workloads to the cloud, customers need to understand their support options and make a directional decision on how they will reinforce their hyperscaler investments prior to beginning the migration to a hyperscaler.
What we’ve found is there are four primary options as it relates to your support models:
- “Do It Yourself” Model (DIY) – Under the DIY model, organizations are maintaining their own support of their SAP applications and managing their own infrastructure services while moving their infrastructure into a hosted facility with a hyperscaler. The hosting and infrastructure services are delivered by the customers themselves. With this model, organizations typically have the talent to maintain these capabilities on their own and feel comfortable leveraging that talent. As a result, the cost is predictable to the organization.
- “Do It for Me” Model (DIFM) – Under the DIFM model, organizations leverage a third-party to manage the hosting services component as well as the infrastructure services, but the infrastructure continues to be hosted by a hyperscaler like the DIY model. This way, the organization forms two contractual relationships – one with the hyperscaler and one with their third-party support provider.
- Professional Model (PRO) – The PRO model leverages a third party to do the hosting services and the infrastructure services. The key difference in the PRO model is that the contractual relationship has now shifted to be directly between the hyperscaler and the third-party support provider. The associated contract provisions and terms have now become a pass-through to you as a customer.
- SAP RISE (RISE) – SAP RISE offers an integrated solution that includes the hosting, the infrastructure services, and the infrastructure so that you have one single contractual relationship with SAP that takes care of all those elements of the stack. RISE is presented in one commercial construct encompassing software, infrastructure, and technical services delivered by SAP and the hyperscaler.
With these support models, we have seen a decreasing level of control, flexibility, and commercial transparency as you move away from the DIY and DIFM models and towards the PRO and RISE models.
Under the DIY model, all you are doing is executing a deal with the hyperscaler to support your infrastructure going forward. This allows for the highest amount of transparency and flexibility as well as the ability to capture any commercial benefits. However, the customer is also assuming a fair amount of risk because they are solely responsible for the application hosting and supporting the SAP functionality.
As for the DIFM model, your organization has a single agreement with a third-party and another single agreement with the hyperscaler. These agreements are relatively transparent and flexible as you can change those elements out in the future if needed.
On the PRO side, your transparency and flexibility become a little less clear because you are having to pay for hyperscaler services through that third-party support provider. At times, the third-parties have been a little less transparent with the cost model, the level of flexibility, and the predictability around pricing.
Finally, RISE is that fully integrated single agreement, with all the elements of your S/4HANA relationship tied up in that RISE agreement. However, there is not a high degree of transparency as it relates to how they price your baseline as well as how you go forward and determine what those requirements are. This is because SAP mostly strives to get to a certain commitment as opposed to delivering and driving what your requirements are during your transformation phase.
What Are Customers Choosing?
With this background information on the four different support models, it is critical to understand When we talk about moving from ECC to S/4HANA, we must focus on the objectives of transformation, ERP consolidation, and hyperscaler optimization. Here, I will break down real client scenarios dealing with these objectives to see where they landed and why they chose that support model.
Client 1 – Transformation
Current State: In this first example, the client is an on-prem ECC customer with a high degree of customization and third-party integrations. Their on-prem environment is self-maintained.
This client had already outsourced their infrastructure management piece for their data center transformation, but they wanted to go to the cloud for the next generation solutions. The transformation from a managed services perspective was ahead of the ECC to S/4 transformation. This client was now looking at going to the hyperscaler and segmenting their SAP environment with their hyperscaler.
End State: What made the most sense to this client was the DIFM model. They leveraged a third-party to take care of the hosting services and the infrastructure services and leveraged a separate agreement and relationship with their hyperscaler.
Decision Drivers: One factor that drove the client to this model over RISE, which they did evaluate, was the cost. They were also motivated by the flexibility of the DIFM model, especially because they have a highly customized environment. RISE would be exclusive of some of the third-party applications, making it an ill fit to support such high levels of customization.
Lastly, the DIFM model was aligned to their overall digital strategy related to the hyperscalers, so the client felt comfortable taking this to the market for third-parties to support their SAP hosting and infrastructure services, while a hyperscaler supported the infrastructure side.
Client 2 – ERP Consolidation
Current State: This client had various ERPs, including SAP ECC. Their on-prem environment was self-maintained, and they were primarily focused on an ERP consolidation. Additionally, in this particular engagement, SAP invested a lot from a relationship perspective. There was a high degree of trust between the client and SAP.
End State: Ultimately, this client chose RISE because it fit their use case. RISE also fit their requirements as far as where they wanted to go organizationally as well as for the foundation they would use to move forward holistically across their organization.
Decision Drivers: This client wanted the simplicity of RISE’s vertically-integrated offering. Working with this client, we were able to help them break all the necessary pieces apart to understand where the areas of risk were contractually, commercially, and financially. They were also able to do their due diligence internally related to their ability to manage this model and they addressed the key areas of risk where they had an unlimited amount of SAP skills. For them, it was easier to purchase than to hire that capability.
Additionally, the speed-to-market was a driving factor in this client’s decision. For them, this solution is much easier to implement and was going to get them to where they needed to be based on the representations they made to their internal stakeholders and other shareholders. However, with this engagement, the question remains, Will SAP be able to deliver on it?
UpperEdge has been doing RISE deals since before RISE was even a thing. In those situations, it’s a combination of switching from perpetual to subscription-based licenses and going from on-prem to HEC with SAP providing a lot of white glove services. It’s going to be really important for SAP to deliver on deals like these for RISE to continue to be a viable option moving forward.
Client 3 – Hyperscaler Optimization
Current State: This client is an existing ECC customer that’s making the journey to S/4HANA. However, what is fundamentally different here is their existing ECC environment is already with one of the hyperscalers, and they have an internal competence on how to maintain the infrastructure environment on top of that particular hyperscaler.
End State: The focus of this client’s approach was to re-evaluate their relationships. This was especially crucial for this particular client given that this was a material inflection point in their relationship which they wished to leverage commercially. Additionally, they had various relationships with other hyperscalers on the business side that exceeded the relationship they had on the IT side with their incumbent hosting provider for SAP thus the desire to consolidate providers.
The client was trying to figure out if there was a way to materially optimize the commercial flexibility in the future as they transitioned to S/4HANA. Ultimately, they decided to stay with the incumbent provider under the DIY model.
Decision Drivers: This organization decided to stay with the incumbent provider for a couple reasons. It ultimately came down to who was going to be best positioned to support their digital transformation roadmap and where the executive relationships, and sometimes reciprocal relationships, driving those decisions were. The client wanted to minimize the overall risk in the S/4 transformation, so staying with the incumbent made the most sense to them.
The client also chose the DIY model because they had the internal resources and internal competence to operate in that model and they understood the risks and complexities of implementing that model.
Where Do Most Customers Gravitate?
From what we have seen, most clients tend to gravitate towards the DIFM model. When it comes down to where customer priorities lie, flexibility and commercial viability are extremely important. The days of going with one, third-party provider who is going to work top to bottom of the SAP stack and then deliver the hyperscaler relationship to you, like we see in the PRO model, will likely not be a popular option in the future.
When you look at RISE, we see a handful of customers going that way. However, the level of lock-in and the inflexibility related to the overall ecosystem and the decisions to make are just a bridge too far from where most organizations want to maintain a degree of control and flexibility. As their needs change, organizations want a more flexible model that can support that change.
Under the DIY model, your company needs to have an incredibly attractive organizational corporate culture and reason for top-tier talent to be joining your company to do it yourself right. You must attract top tier-talent to be able to handle the ongoing support of these hybrid cloud types of environments, which could be an uphill battle.
While we do not want to place a major emphasis on the DIFM model or say that most organizations are going with that model, in our experience we see our customers ultimately land or are trending towards this approach. At the end of the day, your organization must evaluate where your environment is, what your capabilities are, and what the advantages and disadvantages of each model are to choose the support model that will work best for you and your goals.
