Introduction
This post originally started as a comment in response to The Good, the Bad and the Ugly about SAP’s Industry Cloud. However, as my feedback delved deeper, I felt the topic warranted a blog post of its own for a full discussion.
I will quote relevant sections of the blog post here in order to provide commentary. However, I encourage you to read the above blog for full context. The blog starts with finn.backer stating:
When explaining the commercial model of SAP BTP and SAP’s industry cloud to a channel partner who was concerned about (and not happy) paying revenue share to SAP for a solution he built, I used the Good, the Bad and the Ugly concept to explain the commercial model of SAP’s Industry Cloud.
I agree with the channel partner's concerns and advise SAP partners contemplating commercialising solutions on BTP to choose the OEM model over the revenue share model. The revenue share model as it stands now is a non-starter for deploying modern SaaS applications, for reasons I will explain.
I will also provide suggestions for how the BTP partner commercialisation model could be made more equitable so as to encourage higher adoption for partner solutions.
Available Commercial Models
The blog post gives the impression that the PE Build Revenue Share Model is the only commercialisation option available for partner Industry Cloud solutions deployed on SAP BTP. It is worth pointing out that there is also the OEM commercialisation model available. It is based on prepaid Cloud Platform Enterprise Agreement (CPEA) cloud credits. While the OEM model still has opportunities for improvement, this is the model I would recommend to partners because unlike the PE Build Revenue Share Model, it does not require revenue share and it simplifies customer onboarding by decoupling the commercial relationship between SAP and the partner from the commercial relationship between the partner and its customers. I will explain this further later.
The Good
The blog states:
The good news is that the revenue share is not a tax. Revenue share pays for the SAP BTP services the partner needs to run their solution for customers. The business model is that a partner resells SAP BTP services via the PE build program. It is fair that the reseller pays the vendor for what is being resold, right? That is the idea of revenue share.
However, the way the revenue share model is structured, it is indeed a tax, especially at a rate of 25%. While it is certainly "fair that the reseller pays the vendor for what is being resold", it is not fair that the vendor pays for MORE than what is being sold, which is the case with the revenue share model because the partner is not only reselling the BTP services underlying the solution, the partner is also selling their own value-added IP.
For SAP, there are costs associated with delivering the SAP BTP services: virtual servers, electricity of these servers, the security systems, back-up systems, the people doing DevOps, the development and maintenance of the SAP BTP services, the SAP HANA services, etc. etc. SAP uses the revenue share payments from partners to cover the costs and pay the actual bills.
This statement is not entirely accurate. Under the revenue share model, the partner must always pay for the minimum cost of the BTP resources consumed, even if the percentage of revenue share does not cover the total cost. In other words, the partner carries all of the risk while SAP carries none. In a true revenue share model, both parties share the risk. The implication with the current model is that once the revenue moves into profitability for the partner, i.e. beyond covering the costs of the consumed BTP resources, then SAP benefits further from a free share of profits of the partner-developed IP, beyond just the cost of covering costs and actual bills as claimed here. This is like SAP having their cake and eating it too.
Think of the revenue share as a “cost of goods sold” element and not a tax.
Regardless of whether the revenue share is treated as a "cost of goods sold" or a tax, ultimately it must be passed onto the customer, increasing the cost to the customer and making it more difficult for partners to sell their solutions.
The Bad
Yes, you have to pay SAP!
This language is consistent with my experience of working with SAP partner commercial executives who have conveyed a "take it or leave it" attitude. I think part of the problem here is that SAP has incentivised their commercial team with KPIs that manifest such behaviour.
Of course partners must pay SAP because SAP provides BTP to partners as a Platform as a Service (PaaS). The question though is what is the reasonable metric for payment? I would suggest that a consumption-based payment approach makes more sense than revenue share.
The Ugly
The ugly part of all of this is the complexity...This complexity is not related specifically to SAP’s industry cloud or SAP BTP, it is a complexity related to offering true SaaS cloud services.
There are elements of complexity related to some limitations of BTP which I have discussed in the blog post Is SAP Business Technology Platform Ready for Developing Industry Cloud SaaS Applications? However, the real complexity lies in the administrative burden of the PE Build Revenue Share Model as it is not suited to "offering true SaaS cloud services" as suggested. A modern multitenant SaaS operating model requires frictionless onboarding of customers and automated subscription renewals. While the needed automation is technically possible via the SAP BTP APIs, frictionless onboarding is simply not possible with the current PE Build process for Deal Management and Ordering/Provisioning of Production Licenses because the commercial relationship between SAP and the partner is tightly coupled with the commercial relationship between the partner and the partner's customers, creating a bottleneck as per the examples below:
i) A multitenant SaaS application must be deployed in the BTP Provider subaccount before any customers are even onboarded in order to allow customer subscriptions to be provisioned in the first place. This means that BTP resources must be allocated before any customer deals are registered. However, BTP production licenses can only be ordered once a customer deal is registered. So here we have a chicken and egg situation.
ii) Ordering production licenses for a new customer is a completely manual process involving the following steps:
- Register the deal in the SAP Store Partner Cockpit.
- Email your partner experience manager or the PE Build Helpline specifying the order items for the required BTP services and corresponding quantities.
- Wait to receive the electronic version of the order form for e-signing.
- Wait for provisioning of the ordered licenses.
Based on the above manual steps, there is no possibility of automating the onboarding of customers and provisioning of their subscriptions, creating friction in the customer experience.
iii) By their very nature, multitenant SaaS applications use shared instances of resources across customer tenants, such as SAP HANA Cloud. The SAP partner will deploy a minimum instance of the resource, such as SAP HANA Cloud and scale up as needed when customer subscriptions grow. This means that when a new customer is onboarded, additional BTP resources may not necessarily be required, yet production licenses must still be ordered, again via a manual process as follows:
- Register the deal in the SAP Store Partner Cockpit.
- Extend the original order for BTP services by emailing your partner experience manager or the PE Build Helpline.
- Wait to receive the electronic version of the order extension form for e-signing.
- Wait for extension of the existing licenses to the new customer.
Once again, based on the above manual steps, there is no possibility of automating the onboarding of customers and provisioning of their subscriptions, creating friction in the customer experience.
iv) In this day and age, SaaS customers expect the flexibility of rolling month-to-month subscriptions or annual subscriptions. Since the production licenses previously granted are not automatically renewed, the following manual steps must be executed:
- Renew the deal in the SAP Store Partner Cockpit.
- Extend the original order for BTP services by emailing your partner experience manager or the PE Build Helpline.
- Wait to receive the electronic version of the order extension form for e-signing.
- Wait for extension of the licenses to the original customer order.
Yet again, based on the above manual steps, there is no possibility of automating the renewal of customer subscriptions, creating friction in the customer experience.
Consider an SAP partner who has 300 customers on a month-to-month subscription plan for their SaaS solution. This would mean that the partner would need to execute each of the above four manual steps for each of the 300 customers each month, i.e. 1200 steps. Furthermore, it is not clear if the BTP resources are blocked until the license renewal is granted. Can you imagine the impact on customer experience?
The above manual processes are surprising given SAP's core competency of optimising business processes and integrations for their own customers.
Operating Model and Business Partner Relationships for Multi-tenant SaaS Applications
The major issue with the PE Build Revenue Share commercialisation model is the artificial coupling of the relationship between SAP and the SAP partner with that between the partner and the partner's customers, resulting in the customer experience issues described above.
The Partner Community blog post What is multitenancy, and why is it needed in the Cloud Environment of SAP BTP? provides a very good discussion and diagram of the business partner relationships as shown below which I'd like to elaborate on.
Infrastructure, platform, software, tenants, business partners, subscriptions
For context, I'll map the business partner relationships from an SAP and partner perspective as follows:
| Operator | Business Partner |
| Infrastructure Operator | Hyperscaler (Amazon Web Services, Google Cloud Platform, Azure) |
| Platform Operator | SAP |
| Software Operator | SAP Partner |
As you can see, the SAP partner's customers don't come into the picture here, and that is how it should be. Ultimately, SAP BTP is a PaaS and SAP a PaaS provider. All of the major hyperscalers operate on a commercial model of charging their partners (independent software vendors and startups) based on resource consumption, not a revenue share model. Most non-SAP SaaS applications are deployed on one of the major hyperscalers listed above. Can you imagine the reaction if they announced that the only commercial option was now going to be a revenue share model?
This begs the question how is SAP different to the other hyperscalers (PaaS providers) to justify demanding a 25% revenue share?
Suggestions for Improving Commercial Options
At the time of writing, there was only one SAP Certified Industry Cloud partner solution built on SAP BTP listed on the SAP Store, as shown below:
SAP Certified Industry Cloud BTP solutions
In my mind, adoption of SAP BTP for partner solutions can be encouraged and accelerated with the following 3 simple changes:
1. Offer partners commercial PAYG licensing for SAP BTP with the option to transition to CPEA (OEM), in the same way as is currently offered to SAP customers. This would allow a partner to start small and then scale up with customer uptake.
2. Reduce the minimum term for the OEM CPEA commercial model from 3 years to 1 year to allow partners more flexibility in reevaluating their Cloud Credit needs annually based on customer growth while continuing to offer tiered Cloud Credit discounts.
3. For the Revenue Share Model decouple the commercial relationship between SAP and an SAP partner from the commercial relationship between an SAP partner and their customers by replacing manual deal registration with monthly or quarterly reporting as used to be the case, in order to allow partners to offer a frictionless customer onboarding experience consistent with a modern SaaS operating model.
Furthermore, the partner PE build price list should be applicable to all of the above 3 commercialisation options to make building solutions on SAP BTP more attractive and competitive compared to alternative platforms and encourage adoption by SAP partners.
Conclusion
While SAP BTP has a lot of potential for deployment of partner-built Industry Cloud and cross-industry SaaS solutions, the current commercial models, in particular the revenue share model, do not make it viable for widespread adoption. I hope the points raised in this post provide some food for thought for SAP executive leadership and the SAP community.
Please post your own experiences and feedback in the comments below for further discussion.
Reference Reading
The Good, the Bad and the Ugly about SAP’s Industry Cloud
Is SAP Business Technology Platform Ready for Developing Industry Cloud SaaS Applications?
What is multitenancy, and why is it needed in the Cloud Environment of SAP BTP?
- SAP Managed Tags:
5 Comments
