Blog

Die SAP S/4HANA-Reise geht weiter. Die strategischen Überlegungen standen, die Phasen Discover & Prepare lagen hinter uns. Zeit, aktiv Hand anzulegen und uns ins Umsetzungs-Abenteuer zu stürzen.

Explore – wir tauchen tiefer ein

Nachdem das strategische Gerüst stand, wurde es in der Explore-Phase konkreter. Es mussten die Ziele genauer definiert und der Projektplan detailliert werden.

Das Hauptziel war klar: die Konvertierung des bestehenden ERP-Systems auf SAP S/4HANA mittels Brownfield-Ansatzes. Darunter wurde es spannender. So entschieden wir uns als Zusatzziele unter anderem folgende, zentrale Punkte zu definieren:

• Verwendung von Embedded BW mit Zugriff auf Real Time Daten
• Anbindung der Entwicklungen auf SAP S/4HANA (z.B. unser Projektsystem oder unsere Ressourcenplanung)
• Gateway-Ablöse von UI5-Applikationen (Umbau auf den direkten Zugriff auf Backend – CATs)
• Verbesserung der Performance

Zielsetzung unserer SAP S/4HANA Migration

Bei den Prozessen waren HR (Leistungserfassung & Reisekosten), Fakturierung sowie Rechnungswesen / Controlling enthalten, bei der Custom-Code-Analyse Erweiterungen, Formulare, Auswertungen und Schnittstellen. Ein weiterer Punkt war die Planung der Konvertierungszyklen und das Aufsetzen einer Sandbox, um eine reine technische Migration durchzuführen.

Und los geht’s – nun aber wirklich

Bei der Umstellung eines bestehenden SAP ERP-Systems auf SAP S/4HANA müssen mehrere Dinge passieren:

• Softwarekomponenten müssen aktualisiert werden, einschließlich eines Upgrades des zugrunde liegenden SAP NetWeaver-Stacks und eines Austauschs der SAP-Anwendungssoftwarekomponenten (z. B. SAP_APPL) mit SAP S/4HANA-Softwarekomponenten (S4CORE).
• Wenn das SAP ERP-System nicht bereits auf SAP HANA läuft, muss die Datenbank auf SAP HANA migriert werden. Mit der Umstellung auf SAP HANA muss das Betriebssystem des Datenbankdienstes Linux sein.
• Zur Unterstützung des neuen SAP-S/4HANA-Datenmodells müssen die Daten im System in die neuen Tabellen und Felder konvertiert werden.

Das Gute: All diese Tätigkeiten können in einem „Abwasch“, also einem einzigen Projekt und einer einzigen Ausfallzeit, erledigt werden, da der Software Update Manager eine einstufige Umstellung auf SAP S/4HANA unterstützt. Ausfallzeiten sollten hier im Allgemeinen kein Problem darstellen. Wer auf Nummer Sicher gehen will, für den bietet SAP für größere Systeme standardmäßig eine ausfallzeitoptimierte Konvertierung im Software Update Manager sowie für noch größere Systeme den Projektansatz Near Zero Downtime (NZDT) an.

Für eine einstufige Konvertierung für SAP-ERP-Systeme auf einer beliebigen Datenbank (außer SAP HANA) müssen die folgenden Voraussetzungen erfüllt sein:

1. Das SAP-ERP-System ist mindestens auf dem Release SAP ERP 6.0 (kein EHP erforderlich),
2. Unicode und
3.  Single-Stack (nur ABAP-Stack).

