How SAP Used and Abused the Term Legacy

Executive Summary

  • There is a history of the term legacy systems in IT.
  • There is an implied timeframe for replacement.
  • SAP provides false information regarding their ability to replace legacy.
  • SAP has misused the term legacy to meet their sales goals.

Introduction

So as part of my series on SAP as legacy which began with How SAP is Now Strip Mining Customers, I wanted to write an article to describe how SAP and other vendors deliberately misused the term legacy over the past several decades. In this article, I will show how important the adoption of words like legacy is and how they shape opinions and can influence purchase decisions.

So to begin, let us review the term legacy as it applies to systems.

The Definition of the Word Legacy or Legacy System in IT

“In computing, a legacy system is an old method, technology, computer system, or application program, “of, relating to, or being a previous or outdated computer system.”[1] Often a pejorative term, referencing a system as “legacy” means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. By the 1980s it was commonly used to refer to existing computer systems to distinguish them from the design and implementation of new systems. Legacy was often heard during a conversion process, for example, when moving data from the legacy system to a new database. While this term may indicate that some engineers may feel that a system is out of date, a legacy system may continue to be used for a variety of reasons. It may simply be that the system still provides for the users’ needs. In addition, the decision to keep an old system may be influenced by economic reasons such as return on investment challenges or vendor lock-in, the inherent challenges of change management, or a variety of other reasons other than functionality. Backward compatibility (such as the ability of newer systems to handle legacy file formats and character encodings) is a goal that software developers often include in their work.Even if it is no longer used, a legacy system may continue to impact the organization due to its historical role. Historic data may not have been converted into the new system format and may exist within the new system with the use of a customized schema crosswalk, or may exist only in a data warehouse. In either case, the effect on business intelligence and operational reporting can be significant. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used.”Wikipedia

The term legacy should not be confused or mingled with the term obsolete.

Secondly, a legacy system does not have a specific timeframe for replacement.

An Implied Timeframe for Replacement?

This is explained by more of the quotation from Wikipedia:

Organizations can have compelling reasons for keeping a legacy system, such as:

“The system works satisfactorily, and the owner sees no reason to change it. The costs of redesigning or replacing the system are prohibitive because it is large, monolithic, and/or complex. Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero). The system requires near-constant availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. Examples include systems to handle customers’ accounts in banks, computer reservations systems, air traffic control, energy distribution (power grids), nuclear power plants, military defense installations, and systems such as the TOPS database.”Wikipedia

All of this illustrates the fact that a legacy system can still be adding a great deal of value.

However, through time SAP never applied this concept to the term. Instead to SAP, designating a system as legacy was seen as a way to identify it as the replacement, and as a replacement by a SAP system of course.

How the Term “Legacy” Evolved Over Time

The final portion of the definition from Wikipedia on legacy demonstrates that the term legacy evolved.

“Alternative view[edit]
There is an alternate point of view — growing since the “Dot Com” bubble burst in 1999 — that legacy systems are simply computer systems that are both installed and working. In other words, the term is not pejorative, but the opposite. Bjarne Stroustrup, creator of the C++ language, addressed this issue succinctly:

“Legacy code” often differs from its suggested alternative by actually working and scaling.

— Bjarne Stroustrup
IT analysts estimate that the cost of replacing business logic is about five times that of reuse,[citation needed] and that is not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits — they always have, and they always will. New software may increase the risk of system failures and security breaches. The re-examination of attitudes toward legacy systems is also inviting more reflection on what makes legacy systems as durable as they are. Technologists are relearning that sound architecture, practiced up front, helps businesses avoid costly and risky rewrites in the first place. Poorly designed systems often don’t last, both because they wear out and because their reliability or usability are low enough that no one is inclined to make an effort to extend their term of service when replacement is an option. Thus, many organizations are rediscovering the value of both their legacy systems themselves and those systems’ philosophical underpinnings.”Wikipedia

Legacy Equals “To Be Replaced by SAP”

And in fact, many of the systems designated as legacy by SAP were never replaced by SAP. This was one of the common disappointments on the part of companies that purchased SAP, particularly SAP’s ERP system, who often purchased SAP ERP, and other ERP systems to obtain a simplified system landscape and to drive down costs.

However, the proposition was never particularly accurate as SAP ERP never maintained the breadth of functionality necessary to decommission so many legacy systems. And the concept of best practices contained in SAP was also similarly oversold. This is explained well by a quote from KC Richards, a consultant with decades of database and development experience.

