- 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.
S/4HANA means radical changes in the code that companies have developed. In this article, we will propose that companies that plan to move to S/4HANA should not wait until the implementation to perform the code remediation analysis.
See our references for this article and related articles at this link.
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 requires determining a path independent of SAP.
The Major Factors in S/4HANA Code Remediation
S/4HANA means using HANA, and this 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 the process of 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, and then determining the severity of most of the remediations, and then applying 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 the 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 so that it reduces the resistance on the part of the customer to move to S/4HANA or to 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 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 Solution Manager.
The statements made in this video simply don’t occur on projects. Solution Manager has very significant overhead, and while it can be advantageous to document configuration and development in Solution Manager (Solution Manager allows 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 as the thing through which everything on a project was to.
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 the custom code 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
“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.”
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 job of the developer easier.”
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 trying to sell 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 any rhyme or reason or any controlling entity coordinating the information. We conclude that SAP’s degenerate organization of information around HANA code migration is going to lead to inefficient code remediation projects. Whatever the actual level complexity of HANA code remediation, SAP has made the issue far worse though how it has created tools and communicated 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 perform 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.