How to Understand The Declining Upgradability of SAP Products

ByPrimary Researcher

 Executive Summary

  • The upgradeability of SAP products is declining, and this fact is being hidden from SAP customers by both SAP and SAP consulting companies.
  • We will answer why this is happening.

Introduction

  • In this article, we will provide a non-SAP biased perspective on these changes.
  • This information is distinct from anything provided by the SAP media system and compliant surrogates like Deloitte and Accenture, who prefer uninformed customers. Yet, we are trying to get to the actual truth of what these new items mean. As far as we can tell, we are one of the only ones actually trying to do this.
  • We are an independent research entity.
  • We are not attempting to sell SAP software or SAP consulting services.
  • We are not controlled by SAP through a partnership agreement.
  • Therefore, the information we provided is quite different from that which is generally available, and topics have been raised in this article that is not generally available elsewhere.

Rising Issues of Reality of SAP Projects

Some interesting and important changes have been afoot in the SAP space. The SAP media apparatus has done an “excellent” job of communicating the items that cause these changes (that is, jumping on the S/4HANA and HANA “bandwagon” and promoting their purchase as well as the hiring of consulting services). Yet, as is usually the case, none of the complexity of these changes is communicated.

Quite the opposite, in fact.

The SAP media system has made a concerted effort to present all the changes as fast and better than anything they replaced — both functionality, speed, or other characteristics of the application and databases, but also the implementation speed implementation simplicity.

The Expense of Upgrades

In SAP, upgrades are major expense items for a company. Rimini Street in the following graphic explains this.

This cost to upgrade is nearly always dramatically underestimated by IT departments. This is because the costs are hidden in the ERP budget.

The Cost and Effort of Upgrades

Cost is why SAP ERP customers upgrade far less than is generally understood and wait far longer to upgrade. Another reason is the overall disruption to IT and sometimes the business. The book SAP Nation 2.0 provides the following explanation for the lag in adopting the latest version.

“Not all customers adopt every new SAP version. Even the most adopted EHP 4 research a peak adoption rate of approximately 35 percent, and three years after becoming generally available (GA). The time it takes a new version to reach peak adoption is approximately 18-24 months after GA. In addition, we can see that EHP 7 (the latest version, and the required version to support Business Suite on HANA as well as Fiori), has a steeper adoption rate and has the potential to become the most adopted version. Unlike Android or mobile applications, the expected upswing in ERP adoption is measured in years, not months.”

The Problem with Continual Migrations and Reduced Upgradability of SAP

Data points coming in from several locations point to the following characteristics of the new SAP products and their impact on IT organizations and SAP projects:

  1. SAP Project Proliferation
  2. Changing Functional Landscape
  3. Custom Code Remediation
  4. Cloud Confusion

SAP Product Proliferation

Products like S/4HANA and HANA have dramatically increased the associative products required by SAP to run their software.

In our study of the TCO of HANA, we observed that SAP bundles HANA with other database products, notably SAP ASE (formerly Sybase ASE), a row-oriented database, and SAP IQ, which is another column-oriented database.

  • An Independent Row Oriented Database: SAP pitches this is a value bundle, but ASE is necessary for PI/PO integration.
  • HANA Database Archival: To bring HANA’s price down to a reasonable level, extensive archival is required. For this, SAP recommends SAP IQ. And this does not include the components below HANA or on which HANA depends on its normal operating functions.

Changing Functional Landscape

With S/4HANA, those companies that deployed Simple Finance v1 (1503, 1608) now find they are on a different code line to Simple Finance v2 and/or S/4 HANA Enterprise Management (1511 > 1610 > 1709).

It is the case that S/4HANA could not and cannot be upgraded from ECC because of the changes in code and table structures. The story or concept promoted by SAP was that incompatibility was a one-shot deal.

Let us step back for a moment.

  • The Story on Upgrading S/4HANA from ECC: This was the story or concept presented directly to customers in one-on-one sessions. In the public sphere, SAP never discussed whether S/4HANA was “un-upgradeable” from ECC. They attempt to bypass the question essentially. In the area of adapters and custom code that breaks, SAP sidesteps the issue, asking customers if they need the custom code they created in the first place…which we will discuss in just one moment. But the upshot is that SAP talks up how S/4HANA is so different from ECC for the market but then downplays the incompatibility that this brings up.
  • Accepting the Extra Time and Expense: These customers had to take the extra time and expense of a new S/4HANA implementation (inaccurately called a “re-implementation,” but inaccurate because no one re-implemented — instead, they implemented S/4HANA side by side their already implemented ECC system).

But now, there are compatibility issues even between S/4HANA versions, not only between ECC and S/4HANA.