“My first encounter with term “Legacy Systems” was during the adoption period of RDBM systems, mid to late eighties. Yes, there was a time when you could put your job in jeopardy in even suggesting that you would include a “Relational Data Base Management System” in a software architecture. ISAM, flat files, and other creative indexing techniques where the safe way to go. In the decade before, Dr. Codd (IBM System R – “In Codd we Trust”) and Michael Stonebraker (Ingres) where competing over definition of what exactly made up a relational database and what was the most logical data manipulation languages. SQL or QUEL?

Each of the pioneers of relational theory were working on their own products. Larry Ellison was porting his RDBMS on every hardware platform her could find. Sybase was working with Microsoft to license “Data Server”, a database product originally built to run on UNIX computers. That work led to a product called Ashton-Tate/Microsoft SQL Server 1.0 (I remember being a beta user). Anything on a RDBMS was Avant-guard, everything else became “legacy”.

Repeating Historical Patterns in IT

I found this point of KC Richard’s quotation, particularly of interest. Here is why and it is quite pertinent to SAP. According to SAP, relational (actually row oriented) databases are now legacy, and column-oriented databases are recommended by SAP.

As I have covered in multiple articles on HANA such as When Articles Exaggerate HANA’s Benefits, this is an oversimplification. Column-oriented databases have a specific purpose, and their benefits do not generalized to all usage types.

Let us continue where KC Richards states:

“Then came the next generation of “legacy” markers. “If you were not GUI, you were chewy” Then “Legacy Systems” were those not written in “newer” object oriented languages to take advantage of newer hardware platforms. “Legacy Systems” became those that didn’t have GUI screens. Windows 3.1, Macintosh, and OS/2.

Legacy has become that term used to conveniently play on the fears of a company that get define where its sunk costs rest, usually because they have lost track of what they expect of a system. Oddly enough, data entry is still more efficiently on green screens than GUI applications. Legacy systems are simply what you have when you get them.”

This gets to a great point by KC Richards.

What is legacy?

  • Is legacy a term that we simply accept as what is trendy at the time?
  • Is it about usage or about what is new?
  • Are software vendors using this term honestly or is this marketing and perception?

SAP’s Relationship with the Word Legacy

They would simply declare all systems that were developed in-house as legacy.

But that it not a correct use of the term. Legacy systems are the systems for which companies want to reduce their maintenance and future investment. But they are not necessarily systems that can be economically replaced. For example, there were many things that home built systems did that still were required and that SAP would never do.

Porting the functionality to SAP does not solve this basic issue. You are simply porting code to SAP, but that does not mean SAP is “actually doing it.” That is just ported code.

Also, as we are on the topic, why port code to SAP in the first place? Why not simply keep the existing system working and integrate these systems to SAP. When porting to SAP, it means portion what was in most cases an open language like C to a proprietary language of ABAP which does not have a similar development efficiency.

This means that the maintenance and costs invariably increase. This is how SAP radically increased the costs for a large number of companies. The TCO for SAP systems was far higher than anyone anticipated, and the costs of customizing SAP was higher and is now more rigid than creating customizations in open systems. SAP’s own development approach, as well as ABAP, can be considered the “legacy” of going with SAP, which meant adoption their vision of development.

Misuse of the Term Legacy

There is a distinction between legacy and obsolete.

Let me provide a specific example, which is the US rail system.

The US Rail System

The US has roughly 98,000 miles of railroad track. This track is old, but it is not legacy. And why not provides important insights as to how the term legacy should be used.

  • Rail is far more fuel efficient and cost-effective than motor transport.
  • The US would have a very difficult time delivering freight without this rail system.
  • Maintenance should not be minimized on the US network of rails; in fact, maintenance should be kept to a high level. The US should not shrink the total number of miles of track (as we have in the past) but should expand them to take freight off of the roads, which is a highly energy intensive and polluting way to move freight.

Now let us look at another system.

The US Road System

The US has around 4 million miles of roads. Most of these roads were built after the rail network. There have most likely been too many miles of roads created. This is primarily because they were created during a time of low-cost oil. Due to global consumption versus attainable supplies, this looks sure to not be the case in the future. In fact, the proliferation of the automobile is causing human civilizations to use up the global petroleum stock far faster than it would have the automobile not seen such wide usage.

Therefore, while some of the 4 million miles of roads are needed, some are probably going to be legacy as auto travel will need to come down in the coming decades.

So while the road network in the US is partially legacy, none of the rail networks would qualify as legacy. Thus, the age of the items is not the primary driving factor in determining whether something should be considered legacy. Legacy is all about usage or expected usage.

That is legacy is all about usage or expected usage. Not age.

Towards an Accurate Usage of the Term Legacy

