How to Best Understand SAP’s Negative Innovation

Executive Summary

  • SAP produces negative innovation and focuses far more on marketing innovation than actually producing innovation.
  • Examples of fake or negative innovation are HANA and S/4HANA among many others.

Introduction

Many companies exaggerate the amount of innovation they are involved in. This extends from software vendors to the pharmaceutical companies. SAP is probably one of the greatest exaggerators of the innovation that they are engaged in. And in fact, in this article, evidence will be presented that SAP reduces innovation in the enterprise software market.

SAP’s Focus on Marketing Rather than Innovation

SAP has one of the most deception marketing departments that one could imagine. I have spent a lot of time studying the nuclear arms race, or the Cold War, and from that, I learned of the fantastic propensity of Pentagon and US Defense establishment to tell lies. After also studying SAP for many years, I often draw comparisons between SAP and the Pentagon. It is incredible to me how much SAP lies and misleads customers and how they perpetually get away with it. I have documentation many areas of deception on the part of SAP at Brightwork Research & Analysis as well as at LinkedIn. Much like a major pharmaceutical company, they pose as an innovator while being chiefly a marketing company.

SAP’s Acquisitions

As SAP has lost its development ability (that is they can develop products, but not products that are functional), SAP will have to move to a strategy of acquisition. SAP has had a history of problematic acquisitions, and in fact prefers to build their own products rather than acquire, but as SAP becomes an increasingly monopolistic vendor, meaning their development productivity is severely declining, they are in a position of having to acquire new products as they lose the ability to make new products internally. This is something they have been well-known to prefer not to do in the past. However, the problem is that SAP is not very good at acquiring companies and integrating them into the SAP suite.

A good example of this is the Business Objects acquisition. The very act of engaging in a high number of acquisitions is indicative that the acquiring software vendors are not innovative. IBM, another poser innovator, is also a big fan of acquisitions. As with IBM, after a few years, the SAP acquisition is no longer prominent. Therefore not only can SAP not innovate internally, but they smother the innovation in their acquisitions.

The Business Objects Example

The Business Objects acquisition has been so poorly managed that it has been ridiculed even in the ordinarily compliant press. Many customers are furious with how their BO support has declined since the purchase. Thus SAP is decreasing the reputation of BO in the market. This is one of the reasons I greatly oppose mergers because they cause dislocation and customers usually suffer. It also results in few alternatives and greater monopoly power and fewer places for employees to work.

For anyone who has worked SAP, it is clear that culturally SAP should stay away from mergers because they are unable to incorporate people from different companies without making them feel subordinate to SAP. This is one reason SAP recently lost John Schwarz, who came from BO and why he left so quickly and with virtually no notice. However, the problems with software mergers are not restricted to SAP. Oracle’s acquisitions of Hyperion have not made it a top data warehouse vendor even though it was a top vendor at the time that Oracle purchased them. On the topic of mergers, Colin White, a BI expert, has the following thing to say which I found interesting.

“Another issue when a vendor acquires a product is the level of overlap with functionality in existing offerings. Most vendors are unwilling to phase out existing components in favor of new ones because it disrupts the development organization, upsets customers, and impacts revenue streams. The situation gets worse as more products are acquired; and as a result, offerings become gradually more complex and marketing messages confused.” – Colin White

Acquisitions, in general, have a lengthy, well-studied, and poor reputation. However, acquisitions are even more problematic in the software industry. This is something that any company should be aware of when the product their vendor uses gets purchased. The capability of the acquired product stagnates, product support declines, and many of the brains behind the product tend to leave the company rather than be constantly condescended to by the new owners, and you will get pitched other products from the acquiring company. The primary motivation behind software acquisition is to reduce competition.

How SAP Creates Fake Innovation, Such as S/4HANA and HANA

What SAP is deciding for its customers is what they should be buying, and they have pitched HANA as hard as a product can be pitched. However, SAP is wrong about performance being an issue on SAP projects. This is covered in the article What is the Actual Performance of SAP HANA. SAP has deliberately misled customers on how much HANA is innovative. Oracle 12c has everything that HANA has and is a more useful database. This is covered in the article What is Faster HANA or Oracle 12c?

I have worked in SAP since 1997, and there is not a single time I have seen anything in SAP that is innovative. The opposite is the case.

How SAP Pulls Funding Away from Innovative Applications from Other Vendors to Their Own Lower Quality Innovation

SAP has repeatedly pulled intellectual property out of other software vendors. This is covered in the article Why the SAP xApps Program Needs to Terminated. But secondly, SAP wins on software selections that it should lose. It can do this because companies like Deloitte and IBM do not care about their clients and recommend SAP software not matter its capabilities or what the competition has to offer. The topic of the poor state of SAP applications outside of a single application, which is SAP’s ECC system is covered in this article. How SAP is Now Strip Mining its Customers.