Customers who purchased and implemented S/4HANA “v1” were not aware of this at the time of that decision.

But again, Simple Finance was merely kept as a “sidecar” or demo environment. Customers could have waited rather than investing in V1. IT departments that made these decisions don’t want the rest of the company to know, so it is just not discussed.

This leads right to the next point.

With all of the increasing incompatibilities of SAP products between versions, a natural question that arises is…

What is behind that next door? 

Products like HANA and S/4HANA were not well planned. High-level executives at SAP, you know those men with “the real vision” massively overpromised when these products would be ready. And when they arrived, they were not innovative.

Because of the unrealistic timelines, they were introduced too early, which lead to design decisions being made before development was ready to make them.

A Future of Multiple Migrations

As an example, companies that implemented the first versions of these products now face multiple migrations. That is a 3 Step Migration from Business Suite + AnyDb to Simple Finance v1 + HANA 1.0 to S/4 HANA + Simple Finance v2 over HANA 2.0.

Continual changes to the core of these products’ design mean the customers who bought these products will be left out in the cold from upgrades’ perspective. These IT decision-makers, many of them more focused on their careers than the companies they are working for, have put massive liabilities on their current employers. This will become more obvious over time.

Custom Code Remediation

It is understood, although not broadly communicated, that with S/4HANA, all of the custom code or customer-specific code (called zcode) must be rewritten or remediated. SAP tended to obscure this fact by talking about dropping custom code entirely. SAP has tried to soft-peddle this massive amount of work by telling companies to cut their custom code or zcode, drop much of it, and use “standard SAP,” but that is not feasible for most companies. We cover this topic in the article SAP’s Advice on S/4HANA Code Remediation.

These discussions already happened during the first implementation of the ERP system years back, and the custom code was written because it was deemed necessary. SAP has presented the simple idea that “that was then, this is now,” but it is not as simple as SAP would have companies believe.

Roughly 92% of customers that use ECC have either moderate or extreme use of custom code.

And fortunately, observations from the field show that remediating code takes far longer than anticipated. Tools that were supposed to speed this process somehow, one notable example being the Custom Code Analyzer, do not work particularly well. That is, it only catches some of the development objects that require adjustment.

It is essential to remember that all the CCA will do for a customer is tell them where some of the development objects must be changed. It does nothing to make the change. Therefore it is necessary not to think of the CCA doing any “actual listing.” But unfortunately, this is how SAP often presents the CCA. This is because CCA is one part marketing gimmick designed to make the customer think that migration will be easier than it will be.

SAP’s Cloud Chaos

SAP has a highly confusing (both actual and explanation) of its cloud solutions. SAP continually layers on more cloud messaging but without clarifying how things fit together. This is combined with the fact that SAP includes much of its messaging around the cloud, not for customer consumption, but to communicate to Wall Street that they are “rapidly moving to the cloud.” Wall Street assigns a higher value to software vendors that are more rather than less cloud.

In the article SAP’s Cloud Chaos, we observed that SAP’s cloud offering (outside of the acquired products like Ariba and SuccessFactors that have always been cloud) was highly confusing. And every year that passes, it seems to get even more confusing.

  • Mapping various functions between on-premise S/4 HANA and/or SAP Cloud functionality (IBP, SuccessFactors, Ariba, APO/SCM, ECC, SRM, BW, HR/Payroll, Finance FI/CO > Simple Finance) is extremely complex.
  • It means even more consulting expenditures than when the cloud was not in the mix.

Run Simple or Run Increasingly Complex?

Several years ago, SAP introduced a marketing program called Run Simple. At the time, we wrote an article titled How Real is SAP’s Run Simple, where we called into question how anything had been simplified. Yet, in the little more than a year since we wrote this article, SAP’s complexity has done nothing but go up.

SAP’s catch-phrase would more accurately be “Run Un-Upgradable.”

SAP is literally piling on complexity into its accounts, significantly increasing the TCO of its software. For customers as well as vendors that compete with SAP, this much is clear. SAP’s expense and complexity are higher than ever before. Yet because SAP does not work in a competitive market, it can justify these changes and higher expenditures to its customers based on its previous investment into SAP. For all of its talk of being open, SAP wants more of the IT expenditure, and being open is not the way to get there. With HANA’s introduction, it laid claim to the database layer. If one had to characterize SAP’s position, it would be that all databases that run SAP applications should be removed, and a company should use 100% HANA. And SAP is telling customers worldwide virtually any story it needs to (performance is better…., compatibility requires…,  a better long-term vision is…) to move them to HANA. We have evaluated all of SAP’s claims in this area in great detail (and explained in many previous articles), and we conclude that none of them are true.

