Why It Is Important to Pull Forward S/4HANA Code Remediation

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

S/4HANA code remediation is one of the most critical parts of S/4HANA implementations.
In this article, we will explain why it is important to pull the remediation effort forward.

Video Introduction: Why It Is Important to Pull Forward S/4HANA Code Remediation

Text Introduction (Skip if You Watched the Video)

Implementating SAP S/4HANA means radical changes in the code that companies have developed, including that all of the code developed as part of custom development or as integration adapters breaks with S/4HANA. While SAP and SAP consulting firms are trying to push SAP customers to underestimate this effort, a realistic approach would mean not accepting SAP’s claims about how automation will take care of the code remediation effort. You will learn why we propose that companies that plan to move to S/4HANA should not wait until the implementation to perform the code remediation analysis.

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.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

The Problem Getting Accurate Information on S/4HANA Code Remediation

SAP has published its perspective on remediating code for S/4HANA. Both SAP has its consulting partners have consistently underrepresented the complexity involved in code remediation to customers to make the migration to S/4HANA seem to be less work and less cost than it is. In this article, we review the material on remediation without any SAP bias.

The Confusing Aspects of S/4HANA Code Remediation

SAP’s explanations of the process and how to use the tools for S/4HANA code remediation are incredibly confusing and require determining a path independent of SAP.

The Major Factors in S/4HANA Code Remediation

S/4HANA means using HANA, which means that the tables change, that code that was initially written to be portable between databases now has to be altered for only HANA. It means that SQL must change. Overall, S/4HANA upgrades will be the most extensive and trouble-prone code remediations that an SAP customer will typically have faced (for their SAP systems, at least).

Code Remediation Analysis Versus Code Remediation

Code remediation analysis is different than actually performing the code remediation. The code remediation analysis or CRA is simply determining what items need to be changed and then planning the work effort and even the resourcing. One typically attempts to obtain a list of code items to be remediated, determine the severity of most of the remediations, and then apply an appropriate time estimate (which then goes to budget) for each remediation. This can be done without owning any S/4HANA software because the rules of how the code needs to be changed are known.

The Approach of SAP and their Consulting Partners

SAP and SAP consulting companies typically want this analysis to be pushed into implementation when they are firmly in control of the project. The strategy is to keep the unappealing details away from the customer until they have signed to reduce the resistance on the part of the customer to move to S/4HANA or move to S/4HANA in a particular timeframe.

The Types of SAP Custom Code Management Tools

In the book Managing Custom Code in SAP, the following tools are mentioned:

“Solution Manager: Custom code can be managed in Solution Manager.

CCLM: Custom code can be measured in terms of magnitude. There is something called Custom Code Lifecycle Management (CCLM) applications.

RDPD: There is a Reverse Business Process Documentation tool (RDPD) that is used as a process to map custom code to the business process.

TEA: There is a Transport Execution Analysis report, this allows one to obtain an overview of the current management practices for your custom code landscape.

CDMC: The Custom Development Management Cockpit (CDMC) is used to determine the impact of an SAP upgrade on the custom code library.

BPCA: The Business Process Change Analyzer (BPCA) is used to determine the impact on your custom code library of an upcoming change, including the automatic generation of optimized test plan.

SAP Clone Finder: Is used to identify code that you have cloned from SAP standard and comes with impressive comparison capabilities to help revert back to the standard when possible. The code inspector provides a quantitative measure of quality of your custom code against predetermined metrics and patterns.”

Solution Manager

Solution Manager is very well known. However, it is becoming less frequently used to manage either development or configuration details, as is covered in the article End of the Line for SAP Solution Manager.

But a number of the items listed below are actually within the Solution Manager application. SAP provides misleading information on how customers generally respond to the Solution Manager.

The statements made in this video simply don’t occur on projects. Solution Manager has very significant overhead. Simultaneously, it can be advantageous to document configuration and development in Solution Manager (Solution Manager allows you to store the link so that you can go right out to the SAP transaction and configuration). But generally, people don’t like using Solution Manager. And Solution Manager’s use on projects continues its long decline.

Google Trends shows what we have seen on projects. Solution Manager is just less and less relevant. SAP put significant capital behind making Solution Manager the thing through which everything on a project was to.

CCLM

CCLM is intended to reduce custom code. This is explained in the following video.

The problem with this is that SAP is always trying to reduce custom code, even when it is vital for the business processes. This is covered in the article How SAP Used and Abused the Term Legacy.

CCLM is actually within Solution Manager.

The CCLM provides insight into the various categories of development objects.

“Custom Code Usage App
Custom Code Severity App
Custom Code Quantity App
Custom Code Quality App
Custom Code Criticality App” – SAP

RDPD

“The analysis results referring to the SAP standard business process reference model can be converted into a Solution Manager project and can be adapted to the customer specific business processes. Customer specific adaptation of a process structure means including customer’s transactions and programs, defining additional customer specific process steps or individualization of SAP standard process steps. To prioritize which business processes need an adaptation, SoDocA provides detailed information about the usage and frequency of used business processes. This includes also a deep insight into customer specific development and their usage penetration in the productive environment. SAP provides analysis content with more than 14.000 inspections to jump-start the initial documentation of any productive SAP environment. The overall number of SAP inspections will be increased over the coming years to support the whole SAP Business Suite including the different industry solutions. Apart from SAPs provided inspections, the customer has the full flexibility to define their own specific inspections to individualize the discovery process.”

TEA

CDMC

SAP Clone Finder

This is designed to find any code that has been cloned in the past. It will rank how close the SAP object is to the object that was cloned.

More quotations from the book Managing SAP Custom Code are as follows:

“All SAP systems have custom code. Over time, the amount of custom code increases as new features are added and business processes mature and evolve. Custom code may be added to your system in large chunks, delivered as part of a project, or evolve organically over time as part of “business as usual.”

As a general rule, software developers spend much more time reading code than writing code. Most of the time, a developer will need to read and understand existing legacy code before a new feature can be added. This leads to the apparent conclusion that easy to read code can be considered good code because it makes the developer’s job easier.”

Go to top

Conclusion

92% of SAP ECC implementations are moderately or extensively customized. As part of S/4HANA messaging, SAP has been proposing that customization will decrease significantly in the future, but there is little reason to think this will be the case. Most SAP projects were sold under the idea that they could be implemented with very little custom code, but that is the standard position to hold when selling SAP.

Information Provided by SAP on Code Remediation

The information provided by SAP as to code remediation is horrendously complicated. It is a disorganized assembly of information released without rhyme, reason, or controlling entity coordinating the information. We conclude that SAP’s degenerate organization of information around HANA code migration will lead to inefficient code remediation projects. Whatever the actual level complexity of HANA code remediation, SAP has made the issue far worse by creating tools and communicating how code migration works.

Essentially, SAP’s advice and the advice of SAP consulting companies on the subject of custom development is unreliable. The only point that these entities have in providing advice is to make the client as dependent on them as possible.

Rather than listening to SAP or their compliant consulting partner and performing the code remediation into the project, it makes much more sense to pull the remediation analysis forward so that the implementing company can incorporate the remediation estimate into the project plan before consultants or SAP hit the project in force.