How to Understand SAP S/4 HANA SAP Customization or SAP Enhancement

Executive Summary

  • S/4HANA has a very high customization or SAP enhancement adjustment overhead.
  • Learn about the reality of the S/4HANA customization versus the SAP hype.

Introduction to S/4HANA and Customization

S/4HANA has a very high customization or SAP enhancement adjustment overhead. In this article, you will learn about the reality of the S/4HANA customization overhead or SAP enhancement versus what SAP proposes.

SAP’s Presentation on S/4HANA Customization or SAP Enhancement

Hasso Plattner has taken an interesting step in describing what would happen to a SAP customization or SAP enhancement that has been added to an existing ECC system. This is of particular importance as 92% of SAP implementation has a moderate to high level of SAP customization or SAP enhancement.

SAP’s Proposal on Custom Code Usage

SAP proposes that very few custom coded objects for SAP systems are actually used. SAP has proposed that for companies that plan to implement S/4HANA, that the custom code is evaluated for removal. This has been a long-term strategy by SAP to get customers to use standard functionality, the problem being, SAP is always sold with the amount of functionality that will meet the customers being overstated, which we covered in the article How to Understand the Overamapping of ERP to Functionality. This leads to the question of how much custom code in SAP systems is relied upon by customers.

SAP Nation 2.0 on the Percentage

The book from SAP Nation 2.0 provides an explanation of how much custom code is used.

“According to Panaya, a tool vendor, “Our data shows approximately 50 percent of customers use 60 percent or less of their custom code. Being able to easily identify which parts of that code can be safety cleaned from the system can help reduce the future cost of such upgrades.“”

That is no the level of code used by customers communicated by SAP, which attempts to make the percentage utilized seem far less.

Hasso on SAP S/4HANA Allowing the Dropping of SAP Customization or SAP Enhancement

“It is interesting to see regional differences in the speed of adoption. It is similar to the introduction SAP R/3 in 1992/3. The SAP R/3 system was meant to be for smaller companies and who jumped on it first? The large and super large ones. I am absolutely convinced that smaller and midsize companies will now benefit even more, since they might be able to drop most of their modifications, as a consequence reduce the TCO, and have significantly more productive users, who will gain business insights like never before.”

…Smaller and Midsized Companies Will Now Benefit Even More, Since They Might be Able to Drop Most of their Modifications:

Really?

How can using the same functionality in ECC allow any company, regardless of its size to drop its modifications?

The vast majority of changes that exist in SAP customers are because of gaps in functionality.

Mitigating Deficiencies for S/4HANA or SAP Marketing Instructions?

These deficiencies are not altered because S/4 does not provide more or different functionality than ECC. In fact, most of the modifications that companies have made to ECC will never be addressed by future versions of SAP’s ERP systems because they are unique to the company’s requirements.

Without additional functionality, no modifications should be expected to be dropped. In fact, these changes will need to be rewritten.

Our Interpretation

It took me so much time to complete this article. I understand that Hasso wants the customer to buy S/4 licenses, but customers should look at how many statements that are said about S/4 HANA are true or where they cannot be determined if they are true if they are likely to be true.

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.

The Ridiculous Quotation from Deloitte

One of the areas of S/4HANA that has been obscured by SAP has been customizations. In this article, we will describe what happens when S/4HANA is implemented by a company moving from ECC. And we will also delve into comments made by Deloitte regarding its highly customized version of ECC.

Moving From ECC to S/4HANA

As S/4HANA uses a different database schema from ECC, S/4HANA is the first ERP system that will break all integrations and customizations that customers added to ECC. SAP has released confusing information on these topics would prefer to keep them hidden and obscure as it would negatively impact S/4HANA purchases. SAP has instead changed the topic and has said that S/4HANA represents an “opportunity” to SAP customers to evaluate all current customizations and to remove them. SAP appears silent on the topic of integrations that will break and will need to be rewritten when S/4HANA is implemented. SAP is currently deceiving customers on this point and instead of telling them that S/4HANA provides an opportunity to evaluate all customizations and to eliminate them.

Deloitte’s 33,000 Customizations or SAP enhancement

In a press release that was supposed to promote S/4HANA, Deloitte admitted that it performed 33,000 customizations when it implemented a very narrow area of functionality in ECC. 

“Deloitte was an early adopter of SAP’s R/3 ERP system back in 1995 despite it “not really being designed to be used by a professional services firm,” Bray said. “So guess what? We customised the hell out of it,” he added, with more than 33,000 SAP finance customisations made over 20 years.

Over the years Deloitte has adopted some of the professional services-specific editions of SAP software, but was still facing the typical challenges of having an ageing system. Namely, long run times, maintenance issues, little flexibility due to the number of customisations, and outages. Now it is looking to fully upgrade to the next-generation S/4HANA suite, which is built on the software vendor’s in-memory HANA database.”

It is difficult to see how Deloitte, that after all just does consulting, accounting services and outsourcing would need so many customizations. The vast majority of SAP customers will not have anywhere close to that many customizations. Again, if you have that many customizations a few questions naturally arise. 

  1. Did we choose the right application?
  2. Do we even fit into the category of a packaged application?

Deloitte’s Misstep in Releasing Truthful Information on S/4HANA

Maybe the company with 33,000 customizations or SAP enhancement simply needs a custom built application. Also, it boggles the mind that business as simple as Deloitte would need that many. Furthermore, Deloitte did not realize it, but they are directly contradicting SAP by admitting they had to make so many customizations. According to SAP, you should not need customizations because all best practices are already contained in their applications. If even one of their top consulting partners needed to perform so many customizations, then what hope do customers have to stay away from them. 

