- SAP has proposed that Fiori makes sense to customize, that Fiori is extensible and that customization has been a major driver for R/3 and ECC acceptance. Furthermore, that R/3 was popular because it had cost efficient extensions.
- We review the accuracy of these claims.
SAP proposed in the document SAP S/4HANA Extensibility for Customers and Partners, some claims regarding S/4HANA and its customization.
In this article, we will review the accuracy of this SAP article.
“Customers using the side-by-side extensibility approach can use SAP HANA Cloud Platform to build completely new UIs based on the SAP Fiori user experience or integrate with other cloud applications from SAP.”
As we cover in the article What is Actually in the Fiori Box? Fiori is well known to be extremely difficult to customize. Projects where customization of Fiori are estimated end up being stratospheric and often get cancelled. Regardless, this document is stating that customization is a good idea.
ABAP as a Good Value?
“They can also build completely new applications and business logic that natively run on the SAP HANA platform or that are loosely coupled to the ABAP programming language back end of SAP S/4HANA.”
As we covered in the article ABAP programming language back end of SAP S/4HANA.
ABAP is an inefficient programming language which is increasingly limited as development goes to the cloud.
Extensibility, A New Synonym for Customization?
“In SAP S/4HANA on premise, full flexibility to ABAP through ABAP in Eclipse (a development platform) is guaranteed.”
Extensibility means it can be extended, but all application are extendable. SAP can also be extended through using any programming language that can connect to SAP function modules. It is not SAP that guarantees extensibility, is the nature of any application.
SAP R/3 Was Popular Because of Cost Efficient Extensions?
“For many years, SAP has implemented successful processes for scalable and cost-efficient extensions in all product versions.”
Has SAP cost efficient extensions? Having been on SAP projects for decades, I am unaware as to what this is. Either these extensions are a secret or SAP is referring to customization.
Furthermore, does SAP seriously expect to leave with any credibility after proposing that customizing SAP is “cost efficient?”
That is odd. Becuase SAP projects are known for their exorbitant customization costs. Some failed SAP projects have run into the billions of dollars. How did that happen without high priced customizations?
This document must be referring to another company called SAP that sold an application called R/3.
Ding Ding Ding!
This statement by SAP regarding low-cost customizations earns our Golden Pinocchio for being as false and as deliberately misleading as a statement can be.
Ease of Customization Was a Major Driver for R/3 Acceptance?
“This was a major driver of the large acceptance and adoption of SAP R/3 software, the SAP ERP application, and SAP Business Suite software (for example, by using the SAP NetWeaver technology platform for on-premise extensions of SAP Business Suite).”
SAP R/3 was adopted for many reasons, one being an arrangement between SAP and large consulting companies where the consulting companies sold out the interests of their customers so they could profit maximize at their customers. SAP was the vendor that allowed them to make the most money.
SAP is not more customizable than competing applications; it is less customizable. It has the highest cost of customization and maintenance of any vendor that we track at Brightwork. Furthermore, NetWeaver as a specific product never existed, as we covered in the article Did Netweaver Ever Exist?
SAP’s Proposal for Improved Upgradability of S/4HANA: A Whole Lot of Nothing
SAP performs a significant sleight of hand with the following few paragraphs. Now watch how the masters at SAP Marketing set up a false conclusion, without most readers ever noticing.
Step 1: SAP begins the deception by making a true statement.
“When implementing software extensions using a traditional approach, many organizations run large implementation projects with significant modifications to the standard enterprise software. At first, the high degree of flexibility may be regarded as a benefit. However, during subsequent phases of the lifecycle of the extensions, modifications may become pitfalls:”
This statement is mostly correct, but it glosses over the reason for the customizations. We won’t go into it now, let us see where SAP goes next.
“Since business experts usually do not implement extensions, interaction between the line of business (LoB) and IT often works like a waterfall model for large projects (no interconnected requirements determination and implementation phase) and thus increases time to value.”
Yes, the people writing the customizations (i.e., enhancement in SAP’s strange new vocabulary) are not the business. And writing customizations does increase the time to value, but that is true of all customizations. There is nothing new here.
“Large effort occurs for tests, validations, and adaptations necessary at every upgrade of the standard software to a new version due to (mostly) hidden dependencies between standard and extensions. The result is slow implementation of require-
ments from the LoB and delay of adoption of innovations due to the upgrade effort mentioned above.”
A bit of beating a dead horse, but also true. Once again none of the reason for the customization is given in this sequence. These are all negatives of customizations being listed by SAP.
“Today, this approach is taken to the next level with SAP S/4HANA: You can apply a tool-based and platform-based methodology, which is scalable for companies ranging from small startups to large enterprises and which intrinsically avoids the drawbacks mentioned above by using the following extensibility qualities:
- “End-to-end tools: Business users, experts, and implementation consultants can easily apply changes in their area of responsibility without risk.
- Pace layer IT: Custom extensions are loosely coupled with core business processes; that is, they need robust data, process, and UI integration, but the software lifecycle of extensions is decoupled from stable systems of records.
- The ecosystem of SAP partners: Customers get support to apply these principles and to implement differentiating solutions. In particular, partners often require a platform as a service (PaaS) for development, distribution, and maintenance of their solutions.”
The problem? None of these things lead to increased upgradeability.
- SAP does not offer end to end tools that allow the entities mentioned to apply changes quickly. How would that even work? Customization must be adjusted in preparation for an upgrade. That means the code must be modified. Why is that all of a sudden easily applied “without risk” with S/4HANA in the cloud? That is just a marketing fiction.
- Pace layers IT is made up. “tight data, process and UI integration” does not mean anything. And SAP has not had such a high cost of customization has not been because of “loose” data, process and UI integration.
- SAP already has an ecosystem of SAP partners. This did nothing to ameliorate the high costs of customizing SAP in the past. In fact, it fed into it. That “ecosystem of SAP partners” is about billing as many hours for ABAP and possible. This would be like saying people will run faster before because now they will have legs. Yes, but they had legs before.
After all that build up the result regarding what SAP offers for S/4HANA regarding enhanced upgradeability is….nothing at all.
A Comprehensive Set of Tools, Platforms, and Methodologies?
“SAP S/4HANA extensibility provides a comprehensive set of tools, platforms, and methodologies to serve the needs of customers and partners with the qualities outlined above.”
Perhaps, but how is it different from what was offered by ECC? Furthermore just because SAP provides something does not mean it should be used. For example, VW offers the diesel Golf, but we don’t recommend you buy one.
Again, SAP offered many tools for ECC and an SDK for iOS, but none of these items have proven to be competitive with using open tools.
“Since SAP HANA Cloud Platform is a full-fledged development platform, they can even build completely new solutions with a loose coupling to SAP back-end systems. SAP HANA Cloud Platform is designed to be 100% compliant with open standards (for example, using open source software from Eclipse and Apache).”
SAP’s development tools and related products have proven to be uncompetitive in the past and to increase the costs to customers. If SAP were in favor of open standards, they would make their applications accessible to already existing PaaS environments instead of channeling their customers to using 100% SAP items. The idea that SAP supports open standards is “fall laughing” amusing. It is a massive lie.
A Healthy Ecosystem for the HCP?
“When using SAP HANA Cloud Platform, you will therefore benefit from a healthy ecosystem of partners that contribute value to existing solutions and services. With this scenario, you can establish “best of breed” for small and large extensions. By definition, side-by-side extensions are loosely coupled with core SAP systems and therefore support a pace-layered IT.”
Does HCP have a vibrant ecosystem surrounding it? That is news to us.
Does ABAP have a vibrant ecosystem around it? Well yes, if the definition of a “vibrant ecosystem” is a huge group of consultants and employees who will charge customers to do things inefficiently. Furthermore, would anyone use HCP if the environment were not SAP? No? Then that tells you how competitive the offering is. HCP is a highly uncompetitive offering which is forced into companies through SAP’s pressure and by misinforming customers that the HCP is necessary for customizing SAP. SAP played the same tricks with ABAP for decades.
Upon reading the document, it is apparent that SAP plans to push companies from on-premises ABAP to using S/4HANA with the HCP. However, once again, SAP is dictating the programming environment, which has not lead to good outcomes in the past.
SAP presents itself as if it has all the answers on these topics when it doesn’t. For one, S/4HANA in the cloud has a small customer base. But secondly, the terminology used by SAP must be dissected. What is “extensibility?” It seems to be a code word for custom code. What happens when an application is customized? That is right, multitenant is out the window. And multitenant is a foundational underpinning of SaaS and a primary way it leads to cost savings through improved sustainability and lower maintenance. This is why S/4HANA customers in the cloud are small — they don’t customize.
Ding Ding Ding!
SAP receives a Fake Marketing Word Alert for its creation and usage of a new mysterious IT term called extensibility.
Some are consulting companies that are trying to suck up to SAP and use an “implementation of S/4HANA” to get consulting business. That is they barely need S/4HANA but need Quickbooks, and invoicing system and HR system, all of which they could purchase in the cloud for peanuts.
With SAP using the word “extensibility” it makes it seem like it is not customization. Extensibility means it can be extended, but all application are extendable. This is SAP marketing working overtime to mislead customers by coming up with more deceptive words.
There is just all manner of inaccuracies in the document from SAP.
This document receives a 1 out of 10 for accuracy. It is a work of pure marketing fluff and relied upon an enormous number of inaccurate assumptions. It won both a Golden Pinocchio as well as a Fake Marketing Word Alert.
It is a document in search of soft targets.
Search Our Other S/4HANA Content
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 Real Story on ERP Book
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion