How SAP Used and Abused the Term Legacy

Executive Summary

  • There is a history of the term legacy systems in IT.
  • SAP provides false information regarding their ability to replace legacy.

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 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 of their vision of development.

The Statements About All Non-HANA Databases as Legacy

This is from SAP’s website.

Here SAP proposes that all other databases are outdated technology. They also imply that only HANA has in-memory architecture and that it is revolutionary. We will address each of these claims.

This is where the term Legacy is used.

SAP went on to expand on how all non-SAP databases were legacy in the following quote from the PR release, SAP’s Bet Seems to be Paying Off.

Yesterday’s databases can’t solve modern problems, SAP HANA can. That’s the message that SAP will keep repeating as its Spotlight Tour travels the world. The business users will no doubt be eager to hear about how digitizing their enterprises will unleash new opportunities. The geeks in the audience will want to get their hands on cool, new tools. But someone is going to need to do the work and pay the tab.

In a world of open source, and what may appear to be cheaper solutions, getting the C-suite, IT and accountants on the same page may not be an easy job. But SAP has a huge customer base and more than four decades of marketing experience to rely on and, so far, it seems to be doing something right.

Oracle 12c, MySQL, Microsft SQL Server, PostgreSQL are not yesterday’s databases. This is a titanically inaccurate statement that would only be made by someone intent on misleading the reader. HANA does really only one thing well, and cannot beat out databases that are also designed to do that one thing (read access for reporting). SAP does keep repeating this message, but it just happens to be false.

Enterprises are already digitized. This occurred decades ago. Digitization means when information is placed into ones and zeros. Who this statement is tricking is a mystery to us.

The clear direction in databases is towards open source. Google built its infrastructure on open source. AWS is mostly open source. HANA is the most expensive database we track and has been relentlessly exaggerated by SAP and their surrogates since its introduction, as covered in the article When Articles Exaggerate the Benefits of HANA.

What SAP Did with Casting All Non SAP Databases as Legacy

SAP said that all data was loaded into memory. Now, naturally, there is data copied to disk. But SAP stated that everything was loaded into memory all at once, and they put down other vendors that performed memory optimization. Years ago we found the contrary in SAP’s technical documentation around HANA. But the opposite (all in memory) was a major marketing and sales point for HANA, and vendors like Oracle and IBM and others that proposed this was not realistic were called “legacy databases.” SAP still calls all other databases it competes against “legacy databases,” even though HANA mostly follows the same design (it specs massive hardware and memory, but HANA cannot effectively address the memory). This leads to one question

“why are other database legacy?”

At SAPPHIRE 2019 Hasso made the claim that over 200 peer review studies all proved that HANA had produced these great benefits over “legacy databases.” This is not possible. Furthermore, we found these studies do not exist as we covered in the article How Accurate Was Hasso Plattner About SAP HANA Publications?

Evaluation of SAP’s Claims

First, SAP is a more recent database than IBM BLU, Oracle 12c, and Microsoft SQL Server. However, SAP is in no position to call any of these databases legacy. This is because these databases outperform HANA, as we cover in the article What is the Actual Performance of HANA?

Legacy means that the item is near obsolete.

This a ludicrous claim for any of these databases, all of which have many times more installations than HANA, and unlike HANA, all three of these other databases are used outside of SAP with non-SAP applications. SAP cannot claim this, which provides an inkling as to the competitiveness of HANA.

This claim is so exaggerated that….

Ding Ding Ding!

We award SAP a Golden Pinocchio for making this proposal.

The comment is so divorced from reality and so false that there is no other conclusion than to say SAP is undoubtedly aware they are deceiving readers by publishing these statements.

Other Claims

