Having completed multiple SAP S/4HANA Conversions over the last two years, we identified some patterns when it comes to S/4HANA and custom code:
1. Greenfield or Brownfield?
While during the early days of S/4HANA most companies favored implementing their S/4 systems from scratch (aka Greenfield), nowadays most customers seem to be leveraging their strategic assets by selectively migrating customizations from their existing systems to their new S/4 systems. Regardless, it is not about green or brown, but what is right for your business!
2. Technical Upgrade or Functional Conversion?
In 9 out of our last 10 S/4HANA Conversion projects, 98% of the changes that were required to make existing custom code functional and performant in S/4 were purely technical. Only 2% required functional re-architecture. Most conversions are pure technical upgrades when it comes to custom code, even S/4!
3. Material Number Extension ; is it that bad?
On average more than 90% of the MATNR changes reported by Code Inspector/ATC are not relevant … but you need to know how to identify the ones that are! At smartShift, we leverage our automation platform to do this quickly and accurately.
4. Do I really need all my custom code?
On average between 40 – 70% of all custom developments in an SAP system have not been used within the last two years and can be decommissioned. This reduces the conversion effort to S/4HANA massively! We leverage our automation to do this without introducing risk or business impact!
5. Which SAP Notes really matter?
SAP Note 2215424 (Material Number Field Length Extension), 2198647 (S/4 HANA: Data Model Changes in SD) and 2431747 (General Ledger: Incompatible changes in S/4HANA compared to classic ERP releases) represent the vast majority of the total number of issues reported by Code Inspector/ATC. This might make you think that you would be better off with a greenfield approach and throwing away all your custom code. But again, it turns out that a huge portion of the reported issues do not in fact require any adjustments. On top of that, the remainder can be converted automatically!
6. HANA Database changes (the known issue)
Don’t be fooled: HANA is still a big deal when it comes to custom code and habits of old-school ABAP development. Our transformation projects show that the custom code in an average SAP system contains more than 5.000 HANA code compliance issues that can have a functional impact if not addressed (>90% ORDER BY issues). The good news: more than 94% can be transformed automatically!
7. Everything is faster on SAP HANA?
Move to SAP HANA DB and everything is faster? This is what your Business is expecting! But moving to SAP HANA without addressing performance issues in your custom code might even lead to performance degradation. For example, SELECT * is not a good thing on HANA. Everybody knows this. Our intelligent transformation engine can transform SELECT * where it is necessary and leave it where it does not matter, for example in customizing tables with less than 7 columns. On average we find more than 10.000 HANA Performance issues with SELECT * in our projects, and we fix more than 80% of them automatically!
8. SELECT SINGLE on HANA DB (the bomb is ticking…)
For the longest time the SAP community was not aware of the possible issues a SELECT Single statement can cause. Even today it still sounds rather exotic, but SELECT SINGLE (selecting only one record in a database table or view) can cause serious functional problems on SAP HANA. Take it seriously and fix all issues reported in Code Inspector Functional DB!
Although S/4HANA is formally not a successor of SAP ERP, its compatibility mode ensures that most of the custom coding still runs as before. Statistically only a small portion will not run anymore. It turns out, a S/4HANA conversion project can be seen as a technical transformation project after all.
Please contact us if you are considering the next step to S/4HANA, would like valuable insights from our experienced team, or want to learn more about smartShift’s S/4 automation platform!