In this article, I am attempting to describe the term legacy by its objective definition. I don’t make more money if people use it correctly, I don’t make less money if people use it correctly. However, the same cannot be said for software vendors.

I don’t know how all the software vendors use the term legacy, but as I study SAP documentation and SAP statements and I know how SAP uses the term legacy. When SAP uses the term legacy, they mean any applications that were built by their customer. Or when that application is developed by a competitor. SAP used the term legacy to describe all CRM systems that are not SAP’s CRM system.

SAP used the term inaccurately and in the most self-centered and disrespectful sense to diminish the systems that the customers already had. SAP very much pushed forward the concept and the highly dubious concept of best practices which seeks to propose, and to propose falsely that all business processes either fall into SAP’s software flows, or they are illegitimate. In fact, SAP continues to make this argument regarding customizations for their new ERP system, S/4HANA.

“Another key “how” question we hear S/4HANA adopters frequently debating is their approach to customization. Typically, customers have tended to heavily customize their existing SAP ECC on-premise deployments and, in moving to S/4HANA, organizations can rethink their business processes, which may result in more simplicity and avoid the need for a lot of customization.”ASUG

*This quote is from ASUG, but as ASUG is simply a marketing arm for SAP, I do not draw any distinction between statements from ASUG and statements from SAP. This is SAP’s position on customizations. SAP was wrong when it proposed that customers would be able to move to “best practices” with earlier versions of their ERP system, and they will be wrong again when S/4HANA is broadly implemented. 

Conclusion

SAP misused the term legacy on countless sales engagements. They used the term as a term of propaganda. So what does that mean? When a term is used this way, it is used not to describe something accurately, but just the opposite. The intent of the user is to describe inaccurately and to make the listener more amenable to what the message.

A second important characteristic of what defines when a term is used as propaganda is that and often without having to provide evidence to support the claim. And if we observe how SAP used the term legacy, there was never a case by case analysis at companies whether the functionality could be replaced by SAP. Whether it was a good idea to customize it into SAP if it could not be replaced, etc.. That would have taken a lot of work, and in many cases, the outcome would have been both that SAP did not have the functionality and that it made no sense to port the functionality to SAP. But most executive buyers preferred to not do this work, and buy whatever was trend (what everyone else was buying).

It was much easier to simply use the blanket term legacy, to paper over or obscure all of that analysis. Rather than being analytical, the use of the term legacy seems specifically designed to appeal to emotion and to fashion. To a concept of there being an “in crowd ” and and “out crowd.” Companies wanted the new great stuff that SAP offered, and did not want to be stuck with “legacy.” One wonders how many decisions to go with SAP or other similar vendors when this term was in its heyday, simply to present the impression that the company was hip and with the times.

The fashion industry is based upon a premise that its customers need to get the new items, which have higher social status. If you don’t buy the newest items, you are stuck wearing legacy garments. Companies are presented in business school textbooks as highly rational, and one would generally not think that decisions work the same way. However, the term legacy is essentially the same strategy to motivate purchasing behavior as the fashion industry

SAP Contact Form

  • Questions About This Area?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

https://en.wikipedia.org/wiki/Legacy_system

https://www.asug.com/news/asug-research-what-asug-members-tell-us-about-sap-s-4hana-and-sap-hana-cloud-platform-adoption

To Whom Does Your IT Department Owe Its Allegiance?

Executive Summary

  • SAP investments tend to have negative ROI in companies where they over-invest in SAP.
  • We cover the issue of mixed allegiances of IT departments.

Introduction

The conclusion of our research in this area is that IT departments are insensitive to this exact thing. That IT departments, particularly those that buy a great deal of SAP and Oracle have sold out the interest of business users for their own interests. This is covered in detail in the article From IT to the Business: Go Jump Off a Bridge.

The Common Problems with Agency Outside of IT

The claim we are making sounds very controversial. However, selling out the interests of the individuals you are supposed to represent is quite common outside of IT. Let us discuss two very prominent areas where this occurs.

  • The US Political System: It is challenging to look at the voting record of US politicians and see it as anything more than representing the interests of financial contributors. No one would think that their representatives in government look out for the voters. Voting is how the political system is made to look legitimate. The entire concept of representing the interests of the overall population (the vast majority of which are not financial donors) is no longer really a feasible hypothesis by those that are both honest and know how the US political system works.
  • Financial Advisors: In the area of financial advising, it is far more common for the financial advisor to look to maximise their income and to sell out the interests of their clients. Financial firms that provide financial advisors often provide higher compensation to move lower quality financial products. And only around 10% of financial advisors are “fiduciaries.” That is only 10% of financial advisors sign a fiduciary statement that they will put their client’s financial interests above their own.