Now let us review the other claims made in the SAP statements.

  • All other Databases are Outdated Technology?: That is an enormous claim. What evidence has SAP produced that this is true? Information coming back from actual projects indicate that HANA cannot keep up with the performance of previous generation databases outside of data warehouse type queries, (where it loses against the updated versions of these other databases). The details of this are covered in the article HANA as a Mismatch for S/4HANA and ERP.
  • HANA has Revolutionary In-Memory Architecture: This claim is also false, as we cover in the article How to Understand Why In-Memory Computing is a Myth.
  • ACID Compliance?: ACID stands for (Atomicity, Consistency, Isolation, Durability). They are fundamental requirements of a database. Every single one of the databases that HANA competes with is ACID compliant! And they have been for decades. This is tantamount to General Motors saying that its cars are better than competitors because they use spark plugs. Why would SAP say such a thing? Most likely because their readers do not know what ACID compliance is, and therefore they think it is some type of differentiator.
  • Only HANA Can Support High-Speed Analytics?: This is news to every database vendor that competes with SAP. All of these databases can support high-speed analytics. Again, HANA loses against its primary competitors in analytics, if those databases are the most up to date versions. The older version will lose against HANA in analytics because they lack the column-oriented store. SAP is continually attempting to have HANA compete against databases from vendors from six years ago when HANA was first introduced. Of course, HANA on new hardware will beat other databases on older hardware. Something that is quite obvious, but which is missed by IT departments that implement HANA on new hardware and discuss the improvements — without accounting for the percentage of performance which is solely due to the hardware. We covered this topic in the article How Much is Hardware Responsible for HANA’s Performance?
  • Only HANA Has Application Services?: Application Services are a bit of a nebulous term. But they are applications. Oracle 12C, IBM Blu, and MS SQL Server run applications. Applications sit on top of them. Therefore, this is a curious way to differentiate HANA. This seems to imply that HANA is unique because it can interoperate with applications. If it couldn’t then what would it be doing?
  • Only HANA has a Flexible Data Acquisition?: Why is that true? More flexible than competitive offerings? A database stores data. Data acquisition is normally performed by middleware. Of course, it depends upon the definition. If SAP’s definition of acquisition is that data can be loaded in different ways into the database, then again all of the competing databases have this ability.
  • HANA has a Single Platform?: HANA is not a platform. HANA is a database. If SAP means that both the applications are offered by SAP as is the application — then this is true. But because SAP is not as good with databases as their competitors this also means that buyers of HANA give up specialization and many other factors to buy their application and database from the same vendor.
  • Only HANA has no Data Duplication?: It is unclear why HANA offers less data duplication than competing databases. In fact, because of bizarre license restrictions, we are aware of scenarios where HANA has a 100% level of data duplication. This is explained in the article HANA Police and Indirect Access Charges. Here SAP requires companies buy a second license of HANA and replicate all data between the two HANA instances to allow data to be moved to a third database.

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.

The Problem: Tolerating False Information

The misuse of the term “legacy” is a clear example of deceptive practices on the part of SAP and the SAP consulting firms. It is amazing to how many of the clients accept lying from both SAP and the consulting firm. By not calling out the lying, the client encourages more of it. The fact is both SAP and SAP consulting firms lie, and they lie a lot — and we have the evidence to prove it.

The intent of the lying is to be able to charge more for things that are often not true and to cover up previous lies that were told to try to sell or otherwise influence. Many customers seem to have a problem processing that they are being continually lied to by these companies.

The more lying is tolerated, the more SAP and the consulting company will continue to lie.

Being Part of the Solution: What to Do About Leonardo

We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP as Legacy Content

References

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

https://www.cmswire.com/big-data/saps-hana-bet-seems-to-be-paying-off/

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

Testing The Hypothesis of IT Department Indifference to Facts Which Contradict their Favored Vendor

Brightwork Research and Analysis specializes in research that fact checks SAP and Oracle. However, when we reach out to IT directors to connect, our acceptance rate is low. Less than 10%. Our acceptance rate from sales managers at vendors that compete with SAP or Oracle is around 30%. (I change the text a bit for the sales managers to focus on competitive intelligence).

This is reinforcing other datapoints from other areas we have gathered, that IT directors at SAP or Oracle accounts are not actually looking for fact-checking. They think they are getting good information as is. IT decision-makers are not the market for research and services. And that competing software vendors and procurement, that is trying to get a better value is actually a far better market or audience.

This is reinforced by the following quotation from Rolf Paulsen.

“This matches my experiences in the statutory health insurance. IT departments built their kingdoms over years and SAP connections are an important corner stone. Questioning SAP weakens their position and even might disclose their failure to get familiar with state of the art software technology.”

The Example of the Acceptance of SAP’s ABAP

