- There is a poor fit between S/4HANA and the cloud which is hidden by the fact that SAP commingles S/4HANA Cloud with S/4HANA on premises.
- For this article, we needed to cover ASP (Application Service Provider) versus “single =tenant” versus “private cloud.”
- Wikipedia’s definition of the private cloud.
- The problems with the lack of customizations possible with single-tenant SaaS.
Introduction to The Real Story on Cloud and S/4HANA
While researching the actual history of S/4HANA implementations, something that came to the surface is how rare it was for any S/4HANA implementation to be in the cloud. This is curious because so much of SAP’s marketing around S/4HANA has been used promoting S/4HANA Cloud as an application that is flexibly deployed. In this article, you will learn the real story on the applicability of the S/4HANA Cloud to the cloud.
What is the Cloud or SaaS?
Many people think that the cloud aka SaaS is undefinable and or that any claim by a vendor that something is cloud should be accepted as true. However, in fact, SaaS is actually very well defined. The terms SaaS and cloud are quite often used interchangeably. So while not entirely overlapping, they will be considered synonyms for this review.
Important supporting words are as follows:
- Hosted: This means that the application is on servers that are outside of the company that uses them. It does not mean anything more than that. Sometimes hosted is used to be considered distinct from SaaS. But this is inaccurate. SaaS is a particular modality of hosting, and the benefits of SaaS do not generalize to any application that is hosted.
- Application Service Provider (ASP): This means that the application is provided by an outsourced company that is not a SaaS/cloud arrangement.
- Single tenant: This is where a single customer is supported by a hosted application.
- Multitenant: This is where multiple customers are supported by a hosted applications.
Understanding the Interrelationships of SaaS
The interrelationships will be reviewed in this paper.
- The Public Cloud
- Private Cloud
The Public Cloud
The term public cloud is almost never used except when in the same sentence as the term private cloud. In the vast majority of cases, the term public cloud is used without a modifier, i.e., just the “cloud.”
ASP (Application Service Provider) Versus “Single-=Tenant” Versus “Private Cloud”
All of these terms have different origins. All are adjectives to define better a software instance which is a “hosted” service with a single tenant as opposed to multi-tenant, which is one of the basic requirements for SaaS.
The Private Cloud
The problem with this term is that “private cloud” is that it’s a bit of a misnomer because the term does not actually fit the definition of cloud computing. Cloud computing both implies and requires shared resources. Regardless, private clouds are often lauded for their improved security. Still, they have a fundamental limitation. They do not offer the many benefits of cloud, public cloud or SaaS, and they do not scale well.
The Wikipedia Definition of Private Cloud
Wikipedia has a good description of private cloud, which states “they have attracted criticism because customers “still have to buy, build, and manage them,” and thus do not benefit from less hands-on management, essentially “[lacking] the economic model that makes Cloud computing such an intriguing concept.”
SAP’s marketing materials show many cloud-based third-party applications. However, SAP does little of its own hosting except for its newly acquired applications that were already cloud-based before they were purchased. Therefore, most of SAP’s database and applications revenue is from applications not in the cloud. S/4HANA Cloud matches this pattern by having very few customers.
There is no doubt that Concur, Fieldglass, Ariba, and SuccessFactors are delivered via SaaS. Those vendors have traditionally been delivered through SaaS. But they are much more straightforward applications than an ERP system. However, S/4HANA Cloud is not delivered through SaaS to any substantial number of companies or any companies of substantial size. The larger the company, generally the larger and more complex the requirements, and the more need for customization, which moves the company away from being able to use SaaS ERP applications, which includes S/4HANA Cloud.
- Any level of complexity and customization can be supported by hosting the ERP system or what is called a private cloud.
- But then almost all the advantages of SaaS are lost. All that is done that differentiates this from on-premises is the hardware switches locations from the customer to the vendor.
No Customization a Foundation for SaaS
SaaS customization was first reviewed above in the section on multi-tenancy (i.e., One Code Base — Multi and Single Tenancy). SaaS’s underlying data model and system architecture are not customizable. “No Customization” allows the SaaS software vendor to spend less time dealing with various platform patching, compatibility issues, and individual upgrades.
In fact, a true SaaS vendor is supposed to upgrade a single instance, which then updates all customers simultaneously. This should then imply less support expense.
The Reality of No Customization of And ERP System
SaaS applications tend to predominantly be simple applications that are not customized for each client. The fertile areas of SaaS tend to be applications such as bill of materials management, CRM, HRMS, travel and expense, online meetings and email.
However, the current trend indicates that software vendors are increasingly moving more complicated applications, which have a long history of being customized, to the cloud.
That being said, we do not foresee that the need for customizations will abruptly come to an end just because applications move to the cloud. For example, SAP’s ERP system, called ECC, is either highly or moderately customized in 92 percent of instances. SAP’s replacement for ECC, called S/4HANA, will be made available in the cloud.
However, serious questions remain concerning customization and how these customizations will be ported to a SaaS environment as proposed by S/4HANA Cloud. In fact, such questions are already starting to emerge.
For example, the following excerpt from a recent review of S4 HANA Cloud shows these questions arising:
“I’m examining the degree of “SaaSiness” within the scope of S4 HANA – I’m not using it as a standard in comparison to other non-SAP SaaS applications. There are definitely other “purer” SaaS applications in the market but such a comparison isn’t the focus of this piece. Although there are theoretically pure “Private” and “Public” versions of S4 HANA, company-specific manifestations will probably emerge that combine various characteristics of each extreme.
For example, one SI may allow greater customizing for customers at the expense of a weaker SLA or at a higher cost. Furthermore, a company/SI could have multiple S4 HANA-related offers to meet the needs of different customers/business requirements.” – Diginomica
In my view, this industry expert is granting SAP SaaS status before SAP has proven this capability. This expert even states that he is not focusing on how pure S/4HANA is for SaaS because it is not the focus of his attention. However, he is assuming S/4HANA Cloud is SaaS or presenting it as such. I do not see who would care what the focus of his attention is or isn’t. Something either meets a definition of a term or it does not.
Will SAP Be Actually Providing the Hosting?
In most cases though, SAP will not be doing the hosting. There may be cases where the instance is hosted by a firm such as AWS. (In that case, it is also not multi-tenant.) This expert points this third-party hosting capability out in a different part of his article:
“However, there is no reason why a partner couldn’t duplicate this offer for its customers – even exploiting HANA’s multi-tenancy feature included as part of SP9.”
S/4HANA is currently going through a rapid development cycle, with new functionality being released each quarter. The S/4HANA Cloud version lags the S/4HANA on-premises version. It is likely that even when this cycle slows, there will be SAP customers on different versions of this ERP system.
Can S/4HANA Be a Cloud/SaaS Application?
S/4HANA will, in most cases, be implemented with customization requirements. This precludes S/4HANA from being a true SaaS application. SAP also does not follow most of the other SaaS characteristics, and this categorizes S/4HANA as a non-SaaS application. Only the smallest customers will be able to use S/4HANA in a non-customized way. However, S/4HANA is a Rolex watch regarding cost and complexity. ECC had the highest TCO of any ERP system.
See details on the TCO of ECC in the online TCO calculators at this link.
A Top Cloud ERP Vendor’s View on Customization and SaaS
I wanted to get another viewpoint on this conflict between customization and SaaS delivery and S/4HANA Cloud, and the normal requirement for customization in the ERP software category. So I reached out to Rushabh Mehta who leads ERPNext and whom I happen to know has quite a few customers on SaaS delivery for their software. He had this to say on the topic.
“The problem of mass customization, which seems intractable from a pure SAAS point of view, is solvable with a plug-in architecture. An Cloud ERP does not have to be pure multi-tenant, but multi-tenancy can be built on basis of virtualization so you can technically run a multi-tenant cloud with each customer in a separate VM running own set of plug-ins. This would still be some kind of a hybrid “cloud” as long as all customers get upgraded simultaneously. I think it is possible, though I have no idea how “pluggable” is the S/4HANA architecture is.”
Pluggable means that extensions or add-ins from outside vendors can be easily added to the core product. The S/4HANA architecture is not pluggable. It is, in fact, the exact opposite of pluggable.
This is a critical distinction to understand because SAP has for years made it difficult to connect applications to its software. This is used to create a barrier to entry to push customers back to using other non-ERP SAP applications. Software companies develop integrations to SAP ERP, but these are not plug-ins, so that is a different topic.
ABAP Customization of ECC
Customization is written in ABAP to pull in functionality from pre-existing applications the company wrote, or enhancements to ERP. These are one-off and are not shared or at least very little shared between clients.
Let us get back to another quote from Rushabh:
“From the other side, I don’t think any vendor has been able to fix this problem, even for small businesses. The reason in my view is that the incentive for revenue is stacked up in the favor of large-scale customization (emphasis added). So from the SAP point of view, even if they could pull of a common code-base across the cloud with a really cool plug-in architecture, their heart can never be in it, because it’s a recipe to kill their revenue. Companies can spend ~1% of their annual expense on their ERP system and SAP wants to collect all of that tax/rent.”
Is SAP Going to Open Up?
SAP will often give lip service to opening an allowing more interoperability with other vendors. For instance, they talked a good game with SOA. They talk a good game about partnering with software vendors. However, they undermined those partnerships and tried to get companies not to buy from their “partners.” I covered this topic quite extensively from the perspective of something called indirect access in many articles, one being How SAP is Now Strip Mining its Customers.
“That is the core of the problem – not only for SAP but also the entire ERP industry – There is just too much money on the table (esp for large companies) and they see no reason to push for mass customization when customers are ready to pay for re-inventing the wheel every single time.”
SAP does not make much money from customizations, but the SAP consulting companies do.
My take is a bit different from Rushabh’s here. My view is that SAP can only bring out so much functionality, and it cannot (obviously) meet all requirements. To Rushabh’s earlier point, SAP has no plug-in architecture to allow other companies to come in and develop add-ons to ECC/S/4HANA. The approach with SAP been one-off customizations.
SAP’s strategy with S/4HANA Cloud, or delivered by SaaS does not make any sense. It is not working currently and is unlikely to work in the future. The strategy appears to have been hatched by SAP marketing to appeal to Wall Street and to seem leading edge, without consideration for what makes an actual SaaS solution beneficial over a hosted or private cloud.
We predict that SAP will continue to pretend it has a viable “SaaS” option available, but will merely end up hosting/private cloud managing S/4HANA for some companies because the benefits of doing so will be to continue to obtain a higher multiple for their stock price.
See our The S/4HANA Implementation Study. for real story and details on actual S/4HANA implementations.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model