The S/4HANA Simplification List
What This Article Covers
- SAP’s Position on S/4 HANA’s Readiness
- The S/4HANA Simplification List
- Previous Proposals on SAP Application Readiness
Introduction
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…
This article will focus on making sense of the statements made about S/4HANA by SAP.
This should of value to people because the messaging on S/4HANA is confusing and requires translation as well as validation.
SAP’s Position on S/4 HANA’s Readiness
One thing that will definitely undermine SAP Run Simple is the readiness of S/4 HANA. Applications that are incomplete are not at all simple. Just the opposite actually.
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.
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.”
This is a document that describes all the changes to ECC. The term simplification is just a euphemism.
- Many of the changes are not at all simplifications. Why they would be listed then in the S/4HANA Simplification List is not clear.
- The S/4HANA Simplification List lists areas that have been removed from ECC as “simplifications.” Yet, what if you as a company rely upon 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, 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 in 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?
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.
Conclusion
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, when in many 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.
References
I cover how to interpret risk for IT projects in the following 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.
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
