- The upgradeability of SAP products is declining and this fact is being hidden from SAP customers by both SAP and SAP consulting companies.
- In this article we will answer why this is happening.
- 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 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 a bit different than 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
There are some very interesting and important changes that have been afoot in the SAP space. The SAP media apparatus has done an “excellent” job of communicating the items that cause this 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 normally the case, none of the complexity of these changes is communicated.
Quite the opposite in fact.
There has been a concerted effort by the SAP media system to present all the changes as being fast and better than anything they replaced — both in terms of the functionality, speed or other characteristics of the application and databases, but also the implementation speed, implementation simplicity.
The Problem with Continual Migrations and Reduced Upgradability of SAP
Data points coming in from a number of locations point to the following characteristics of the new SAP products and their impact on IT organizations and SAP projects:
- SAP Project Proliferation
- Changing Functional Landscape
- Custom Code Remediation
- 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), which is a row-oriented database and SAP IQ which is another column-oriented database.
- An Interpendent Row Oriented Database: SAP pitches this is a value bundle, but in fact, ASE is necessary for things like PI/PO integration.
- HANA Database Archival: To bring the price down of HANA 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.
Actually, 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 essentially bypass the question. In the area of adapters and custom code that breaks, SAP sidesteps the question, asking customers if they actually need the custom code that 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 accept 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, as Simple Finance was merely kept as a “sidecar” or demo environment. Customers could have simply waited rather 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 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 the design of these products mean the customers that bought these products will be left out in the cold from the perspective of upgrades. These IT decision-makers, many of them more focused on their own 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. That is SAP has tried to soft peddle this large amount of work by telling companies to drop their custom code or zcode, or drop much of it, and use “standard SAP,” but that is not feasible for most companies.
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 facile 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 somehow speed this process, 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.
Even still, it important 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 actually 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. Obviously this is because CCA is one part marketing gimmick designed to make the customer think that migration will be easier that 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 actually fit together. This is combined with the fact that SAP includes much of its messaging around 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 really 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 actually been simplified. Yet in the little more than a year since we wrote this article, SAP’s complexity has done nothing but go up.
In fact, 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 is 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 on the basis of 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 around the world virtually any story it needs to (performance is better…., compatibility requires…, a better long-term vision is…) in order 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 our conclusion is 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 problems with this is that HANA has a higher TCO and a higher level of complexity and overhead (which of course directly relates to TCO) than any of the other database alternatives.
SAP consulting companies and SAP consultants will benefit in the short term from this increasing chaos in SAP products. I expect comments SAP consultants on this article that proposes 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 to reach out to me privately and say they have some similar questions as to what is happening with SAP HANA and S/4HANA, but 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 important that SAP consulting companies not mention how much more unsustainable SAP’s new products have become. It’s bad 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 that are 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 really only looking out for the short term), SAP’s showcase products are truly money pits.
As readers know Brightwork maintains the really only online TCO calculators that exist. The lack of compatibility between different versions of these new products is going to 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 sort of the final 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 the purchase helps some political goal. Either it supports the career plans for the executive, 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 simply too long to put into LinkedIn.
“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 blame for the Under Armour implemenation problems on business continuity management, which is the process side of the implementation rather than the software side of the implementation.
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 try to conflate my coverage with something you might find in celebrity gossip magazine.
But I think your comment may be related to my pointing out that Bill McDermott sits on the board of directors at UA. Is that lurid? Well, it is unethical and profoundly stupid for UA to have allowed. 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 shocking 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 actually 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 everytime he speaks that I wonder if you really 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?
So let me address the question of 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. In fact, 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 good for your business. Most SAP consultants operate as cheerleaders for SAP. It would be very difficult for you to work as an SAP consultant if you were to 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. Obviously, information that is true about SAP helps make better decisions about it. But it is not value add for you. It’s not value add for the roughly 248,000 consultants that work in the top 18 consulting companies that give a one-sided and profit-maximizing perspective of SAP. 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 to deceive their customers. This would allow SAP to get companies to invest in S/4HANA, without knowing about future incompatibilities. That is for SAP to get revenues from S/4HANA in the short term, for consulting firms to get consulting revenues for performing a (mostly) pointless implementation of S/4HANA and to 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 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 terms that have the deliberate purpose to 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 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 than there is no reason to go around looking for other reasons the project ran into issues.
Don’t Blame SAP?
In your entire response to do not address whether S/4HANA is an application that is 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 is 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 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 is really horrendously unethical behavior on the part of SAP.
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 that they actively discriminate against other vendors, repeat lies from SAP that they know to be untrue? Under those circumstances, which happen all be true, one would have to be a bit blind, or perhaps financially biased, not to blame consulting companies.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
Enterprise Software Risk Book
Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model
Getting to the Detail of TCO
One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.
The Mechanics of TCO
Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
- Understand why you need to look at TCO and not just ROI when making your purchasing decision.
- Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
- Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
- Learn why ERP systems are not a significant investment, based on their TCO.
- Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
- Appreciate the importance and cost-effectiveness of a TCO audit.
- Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
- Chapter 1: Introduction
- Chapter 2: The Basics of TCO
- Chapter 3: The State of Enterprise TCO
- Chapter 4: ERP: The Multi-Billion Dollar TCO Analysis Failure
- Chapter 5: The TCO Method Used by Software Decisions
- Chapter 6: Using TCO for Better Decision Making
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.