What this does is redirect funding away from software vendors that are producing innovation to SAP, which spends the money on marketing and executive salaries. I can provide one excellent example.

The Horror of That is PP/DS

In the production planning and scheduling space, there is no vendor more innovative than PlanetTogether. PlanetTogether is rated at this Brightwork Research & Analysis link. PlanetTogether is one of the most intuitive and robust applications in supply chain planning, and they have received a perfect score in innovation from us. SAP also makes an application for production planning and scheduling. It is an application that I have personally implemented. It is called PP/DS, and I consider it to be one of the worst applications I have ever tested. PP/DS is rated at this Brightwork Research & Analysis link. PP/DS does not change much from year to year, and it was always a bad application. Its optimizer does not work and cannot be implemented. PP/DS is an utterly derivative application that sets back production planning and scheduling everywhere that it is implemented.

Use Indirect Access to Prevent Companies from Buying Applications they Prefer over SAP’s Applications

SAP has begun to apply indirect access claims to its customers. Indirect access means that any system that is connected to SAP is a potential liability for the customer. When customers show a preference for using far better applications that are innovative, SAP does not respond by making their products innovative, but by either lying to their customers or by applying indirect access claims against them. The very existence of indirect access as enforced by SAP, which differs from the definition of indirect access of every other software vendor, as well as the constant lies on the part of SAP about the abilities of their applications tells you all you need to know about how shockingly derivative SAP is.

Significant Areas of Backwardness and Negative Innovation

SAPGUI

First up is the most obvious, which is right in front of one’s face. That is the SAPGUI. Although we take much of what Hasso Plattner says serious, he was correct when he stated:

“Our UI Sucks!”

However, the problem is that Hasso only admitted this after SAP had released Fiori. SAP will occasionally provide accurate descriptions of its products, but only to create a burning platform to move to SAP’s new product. Now that years after this comment was made and there is no real pathway to Fiori adoption if Hasso would have made this comment. That is if 99%+ of all the users of your applications still use SAPGUI, do you want to admit that it sucks.

The problem is that Fiori never took off and in our estimation, Fiori probably won’t be the future UI of SAP which is covered in the article Why Fiori Will Probably Not Survive. However, I participated in some SAP sales presentations where customers were told not to focus on the SAPGUI because it would all be replaced by Fiori (or Personas — another SAP UI that did not work out).

This means that SAP customers will have their users on a UI that “sucks” for the foreseeable future. Furthermore, as other UIs are increasingly web-based, allowing for broader usage and distribution of the applications, SAP customers are stuck with a non-web based front end.

ABAP and Development Tools

92% of SAP customers have either moderately or highly modified their SAP system. However, they have had to do it with the inefficient and proprietary ABAP language, as well as SAP’s inefficient tools. This means that every SAP IT shop must have specially designated ABAP coders that only work on SAP. ABAP and SAP’s other development tools are one reason why SAP’s TCO is so much higher than other vendors. This topic is covered in Why Customers Followed SAP’s Advice on ABAP and Tools.

Data Model and Data Access

If you use an ERD tool to diagram SAP’s data model, you often end up with a highly confusing set of tables.

Here is part of the data model from within APO. One has to wonder who was doing the data modeling for SAP as its tables often lack a logical reason for their schema. That is far more straightforward schemas should have been created. 

To access that data, it is necessary to use the transactions SE16 or SE16N. SE16N is more feature rich, but it does not exist for many SAP products, SAP APO being one example.

SAP’s products are the most difficult to get data out of and back into because SAP does not allow a direct SQL onto their tables. This is ostensibly done for security, but no other software vendor imposes this overhead on their customers. To integrate with SAP one must connect to function modules which are another layer of complexity, or pass IDOCs, which are hierarchical mainframe era text files that are not self-describing as with XML. It is positively backward, and strange for a company that claims to be so innovative.

What is the SAP Mirage?

The SAP mirage is a combination of factors that move the discussion away from what SAP has in a debate about a fantasy of what SAP has. Examples of techniques that support the creation of this mirage are:

  • Selling Off of SAP Roadmaps: SAP prefers to spend as much time as possible discussing the future of their products versus the present. When we supported SAP sales engagements in a technical capacity, customers were told by the salesperson to ignore the SAP UI (called the SAPGUI) because a new user interface was coming that was going to “blow the customer away.” Three years after this promise, the new user interface the salesperson was talking about (Personas) is dead, and the one that followed, Fiori, is on life support (and we predict will eventually die as we cover in the article Understanding Why Fiori Won’t Be Able to Survive).
  • Selling Exaggerated Products: This topic gets virtually no IT media coverage, which is a story in its own right. However, SAP continually exaggerates what its products can do. SAP places functionality into its products that often can’t be practically accessed or once accessed can’t be maintained. SAP has the widest discrepancy we have ever recorded between what it says its products can do versus what they can do in actual practice.
  • Co-option: SAP is a master at co-opting concepts and trends that it not only has nothing to do with but that its business model is opposed to. Cloud, SOA, “modular architecture,” the list goes on and on. Whatever is popular at the time, SAP “has always been about that” or has a partnership with some vendor that does precisely that, or is working on something that will meet that big need. However SAP keeps to the strategy that has worked for it, and this does not mean doing anything to make its products less expensive to implement, easier to use with other applications, etc..