In addition to the functionality/performance/platform claims not being true, the problem with this, or should we say, one of the many issues with this, is that HANA has a higher TCO. It also has a higher level of complexity and overhead (which, of course, directly relates to TCO) than any of the other database alternatives.

Go to top

Conclusion

SAP consulting companies and SAP consultants will benefit in the short term from this increasing chaos in SAP products. I expect comments from SAP consultants on this article that propose that I need to understand that this is all extremely competent on the part of SAP and that it is all worth it for SAP’s “innovation.” Interestingly, SAP consultants reach out to me privately and say they have similar questions about what is happening with SAP HANA and S/4HANA. Still, they also say they would never make anything but a positive public comment about SAP. They have to either say nothing or make a supportive comment about SAP as SAP or someone they know might be watching.

However, it is vital that SAP consulting companies not mention how much more unsustainable SAP’s new products have become. It isn’t good for business. So the SAP consulting companies will do what they can to normalize the lack of upgradability of SAP’s new products. Readers can check. Are the issues brought out in this article published on any SAP consulting company’s website, or instead, do these websites seem more about selling customers on the new SAP products?

The problem is in the medium to longer-term as there is no way around that SAP is becoming less sustainable. And SAP was already the highest overhead set of solutions that were available in the market. Now through massive errors in product management (driven by marketing and stock optioned executives who are only looking out for the short term), SAP’s showcase products are indeed money pits.

As readers know, Brightwork maintains the only online TCO calculators that exist. The lack of compatibility between different versions of these new products will push SAP’s TCO to new heights. We have estimated the TCO of HANA (not yet for S/4HANA), but as new information keeps coming in from projects globally, it means these estimates will need to get revised upwards. The story is becoming so problematic that we have already seen strong efforts within IT companies to hide these investments from the business.

What we have in effect is the end state of inaneness in many SAP-centric IT organizations. This is where products are purchased not because they work or add value to the business but because they help some political goal. Either it supports the executive’s career plans, is in response to some SAP indirect access claim, etc.

The IT media loves covering sexy new concepts like SaaS and how this or that new product “transforms” some business process. However, this reality of corruption and bad decision-making is virtually impossible to find in IT media.

And why would you cover it? No one will pay a media entity to cover this story.

Comments from LinkedIn

This section includes questions that came from LinkedIn but which were too long to put into LinkedIn.

Comments 1

“I read your UA (article) and have internal view as well as it was a manifest BCM (Business Continuity Management) failure

Your tabloid approach adds no value

We see the same problems with digital transformation as we did 30 years ago

Don’t blame SAP blame and on the whole don’t blame the Consulting industry blame the customer knows better culture within many organizations which is a manifest BCM issue which has to be addressed at the beginning of a program.”

For those unfamiliar with BCM, this comment places the Under Armour implementation problems on business continuity management, which is the implementation’s process side rather than the implementation’s software side.

Shaun’s Answer

Is the Coverage Sensational, Lurid, or Vulgar?

I looked up the definition of tabloid before I responded here.

The definition is thus…

“Covering a story in a sensational in a lurid or vulgar way.”

It is challenging to see how my analysis falls into this category. This statement seems to conflate my coverage with something you might find in a celebrity gossip magazine.

But I think your comment may be related to my pointing out that Bill McDermott sits on the UA board of directors. Is that lurid? Well, it is unethical and profoundly stupid for UA to have allowed it. But I don’t know how else to report this. Is Bill McDermott not on the UA board of directors? Why is Brightwork the only entity that seems to have published this fact?

These appear to be facts you don’t want people to know rather than the coverage I am offering being itself sensationalized. I agree the facts are sensational, but I am not doing anything, in particular, to “Gussie them up.” SAP is lying to the analyst community about how many customers are live on S/4HANA. Our research shows that as opposed to SAP’s claim of 1000 customers being live on S/4HANA, our research in the Study into S/4HANA Implementations indicates that almost no customers are live on S/4HANA (that is, using it in a production sense).

Again, the conclusion is rather shocking or sensational, but what are we supposed to do, change the story, so it is less surprising even though all the evidence points in that direction? Altering stories to be less accurate so they fit with the prevailing narrative (which is formed by paid placements by SAP into Forbes, Fortune, and by Deloitte and Accenture releasing information that places SAP in a positive light for commercial reasons) would undermine the research.

Finally, the information released by SAP is quite sensational. Hasso Platter claims to have invented a database with zero latency. SAP claims to have more database capability than any other vendor and that no other database vendor can keep up with their “innovation.” Bill McDermott makes such outlandish claims virtually every time he speaks that I wonder if you have all that much of a concern about sensationalized commentary. Or if you like sensational commentary when it helps your consulting business versus when it hurts that consulting business.