This issue with financial advisors is explained in the following quotation.

“If you’re looking for a financial adviser to give you advice on saving for retirement, you’d probably want one that looks out for your best interests. But finding such an adviser may be more difficult than you’d expect. Some advisers are just as concerned—maybe even more concerned—about their own financial interests.

Those that look out for your best interests are known as fiduciaries. Such advisers invest your savings, say, in low-cost funds for a fixed fee instead of comparable funds that charge more in commissions. They promise there won’t be any hidden fees that surprise you later. And if your adviser has any conflicts of interest that could sway his judgment about which investments are best for you, he’s required to tell you.

Savers also have the option of turning to commission-based advisers who may not be fiduciaries. These advisers are only required to make investments on your behalf that are “suitable” for your needs. That means that while the investments your adviser chooses could be appropriate for your financial goals, you could end up paying him more money in commissions and other fees than if you had hired a fiduciary.”

So why should IT departments be immune from agency issues? Virtually no one will write on this topic, because they need to flatter IT decision makers to gain business from them.

The financial advising industry has repeatedly fought against law requiring financial advisors to be fiduciaries. The reason is quite simple. Financials firms want to continue to make the most money off of those they advise, which means putting them into investment vehicles that primarily benefit the financial advisor.

Are IT Departments Fiduciaries?

The concept of a fiduciary is that the entity places the interest of a party above their own interests. However, this argument would be very difficult to make for IT departments that we have worked with. Furthermore, SAP has sold so many non-functional or semi-functional applications and databases to IT departments, that whose interests the IT departments represent is a very natural and quite logical question to ask.

Our Advise to IT Departments

We maintain probably the largest store of information on SAP products for what works, what does not work, and so on. We disclose this to clients.

What might be surprising to readers is that even after we tell clients that they are buying a problematic or failed item, they go ahead and do it anyway. It is strange, but they don’t seem to care. It is as if they have a certain amount of SAP they need to buy, and they are going to buy it.

One of the significant observations from these interactions is that IT departments do such a tiny amount of research before they buy.

What it All Means

If one takes stock of this behaviour by IT departments, it almost appears as if the IT decision makers are agents for the vendors, as if they have sold out the interests of the companies they work for to these powerful vendors. One possibility that has been brought up to us is bribery. We don’t have the evidence for this, but there are various benefits that powerful vendors like SAP can provide to IT department decision makers. SAP has been involved in several bribery scandals in South Africa and Panama. There is no doubt that SAP has paid bribes. It is a matter of public record. However, the broader question is how widespread is bribery.

Conclusion

Our analysis of the decision making by IT departments for companies that use SAP is that something strange happens when SAP offers software to companies. IT departments perform very little research, are easily swayed by claims made by SAP sales reps, and disregard warnings about SAP software, even when that software is declared by us as not capable of being implemented of being extremely difficult to maintain. IT departments routinely bypass far more mature non-SAP applications, and applications which are far better fits with business requirements in favour of SAP applications.

Financial Disclosure

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.

SAP Licensing Contact Form

  • Questions About This Area?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

https://www.consumerreports.org/retirement-planning/make-sure-you-get-the-best-retirement-advice/

https://www.reuters.com/article/us-sap-safrica/germanys-sap-admits-misconduct-in-south-africa-gupta-deals-idUSKCN1GK19M

https://www.huffingtonpost.co.uk/jeanette-buis/sap-has-shown-us-that-bribery-doesnt-happen-in-a-vacuum_a_23261113/

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

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.

Chapters

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.

How To Best Understand SAP as Legacy for SAP Customers

What This Article  Covers

  • How SAP Will Deal With its Customers that do Not Comply
  • Inappropriate Constructs in IT Decision Making for Companies Using SAP
  • How Much do You Know About SAP’s Practices?

Introduction

In a previous article, I laid out why I think that SAP has reached an inflection point in its history and show now be treated by companies as selling legacy systems. For decades now SAP has been seen as a software vendor with a broad suite of applications which are competitive, and that SAP would bring out improvements in functionality that was important to its customers.

This way of viewing SAP, which became increasingly out of sync with the reality of SAP drove everything from SAP software purchases to companies paying what is now 23% in support. Yet, under the construct of SAP as legacy, the question becomes how other software vendors can take advantage of the new phase that SAP is now in.

How SAP Will Deal With its Customers that do Not Comply

If you do not show interest in buying SAP, you will be most likely subject to an audit.