The whole ABAP acceptance by IT departments shows this passivity. One does not have to use ABAP to customize SAP — in fact, many custom applications “legacy” should have never been ported to SAP. SAP is a highly inefficient system for development. Instead, these applications should have been maintained, and then integrated to SAP. These IT departments greatly damaged their companies and took on large technical debt by listening to SAP on this subject. And after they did, now SAP and their consulting firm had far more account control then if these native applications had been kept as is and integrated. IT departments also suffer from the Dunning Krueger Effect. They think they are experts in IT, but in reality, they have no research capability and they are normally divided into a Director and other management and then workers who have narrow and specific skills and are not involved in decision making.

Anyone who uses the Brightwork Research & Analysis TCO Calculators will find that SAP has the highest TCO applications in the IT industry. The reason for this is several-fold. However, one reason does not only do SAP (like virtually all vendors) follow an application data model, but SAP uses one the worst development languages that any customization can be performed with (ABAP). The ability of SAP to force a report writing language onto customers is covered in this article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.

The very concept that an application vendor can choose the development language demonstrates, that IT decision-making capacity and leaders in SAP accounts are seriously either corrupted or incompetent or both. The technique used by not only SAP but many other vendors is to fake a requirements match, with the help of a corrupt consulting firm, then begin large scale custom development after it is learned that the packaged software is a weak match for requirements. This is an algorithm at this point. Yet buyers still cannot seem to figure out this simple fraud. Deloitte and Accenture and so on have been ripping off customers for decades with this same strategy.

This brings us to the quote of Christian Kaul.

It seems to me that many it departments are more like parasites feeding upon the host company instead of actual parts of the whole.

Obviously, if the IT department does not represent the interests of the company, the IT department is a major part of the problem. The argument is, and it has some validity, that in the US at least, companies provide so little in the way of job security, that the management of IT feels they are better off aligning themselves with a vendor or consulting firm. They can then find another job with that technology if they lose their job at their current employer. I have presented so many analysis to various companies telling them to not buy certain SAP applications and they went ahead bought them anyway. It is just bizarre that so many IT departments have little concern as to whether the software they purchase is even desired to be used by the business.

A following important observation is provided by Markian Jaworksy.

Definitely in large organizations IT dept. Is a business within a business. Run as a BlackBox so only those in charge have the ability to communicate the “truth” to the company at large. From experience, any leakage of “truth” is a disciplined offense. HR does not compute that rank and file could be ever so wise.

This is quite curious because I have observed IT rigging information, or presenting inaccurate information to the business in a very frequent fashion. IT departments claim great knowledge on information technology topics, but this knowledge is not apparent to me from interacting with senior members of IT departments. Far more often they seem to be swayed by vendor salespeople and they only in very rare instances fund any research function within the department. Their main interaction with research is to purchase research from Forrester or Gartner. However, the problem is that Forrester or Gartner are paid by vendors and consulting firms, and only provide information within a very narrow framework, which is profit-maximizing to these two firms as is partially covered in the article How Gartner Opposes Open Source for its Own Benefit.

The IT Department’s Concern for What is True

The issue with enterprise software risk management is that the risk for software buyers is not actually the risk of the project failing. Rather the risk of project failure must be balanced in the buyer’s mind against other risks. One equally important risk is buying software that is not a major brand name.

“I used to think that marketers in companies were trying to be better marketers, and then I realized that many of them were mostly just trying to move themselves forward. This is a jaded view of things but in reality it often rings true. If a marketer is working in a large company their goals are probably to move up and impress the boss, if they work in a small company or are their own boss their goals most likely revolve around increasing revenue and making more money.

What that means is whoever you’re selling to probably isn’t buying your products or services for anything but themselves. If you sell shoes, they’re probably buying them to look good (hence why every clothing commercial features people looking good and being admired), if you sell business services then people are probably buying to make themselves richer or more successful.” – Interact

The Shop Concept

Most companies are “SAP shops” or “IBM shops” and show extreme loyalty to major vendors. Loyalty should be translated in this instance to choosing products that are a bad match for the business requirements.

In a regulatory environment, which is similar to IT departments as they are in a way to regulate the purchases from various vendors, the phenomena of selling out your interests for the interests of outside parties is called being captured. There is quite a bit of research into capture. Wikipedia has the following definition of capture:

“In economics, regulatory capture occurs when a state regulatory agency created to act in the public interest instead advances the commercial or special interests that dominate the industry or sector it is charged with regulating. Regulatory capture is a form of government failure, as it can act as an encouragement for large firms to produce negative externalities. The agencies are called “captured agencies.”

Through receiving consideration, sometimes in the form of job offers, or ego stroking or financial contributions, the individual making decisions is corrupted. Regulatory capture is more blatant than the capture that occurs between large vendors and IT departments. Large vendors are not able to make direct financial contributions to companies to influence policy, and while there is some job movement between IT departments and the large vendors, it is nowhere near as prevalent as it has become in the various regulatory bodies where the senior positions are literally a revolving door between the regulatory body and the companies they regulate.

The largest vendors like SAP, Oracle, Microsoft and IBM, one way or another, have so captured the interests of IT, that at sometimes it appears as if the IT department works for these vendors, rather than for their employer. This is actually a subtle form of corruption, is the ultimate objective of any account manager for a major software vendor (that is to get the IT decision makers to be more loyal to the software company they buy products from than the company that actually pays their salary) and is part of the reason that large enterprise software vendors have little incentive to innovate.

Vendor Capture of IT Departments

The topic of software vendor capture of IT departments is much less investigated or researched. However, it is essential to understand how capture works in regulatory bodies as the behavior is substantially similar.

The interesting question is large software vendors can accomplish this goal. Here are a few of the ways they achieve this goal. The quotation below is one of the few that can be found on the internet for what is a significant problem. It’s uncommon for this to be discussed.

“The purchase of software, consultants, and IT services to those NOT most qualified, but to those that provide the manager with tickets to games, vacations trips, potential new job opportunities, and other ‘loop holes’ in corporate policy. This can cost companies millions of dollars down the road on failed integration projects, extra contractors, and unneeded services and software.  I never thought much about this as a young developer, but as I advanced higher into the ranks as a senior developer, I would be invited to attend manager meetings for ‘technical support’.  Here I would see Directors spinning products that were total crap and way over-priced.”DoodleKit.com

Buying off the decision-making inside of IT organizations has an interesting precedent in an ongoing legal case. However, in this case, it was a consulting company, Deloitte, which clearly wined and dine and eventually hired an internal project auditor for Marin County, a mere two months after he approved $3 million in consulting charges for what ended up being deficient work. This topic is covered in this article.

Pushing Lying to New Heights

In some cases, the methods used by vendors and consulting companies are straight up corruption. However, the slick salesmanship within large vendors and large consulting companies, is, in effect to help companies make poor decisions that are against their interests. These companies would not employ so many salespeople who so commonly lie unless it was understood that they would be using this skill of lying against prospects and current customers. This extreme form of lying is evident from any of the quarterly calls from the major vendors, where the executives like Mark Hurd or Bill McDermott lie on a regular basis and are sort of the special forces of liars. That is they produce a level of lying that is the ultimate goal of many of the sales reps within these companies aspires to.

What Happened to IT Departments?

IT departments at this point share similarities with the health care system. They are highly inefficient, highly bureaucratized, and more about its narrow interests than serving the customer (in this case the business).

A perfect example of capture is this video from Florida Crystals at an SAP ASUG conference where the CIO is lying about his project with S/4HANA. The CIO here declares an impossible migration to S/4HANA of 3-4 weeks. How did the vendor, SAP, in this case, motivate this CIO to lie is such an obviously falsifiable way? The Florida Crystals case study is covered in detail here. and was one of the many case studies used at part of Brightwork’s research into the implementation history of S/4HANA.  

Why IT departments have become so insular is an interesting question, however, if we look at for instance the marketing department at companies, they are quite frequently wholly unconcerned with how their policies affect operations. That is marketing sees its role to excite demand as much as possible, the accuracy of the information provided usually is not a concern. Therefore insensitivity between departments is indeed nothing new. IT departments have reached a state where they are unconcerned as to whether the business derives value from the applications they support. IT departments cause a major drag on economic efficiency because they tend to steer enterprise software selection decisions away from applications with high functionality that meet the business need, to high maintenance applications that meet IT needs.