My Approach Adds No Value?

Let me address whether the approach (whatever you may define it) adds no value.

I looked at your profile. You offer SAP advice. If I am not mistaken, you primarily promote SAP. For example, you commented about customers benefiting from SAP innovation if they stay the course. I see this as a statement that is not supported by the evidence of SAP projects. SAP is not an innovative software vendor. They claim a great deal of innovation that they had nothing to do with. My research demonstrated that SAP and Hasso Platter made up the story about Hasso inventing HANA. You can read this article in Did Hasso and PhDs Actually Invent HANA?

But I think you likely make the innovation claim about SAP because it is suitable for your business. Most SAP consultants operate as cheerleaders for SAP. It would be tough for you to work as an SAP consultant if you publish many of the negative things that I am sure you know. You might tell me a few things in private, but most SAP consultants I know will never actually publish anything non-promotional about SAP. It is not profit-maximizing to do so.

Now, this takes us back to the question of “value add.” This article explained what is discovered incompatibilities in HANA and S/4HANA. The HANA incompatibilities can be found in a published form (although they are not promoted), but the S/4HANA incompatibilities are being hidden by SAP. That is, you find out, but only on one on one sessions. This information would be quite valuable to a company trying to make decisions on S/4HANA. Information that is true about SAP helps make better decisions about it. But it is not a value add for you. It’s not a value add for the roughly 248,000 consultants who work in the top 18 consulting companies that give a one-sided and profit-maximizing SAP perspective.

Similarly, you are a consultant and promoter of SAP and very much value your relationships with SAP. The information is also not value add to SAP as it restricts their ability to control their accounts and deceive their customers. This would allow SAP to get companies to invest in S/4HANA without knowing about future incompatibilities. For SAP to get revenues from S/4HANA in the short term, consulting firms can get consulting revenues for performing a (mostly) pointless implementation of S/4HANA and lock the customer into repetitive cycles of implementation.

So when we discuss value add, I know that information does not add value to you. I assume you would prefer your customers do not to read it. But that does not mean it does not add value for other readers. That is an important distinction. That being the value to you versus the value to others who can benefit from the information.

This article is about the decreasing upgradeability of SAP’s new products.

Same Problems “Old” with Digital Transformation?

As an FYI, I consider the term digital transformation to be a term of propaganda. I am concerned when we use words that deliberately deceive the listener as to what is being discussed. Please see the article on LinkedIn, The Problem with Digital Transformation and Modern IT Projects; I would look forward to your comments.

But getting to your comment. I think it is about the article on UA’s problems with S/4HANA, which can be found at The Real Reasons for Under Armour’s S/4HANA Problems.

So this is my primary issue with SAP consultants stating that UA’s problems are due to implementation. That may be reasonable to observe if S/4HANA were a mature product. However, it isn’t, and SAP has misled companies as to the readiness of S/4HANA to be implemented. Most of the S/4HANA implementations globally are fake go-lives. They are run as offline systems.

Therefore, if we have a textbook case of an application that should not have been sold or implemented and was released too early, then there is no reason to go around looking for other purposes the project ran into issues.

Don’t Blame SAP?

In your entire response, do not address whether S/4HANA is an application ready to be installed. It almost seems like you do not have an interest in discussing S/4HANA’s maturity. I know quite well what S/4HANA’s maturity is as I have spent a great deal of time researching it, and unlike you, I am not concerned about maintaining a relationship with SAP. That is, I can write about the actual state of S/4HANA while you cannot. And S/4HANA is still not ready to be implemented.

Therefore your request that a company that knowingly deceives its customers about the state of its products and that gets companies to implement products that are not ready to be deployed should not be blamed. Even when those projects go south and waste the resources of the company that implemented them?

That seems like an enormous request. It looks like an unethical request. You are normalizing what horrendously wrong behavior on the part of SAP is.

Don’t Blame the SAP Consulting Industry?

In the last part of your comment, you state that I should not blame the (SAP) consulting industry. However, what if I have evidence that the SAP consulting industry mindlessly repeats what SAP says and that they do so for money? See the article on their media and private conformance with the SAP Run Simple campaign, which you can read about in Is SAP’s Run Simple Campaign Real?

What if I have evidence that the SAP consulting companies often pretend to offer independent advice on SAP but act as sales arms for SAP and actively discriminate against other vendors? Repeat lies from SAP that they know to be untrue? Under those circumstances, which all happen to be true, one would have to be a bit blind or financially biased, not blame consulting companies.