This is described by Ray Wang.

  1. “Open up dormant accounts. After pleasant introductions, new sales reps will use this technique to further deals.  Former sales reps agree this is a shake-down for cash technique.
  2. Drive sales through fear of audits. Audits are used to start the discussion.  Unsuspecting customers who no longer have context about the original contract may fear breach of contract.
  3. Scare customers into making additional purchases. Threats are used to set expectations.  The vendors often waives the issue if the customer buys additional licenses as a “compromise”
  4. Force compliance into new licensing policies. Vendors use this as a way to drive conformity to new license models.  The move from concurrent usage to named users was one example.
  5. Meet territory sales goals. Unscrupulous sales managers suggest this technique to meet their numbers.  Sales reps are told they are defending the vendors license rights.” – Ray Wang, Constellation Research

Inappropriate Constructs in IT Decision Making for Companies Using SAP

Every SAP shop in the world is now following a faulty construct. It is a construct somewhat based upon the past, but which was always exaggerated, and it goes something like this.

SAP is a leading software vendor. We rely upon SAP’s new products to improve our IT capability. SAP’s applications are not always the best, but they connect back to the “mothership,” the ERP system. Therefore, whenever possible we will buy SAP.

This construct has been leading to bad IT software decisions at companies using SAP for over twenty years. The downsides of relying upon this construct are about to get worse. Here is why: 

  1. Post-ERP Applications: SAP’s non-ERP applications have not been value added to companies that implemented them. And we have several decades of data points on this fact.
  2. S/4HANA and HANA: SAPs new ERP system S4 is not compelling and its new database, HANA is not differentiated from the competition.
  3. SAP Support Decline: SAP support has dramatically declined in the past ten years and is now mostly outsourced to the lowest cost countries, pushing the maintenance burden to SAP customers. SAP now expects a 90% margin on the 23% basic support that it charges customers.
  4. Indirect Access and Other Trickery: Lacking the ability to meet Wall Street growth demands, existing SAP investments are increasingly a liability. This is because SAP intends to use its power, size and legal muscle to use indirect access to either receive monies for ERP licenses or arm twist purchases of uncompetitive applications.

This construct that is reinforced by companies using SAP by both the IT department within the company. And the consulting company without. In fact, as the best decision becomes to migrate or diversify away from SAP, the IT department and the IT consulting companies push in the opposite direction from this.

Many IT departments place SAP above the interests of the business of the company they work for. This observation has come from many years of interacting with IT departments at companies using SAP. I have presented to numerous IT organizations over the years the problems with various SAP applications that they purchased, and I am invariably told that.

“The thing is Shaun, we are an SAP shop.”

Therefore, SAP customers should be on notice that your IT department will in most cases lack sufficient independence from SAP to represent the interest of the company they work for, and by the way, that pays their salary. How this was accomplished, at least the full story, is still a mystery to me.

  • The IT Department: The IT department and IT consulting companies had somewhat of a role, will now increasingly serve as a barrier as the reduction in investment from SAP begins.
  • Large IT Consultancies: As for the large IT consulting companies. They have hundreds of thousands of SAP consultants and investments in SAP and revenues from SAP. For a large IT consulting company the only advice they provide is to invest more in SAP implementation. The large IT consultancies have a business model to protect, and it will be protected. These companies are a major liability. Given this environment, what is the value of that advice exactly?

How Much do You Know About SAP’s Practices?

SAP History Quiz

This quiz will test your knowledge of SAP's history as a software vendor.

Our Work With the New SAP Construct

We are one of the few entities that focus on SAP but also tells the truth about SAP. If you want to be provided biased information on SAP there are many choices in the market. We can recommend Deloitte, Accenture, KPMG, E&Y, Infosys, IBM and Gartner among others. However, for unbiased information on SAP, the options narrow considerably.

If you are interested in our advice on how to deal with SAP, and how to manage to diversify away from SAP, reach out to us. We offer a wide variety of advisement all focused around getting a better value from your SAP investment.

References

https://www.constellationr.com/blog-news/insights/sap-wins-major-court-victory-over-indirect-access-customers-should-pay-attention

https://www.computerweekly.com/news/450413224/High-Court-rules-for-SAP-against-Diageo-in-indirect-licensing-case

 

Software Selection Book

SELECTION

Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources

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.

Chapters

  • 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

How To Best Understand SAP as Legacy for Software Companies

Executive Summary

  • It is increasingly obvious that SAP has a very high maintenance overhead, and that the new products from SAP are worse than SAP’s ERP system.
  • The new concept for getting value from SAP is to use non-SAP applications with non-SAP infrastructures like AWS and Google Cloud.

Introduction to SAP as Legacy