In our view, no one is more skilled at selling a future with less supporting information than SAP. We have covered in other articles how S/4 HANA is not even released yet, and how its implementation numbers are greatly exaggerated as explained in the article How SAP Controls Perceptions with Customer Numbers, and how it has been found to be roughly 95% identical to its predecessor (ECC).

SAP’s Influence Over IT Media

No other vendor is as effective at getting a vast number of influencers, IT media entities or SAP consulting companies to repeat SAP’s messaging. For example, people like Hasso Plattner and Bill McDermott speak as if S/4 is already providing value to customers, and this has been little questioned in the IT media. Our Study into S/4HANA Implementations indicates that this is highly unlikely.

As a vendor, you know your application, and it’s valued and how to position it. But….are you prepared to compete not with SAP’s actual application something that does not and will never exist? 

  • Whatever you have, SAP is working on something that they will be released soon that is “better.”
  • If SAP has no experience in that application category, it makes no difference. They will partner with a vendor that is, promise them access to their clients, and slowly reverse engineer their products. With their market power, the only reason SAP is not successful in more areas is their development organization is inefficient.

For instance, according to Hasso Plattner, SAP already has the BEST USER INTERFACE in enterprise software (although it is barely used by customers) And the future SAP application will be integrated to SAP ERP (of course).

For SAP Bad Applications, Hope Springs Eternal

Old applications, like CRM, PLM, EWM, SPP, Netweaver that did not work out don’t count as misses in the minds of your potential customers. The promise of the future continually beacons to them.

SAP is, after all, working on next level stuff better in every way in every application area than any other vendor on earth.

  • It’s all web (or on-premises)!
  • They are re-imagining business processes!
  • It’s all completely integrated!
  • Steve Wozniak is at SAPPHIRE this year!

Vendors that compete with SAP are not competing against what SAP has to sell. If it were that straightforward, SAP would lose a lot of its market share.

Instead, vendors must compete with a mirage that is created by SAP marketing. As alluded to earlier, many, perhaps most of the announcements made by SAP never come to pass.

The Enterprise Software Procurement Environment

One would assume that the enterprise software market is filled with informed decision makers, highly focused on doing research and selecting the best products for their company. That assumption is wrong. It goes without saying that corporate decision-makers are concerned with their careers and look to make selections which will place them in a favorable light. Companies are often not looking for innovative solutions that can improve the business, but decisions which are “safe.” (even if the results are middling) The major enterprise software companies know that most of their clients have weak critical thinking skills and that they have captured the IT department (different large vendors “own” different company’s IT departments. Some companies are “SAP shops,” or “Oracle shops”). Many corporate decision-makers are not looking for the best product; they are looking instead for a product that can provide them with a plausible excuse if the implementations go poorly.

Companies are merely, in most cases, unable to make good decisions concerning enterprise software selection. A major reason is the large vendors are just so large and so corrupt. Simply having market power is not enough, you have to be willing to abuse the position by lying and using underhanded tactics, which all the large software vendors are, and can tilt the playing field in their direction.

Mind Control Over IT Departments

The IT department, with their series of political objectives, is one of the main entities in companies promoting the use of dated approaches provided by the largest vendors. SAP, Oracle, and IBM 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 actual employer. 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). This is described in more detail in this article.

Partners in Crime

The large companies have powerful relationships with the major consulting companies which control much of the decision-making in the enterprise software space. The major consulting companies don’t much care about how good the application is but are looking out for their interests, which means pitching the software from the major vendors which they have resources trained up on that they can bill.

Lack of Motivation for Innovation

Large vendors do not have to innovate because they can either develop a partnership with a smaller vendor, and partially reverse engineer the product, or they can simply buy out smaller innovative vendors (eventually killing the innovation in the acquisition). Since the majority of companies use software from the major vendors, this means that most companies use backward methods in software. This has implications for the efficiency of the overall economy. Large vendors, consulting companies and internal IT departments, in essence, conspire against the business, barring them from accessing the best functionality.

How SAP Consultancies Keep SaaS Cloud Innovation Out of Their Clients

In the article the Fallacy of the Benefits of an Integrated Suite. We covered how consulting companies push their clients away from innovative software if the software is not from a major branded vendor that they have resources ready to bill.

