- The Concept of SAP as Legacy and What it Means
- What Replaces SAP?
- TCO Versus ROI
- The Logic of Stripping out Non-ERP SAP Applications
- Selling the Opportunity of SAP?
In a comment on my article How to Best Understand SAP as Legacy for Software Companies I was asked the following question.
I wanted to take the time to address the first part of this question in an article. To do so I need to review the concept of SAP as legacy and what it means.
The Concept of SAP as Legacy
In my article How to Best Understand SAP as Legacy for Software Companies, I outlined how SAP has not been successful outside of ERP.
If we look at one SAP application after another, they disappointed after implementation. The list of applications and my categorization of them are included in that article so I won’t repeat the listing and categorization in this article. But the important observation from any objective review of SAP’s applications is that the concept or strategy of implementing more than the ERP system from SAP has not resulted in good outcomes for the implementing companies. It has of course been great for SAP consulting companies and for SAP itself. In fact, the over the implementation of SAP would have to be categorized as one of the great wastes of resources in the history of IT. Implementing a non-ERP SAP application with a large SAP consulting partner is easily the worst value in IT, and there really is not a close second. At Brightwork Research & Analysis there are a number of online TCO calculators, and in my estimates SAP has the highest TCO in every category.
TCO Versus ROI
Yet, the story is far worse than just this. This is because TCO is only part of the equation. SAP has so many incapable applications outside of its ERP application that they have great difficulty adding value to companies. There are winners and losers here. SAP is very good for the resumes of those that work in IT, which explains IT’s blind adherence to SAP regardless of the outcomes for the users of these systems.
This is very much like doctors who recommend medicines to patients that are on a patent when an identical generic is available. Pharmaceutical companies have greatly increased their revenues by financially incentivizing doctors to recommend drugs that are good for the doctor’s and the pharmaceutical company’s bottom line. Pharmaceutical companies have been very effective at doing this, which shows that very few doctors have made the decision to place their patient’s financial interests ahead of their own. This explains how Nexium is prescribed by roughly 97% of doctors over Prilosec (which is a generic and came off of patent), even though they are virtually chemically identical.
Therefore in addition to the highest possible costs, in most cases outside of ERP, SAP customers also get the worst software usability and the lowest possible user uptake. A perfect example of this is the SAP BW application which consumes massive IT resources but is able to produce very few actual reports. In a previous article, I questioned whether SAP BW could even survive as an independent product.
The Logic of Stripping out Non-ERP SAP Applications
Looking at SAP as legacy means in most cases keeping the ERP systems that were already installed. But it means diversifying away from SAP outside of ERP. This breaks down a bit differently depending upon the size of the company in question.
- A Strategy for Smaller Companies: Many smaller companies were lulled into purchasing ECC due to false statements by SAP and the SIs about it being much easier to implement and maintain than it was in the past. However, nothing changed in ECC to make these things true; it was all marketing smoke. Like the Run Simple campaign. Those smaller companies may in some circumstances want to remove ECC as it is too high in overhead and can’t justify its yearly expense.
- A Strategy For Larger Companies: For larger companies that keep ECC, or in most cases keep ECC, looking at SAP as legacy means decommissioning the non-ERP SAP applications. Presently many IT departments are hiding how little value these applications are adding…for career reasons.
Selling the Opportunity of SAP?
The idea that future versions of these problem applications will improve things is no longer tenable if one is objective on the topic. If the individual does not care about business value and just want to keep more SAP on their resume for career purposes, then keeping these SAP applications makes sense. And this is why IT members should be directly queried as to where their loyalties lie, and why they continually defend ineffectual applications from SAP.
SAP as legacy means acknowledging what is obvious from the large number of projects that we receive information from.
- SAP is not capable of developing effective products outside of ERP.
- SAP is far more of a marketing organization than a software development company.
- SAP only has the market share they do in the products outside of ERP because of the tie into ERP and because the major IT advisors are in SAP’s pocket. Therefore SAP customers can receive large returns from dropping non-SAP ERP applications and putting in competitive applications that are selected for the actual characteristics of the application, rather than to meet the sales quota of a partner at an SI, or to pump up IT resumes.
As the problems with non-ERP SAP applications become impossible to continue to ignore, the question of the loyalty of so many IT departments to SAP becomes a question that should be highlighted. What is apparent is that in many cases those that work in IT departments have preferred to put in uncompetitive SAP applications that while they have cost the companies mightily, they have been good for the careers of these IT decision makers.
Outside of the ERP system, SAP applications have become liabilities rather than assets for the companies that implemented them. This brings up the topic of to whom do these decision makers owe their allegiance, to the companies that employ them or, through their careers, to SAP.
Enterprise Software Risk Book
Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects
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
Enterprise Software Risk
See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.
Who is the Most Accurate Source on SAP?
Want to find out? See... A Study into The Accuracy of SAP