In a previous article titled SAP is Now Strip Mining its Customers, I laid out why I think that SAP has reached an inflection point in its history and should now be treated by companies as selling legacy systems. In short form, the most accurate way of thinking is that SAP is legacy. There is a lot of background that is necessary to cover to understand why I have come to this conclusion, so I won’t retrace the evidence in this article, but please go back to the original article link above if you have not read it.

The Flaw in the Current Interpretation of SAP

For decades now SAP has been seen as a software vendor with a broad suite of applications which are at least somewhat competitive. The concept was that SAP would bring out improvements in functionality that was important to its customers.

This way of viewing SAP, which has become increasingly out of sync with the reality of SAP, drove everything from SAP software purchases to companies paying what is now a minimum 23% in support. Yet, under the construct of SAP as legacy, the question other software vendors have asked me is how they can take advantage of SAP’s new phase. This article is for them.

How Other Software Companies React

For other vendors, you now face a crack in the facade or an opening. Brightwork Research & Analysis is early in this analysis. My article on SAP is Now is Strip Mining its Customers is the first article that presented SAP as legacy, or even associates SAP with being a legacy system or a set of legacy systems.

Almost all the media entities that cover SAP take money from SAP, Therefore, they cannot bring up this point even if they wanted to.

Software Vendors Effectively Following the Wedge

If you are a software vendor reading this, this reality of SAP as legacy does present considerable opportunities.

Yet does your company have the knowledge of SAP to widen that crack?

Let us review two areas to see how software companies that compete with SAP can follow the wedge.

  1. The Software Company’s Understanding of SAP
  2. The SAP Partner Program

The Software Company’s Understanding of SAP

I have spoken to many vendors that compete in my time, and in my view, only a small minority understand how to compete against SAP. Most software vendors are very good at focusing on and presenting their value proposition. But they do so often without any consideration to how the chessboard has already been set by SAP before you get to make your case. SAP sets the chessboard that the other software vendors work on in the following ways:

  • Through Conferences
  • Through SAP Partners
  • Through SAP Marketing Literature
  • Through the Incentives of the IT departments

All of these things are present before these vendors even begin to present their value proposition.

It should be noted that much of the information presented through the mechanisms listed above are false. Yet, they are still effective in shaping the views of the buyers. I can come up with example after example of how SAP stopped competitors by pitting immature products against established and effective applications through promising future growth in what the application could do.

One example of this is in the service parts planning space.

The MCA Solutions Story

Back in 2006 a vendor called MCA Solutions had one of the highest rated applications I had ever tested called SPO. SPO focused on the most difficult problem in supply planning called service parts planning. SPO performed services parts planning using two sets of advanced mathematics called inventory optimization and multi-echelon planning.

  • *I have an article here which provides an overview of this category of software.
  • *See my book on this topic if you have the interest.

SAP developed a partnership with MCA Solutions, and developed an xApp that worked with MCA Solutions. But they eventually dropped MCA as a partner. SAP took a significant amount of knowledge about service parts from MCA and launching their SPP product which was a stand alone application. (For more detail on the xApp program, see the note at the end of this article.)

For years SAP customers were lulled into going with SPP over MCA SPO because it had the SAP name, would integrate better, etc..

So where are we close to 10 years later?

  • MCA Solutions was eventually purchased by Servigistics, which subordinated SPO to their own services parts planning application, and they were in turn, themselves acquired by PTC. I believe SPO has been all but erased from the marketplace.
  • SPP has bombed at every account it has been implemented, wasting enormous amounts of resources. I published on SPP’s implementation problems back in 2010 as you can see in this article. I paid to attend both the one week SPP classes at the SAP in 2008. Yet, when I tested SPP back in 2008 I found numerous areas of the application that simply did not work. The application had a weak design and even if its functionality had worked, it still would not have been a competitive application with MCA SPO. Millions and millions of dollars spent and virtually no improvement to the planning of service parts. More money has been spent to keep SPP applications on life support so that the company can cover up the fact that the application does not work and to protect themselves from the political consequences of being seen as responsible for the error.
  • I currently categorize SPP as one of SAP’s dead applications. At a recent client, SPP was introduced as a potential solution by a member of the client’s IT department with extremely low standards of evidence. He showed me a PPT with around 10 customer “references.” I was able to recognize at least 5 of the 10 references that had already failed with SPP. I was able to find out the real story on 2 of the others on the list, and it turned out they had implemented SPP, but few people were using it. I was not able to verify the other three.

The MCA Application

The end result is that one of the best applications I have ever tested in MCA lost market share to one of the worst I have ever tested in SPP. And here is an important point for vendors that compete with SAP to consider.