Deloitte may not remember the marketing material and what they present to their clients, but SAP contains all the best practices in the universe within the application. SAP is extremely clear in its messaging that most of the customizations that clients make to their software — which remember contains all best practices — are unnecessary.

It is still amazing to me that Deloitte even admitted this. They are supposed to get this stuff approved by SAP before its released as a complete story for ComputerWorld to reprint. It is incredible that some people don’t even know the implications of what they are saying. SAP marketing is going to ream them out big time. And from what SAP partners who are vendors tell me, it is not a pleasant experience. I heard what SAP did to Gartner over S/4HANA, and it was very humbling for Gartner. That information related to customizations or SAP enhancement may get retracted in a day or so. But it’s too late, I have taken a copy of the article to my Evernote. I may write an article on this; it is too humorous to pass up.

Comments by Sam Graham

In a discussion on this topic on LinkedIn, the following comment was made by Sam Graham

“So, Deloitte, who earn hundreds of millions of dollars every year from implementing SAP are going to revolutionize their business by moving to, guess what?. SAP! What a surprise! And I wonder of all of the companies who implemented R/3, under advice from Deloitte, realized what a low opinion Deloitte had of R/3? What was that phrase, “We customized the hell out of it”? At whose cost; I wonder? And will they also ‘customize the hell’ out of S4/HANA? And, having spent millions or tens of millions on S/4HANA, following Deloitte’s recommendation, will their customers be paying millions more for the customization that Deloitte recommends?”

Customizations or SAP enhancement as Not a Good Measure of Fit of an Application?

In the LinkedIn interaction, Pete Chapman stated the following:

“Gosh everyone is a cynic 😉 The conclusion most large enterprises come to involves a mix of COTS products with mods where possible, custom build where it offers a competitive advantage and messy integration. Who wants to build their own finance package from scratch? Horses for courses. I’m sure there’s a better way out there, let me know when you find it…”

Shaun Snapp’s Comment

“I can’t speak to what everyone wrote on this thread, but my proposal was simply that S/4HANA Finance was not a good choice for Deloitte and that Deloitte did not select S/4HANA for its match to business requirements, but for marketing and skill development reasons. Deloitte would be better served with a financial best of breed combined with an HR solution. I did not propose building a finance application from scratch but instead proposed a best of breed financial application that was not part of an ERP suite. On the topic of messy integrations, customizing applications is not any less messy. It’s coding. Its development hours, etc.. I don’t think going with a 100% internally developed application is preferable, though in some areas there is no packaged solution that meets the requirements (some forms of production planning and scheduling are a perfect example of this) if you have 33,000 customizations in mostly a single module, then how much of the standard functionality was used?”

Sam Graham’s Comment

“Pete; can you justify 33,000 modifications to a system that most customers have paid many million of dollars for? How many ERP systems have an implementation consultant who advises that a customer should make 33.000 modifications? Are you saying that Deloitte are irresponsible or just incompetent? If customers haven’t paid for these 33,000 modifications that a SAP implementation partner deems necessary; are they using an inferior system? Can you explain?”

Pete Chapman’s Comment

Without commenting on a specific case global implementations accumulate a lot of custom code after 20 years of business change – some of it technical debt. You know it: Workflows. Reports. Interfaces. Conversions. Enhancements. Forms. Authorisations. Plus entirely new transactions. 33,000 is meaningless without proper context. Ideally changes are justified by commensurate benefits – although good governance is under appreciated. Major ICT transformation programmes can now cost hundreds of millions of dollars with benefits measured in billions. Context matters. I’d rather build a well-tailored experience on COTS services than train 50,000 users on generic screens.

Shaun Snapp’s Comment

“I learned something really amazing from these comments Paul. The number of customizations, even after Deloitte pointed out the heavy maintenance of ECC is absolutely meaningless. The decision that Deloitte made was fantastic. And if you disagree with mass idiocy, you may be a cynic. As long as we have financial bias promoting analysis, one will always come to ludicrous conclusions.”

Paul Coester Comment

“Cold facts are though that SAP is not quite as adept at the end to end stuff as the hype says it is. Forget DTT, even now today that is true. Case in point…Not one of the EAM Fiori apps work…But SAP flog them into the customer base like it’s THE thing…”

Pete Chapman Comment

“Paul Ever since ITS I’ve wished they would publish some light services with templates in popular web technologies. As long as business data and logic doesn’t leak from the application side the UX would almost be “disposable”. 

Conclusions

There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated.

As for Deloitte, this is what happens when a person who knows nothing about system implementation makes statements that he does not realize can be triangulated to determine that SAP made an enormous error in selecting SAP ECC. But for course, this could also have been determined by simply analyzing Deloitte’s business and understanding ECC. However, the match was unimportant to Deloitte. Deloitte wanted to implement SAP for marketing and skill development reasons.

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.

S/4HANA Implementation Research

We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.

Select the description that best matches you.

Option #1: Do You Work in Sales for a Vendor?

See this link for an explanation to sales teams.

Option #2: Do You Work for an Investment Entity that Covers SAP?

See this link for an explanation for investment entities. 

Option #3: Are You a Buyer Evaluating S/4HANA?

For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers

Search Our Other SAP Custom Code Content

References

I cover how to interpret risk for IT projects in the following book.

*https://www.amazon.com/SAP-Nation-2-0-empire-disarray-ebook/dp/B013F5BKJQ

The Risk Estimation Book

 

Software RiskRethinking 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