The Battle Between Business and IT

The inflexibility on a host of issues, including IT offering up the same old lagging edge applications from large vendors that sub-optimize the business has helped deepen the discord between the business and IT. The business often views IT as not having an interest in providing them with solutions which help the business meet their objectives, and as an independent consulting who often is hired by IT and works with the business, I have to say this view is quite often accurate. Many IT departments show utter disdain for the business, implementing software in a way that has little regard for how the business benefits, something which has quite a bit in common with how IBM tends to implement software.

I have been at companies repeatedly when the IT resources that the IT director loves so much turn out to be incomprehensible to the business. I have seen many instances where the IT resource provides convoluted and false answers (often to protect software weaknesses or flaws) and the IT director supports the IT resource in essence “snowing” the business resource. For the IT director unintelligible resources who play fast and loose with the truth help get the business resource to “go away.”

Who Cares About IT Efficiency?

Our primary focus has been SAP and Oracle and consulting firms like Accenture and Deloitte. We have recently concluded that IT does not care much about the actual benefits of software to the business. Instead of the benefits to the customer, the careers of the IT decision makers is placed above the business user. And the larger vendors have convinced IT departments that it is in their best interests to align with the vendor.

“Look, we draw a paycheck, but we don’t really work here.”

Is there any love as pure as that between a sales rep and their customer? If you have any type of decision making authority over IT dollars, prepare for some out of the world treatment. You are “brilliant,” “bold,” “forward thinking” and you know the best software is offered by that sales rep. 

Lessons in Extreme Flattery

If you sit outside of an IT director’s office and listen to vendors and consulting firms visiting, (as we have) it is rather sickening. Many of the conversations sound more like a discussion on a golf course than any serious business. The sales rep butters the IT director up, and this is often quite readily accepted by IT directors who feel underappreciated.

Finally, someone who appreciates them, and who shows them the respect they deserve! Not at all like their business counterparts that only complain about the poor systems they are forced to use. If the IT director continues to buy from the vendors, they can expect an unending sequence of flattery and free goodies as well as resume enhancement that can stretch on for years. SAP takes the most compliant CIOs that have wasted the most of their company’s budgets and gives them jobs in ASUG when they are between CIO gigs.

Sales reps know how to get the decision makers to put their own interests ahead of their company’s interests that they represent. The game these reps are playing is one of corruption. They are not simply offering information about a product or a service, rather they are engaging in a velvet glove handling of an IT decision maker, making them think that their lifestyles will improve if they align themselves with a particular vendor. This is why so many reps have expensive hobbies. Sailing, playing polo, golf, all of these things create an illusion of a lifestyle more exciting than that of the IT decision maker.

Switching the Allegiance of the IT Decision Maker

The objective of the sales rep is to get the IT decision makers to put their own interests first, and their company’s interests second. Any sales rep can sell a good quality solution, it takes an exceptional sales rep to sell a barely functional solution. And this is why they are paid the most, and why Oracle and SAP have the highest paid sales reps.

And it is perhaps surprising how easy this is to do. Sales reps have done their job so well that they have completely screwed up IT. They have promoted massive waste due to a combination of technological ignorance on the part of customers and sales reps getting IT decision makers to throw the interests of the company out the window in exchange for more “personal benefits.” Sales reps may have created “great relationships with IT directors and VPs,” but IT is suffering from these “relationships.”

For CIOs it is “In and Out”

CIOs have an average tenure of 3 years at companies in the US. The objective is to get in, make announcements of change, but leave before the changes can be tested. This tenure is an example of the way in which IT has developed a culture of irresponsibility where they are unable to perform the fundamental aspects of their jobs as decision makers. This would include evaluating project risk, holding bad vendors responsible, keeping the company from being leveraged by audits and lock-in.

The current model of choosing CIOs does not work. Companies end up with highly ambitious individuals with little concern from what is true. Ambition is what leads them to care little about the outcomes of IT decisions versus their own personal outcomes. 

Companies don’t seem to understand, switching out one compliant and brainwashed CIO for a new compliant and brainwashed CIO will not do anything to change the outcomes. It is the structure of IT and how IT is controlled by vendors that is the problem. Each new CIO comes with their own vendor relationships before they assume the new job. CIO’s are often chosen because they have “experience” in various items. However, CIOs don’t touch systems, so their domain expertise in a particular application or database is far less important than their ability to look at the new situation objectively.