SAP never demonstrated any competence with SPP.

They future sold gullible clients who decided to not do the basic research into the application that I did do.

For competing vendors, you cannot rely upon prospects to do their research on SAP’s products or on the overall usage of the SAP products in the marketplace.

SAP’s Problematic or Dead Applications

I have already listed SAP’s dead or problematic applications in the strip mining article. But as a software vendor, you have to raise the issue of the overall success (or lack of success) of the SAP application. This is because most SAP customers tend to assume that other customers are having success with the application, and they just did not have success because of an implementation failing, poorly trained users, etc.. I am amazed how often I go to clients and they tell me they would like me to fix an issue that is actually a well-known software bug, but which SAP support has hidden from them. There are SAP customers that are repeatedly attempting to bring functionality online that I have already tested and have determined should not be activated and it is not useful.

  • Dynamic Safety Stock (called Enhanced Safety Stock by SAP): SAP’s dynamic safety stock is one example of this.
  • Deployment Optimizer: Companies are still trying to use SAP’s deployment optimizer in SNP (it is a procedure that moves inventory through the supply network) and paying SAP above the standard 23% support to try to get benefit out of it. I have already tested and published on being unable to produce logical and useful output under any circumstances.
  • Best Fit Procedure in SAP DP: The best fit procedure, where a forecast system selects the appropriate statistical forecasting model is not reliable enough in SAP DP to use in a production environment. Yet consulting companies continue to bill clients for using and tuning problematic functionality that can be accessed far more robustly outside of SAP, with the results ported back to SAP DP.

This is how bad the information sharing is on issues is in the SAP space.

The Problem with SAP’s Flexibility

SAP systems greatly reduce the flexibility of their customers. With indirect access, SAP can control which applications are connected to SAP applications. This dawning awareness of SAP’s inflexibility is highlighted in the following quote from the book SAP Nation 2.0.

“When ERP was in its heyday, CEOs and business executives wanted reliable and integrated solutions, so they seized upon ERP as the way to provide….Business stakeholders still want these same qualities, but now they assume that these qualities will be present in any software solution, and their requirements have switched to the twin concerns of lowering IT costs and seeking increased flexibility. A system that is not sufficiently flexible to meet changing business demands is an anchor, not a sail, holding the business back, not driving it forward.”

How the SAP Partner Program Censors Partners and Reduced Competition

A major part of SAP’s success, probably the most important part, in fact, is its partner network. There are over 10,000 SAP partners. SAP will partner with just about anyone.

Software vendors that are part of the SAP partner program are themselves guilty of promoting partnerships with SAP as being far more significant than it is in terms of how it benefits customers. Here are the most important characteristics of the SAP partnership program.

  • The SAP partner program is a primary way that SAP reduces the competition that it faces in the marketplace. The SAP partnership program is never mentioned in the same sentence as competition limiting, but the way that SAP uses it, it certainly qualifies. There are too many dimensions to discuss to fit in this article, as SAP’s partnership program is really its own detailed subject. But a lot of underhanded things happen in the SAP partnership program. The partnership program also changes for small market countries, and it differs based upon the size of the software vendor, and along many other dimensions.
  • The SAP partner program is how SAP controls the marketing output of companies that compete against it. Software vendors start off thinking that they will benefit from the agreement, and before they know it, they are being played like a piano by SAP.

SAP’s Leverage Over SAP Partners

SAP has considerable leverage over SAP partners, as the partners often need or believe they need their certification or partnership credentials to sell into SAP accounts.

  • In most cases, the actual certifications are falsified. It is common for a single field to be sent across to SAP and for that to essentially certify the software company.
  • SAP puts extremely little effort into testing the technical validity of a certification, say of an adapter.
  • Simply put, SAP certification is much more about marketing hoopla than engineering.

There are a variety of SAP certification logos that companies that have “become certified” can place on their websites.

This certification can be found on the websites of many software vendors. The SAP Partner program for software vendors is more of a marketing construct. Every software vendor likes to state that they are a certified partner. 

The following are important characteristics of the partner program.

  • Who Are Partners?: Most vendors that complete with SAP are partners with SAP.
  • SAP Censorship: They are limited in what they can say by their partner agreements.
  • No Referrals: SAP only very rarely refers business to their partners.
  • Second Banana: Most SAP software partners feel they are mistreated by SAP. SAP regularly stabs their partners in the back to push sales over to their own applications, even when the fit between the requirement of their customers and the SAP application is either terrible or if the SAP application is not even ready to be implemented.
  • Lowering Competition: SAP has partnered with any software vendors (almost) that competed with them, and then uses controls gained from the partnership agreement to reduce that vendor’s ability to compete with them. The software vendor becomes normalized to presenting their solution as complementary to SAP rather than competitive with SAP so as not to ruffle any SAP feathers.

