- There are facts of the Diageo vs. SAP case that bring up important questions regarding SAP’s logic and what a poor job Diageo did in this case.
- To understand indirect access as enforced by SAP, it is necessary to connect the topic to CRM and SAP’s concern with Salesforce.
- The judgment in the UK does not necessarily apply to the US, and the UK judge appeared out of her depth in judging and evaluating the cases.
- Why SAP needs indirect access to extract income from customers as SAP’s applications created after R/3 have been of such low quality and fail so frequently when implemented.
- In this article, I will cover a change I observed that I think needs to occur on how to properly interpret SAP.
- This change will not be accepted by many, particularly those with a financial bias towards SAP. An analysis of multiple data points, observed over a number of years support this conclusion presented in this article. I have included quite a bit of evidence, as well as links that provide more support into specific details.
Let us being with the recent Diageo vs. SAP case.
The Facts of The Diageo vs. SAP Case
In the case that was tried in a UK court, SAP just recently won its case against its longtime customer, Diageo. The following quotation provides a nice synopsis.
“Diageo also licenses SAP Process Integration, which it has used to connect Gen2 and Connect with its core SAP system. Although the applications’ end users don’t directly interact with SAP, the company contended that it was also entitled to named user licenses for those end customers—all 5,800 of them.” – Constellation Research
This is a highly controversial case as it deals with indirect access. I covered indirect access as it pertains to HANA in my last article, however right after that article was written, the judgment was announced in this case in the UK. The case has left a lot of people scratching their heads. I followed the judge’s logic, and she tried to get to an equitable judgment, but I believe the judge made an error regarding the basic interpretation of the legitimacy of indirect access.
The liability for Diageo is substantial. If the judgment stands, they will owe SAP roughly $70 million.
The Connection of ERP to a CRM System
I do not know exactly how Salesforce (the CRM system) was connected to the SAP ERP system at Diageo. However, I have spent a significant amount of time in application integration, and in the vast majority of cases, a CRM system integrates with the SAP ERP system in two primary areas of data. One is the customer data, and the other is the sales history. The CRM system does not need to access any application logic in the ERP system. Application logic was applied to sales order process in SAP ERP to create the data that sits in the SAP ERP system database.
All of this is a normal integration between systems. Something that, up until a few years ago, did not require the purchase of extra ERP licenses from SAP.
SAP proposed in its lawsuit that this was “indirect access” to its SAP ERP system software. Diageo proposed that it wasn’t, and the judge sided with SAP, although in a strange outcome, the judge was not able to find the appropriate SAP license that applied to the usage.
The quote below from Computer Weekly:
“In my judgment, there is no applicable named user category for the Connect customers… They do not have access to source or object code. They do not have access to the functionality provided by SAP ERP in support of the wider operation of Diageo’s business. They access business process functions and information from the database for the purpose of ordering products and managing their own personal accounts only.”
This is quite confusing. How can Diageo be responsible for paying a SAP license that even after litigation it is unclear as to which SAP user license applies?
Interestingly, SAP wanted, even more, money from Diageo than was granted.
“..she (the judge) resisted SAP’s full demands, declaring that such usage did not need to be licensed at professional user level – £9,400 per user including VAT, as demanded by SAP – but rather as other types of users that could not be identified and were not listed in SAP’s price lists.”
Again, SAP has a large number of SAP user / SAP license types on its price list.
The following questions naturally arise.
- How can the way that Diageo users used Salesforce not fall into one of these categories? What occurs to me is that the SAP users definitions were created before indirect access was initiated as a concept.
- How can any SAP customer figure out the appropriate SAP license if a litigated court case cannot make that determination?
My View on the Diageo Case
The only type of indirect access definition that I find reasonable is when an entity essentially duplicates the functionality or a part of the functionality of a software vendor and then uses that functionality to circumvent the intent of the application which it purchased from that software vendor. The Diageo case is not even close to meeting that definition because SAP ERP does not have CRM functionality. SAP has its CRM software which is purchased as a separate product from the SAP ERP system. Salesforce CRM relies on data in the SAP ERP system, but there is no duplication of functionality and no circumvention of functionality that is possible by using Salesforce CRM when connected to the SAP ERP system.
For people that don’t work in IT for a living, there is, in fact, a very simple way of testing whether SAP should have had a valid case of indirect access against Diageo. And it is this.
If Diageo had purchased SAP CRM instead of Salesforce CRM, would SAP still have demanded that Diageo pay them for the same number of SAP ERP licenses?
If the answer is “no,” then this is anti-competitive protection. If the answer is “yes,” then the Diageo case was correctly determined in the UK.
However, the answer is in fact “no.” There is in my view, no way that SAP would have made a claim against Diageo if Diageo had purchased SAP CRM instead of Salesforce CRM.
Now many people know the terms offered to SAP customers that will read this article. If anyone disagrees with my statement, then comment on this article. I am very interested in learning how what I proposed is not the case, or under what conditions it would not be the case.
SAP as Legacy
This case, along with a buildup of performing many years of research on SAP, ranging from SAP technology to SAP business practices, has lead me to conclude something I think is quite significant.
SAP is now legacy.
Back in the 80s SAP marketed against legacy systems. SAP, along with Gartner and all of the major and most the minor IT consulting companies told potential customers the following:
- ERP systems would eliminate all homegrown legacy systems with a single system.
- ERP systems would be the only systems that these companies would ever need.
As this period predates my career, I learned of this in what I can only describe as hidden history from my research for the book The Real Story Behind ERP. All of these entities (SAP, Gartner, the consulting companies) were amazing inaccurate in their predictions on ERP. And, each of these entities communicated these unproven messaging without worrying about compiling a shred of evidence.
- In fact, my review of all the research into the productivity of ERP systems revealed that there was never any evidence for ERP having any return on investment.
- While fabulously wrong, the biggest proponents of ERP, were also its major beneficiaries.
SAP has used its ERP system to push customers to buy more systems from SAP. However, after customers purchased the ERP system, they faced a diminishing marginal utility from each additional SAP purchase. There is a strong trend at play here, and it has been largely ignored. But the more the company invests in SAP, the less they incrementally get out. That has been the reality for the past few decades. And now, there are now increasing liabilities to maintaining or growing one’s SAP footprint. Costs continually rise, and any company is now potentially subject to an audit, and to indirect access fees that in most cases would never have been actionable at the time, the SAP software was purchased.
SAP’s Problematic Sustainability
As with the companies from the 1980s who had become overwhelmed with the maintenance of so many home-grown legacy systems, SAP’s unsustainability is now ever more apparent.
Let us talk about just a few of the reasons why. “Why” could probably be the subject of a lengthy paper, but we can review a few of the most important factors in a less comprehensive form.
- The Casual Strip Mining of Customers Using Constructs like Indirect Access
- The Decline of Post ERP products
- The Failure on SAP’s Big Bets like S/4HANA and HANA
I have covered the use of indirect access to extract from a customer. Something which is missed by just about every analyst that covers SAP is that most of its post ERP applications have not been successful.
With its top-selling ERP system, SAP embarked on diversification into other application categories in the 1990s. Let us now discuss those applications.
Post SAP ERP System Applications
If we review these applications, while they have certainly generated sales, none of them can be considered successful technically.
Here is a brief overview of post ERP applications that SAP released.
- SAP BW – Business Warehouse: A lagging BI application with famously high operating and maintenance costs.
- SAP CRM: Very close to a dead application.
- SAP PLM – Product Life Cycle Management: Never actually existed.
- SAP Netweaver: Never actually existed (a container or marketing construct for a hodgepodge of mostly infrastructure tools)
- SAP SRM – Supplier Relationship Management: A dead application (supposedly replaced with Ariba)
- SAP APO – Advanced Planner and Optimizer: A lagging set of supply chain planning applications.
- SAP MDM – Master Data Management: A dead application.
- SAP Solution Manager: A dead application.
These were all home grown applications. SAP customers invested enormously in these applications, and what was the payoff? Each of the applications above either does not work or is limping along in companies. Each of the applications has declined in prominence since released. Imagine how many resources were wasted in buying, implemented and maintaining these applications?
One of the more successful product suites was APO (my area of expertise, and a suite of applications for which I have authored five books). While consulting with them has paid the bills, I can’t say that companies see much business value from APO. The maintenance overhead on APO is quite large, and customers tend not to like using the APO modules. So again, the waste involved with here is overwhelming when we consider all implementations of these products globally. Now Deloitte or Accenture see this list, and a big smile comes over their faces, but it is hard to look at this list as an implementing company and have many good feelings. Mostly these applications are just a bunch of bad memories for those that bought them.
I should also bring up; I am one of the only SAP consultants who will write this. It is the case that SAP consultants will come up with any excuse they can to support the reasonableness of using the list of products listed above. It is accepted that as an SAP consultant you both only say and write positive things about SAP, and most SAP consultants I have met have no knowledge of applications outside of SAP.
I chalk this up to financial bias, it is impossible for me to believe that the inherent limitations of the list above are not self-evident to many SAP consultants. However, it should be remembered that most SAP consultants work for a SAP consulting company, and writing what I have written, or any real criticism would be an excellent way to get fired from a consulting company. SAP consultancies are about profit maximization, not truth-telling or following an evidence-based approach to coming to conclusions.
Other Problematic SAP Applications
And of course there were more applications, but none of them stand out much differently than what I listed above. SAP also has acquired some applications, from Business Objects to SuccessFactors to many others.
However, none of the acquired applications are even as prominent now as when they were purchased. In fact, most are considerably less prominent, and as development lags, they follow a trajectory very similar to IBM’s software acquisitions where they become out of date and less relevant as time passes. SAP has quite a lot in common with IBM. IBM is doing reasonably well financially, but IBM has lost its ability to innovate or even to provide much value. They now rely upon acquisition, labor exploitation, lawyers, and contracts. IBM is no longer even a desirable employer.
The Failure on the Big Bets like S/4HANA and HANA
The next topic is that the big bets SAP has placed on HANA, and S/4HANA have not worked out anywhere near expectations. HANA is a moderately selling super premium priced database. S/4HANA has very little traction in the marketplace.
For those that know my writing, I have extensively covered both HANA and S/4HANA, and there is far less actual fire than smoke on these products. See my other articles on these products on my LinkedIn article page. The sales for both do not contribute very much to SAP’s revenues.
And now we get to why SAP has to employ something like indirect access. It is broadly known that SAP cannot meet growth goals. If we look at the applications released after ERP, the growth story is not there. The growth is not there with the big bets. HANA, S4, etc.
Indirect access is simply strip-mining their customers. Under that analysis, it is a marker or leading indicator of the decline of SAP. SAP is using indirect access, so it does not have actually to compete. This is textbook monopoly behavior. Textbook as in going way back. Going to back to Standard Oil in the US.
SAP’s CRM application is simply not competitive. How can SAP compete in the CRM space with Salesforce or BaseCRM with what SAP CRM has to offer?
- My research entity reviewed SAP CRM which you can see at this link.
- Notice SAP CRM earned a 65% chance of project failure, higher than any other CRM system reviewed. (The risk estimate is an average, and not customized for any one SAP customer)
And after reviewing all of these different data points is when I realized, that SAP is the legacy system!
What is a legacy system? Well, it is a system you have relied upon historically, but which you are trying to minimize the investment into as you migrate to something more to “your liking.” No company can replace everything at once. Legacy is the portion of your systems that you rely upon, but which may be replaced at some later date.
The question now is not whether to grow your SAP investment but how to shrink it.
Who Figured This Out First?
Who had the best bead on this? I nominate Vinnie Mirchandani. He laid out in his book SAP Nation and SAP Nation 2.0 how unsustainable the whole SAP industry was. And there are very few candidates for this title, as very few people were willing to write accurately about SAP.
The degree of groupthink on SAP has been awe-inspiring.
Future Articles on SAP as Legacy
In my upcoming articles, I will cover what SAP as legacy means for customers, SAP partners and software companies that compete with SAP.
Software Selection Book
Mastering Software Selection
Software selection is a form of forecasting, just as any another purchase decision is a forecast of how successfully the purchased item will meet expectations. Forecasting is necessary because it is not feasible to implement each application under consideration before it is purchased to see how it works in the business.
The Importance of Software Selection
Software selection is the most important part of any software implementation because it is the best opportunity to match the software with the business requirements, which is the most important factor in determining the success of the project. This book explains how to get the right information from the right sources to perform software selection correctly.
What You Can Expect from the Book
Essential reading for success in your next software selection and implementation. Software selection is the most important tasks in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software the software that matches the business requirements is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues, and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that much like purchasing decisions for consumer products the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision and gives the reader an insider’s understanding of the enterprise software market. By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to interpret information from consulting companies correctly.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process
- Chapter 8: Conclusion
- Appendix a: How to Use Independent Consultants for Software Selection