IT as the Inside Man

I have been dissuaded by IT to censor analysis that would end up pointing a finger at their bad decisions. I have witnessed behaviors that clearly demonstrates IT decision makers being the but back pocket of these vendors. Truth has little currency in most IT departments, the rule is exaggerating one’s knowledge to IT, and covering up previous decisions that went sour because the IT decision maker spent more time listening to sales reps than doing any research. IT departments have become extremely hierarchical with a clear segmentation between executive decision makers and worker bees. And the worker bees, those with the technical knowledge, are normally not even asked for their opinions as to the various claims made by sales reps.

None of this corruption could work without compliant IT departments. Why? This would empower them, and display the lack of understanding of technology on the part of executives to the people that work below them, and earn far less money than they do.

In many bank heists, there is an outside team and an “inside man.” The title of the 2006 movie Inside Man is a nod to this feature of heists. So while the sales reps for the software vendor and the consulting firm is the outside man — IT decision makers are the inside man, or their willing accomplice.  

The best way to break into something is to find someone who can be bought who is already inside. If you can compensate them, they can let you in after hours, without having to actually break in.

Accepting Information for Bad Sources

IT in the vast majority of cases does not look for independent entities to advise them. IT departments do not want their favorite vendors and consulting companies fact-checked. This same pattern applies to both SAP and Oracle, but let us keep it to SAP for the sake of simplicity.

  1. SAP immediately points the customer to several partners.
  2. A partner selection commences and there is a winner.
  3. SAP sets up the partner as the goto trusted advisor. It is like they are assigned a dance partner

Recently someone at a client told me..

“SAP and Deloitte both sat there and lied to them.”

But there is a problem in this interpretation. The clear implication in the statement is that SAP and Deloitte are separate.

They are not.

Deloitte’s SAP practice is a consulting arm of SAP. Deloitte and SAP jointly coordinate against the customer. If SAP is negotiating with the customer and shares information with Deloitte, Deloitte will immediately share that information with SAP, to score brownie points and to allow SAP to gain the upper hand in the negotiation. All of the SAP consulting partners complete to show themselves as more compliant than others to SAP. SAP distributes various goodies (referrals, ramp up programs) to the partners that do the best job kissing up to SAP. And SAP is to never be questioned, only promoted.

And there are no repercussions for lying or being caught lying.

A System Rigged Against Companies and Business Users

This is the problem. SAP and their consulting partners rig information against these customers. Neither of them provides accurate information, and the customer is repeatedly fooled that these are good sources of information.

The extent of mind control is simply bizarre. Customers will catch SAP or Deloitte lying to them…..in fact, I point these lies out to multiple clients, but in the end, they say..

“These are the sources we have selected.”

So they live with the lying.

Outcomes do not matter to them much except for the appearance of outcomes. Resume building and vendor relationships and comfort level are all higher priorities.

Our Exposure

We repeatedly tell companies not to buy applications that they go ahead and buy anyway, in part because IT does not care if the solution is good for the company. They are in our experience buying items that they can place on their resume or that allows them to strengthen their relationship with a vendor.

Employing companies are a big part of this by making the job market so insecure that the employee or executive feels they have to put their interests ahead of the company that they work for.

The Problem of Corruption in IT Matches That in US Politics

  • This video explains the problems with the US political system.
  • With some slight adjustments, it can be used to explain a similar problem in the IT industry.

The Problem With the US Political System

In shorthand, the US political system has been hacked by monied interests who have succeeded in converting a government that was supposed to have a degree to participation to where the participation is facia. The fascia of participation is maintained because, without a facia, the system would lose its legitimacy, which is, of course, a major part of its power.

The video does a superb job of showing that the percentage of the electorate that favors a law being passed has no correlation with whether it is passed. This is because legislation is passed based upon financial power.

The Corollary with IT

The state of IT is very similar, all that is necessary is to move around the primary interest groups, and the video could just as easily be applied to IT.

Voters = Business Users

We need to convert voters to business users. Business users ultimately have to use the software that is purchased but has close to no control over what software is purchased. This is because the decision making has been delegated to a specializes group called IT.