Eine Systemumstellung auf SAP S/4HANA ist auch in anderen Fällen möglich, würde jedoch mehrere Schritte erfordern (z.B. zunächst einen Dual-Stack-Split, wenn es sich um ein Dual-Stack-System handelt.

Wenn das Quell-SAP-ERP-System bereits auf SAP S/4HANA läuft, müssen die SAP-ERP-Systeme zum Zeitpunkt der Systemkonvertierung auf der Version SAP HANA 2.0 (und SP05 für SAP S/4HANA 2020) sein.

Wir hatten Glück: Wir waren in diesem Bezug sehr aktuell, da wir diese Voraussetzungen bereits alle erfüllten. Für uns war vor der SAP S/4HANA-Systemumstellung kein Upgrade- und / oder Datenbankmigrationsprojekt erforderlich.

Wiederholter Readiness Check mindert das Risiko

Da sich im Laufe der Explore-Phase der Release-Stand auf S/4HANA 2022 veränderte, wurde auch der Readiness Check für SAP S/4HANA wiederholt, um Auswirkungen einer Veränderung zum zuvor erstellten Readiness Check zu erkennen. In dieser Phase wurde klar, wie wichtig es ist, Transparenz über die erforderlichen Anpassungsaktivitäten bei einer Systemumstellung zu gewinnen. Eine ordnungsgemäße Analyse- und Scope-Definitionsphase ist also essenziell, denn auf Grundlage dieser Ergebnisse wurden Vorprojekte, der Umfang des Übergangsprojekts und obligatorische Aktivitäten bestimmt.

Und mehr noch: Wir empfehlen in dieser Phase außerdem, nicht nur die obligatorischen Anpassungen zu prüfen, sondern auch weitere Neuerungen, die einen Mehrwert für das Unternehmen schaffen könnten. Bei viele Kunden erleben wir, dass auch ein Prototyp erstellt wird, um den Aufwand und die Aktivitäten bei der Konvertierung besser zu verstehen. Gleichzeitig wird damit eine Umgebung für die Durchführung einer Funktionsbewertung bereitgestellt, die hilft, den Wert für das Unternehmen zu verstehen und zu demonstrieren.

Prozesse unter der Lupe

Ziel der Explore-Phase war es auch eine „FIT GAP Analyse“ durchzuführen, um die bestehenden Prozesse zu analysieren und ggf. zukünftige Prozesse zu definieren. Eines der heiß diskutierten Themen ist dabei der Umstieg auf das neue Hauptbuch – insbesondere für „langgediente“ SAP-Kunden, die nie den Schritt vom klassischen Hauptbuch in das neue Hauptbuch mit parallelen Ledgern gemacht hatten. Gut, dass es bei uns Norbert Leimgruber, seines Zeichens Bereichsleiter Finance & Analytics, gibt. Genau das ist sein Lieblingsthema und er ist überzeugt:

„Ja, die alte Kontenlösung ist unschön und würde man heute nicht mehr so machen, aber sie funktioniert. Wer also bis jetzt kein neues Hauptbuch mit parallelen Ledgern eingeführt hat, braucht das für die S/4-Umstellung auch nicht einführen.“

Explore bei SRB: Unser Fokus

Bei uns „SRB-Abenteurern“ lag der Schwerpunkt der Explore-Phase vor allem in zwei Dingen: der Festlegung des Projektumfangs und der geplanten Vorgehensweise. Hilfreich zudem: Projektmarketing. So wurde unser Vorhaben beim Monatsmeeting vorgestellt, um alle unsere Mitarbeiter:innen nicht nur zu informieren, sondern auch frühzeitig mit ins Boot zu holen zu den bevorstehenden Neuerungen.

Realize – ran an den Speck

Die Realize-Phase bestand bei uns aus zwei Teilen: einer Vorprojektphase & der SAP S/4HANA Umstellungsphase.

Vorprojektphase

Durch die Vorprojektphase minimierten wir das Risiko. Hier erfolgte der Umstieg auf CVI und ein Upgrade auf EHP8. In unserem Fall haben wir uns dazu entschieden einen ECC EHP8 Upgrade durchzuführen, um den Umstieg so „smooth“ wie möglich zu gestalten. Dieser Schritt, gleich auf den neuesten EHP-Stand upzugraden, hatte sich in der Vergangenheit auch bei unseren Kunden bewährt. Schließlich verringerte das nicht nur den Aufwand des Einspielens von Hinweisen, sondern brachte auch alle unsere Testfälle im Zuge des Upgrades auf den neuesten Stand. Und letztere waren dann die Basis für die späteren Tests im Zuge der Integrationstests innerhalb der Konvertierungszyklen.

Customer Vendor Integration

Als wichtiges Vorprojekt starteten wir die Customer Vendor Integration, kurz CVI. Dies ist eine zwingende Voraussetzung bei der Einführung von SAP S/4HANA. Ziel dabei ist es, die Kund:innen und Lieferant:innen auf das „Business-Partner-Modell“. Die Vorteile liegen auf der Hand: Es ist nicht Teil der SAP S/4HANA Konvertierungs-Downtime, kein kritischer Pfad der SAP S/4HANA Konvertierung und es gibt keine Überraschungen in letzter Sekunde und somit Risikominimierung. Aus diesem Grund sollte hierauf ein besonderer Fokus gelegt werden.

Doch wie funktioniert das Modell des Business Partners? Unter dem „Business Partner“ (BP) wird eine Person, Organisation, Gruppe von Personen oder Gruppe von Organisationen verstanden, an der ein Unternehmen ein geschäftliches Interesse hat.

Für eine bessere Übersichtlichkeit wachsen durch den Business Partner also Lieferanten- und Kundenstämme eines Geschäftspartners zusammen. Das gibt weiters die Möglichkeit, Altdatenbestände aufzuräumen und Bestände an Business Partnern zu konsolidieren. Bestehende Lieferant:innen, Kund:innen und Stammdaten werden dabei geprüft und konsolidiert. Auch thematisch zusammengehörende Business Partner sollten zusammengefasst werden.

Auch in diesem Bereich hatten wir bei SRB eine ausgewiesene Expertin an der Hand: Veronika Wolfgruber. Sie führte bei uns die CVI durch. Dabei gab es wichtige Fragen zu klären:

• Wie soll die Nummernvergabe erfolgen (auf BP, Kunden, Lieferantenebenen)?
• Wie geht man mit bestehenden Kunden / Lieferanten um?
• Wie führt man Lieferanten und Kunden zusammen? Wer darf welche daten pflegen?
• Welche Daten müssen vor der Umstellung bereinigt werden (z.B. Adressdaten, Steuernummern, …)?
• Welche Daten können vorab archiviert werden (alte Buchungsdaten)?
• Welche Beziehungen müssen abgebildet werden (Stichwort Bonusabrechnung)?
• Müssen alle bisherigen Kontengruppen abgebildet werden?
• Zukünftige Abbildungen von Vertriebsbeauftragten? Werden diese noch benötigt?
• Wie „übersetzt“ man das „bestehende Kunden / Lieferanten Kontengruppen-Customizing in Business Partner“ Customizing mit
  • BP Gruppierung (zur Nummernvergabe)
  • BP Rollen (für Berichte, Funktionalität, …)
  • BP Typen (Person, Organisation, Gruppe)

Um diese wichtigen Fragen mit unseren Kunden zu klären und Antworten zu erhalten, mit denen wir arbeiten können, wurden Workshops durchgeführt. Die Folge: Im Großen und Ganzen verlief die CVI-Umstellung sehr gut und wir kamen zügig in unserem Projekt voran. Daten wurden analysiert, bereinigt und die CVI getestet. Schlussendlich wurde die CVI auf dem Produktivsystem erfolgreich durchgeführt. Ein weiterer Schritt war getan. Doch der nächste wartete schon.

Custom Code Migration

Eine weitere zwingende Voraussetzung für eine erfolgreiche Migration zu SAP S/4HANA ist die Custom Code Migration. Hier empfiehlt es sich produktive Nutzungsdaten mittels SCMON/SUSG sammeln. Wir haben zudem remote ein ABAP Test Cockpit eingerichtet, um im Entwicklungssystem die SAP S/4HANA Checks des Cockpits zu verwenden. Denn das remote ABAP Test Cockpit ist die technische Infrastruktur für alle statischen Checks an ABAP Custom Codes. Mittlerweile nutzen wir hier die BTP für Custom Code Analysen mittels Custom Code Migration App.

Was man an dieser Stelle nicht vergessen darf: Auch die Entwickler:innen müssen „SAP S/4HANA ready“ werden oder sein. Gut ist, wenn sie sich an diesem Punkt praktische Skills in ABAP-Entwicklungstools in Eclipse aneignen und sich mit SAP S/4HANA Must-have Technologien (z.B.: CDS, BOPF, Odata) vertraut machen – ein Punkt, den wir auslassen konnten. Aus guten Gründen. 😊

An diesem Punkt der SAP S/4HANA Reise angelangt, gibt es natürlich noch mehrere Schritte, die man berücksichtigen kann, aber nicht zwingend muss. Zum Beispiel kann man die eigenen Codes im Entwicklungssystem anpassen. Oder auch wechseln zu Unicode, und falls nicht schon erledigt, reparieren der SAP HANA bezogene ATC-Fehler (z.B.: NO ORDER). Ein Tipp noch: Lassen Sie die SAP S/4HANA Checks in ATC für alle Custom Codes laufen.

SAP S/4HANA Umstellungsphase
SAP S/4HANA kommt näher und näher. Doch die Planung ist auch bei der Migration nicht zu Ende.

Konvertierungszyklen

Die Planung der Migrationszyklen ist bedeutend und darf nicht unterschätzt werden, schließlich hilft sie dabei, den Umfang und den Ablauf des SAP S/4HANA Migrationsprojektes richtig zu definieren. Das Ergebnis ist eine erste Version eines Ablaufes, welche als Grundlage für einen Projektplan fungiert. Eine detaillierte Auseinandersetzung damit unterstützt, den Projektplan als Teil des Projektmanagement-Workstreams im Laufe des Projekts ständig zu verfeinern.

Für uns bedeutete dies im Zuge der Umstellungsphase folgendes:

Was geschieht alles innerhalb eines Konvertierungszyklus:

1. Kopie des Produktivsystems auf eine Sandbox / System
2.  Sandbox wird von einem ECC-System auf SAP S/4HANA mittels SUM Upgegradet (technische Migration)
3.  Migration der Rechnungswesen-Daten: Hier werden die im System befindlichen Daten des Rechnungswesens in die neuen Strukturen übernommen. Dies geschieht in 2 Schritten: Customizing sowie Durchführung der Konvertierung. Hier kommt es durch „historisch gewachsene Buchungen“ zu Fehlern in den verschiedensten Bereichen des RW, die akzeptiert oder korrigiert werden müssen.
4.  Anpassungen der obligatorischen Simplifikation Items: Neuerungen im SAP S/4HANA in den verschiedenen Bereichen werden im System übernommen und müssen getestet werden (z. B. das neue Kreditmanagement, Settlement Management, Intercompany usw.).
5.  Custom Code Anpassungen – siehe oben
6.  Testen und Bugfixing in verschiedenen Ausprägungen:

© SAP Transition to SAP S/4HANA – Implementation Roadmap S207

Das nicht immer alles bei jedem Konvertierungszyklus glatt läuft, wurde uns im Bereich der Anlagenbuchhaltung vor Augen geführt. Nach erfolgreicher technischer Konvertierung hatte sich nämlich herausgestellt, dass diese über einen Monatswechsel hinweg gelaufen ist und dadurch die Abschreibung der Anlagen nicht mehr möglich war. Das bedeutete: Zurück an den Start, was besonders unseren Bereichsleiter Tech, Herwig Stecher, gefreut hat. So lernen wir alle.

Reich an Erfahrungen: eine Reise mit Mehrwert

Blicken wir zurück auf unsere Reise stellen wir fest: Die Erfahrungen, die wir bislang gemacht haben, sind unbezahlbar. Jede Phase für sich ist wichtig, jede bedeutend für späteren den Erfolg.

In der Explore-Phase wird der Grundstein für eine erfolgreiche SAP S/4HANA-Umstellung gelegt. Hier werden grundlegende, richtungsweisende Entscheidung getroffen, die die ganze SAP S/4HANA Umstellung beeinflussen. Auf Basis dieser Entscheidungen wird der Projektumfang im Detail definiert und der Projektplan detailliert.