How to Understand SAP S/4 HANA SAP Customization or SAP Enhancement
Executive Summary
- S/4HANA has very high customization or SAP enhancement adjustment overhead.
- Learn about the reality of the S/4HANA customization versus the SAP hype.
Video Introduction: S/4HANA and Customization
Text Introduction (Skip if You Watched the Video)
S/4HANA has very high customization or SAP enhancement adjustment overhead. SAP has had a long term strategy of getting customers to use SAP standard functionality, even in cases where it does not fit the customer’s requirements, by weaponizing the term best practices. With the problems in code remediation that comes with S/4HANA, SAP has taken this as another opportunity to try to get customers to eliminate or reduce their custom code. You will learn about the reality of the S/4HANA customization overhead or SAP enhancement versus what SAP proposes.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
SAP’s Presentation on S/4HANA Customization or SAP Enhancement
Hasso Plattner has taken an unusual step in describing what would happen to 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 a 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 used. SAP has suggested that for companies that plan to implement S/4HANA, 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 explains 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 not 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 ECC functionality 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. 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 its requirements.
Without additional functionality, no modifications should be expected to be dropped. 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 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.
Moving From ECC to S/4HANA
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 subject and has said that S/4HANA represents an “opportunity” to SAP customers to evaluate all current customizations and remove them. SAP appears silent on 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 eliminate them.
Deloitte’s 33,000 Customizations or SAP enhancement
In a press release 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 isn’t easy 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.
- Did we choose the right application?
- 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 a business as simple as Deloitte would need that many. Furthermore, Deloitte did not realize it, but they directly contradict SAP by admitting they had to make so many customizations. According to SAP, you should not need customizations because all best practices are already in their applications. If even one of their top consulting partners is required to perform 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 release as a complete story for ComputerWorld to reprint. Incredibly, 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 essay 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. Although, Deloitte’s finances are not very complicated — so it could be custom developed, or one could use open source finance or ERP system.
On the topic of messy integrations, customizing applications is not any less messy. It’s coding. Its development hours, etc.. ECC was such a poor fit for Deloitte, that it appears that they used very little of the application, so how was custom development avoided in this case? If you have 33,000 customizations in mostly a single module, then how much of the standard functionality was used?
Furthermore this question sets up a false dichotomy. On one side, one uses SAP ECC, or one creates from scratch. Those are not the only options. Furthermore, Deloitte did not implement ECC because it made any business sense, but because they wanted to build skills and obtain the marketing benefit of being on ECC.”
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 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 of 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.