Considerations when moving to S/4HANA - Handling C...
Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
In this final part, I will talk about handling of custom code and the development and deployment of future S/4 landscape change.
SAP Custom Code
Historically, one of the reasons why SAP is such a dominant product today is linked to how flexible and relatively easy it was to extend or adjust the product to meet every customers’ needs. This was possible via the inbuilt ABAP programming language and has led to the creation of tens or hundreds of thousands of custom objects and millions of lines of custom code in many of the world’s largest SAP customers.
This double-edged sword is now one of the key challenges facing customers as they approach their S/4 transformation, as much of the custom code which was necessary during initial deployment and ongoing continuous improvement represents one of the biggest barriers to simple S/4 transformation.
Custom code could even be a key factor in determining which transition approach is right for each customer landscape. High amounts of relevant custom code, for which the customer does not want to transform their business process or move back to standard, would be a reason to go Brownfield or Hybrid (see part 1 of this series for more details). Conversely, a huge amount of unreliable custom code with poor documentation and loss of knowledge could be a reason to start again and go Greenfield, with a goal of leveraging standard SAP best practices wherever possible.
SAP recognizes the importance of custom code and the fact that it is a barrier to S/4 adoption, so they have many tools which can be used to better understand what custom code exists, whether it has been deployed and whether it is being used (if so, how often and by whom), in addition to whether it is of the right quality and whether it will work with S/4HANA:
Once you have made a decision on the approach to take for a particular landscape, you need to decide how to handle the custom code. In many cases if you are going Greenfield, the simplest and most cost effective approach will be “if it ain’t broke, don’t fix it” – leave it to die in the ECC system or only refactor / clean-up those selected custom solutions which need to be maintained. They can be “lifted and shifted” to the new S/4 development system.
If, however, you are planning a Brownfield or Hybrid approach (based on shell creation), then it is important to better understand the custom code and to cleanse it. By cleanse, I mean remove code that isn’t needed. Most companies only use <40% of the code they have created and even then, there could be code branches which are no longer relevant.
In the case of shell creation, this clean-up can be done in the new shell system, but in Brownfield it needs to happen in the current landscape (at minimum the removal of no longer required objects), and the sooner the better. This work could take months and will hold up your S/4 transformation so I’s best to begin as soon as possible.
Making it work on S/4
In order to have a healthy S/4 system running with custom code that was originally designed and developed on ECC, it is important to understand that there are 3 different types of work to consider regardless of the approach and the amount of custom code that has been retained. SAP S/4HANA System Conversion – Challenge for your custom code | blogs.sap.com
Functional – The first category is to ensure that the custom code still works with the core system and has not been affected by changes to the solution which SAP documents in the Simplification List. Functional changes cannot be automated and must be analyzed to adjust based on what was originally intended and how the new system functions in that process.
Technical – HANA itself is one of the more obvious technical changes that are required. If native SQL has been used or if ordering is assumed in the response from the DB, then changes may be necessary.
Performance – Lastly, to take advantage of running on an In-Memory database, code can be re-written or adjusted to allow some of the functions to be performed at the DB level (code pushdown) so that the new platform can be fully leveraged.
There is a lot more detail in the following SAP blog.
Depending upon the amount of custom code, the impact of the simplification DB and the approach being taken, the amount of work in custom code adaptation could be extensive. Services exist which can accelerate/automate this to a large extent – for example smartShift. Significant custom code remediation coupled with a lengthy dual maintenance process and high volumes of change also demand an automated solution for change control and governance. Such solutions ease the merging of ECC and remediated S/4 code throughout the transformation to S/4.
Future S/4 Landscape Complexity and Volume
Personally, I see the following drivers within future S/4 landscapes which will mean higher volume of change being managed across more people, with a higher degree of orchestration needed than is the case today:
The pace at which SAP is releasing updates for their S/4 solution is higher than at any point in history. Annual releases (1511, 1610, 1709, 1809, 1909, ..) and bi-annual Feature Pack Stacks (FPS) make the ability to efficiently upgrade and stay current more than important ever before. It could even be necessary to consider an upgrade during your S/4 migration.
Staying current will also allow for a reduction in the amount of custom code that gets developed, as hopefully SAP is building out new S/4 features in areas which can be leveraged to avoid custom solution development.
In addition, the demand for agility in a future S/4 system will continue to grow despite higher change volume and higher business risk of failed changes. This is why organizations are continuing to explore new solutions like automated regression testing to stay current as efficiently as possible during and after the transition.
In summary, planning the move from legacy ECC systems to S/4HANA with the three key considerations mentioned in this blog series will ensure your team is equipped to take on the journey and the challenges that may come along the way.
