Skip to Content
Personal Insights
Author's profile photo Mustafa Bensan

Is there really any “Good” in “The Good, the Bad and the Ugly about SAP’s Industry Cloud” Commercialisation Model for SAP Partners?

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:

  1. Register the deal in the SAP Store Partner Cockpit.
  2. Email your partner experience manager or the PE Build Helpline specifying the order items for the required BTP services and corresponding quantities.
  3. Wait to receive the electronic version of the order form for e-signing.
  4. 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:

  1. Register the deal in the SAP Store Partner Cockpit.
  2. Extend the original order for BTP services by emailing your partner experience manager or the PE Build Helpline.
  3. Wait to receive the electronic version of the order extension form for e-signing.
  4. 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:

  1. Renew the deal in the SAP Store Partner Cockpit.
  2. Extend the original order for BTP services by emailing your partner experience manager or the PE Build Helpline.
  3. Wait to receive the electronic version of the order extension form for e-signing.
  4. 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%2C%20platform%2C%20software%2C%20tenants%2C%20business%20partners%2C%20subscriptions

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%20Certified%20Industry%20Cloud%20BTP%20solutions

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?

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Murali Shanmugham
      Murali Shanmugham

      Hi Mustafa, Thanks for sharing your feedback on these commercial models for partner solutions.

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Thanks for your support, Murali.  Given the strategic importance of partner built SAP BTP Industry Cloud solutions, I wanted to highlight some practical aspects and implications of the current commercial model.  Hopefully the feedback will be given due consideration by SAP leadership.

      Author's profile photo Finn Backer
      Finn Backer

      Hi Mustafa

      First of all; thank you for your reply with detailed comments and information sharing!    I feel honored you spent so much time reading and replying to my blog post.  And I think it is cool you responded with another image of the famous cowboy movie.

      While I think you sometimes pull my statements a little bit out of the context, I personally found it very interesting to read your comments and thoughts.  SAP should definitely consider your inputs, if not already being done.

      However, the key comment & add I would like to make is that of PE build vs OEM contract form.

      I stated in my blog post that my post is mainly targeting SAP channel partners and related to the “SAP industry cloud use case”.

      A channel partner is an organization which typically started (many years ago) doing services to organization which had purchased software from SAP and needed somebody to implement them.  Then these partners started to resell SAP software themselves, typically to mid-market companies.   Over the years these partners typically also developed some customization or even solutions for some customers, often starting with one customers needing something specific not available in the core SAP, and then copy/paste a (modified) version of the same code to other customers.   A key element of these solutions from channel partners is that they extend the core SAP solution the partner sold and implemented at the customer.

      Today, many channel partners are at the stage of standardizing their IP and make (yet) another step;  becoming solution partners as well.   In a previous blog I write how I think these partners can benefit of the SAP industry cloud program in this journey.    As such, channel partners are starting making their first standardized solution and getting their first customers to run a real cloud solution, all related to their core business of selling and servicing customer with core SAP solutions .

      In this situation, doing negotiation with SAP OEM AEs on (big) BTP contracts and making up front purchase commitments is not the ideal approach.   These are the dynamics of the OEM contract form.

      Channel partners are looking for low cost, low risk, “pay as you sell” to get started.   And that is exactly what PE build offers them in my opinion.  PE build is a volume program with standard terms and conditions.  No negotiation, big business plans commitments or 1:1 agreement needed with SAP.

      I personally believe that SAP actually have made it very easy with PE build program for channel partners to start out, and then grow.   Exactly what these channel partners need.

      Longer term, when a partner has built up a solution business, it might make sense to look at another contract form.   My experience speaking with a lot of channel partners is that they see it exactly like this: for them it is important to grow step by step, not taking too much risk and commitment from day one.

      Another element to discuss regarding contract form is that of “SAP industry cloud” program.   As the name says, this program is very “SAP” branded.  The whole idea is that the partner and SAP go-to-market together with solutions developed according to IC guidelines created by SAP.  Part of this GTM is that the SAP store should be used to promote the solution (both for external AND internal sales AEs)  and the benefit for the SAP partner to associate itself with the SAP brand.

      OEM (original equipment manufacturer) is typically a concept where a company will “hide” components from a supplier (in this case SAP supplying BTP services) into their offerings to customers.    An OEM typically have their own sales machine and do not need SAP store for this.   Thus, SAP store listing is also not a standard element of the OEM contract.    This is not ideal in my opinion for SAP channel partners trying to sell their solutions into and through the SAP ecosystem.

      Thus, I still believe there is a lot of good stuff and opportunities for channel partners to leverage the PE build program to get going moving to the cloud, and doing this via the SAP's industry cloud program.  Here is a link to a previous blog post for more this.

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Finn,

      Thanks very much for making the effort to respond in such detail to clarify the “Good” in the “The Good, the Bad and the Ugly about SAP’s Industry Cloud”.  As for the image of the cowboy movie, I would say your original post inspired my creativity 😊

      I now have a much clearer understanding of the context and intent of the PE Build program as targeted to Channel Partners.  A couple of more questions and comments:

      Channel partners are looking for low cost, low risk, “pay as you sell” to get started.   And that is exactly what PE build offers them in my opinion.  PE build is a volume program with standard terms and conditions.  No negotiation, big business plans commitments or 1:1 agreement needed with SAP.

      In the case of ISV and solution partners looking for a similar "low cost, low risk" entry point, I think it would make sense to offer them a PAYG commercialisation option.  SAP already offers partners the PAYG option for non-commercial (Test, Development and Demo) use and this works very well.  I can't help but wonder why SAP cannot extend the PAYG option for partner solution commercialisation as well?

      OEM (original equipment manufacturer) is typically a concept where a company will “hide” components from a supplier (in this case SAP supplying BTP services) into their offerings to customers.

      I think OEM partners can still choose to benefit from the SAP brand by having their solutions officially certified as "Built on SAP Business Technology Platform".