What This Article Covers
- The Unusual Clause
- SAP’s Often Deliberately Obtuse Clauses
I recently had a colleague send me this quotation from the S/4HANA 1610 Simplification List. He was extremely surprised by this quotation and asked me to analyze it.
In this article, we will review this clause, what it most likely means and what it means for S/4HANA customers.
The Unusual Clause
“In addition, customers should be aware of the fact that only SAP S/4HANA packages (and no other software) shall be deployed on an SAP S/4HANA installation. Details are provided in the Software Use
“….For clarity the preceding sentence only applies to software licensed from SAP, its affiliates and or its authorized distributors and resellers.”
I don’t see how that clarifies anything except to say this is only for SAP software.
Also, the Software Use Rights Document does not clarify what this means. Therefore, SAP is telling customers to check another document for clarification, which does not do what SAP says it does.
I searched it for every appearance of the term S/4HANA, and there was no more information on this topic within the document at least concerning S/4HANA.
SAP is known to add clauses that are deliberately obtuse, and they come by later and say it meant XYZ and you signed the agreement.
SAP’s Often Deliberately Obtuse Clauses
If the customer reads this and then reads the supposed supporting document it is not clear what they are talking about in this quotation.
But that is the point.
If we take one possible interpretation, then no non-SAP system can be integrated to S/4HANA. That is not exactly what the clause sounds like. But at first, it was difficult to see what else the clause could be referring to. That is until I conferred with a resource with the first-hand experience on S/4HANA implementations. He had the following to say.
“They mean you cannot install non-SAP software on the S/4 platform. Nothing to do with IA or integration.
This is to avoid performance and conflict on resource issues. It also stops customers from doing this because if they do, SAP cannot see where data starts and stops…:)”
This is odd because, on all of the SAP projects I have been on, I don’t recall the topic of other software being installed on the ERP hardware being brought up. But with S/4HANA, apparently, customers spend so much money on S4 hardware that they have been running other applications on the hardware to manage their budget.
S/4HANA projects routinely underestimate their hardware size and therefore the eventual hardware cost. This has led some S/4HANA customers to try to save money by installing other applications on top of the S/4HANA hardware. This is why the clause was added to the Software Use Rights Document, where it was not there before.
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.
I cover how to interpret risk for IT projects in the following book.
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