There is in fact, no real partnership. It is a false construct. It is a marketing construct that exists primarily in the minds of buyers. The SAP partnership, with its effect on competition, is an interesting curiosity because it is not willingly entered into by software vendors. It is enthusiastically entered into by these software vendors.

I can’t tell you how many software vendors became partners in part because they thought SAP would bring them deals.

The Importance of Software Vendors Knowing The Limits of Their Knowledge

If you are in senior management at a software vendor, who believed this, you then you did not have enough exposure to or information about SAP to compete against them. And its good to know this, so that you can address the issue because addressing the issue has good potential to lead to higher sales.

SAP is a complex beast and cannot be understood with light or occasional exposure. It often surprises me that SAP marketing works not only on customers but works almost as well on competing software vendors. They will often come to assume that many of the fanciful items presented by SAP marketing are in fact true.

Conclusion

SAP has passed into a new phase of its existence. SAP’s marketing machine is intense. The term reality distortion field seems appropriate.

The fact remains that outside of SAP ERP, the returns from SAP’s other applications have been extremely weak (something I have covered in my previous articles). Of all software companies, SAP has the most implementations of applications that add little value to their customers. This makes sense as for decades SAP has had all of the major SIs mindlessly shilling for them. Therefore the SAP “garden” is overgrown with “weeds” and various applications with serious problems. The IT departments in these customers often try to defend these bad applications by pointing out the stupidity of the users, or denying the problems.

This information comes from two decades of evaluating SAP installations at many accounts. However, you don’t hear this information because the people that now have a financial incentive not to publish this. This is the real story, not the paid off story offered by SAP consulting companies. These SAP applications are vulnerable, particularly after it can be explained that each of them has little in the way of a future. You can only promise the future for so long until it eventually arrives. Well, the future is now here.

Brightwork Research & Analysis published the first article to call out SAP applications as legacy. Although if you read SAP Nation by Vinnie Mirchandani he says essentially the same thing, without using the terminology of “SAP as legacy.” Realistically, there is no likelihood of SAP bringing out future products that do anything special. SAP still has its ERP system. But outside of that, there is not much to be concerned about, in real, rather than perceptual terms.

But now the question turns to what software vendors can do to take advantage of this opportunity.

Note on the SAP xApps Program

Back in 2010, I called for the SAP xApp program to be terminated as it was resulting in a large amount of intellectual property being extracted from software vendors and transferred to SAP. And that companies that were engaging in the xApp partnership were naive to how SAP operated. In my article, I stated it is a program that should have been reviewed by the US Federal Trade Commission. Larger software companies are not supposed to have a program where they promise improved sales that largely never materialize in order to Hoover up their IP.

I also covered how SAP used a partnership with i2 Technologies to extract intellectual property from them in the 1990s to use as the basis of SAP APO, and covered this story in the early drafts of my book on Discover SAP SCM. This material was censored from the book by the publisher SAP Press, and so it never appeared in the published version. My experience with SAP Press promoted me to not publish books through traditional publishers.

There are no publishers in the SAP space who will publish 100% truthful information on SAP. But unfortunately for me, that is the only information I was or am interested in writing or publishing. SCM Focus Press is my publishing company, where all the books are uncensored.

SAP Contact Form

  • Questions About This Area?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

https://www.constellationr.com/blog-news/insights/sap-wins-major-court-victory-over-indirect-access-customers-should-pay-attention

https://www.computerweekly.com/news/450413224/High-Court-rules-for-SAP-against-Diageo-in-indirect-licensing-case

*https://www.amazon.com/SAP-Nation-2-0-empire-disarray-ebook/dp/B013F5BKJQ

 

Software Selection Book

SELECTION

Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources

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.

Chapters

  • 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

How SAP is Now Strip Mining its Customers

Executive Summary

  • 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.

Introduction

  • 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?

SAP APO

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 CRM

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?

It can’t.

  • 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.

SAP Licensing Contact Form

  • Questions About This Area?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

https://www.constellationr.com/blog-news/insights/sap-wins-major-court-victory-over-indirect-access-customers-should-pay-attention

https://www.computerweekly.com/news/450413224/High-Court-rules-for-SAP-against-Diageo-in-indirect-licensing-case

*https://www.amazon.com/SAP-Nation-2-0-empire-disarray-ebook/dp/B013F5BKJQ

Software Selection Book

SELECTION

Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources

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.

Chapters

  • 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