Representatives = IT

The US was never a democracy and the term democracy is not used in either the US Constitution or the Bill of Rights. It is a representative system of government or a republic.

The founders of the US opposed democracy on the grounds that it would lead to the masses being able to be lead by a demagogue to execute policies that were popular, but ultimately bad for the system. The only democratic aspect of the US political system are referendums that have direct voting. But these are rare compared to the decisions that are made through the representative process.

  • A representative is someone who is elected to execute the will of the electorate. That is in theory.
  • Similarly, the business has IT make decisions for technology under the idea that IT has specialized knowledge. In the US political system, the problem is that the representatives are responsive to money rather than to the electorate. A representative system only works if that system cannot be gamed by non-electorate based forces — which is unfortunately exactly what has happened.

Lobbyists = Sales People

Lobbyists are instruments of corruption. In a system that was about the representation of the electorate, lobbyists would not exist. There is already a system for influencing representatives, it is called voting. However, lobbyists and lobbyist money is designed to minimize the influence of voters on their representatives.

They bring the interests of the elite to bear on the representatives, pivoting the representatives away from representing the electorate to representing whoever is paying the lobbyists. Lobbyists don’t care what is true, they push any message in return for money.

In the IT space, lobbyists are salespeople. Salespeople are hired to get customers to buy things that are bad for the company, but good for the people that work in the IT department. Their role is to corrupt the IT decision makers by any means necessary. Salespeople frequently talk about how they are the voice of the customers. However, having worked with them, this is clearly false. Salespeople are expert at highlighting areas that are strong and hiding areas that are weak in applications from customers. Like lobbyists salespeople will laud their relationship with their customers, but these relationships have a specific purpose — to sell software, and the stronger the relationship, the less appropriate the software needs to be to get purchased.

As a lobbyist, it is virtually impossible to keep one’s job without lying, and then lying about lying, and the same is true of sales people. Their job is to get the sale, by any means necessary. Both lobbyists and salespeople see their roles as essential and normally have a blind spot about lying, preferring to adopt the idea that either “everyone is doing it,” or “there is no objective truth.”

However, the end result of their activities is that the entire system is pivoted away from the representatives (IT or political) from representing the interests of either the voters or the business users. Like lobbyists, those salespeople that are most successful in turning IT decision makers against the interests of their companies are paid the most.

What it All Means

If one takes stock of this behavior 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

  • Here we are decades into computing, and IT departments are the impediment because they are not set up to care about outcomes.
  • IT departments have proven extremely easy for sales reps at vendors and consulting companies to manipulate. Sales reps are promoted and compensated based upon their capabilities at manipulation, and never evaluated on the basis of the accuracy of the information they provide. Accurate information is bad for quota attainment.
  • The corruption in the enterprise software space is off the charts. Yet, in the popular media coverage of IT, it may as well not exist.
  • It is not entirely clear why IT decision makers are so unwilling to challenge software vendors and consulting companies even when they are robbing their companies blind. But if they are not held to account by the business, they quickly become captured by outside entities.

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.

The problem with the fact-checking services that we offer is that IT departments are not interested in having the facts checked of the major vendors. The IT departments are “in on the fix,” they are compliant in providing substandard solutions to the business if it feathers their own bed.

This is why the only real market for fact-checking services is not IT. Instead, it is either the business side of companies or the procurement department.

  1. For marketing to procurement, this means communicating that IT will not help them fact check the vendor.
  2. For marketing to the business, this means communicating that without an outside party, many or most IT departments will sell out the interests of the business for their own IT interests. This means that business departments cannot trust IT to get them the best solutions from the market. If business departments can recognize they need their own fact-checkers independent of IT, then they can see the need to fund this type of work.

A final end state of corruption is attained through decades of small incremental degradation of the system. After enough decades pass, eventually, the system becomes so obviously corrupt that it requires reform. This is where both the US political system and IT is currently. Those inside of the system is so used to corruption that they barely question it. Those looking inward toward the system can’t believe how the people on the inside who benefit can’t see how dysfunctional the system has become.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other IT Department Failures

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

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

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.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP as Legacy Content

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.

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 an 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 anyone 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.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP as Legacy Content

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