- SAP’s has made exaggerated claims regarding S/4HANA’s readiness.
- SAP continually pivots away from the topic of the completeness of each module.
- SAP has misnamed a listing of changes to S/4HANA from ECC as a “Simplification List” that is anything but simple.
Introduction: How SAP Games S/4HANA Readiness
S/4HANA was released far before it was ready to be implemented, and SAP has been exaggerating its implementability since its introduction. You will learn the reality around the readiness of S/4HANA and how this connects with the Simplification List.
What is S/4HANA?
S/4HANA is the first major upgrade to what was R/3.
- ..aka ECC (Enterprise Core Component)
- ..aka Business All in One
- aka All in One…
SAP’s Position on S/4 HANA’s Readiness
One thing that will undermine SAP Run Simple is the readiness of S/4 HANA. Applications that are incomplete are not at all simple. Just the opposite.
While researching this topic, I found the following quotation from SAP. This article quote I found is quite amazing. See it below:
“If you look at the S/4HANA system that we released in November of last year that we are calling 1511, we can say that this is already a complete ERP system,” said Uwe Grigoleit, SAP global head of business development for Business Suite on HANA and HANA applications.”
Errrrr…..you could release a complete ERP system without much of the functionality working. That seems to be the line Uwe is walking here. I mean you can release anything, and it is still that thing. A motorcycle with no pistons is still a motorcycle. And you can release it that way. However, when a motorcycle is released that way, it is obvious. With software, it takes much more analysis to verify if the application is ready.
Pivoting From the Completeness of Each Module
Let us go on to see more from Uwe.
“Why can we say this? If we are looking at pure modules we are shipping already, S/4HANA spans across financials, material management, inventory management, procurement, distribution, product and planning,” he explained. “It’s going across the vast majority of the ERP system already.”
- This gets away entirely from the question of the completeness of each of these modules.
- What Uwe does not state is that 1511 is not a completed ERP suite in that most of the functionality is incomplete. Some of the old functionality works, but it’s just a big mixed bag.
- S/4 HANA has multiple modules (recently renamed) that are called things like Supply Chain, Sales, Research and Development and Manufacturing, etc.. There is no mention of these names even in SAP’s marketing literature as introduced applications. Why? Why the strange four digit release numbers associated with each version (either on-premises or cloud)?
1511 is a beta release that has some components of functionality changed while many others are not. 1511 comes with a lengthy document called the “S/4HANA Simplification List.”
Is This a Simplification List?
This is a document that describes all the changes to ECC. The term simplification is a euphemism.
- Many of the changes are not at all simplifications. Why they would be listed than in the S/4HANA Simplification List is not clear.
- The S/4HANA Simplification List lists areas that have been removed from ECC as “simplifications.” What if you as a company rely on this functionality? Is the S/3 Simplification List making things more simple or more complex?
- Even if we leave out the topic of which areas of functionality are ready, we still face a problem. Unless you are a Greenfield customer that the company relied upon are not part of S/4 HANA. One would need to extensively read the lengthy S/4HANA Simplification List, along with all the associated SAP notes that explain what things (fields, transactions, etc..) have been changed.
- What is the real purpose of calling the list of changes the S/4HANA Simplification list? By calling it someone so misleading is this a way of trying to convince customers that changes are always simplifications?
A Lot of Information to Digest in the Simplification List
I am still digesting the S/4HANA Simplification List myself. Understanding all the implications is a ton of work. So much so that SAP is primarily focusing on as migration or re-implementation is so difficult with S/4 HANA)
I think Uwe Grigoleit knows that what he is saying is untrue, but as Global Head of Business Development, let’s first acknowledge that he has probably told some whoppers in the past. Considering he may not have ever logged into a SAP system himself, it would be easy for him to hear something second hand, and then to start repeating it. Uwe Grigoleit is in sales, so he wants to sell S/4 HANA and therefore has a strong bias to mislead customers on the status of S/4 HANA.
The S/4HANA Simplification List is misnamed. Instead of being called the S/4HANA Simplification List it would simply be called the “changes made is.” Naming the list, the S/4HANA Simplification List makes it seem as if everything in the S/4HANA Simplification list is a simplification. However, in most cases the opposite is true.
One of the reasons I wrote this article is that I am beginning to wonder myself how many people who have investigated S/4 and know that outside of Finance (which also has rough areas and a big question mark with how may Fiori apps can be used). S/4 as a suite is not ready to be implemented.
Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.
As of August 2018 this article was reviewed and while S/4HANA has continued to see development SAP still has few live implementations once the S/4HANA and SAP’s exaggeration of S/4HANA’s go lives, as well as S/4HANA’s simplification have continued.
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.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation Book
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