“Consulting companies like to create “uni-crop” software environments which allow them to have large numbers of consultants in a relatively smaller number of applications. Consulting companies overstate their software coverage and resource specialization to their clients on a routine basis. They will often hire independent consultants off of the market (as the client could have done) and then present the independent consultant as if they are a full-time employee, and that represent furthermore, the consulting company was somehow responsible for developing their skills. The consulting firms demand a significant margin on the resources even if they just met the resource a week ago.”

Disguising Simplistic Platitudes that are False as Advice

The largest entities in the space state things and they become the accepted truth, but being big means (appears to mean at the very least) that you can get away without having to provide evidence. You can merely assert. And assert in the face of all the contradictory evidence.

I have been on so many projects where none of these assertions are questioned. The assertions come at decision-makers at high speed.

  1. It is much like “ABC because of an unproven assertion.
  2. XYZ because of an unproven assertion.”

The point is not to have your assertions questioned so you can move the customer down the rat maze that is in the desired routing.

Companies like Accenture and Deloitte perform no research and wouldn’t know what to do with it if they did because they don’t make their decisions by what is true. They make their decisions based on what they find profit maximizing, and then craft the simplistic platitude to be used by backward engineering from the outcomes that are profit maximizing to them.

And these are the companies we have advising other businesses on enterprise decision making.

Keeping Innovation and Threats Out

Additionally, a critical function of major consulting companies is to keep innovation and better applications out of their clients. Their continual quest is to keep smaller point solution providers out of “their” accounts. A small vendor or non-ERP suite vendor may produce a fantastic value proposition and fit with requirements, but the entire time of the software selection which the consulting company is “advising” the client, the major consulting company is telling their client,

“but the vendor is not one of the major brands and “it won’t be integrated like a single branded application.”

The translation is (gee, we won’t be able to staff that project, so let’s block that vendor from getting into our account!)

Beyond the loss of the specific application consulting business, non-major branded vendors pose an existential threat to the consulting company’s ability to extract from the account. What if the vendor implements successfully and makes our high TCO and low utilized applications implemented by the consulting company look bad!

It could lead to a realization for their clients, and they could lose control of our low value-add revenue stream.

Fighting Changes Towards Innovation and SaaS

SaaS and cloud advantages existed for at least 15 years at this point, but true SaaS applications are still not that common. Vendors like SAP have cloudwashed their solutions — so it seems like there is more cloud than there is. Certainly, AWS has seen great growth. But SaaS was supposed to be the way to break the stranglehold of the on-premises suite vendors and their partners (the major consulting companies). This is taking a very long time to happen.

To make it work, they have to be careful never to quantify TCO or project success. The lack of quantification pushes the advantage to the highest cost and least efficient providers.

So here is the big challenge. Bringing this message across in a way that is tolerable to those people that have only ever been exposed to the evidence-free assumptions of the biggest vendors and of the consulting companies.

Conclusion

Far from being innovative, SAP is not only not innovative or an innovation poseur, but it also has many components that are typically more backward that competing software vendors. We call this being “negatively innovative.” Being negatively innovative is when the vendor holds back the potential of their customers with their software. This is when a vendor cannot match the capabilities of other vendors that have been achieved for decades (for instance, being able to use SQL to address the vendor’s database).

In our view SAP allowed these backward components to persist because of two primary reasons:

  1. Revenue Maximizing: They were more interested in creating new products the could charge for then going back and modernizing their backward components.
  2. Account Control and Monopolistic Competition: In other cases, SAP kept these components because they improved the account control over their customers. That is SAP in fact preferred that its applications were difficult to integrate to, allowing it to promote the idea that customers were safest if they merely exclusively purchased SAP applications to connect back to the SAP ERP system.

Large software companies have overwhelming advantages, which acts to overcome what is in many cases a mediocre solution. In some cases, the solution is just mediocre, but it is often worse than this. SAP has been selling some products for years that not finished products, continue to push out far more capable and mature solutions as companies attempt to move towards a single vendor monoculture.

As with other industries, the bulk of the innovation comes from smaller companies. The most that large companies are involved in innovation is typically limited to discussing innovation in advertisements (observe the false alternative fuel “innovation” occurring at the major petroleum companies).

Does anyone believe that the large oligopolistic oil companies are investing in alternative fuels?

Why would they?

They sell gasoline. Also, while the woman in the ad looks very happy, she should know that Hydrogen is not an alternative energy source, it’s an energy storage device. However, this is irrelevant to Shell (who certainly knows all this), Shell is selling the illusion of innovation. This false innovation is the same strategy employed by the large monopoly enterprise software vendors.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: What to Do About S/4HANA

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.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

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 Innovation Content

References

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