I wanted to follow up on my last posting regarding migration from SAP ECC to S4/HANA with a looming timeline of either 2025 or 2027 for end of support from SAP.
In my last blog, I spoke about utilizing WestTrax, a super awesome app that ‘discovers’ things you never knew about your SAP ECC instance. Like custom code. I was speaking with a business leader today and we both agreed that using an expensive tool like SAP and then customizing it causes all sort of unforeseen (but usually known!) ramifications. So, here is some top-of-the-mind thoughts on custom code.
First, there are really two types of custom code: 1) code that modifies standard SAP transactions (ouch!) and 2) home grown custom code that adds additional capabilities and/or functionalities to your SAP system. In both cases, customizations (not configurations) are generally due to:
- Changing business requirements
- Changing reporting requirements
- Changing legal requirements
- ‘This is the way the users have always have done it’ requirements 😊
With all of this, what are the unintended consequences of using custom code?
Standard SAP ECC software is highly efficient. Run times are short and the system will generally not time out. Whereas custom code has typically longer run times, performs less optimally and as a result, can time out, causing user frustration, lost time to deliver business results. Let’s remember that standard SAP software has built-in safeguards to maintain overall system integrity (aka passing an audit!), is internally logged, is supported, and maintained by SAP.
Custom code on the other hand is up to the business and IT teams to document, ensure integrity is not invalidated which means lots of testing to ensure it runs properly but also does not compromise any standard SAP functions, tables, or transactions (aka making sure it can pass an audit!). And it is not always logged internally like standard SAP functions and requires IT to manage access controls. Any custom code that modifies standard and/or completed financial documents are consider critical objects within SAP, hence required to managed carefully including monitoring, and controls adherence.
Remember, critical objects in any system have the potential to modify standard transactions in SAP which could unintentionally result in fraudulent transactions being executed without anyone’s knowledge. Discovering these potential anomalies is hard, very hard.
As a result of all this, there now a new requirement called SAS 145 which requires a publicly traded company to audit any transactions / custom code that modifies standard fields/tables within a financial system. Typically, this has not been done in the past which may have resulted in fraud.
OK, with all that said, why do we actually cave in to user requests to modify a perfectly good, solid SAP ECC system? I don’t have the answer other than this is the way it has been done and lack of effort to change an old habit and use a well-thought-out standard transaction. In referring to migration of your SAP ECC system to SAP S4/HANA, all of this customization needs to be taken into account. Not all the transitions will run in the S4/HANA world. Even some of the standard SAP transactions have changed, thus if you modified a standard transaction, these babies are up for grabs too.
This is where WestTrax is eyeballs into what has been built over the years. You need to evaluate what you have done, what it impacts, will it run in the future, will it pass the SAS 145 audit, and more! You don’t want to be migrating to S4/HANA and dragging forward all the custom code, especially the code that no longer runs, or won’t pass the SAS 145 audit.
So, when looking to migrate and transition to S4/HANA, whether greenfield or brownfield, you need to do all this analysis to figure out the road ahead. That’s why WestTrax exists: it uncovers the truth and clears the path to a successful SAP S4/HANA migration.
