Nachdem wir in den letzten zwei Jahren mehrere SAP S/4HANA-Konvertierungen durchgeführt haben, haben wir einige Muster erkannt, wenn es um S/4HANA und benutzerdefinierten Code geht:

1. Greenfield oder Brownfield?
Während in den Anfangstagen von S/4HANA die meisten Unternehmen ihre S/4-Systeme von Grund auf neu implementieren wollten (auch bekannt als Greenfield), scheinen die meisten Kunden heute ihre strategischen Assets zu nutzen, indem sie selektiv Anpassungen aus ihren bestehenden Systemen in ihre neuen S/4-Systeme migrieren. Wie auch immer, es geht nicht um grün oder braun, sondern darum, was für Ihr Unternehmen richtig ist!

2. Technisches Upgrade oder funktionale Umstellung?
In 9 unserer letzten 10 S/4HANA-Konvertierungsprojekte waren 98% der Änderungen, die erforderlich waren, um bestehenden benutzerdefinierten Code in S/4 funktional und performant zu machen, rein technischer Natur. Nur 2% erforderten eine funktionale Umstrukturierung. Die meisten Konvertierungen sind rein technische Upgrades, wenn es um benutzerdefinierten Code geht, auch bei S/4!

3. Material Number Extension ; ist das so schlimm?
Im Durchschnitt sind mehr als 90% der von Code Inspector/ATC gemeldeten MATNR-Änderungen nicht relevant ... aber Sie müssen wissen, wie Sie die wirklich relevanten identifizieren können! Bei smartShift setzen wir unsere Automatisierungsplattform ein, um dies schnell und präzise zu tun.

4. Brauche ich wirklich meinen gesamten benutzerdefinierten Code?
Im Durchschnitt wurden zwischen 40 - 70% aller Eigenentwicklungen in einem SAP-System innerhalb der letzten zwei Jahre nicht genutzt und können stillgelegt werden. Das reduziert den Umstellungsaufwand auf S/4HANA massiv! Wir nutzen unsere Automatisierung, um dies ohne Risiko und Business Impact zu erreichen!

5. Welche SAP-Hinweise sind wirklich wichtig?
Die SAP-Hinweise 2215424 (Material Number Field Length Extension), 2198647 (S/4 HANA: Data Model Changes in SD) und 2431747 (General Ledger: Inkompatible Änderungen in S/4HANA im Vergleich zu klassischen ERP-Releases) stellen die überwiegende Mehrheit aller von Code Inspector/ATC gemeldeten Probleme dar. Dies könnte Sie zu der Annahme verleiten, dass Sie mit einem Greenfield-Ansatz besser dran wären und Ihren gesamten benutzerdefinierten Code wegwerfen sollten. Aber auch hier zeigt sich, dass ein großer Teil der gemeldeten Probleme in Wirklichkeit keine Anpassungen erfordert. Darüber hinaus kann der Rest automatisch konvertiert werden!

6. HANA-Datenbankänderungen (das bekannte Problem)
Lassen Sie sich nicht täuschen: HANA ist immer noch eine große Sache, wenn es um benutzerdefinierten Code und Gewohnheiten der ABAP-Entwicklung alter Schule geht. Unsere Transformationsprojekte zeigen, dass der benutzerdefinierte Code in einem durchschnittlichen SAP-System mehr als 5.000 HANA-Code-Compliance-Probleme enthält, die funktionale Auswirkungen haben können, wenn sie nicht behoben werden (>90% ORDER BY-Probleme). Die gute Nachricht: Mehr als 94% können automatisch transformiert werden!

7. Alles ist schneller auf SAP HANA?
Umstellung auf SAP HANA DB und alles ist schneller? Das ist es, was Ihr Unternehmen erwartet! Aber wenn Sie auf SAP HANA umstellen, ohne die Leistungsprobleme in Ihrem benutzerdefinierten Code zu beheben, kann dies sogar zu einer Leistungsverschlechterung führen. Zum Beispiel ist SELECT * keine gute Sache auf HANA. Jeder weiß das. Unsere intelligente Transformations-Engine kann SELECT * dort umwandeln, wo es notwendig ist, und es dort belassen, wo es keine Rolle spielt, zum Beispiel bei der Anpassung von Tabellen mit weniger als 7 Spalten. Im Durchschnitt finden wir in unseren Projekten mehr als 10.000 HANA Performance-Probleme mit SELECT *, und wir beheben mehr als 80% davon automatisch!

8. SELECT SINGLE auf HANA DB (die Bombe tickt...)
Lange Zeit war sich die SAP-Community nicht bewusst, welche Probleme eine SELECT Single-Anweisung verursachen kann. Auch heute noch klingt es eher exotisch, aber SELECT SINGLE (Auswahl nur eines Datensatzes in einer Datenbanktabelle oder View) kann ernsthafte funktionale Probleme auf SAP HANA verursachen. Nehmen Sie es ernst und beheben Sie alle im Code Inspector Functional DB gemeldeten Probleme!

Schlussfolgerung

Obwohl S/4HANA formal kein Nachfolger von SAP ERP ist, stellt der Kompatibilitätsmodus sicher, dass der größte Teil des benutzerdefinierten Codes noch wie zuvor läuft. Statistisch gesehen wird nur ein kleiner Teil nicht mehr laufen. Es zeigt sich, dass ein S/4HANA-Umstellungsprojekt doch als technisches Transformationsprojekt angesehen werden kann.

Bitte kontaktieren Sie uns, wenn Sie den nächsten Schritt zu S/4HANA erwägen, wertvolle Einblicke von unserem erfahrenen Team wünschen oder mehr über die S/4-Automatisierungsplattform von smartShift erfahren möchten!