So gelingt die SAP S/4HANA System Conversion

Die System Conversion, oft auch als Brownfield-Ansatz bezeichnet, ist eines von drei grundsätzlichen Umstellungsszenarien, um auf SAP S/4HANA zu migrieren. Dabei wird ein bestehendes ERP-System auf SAP S/4HANA upgegradet. Die beiden anderen Varianten sind die Neuimplementierung (Greenfield-Ansatz) und die Landscape Transformation, bei der nicht das gesamte System, sondern nur ausgewählte Teile des Geschäftsprozesses konvertiert werden.

Was müssen Sie bei der System Conversion auf SAP S/4HANA beachten?

Da die meisten Unternehmen bereits ein ERP-System im Einsatz haben, ist die System Conversion das häufigste Migrationsszenario. Zudem ist es im Vergleich zur Neuimplementierung und zur Landscape Transformation deutlich weniger aufwendig. Auch wenn jedes Unternehmen in Bezug auf sein ERP-System individuelle Besonderheiten aufweist, gibt es einige allgemeine Tipps, um die Vorbereitung und die Durchführung der System Conversion vereinfachen.

Eine der wesentlichen Fragen im Zusammenhang mit der Migration auf SAP S/4HANA dreht sich um die erforderlichen personellen Kapazitäten. In der Regel werden bei der System Conversion die drei Phasen Prepare & Explore (Pre-Conversion), Realize & Deploy (Conversion) sowie Run (Post-Conversion) unterschieden. Gerade den vorbereitenden Tätigkeiten der Prepare-&-Explore-Phase, die vor der eigentlichen Conversion anstehen, sollten Unternehmen genügend Raum geben, da sie einen erheblichen Teil des Gesamtaufwands ausmachen können.

SAP Readiness Check ermittelt Voraussetzungen

Einen geeigneten Einstieg in das Projekt stellt der SAP Readiness Check für SAP S/4HANA dar. Das Tool analysiert die Voraussetzungen für die Migration und liefert einen ersten Überblick über das Gesamtsystem als Cockpit, ohne sich in Details zu verlieren. Sowohl funktionale als auch technische Themen stehen im Fokus. Zu den wichtigsten Aspekten gehören die Simplification Items, also die relevanten funktionalen Änderungen, die mit dem Wechsel auf SAP S/4HANA einhergehen. Auch Konsistenzprüfungen, relevante Custom-Code-Anpassungen und eine Empfehlung zur Verwendung der Fiori-Apps sind Teil des SAP Readiness Checks.

Über die mit den SAP Notes 2399707 und 2502552 gelieferten Reports wird das System auf relevante Simplification Items geprüft. Dazu ist es erforderlich, den SAP-Katalog mit den aktuellen Simplification Items online abzurufen oder als Datei hochzuladen. Nach der Auswahl der gewünschten SAP S/4HANA-Version prüft das System, welche Simplification Items erforderlich sind. Die jeweilige SAP Note mit Erläuterungen und Details zu den erforderlichen Aktivitäten kann aus dem Prüfreport über einen Link aufgerufen werden.

Business Partner als zentrales Stammdatenobjekt

Der Business Partner gehört sicherlich zu den prominentesten Simplification Items. Als zentrales Stammdatenobjekt in SAP S/4HANA subsummiert er Kunden, Lieferanten und Mitarbeiter. Deren Grunddaten, beispielsweise Name, Adresse, Steuernummer etc., werden auf der Ebene des Business Partners gepflegt.

Für die Umstellung auf SAP S/4HANA ist der Business Partner eine notwendige Voraussetzung. Das heißt, er muss bereits vor der System Conversion eingeführt werden, da die technischen Upgrade-Routinen prüfen, ob die Business-Partner-Verknüpfung vorhanden ist.

Technisch erfolgt die Umstellung auf den Business Partner im ERP-Release über die Customer-Vendor-Integration (CVI). Diese verknüpft den Business Partner mit den Kreditoren- und/oder Debitoren-Stammsätzen. Bei der initialen Umstellung wird der Business Partner über die CVI erzeugt, im laufenden Betrieb hält die CVI die Grunddaten zwischen Business Partner und Kunde/Lieferant synchron.

Daten bereinigen

Im Zuge der Einführung des Business Partner ist ein umfassendes Data Cleansing ein sinnvoller Schritt. Bestimmte Bereinigungen müssen ohnehin durchgeführt werden, um den Business Partner erzeugen zu können. Inkonsistenzen treten beispielsweise bei Kunden- und Lieferantendaten auf, die längere Zeit nicht geändert wurden, da sich in der Zwischenzeit Validierungen oder Pflichtfelder geändert haben können. SAP liefert eine Transaktion aus, welche die häufigsten Inkonsistenzen analysiert. Sie lässt sich über die SAP Note 2743494 einspielen. Optional ist außerdem eine Dublettenprüfung zu empfehlen, die Dubletten können im Zuge des Cleansing-Projekts bereinigt werden.

Universal Journal statt anwendungsspezifischer Tabellen

Der umfangreichste Teil der Umstellung auf SAP S/4HANA ist die Finance Conversion. Im Finanzbereich gibt es erhebliche Unterschiede im Datenmodell zwischen dem ERP-Release und SAP S/4HANA. Aufgrund der Funktionalität der HANA-Datenbank werden die Summentabellen der einzelnen Anwendungen nicht mehr benötigt und entfallen. Weiterhin werden verschiedene Teilanwendungen wie FI-AA, CO etc., die in der Vergangenheit eigene (Teil-)Tabellen hatten, im Universal Journal (ACDOCA) zusammengeführt. Darunter ist eine gemeinsame Einzelpostentabelle zu verstehen.

Mit dieser Umstellung gehen bestimmte Migrationstätigkeiten, Prüfungen vor dem eigentlichen Upgrade und Änderungen im Customizing einher. Verschiedene Prüfroutinen in der Preparation Phase betreffen beispielsweise das Customizing und Dateninkonsistenzen. Nach dem technischen Upgrade stehen noch die eigentlichen Conversion-Aktivitäten an.

Ablauf der Finance Conversion

Die vorbereitenden Maßnahmen für die Finance Conversion sind das Prüfen der relevanten Simplification Items, das Korrigieren von Dateninkonsistenzen – prominentes Beispiel ist der Abgleich zwischen Summentabellen und Einzelposten – und das Untersuchen der Konsistenz im Customizing. Über Prüf- und Korrekturreports können Inkonsistenzen bereits vor dem Upgrade identifiziert und korrigiert werden. Aber auch „Housekeeping“-Aktivitäten sind vor der Conversion sinnvoll – zum Beispiel die Archivierung von Daten oder das Löschen nicht mehr benötigter Buchungskreise.

Die eigentliche Finance Conversion startet nach dem technischen Upgrade. Zunächst müssen hierbei einige Customizing-Einstellungen für die Conversion erfolgen. Exemplarisch seien hier die Einstellungen für die Migration des Hauptbuchs, der Anlagenbuchhaltung, des CO, des Material Ledger und des Credit Managements genannt. Üblicherweise erfolgt das Customizing im Zuge der ersten Testumstellung und wird dann in die Folgesysteme transportiert.

SAP S/4HANA setzt auf der neuen Anlagenbuchhaltung auf, die im Zuge der Conversion eingeführt werden kann. In früheren SAP S/4HANA-Releases war außerdem die Nutzung des neuen Hauptbuchs (New GL) eine verpflichtende Voraussetzung für die Migration. Mittlerweile ist es aber in bestimmten Szenarien möglich, vom klassischen Hauptbuch direkt auf SAP S/4HANA zu migrieren Die Bedingung dafür ist, dass Unternehmen weder die Belegsplit-Funktionalität noch parallele Ledger nutzen. In diesem Fall entfällt der Zwischenschritt der Umstellung auf das New GL, sodass die Funktionalität nachträglich in SAP S/4HANA eingeführt werden kann.

Kreditmanagement in FI-AR wird mit SAP S/4HANA nicht mehr unterstützt

Historisch gibt es in der SAP-Welt zwei Lösungen für das Kreditmanagement: FI-AR Credit Management und SAP Credit Management/Financial Supply Chain Management (FSCM). SAP S/4HANA unterstützt das FI-AR Credit Management nicht mehr. Stattdessen setzt SAP hier auf die neuere Lösung, die auch auf dem Business Partner basiert. Die Umstellung auf das SAP Credit Management ist im Zuge der SAP S/4HANA Conversion möglich. Allerdings müssen Unternehmen berücksichtigen, dass SAP S/4HANA lizenztechnisch nur eine Basisversion von SAP Credit Management umfasst. Darin sind etwa die Kalkulationsfunktionalitäten, die Kreditlimits auf der Basis von Formeln automatisch berechnen, nicht enthalten.

Auswirkungen auf den Custom Code

Ein weiterer Aspekt mit hoher Relevanz ist die Überprüfung der Kompatibilität des Custom Code mit SAP S/4HANA. Anpassungen im Datenmodell mit S/4HANA bringen gegebenenfalls die Notwendigkeit mit sich, die eigenen Z-Programme entsprechend anzupassen. Vorbereitend dazu sollten Unternehmen frühzeitig ermitteln, welche Programme nicht mehr erforderlich sind. Das funktioniert über die Aktivierung des Usage & Procedure Logging im System. Es läuft über einen bestimmten Zeitraum im Hintergrund und erkennt, welche Programme wie oft ausgeführt werden.

Die Custom-Code-Prüfung kann wahlweise bereits vor dem Upgrade oder erst im eigentlichen SAP S/4HANA-Projekt erfolgen. Ein zentrales Prüfsystem unterstützt die Code-Anpassung und ermöglicht, die SAP S/4HANA-Kompatibilität bereits vor dem Upgrade im ERP zu prüfen.

GUI, WebDynpro oder Fiori?

Damit die System Conversion auf SAP S/4HANA erfolgreich verläuft, sollten Unternehmen vorab festlegen, in welchem Umfang sie die moderne UI-Technologie SAP Fiori nutzen möchten. Grundsätzlich gibt es keine zwingende Notwendigkeit, komplett auf SAP Fiori umzustellen, da die meisten SAP GUI- und WebDynpro-Anwendungen weiterhin nutzbar sind. Deren Look-and-feel wird sogar mit dem Fiori Visual Theme farblich angeglichen.

Außerdem gilt es zu beachten, dass Fiori-Apps die bestehenden GUI-/WebDynpro-Anwendungen nicht 1:1 ersetzen. Vielmehr werden manche SAP GUI-Transaktionen in mehrere Fiori-Apps aufgeteilt. Umgekehrt fasst SAP auch bestimmte GUI-Transaktionen in einer Fiori-App zusammen und integriert einige neue Funktionalitäten.

Fiori-Apps bringen eine grundlegende Umstellung der Anwendung mit sich und haben in der Regel einen starken analytischen Fokus. Mit ihrer Bedienfreundlichkeit schaffen die Fiori-Apps einen zusätzlichen Mehrwert für den Fachbereich. Es ergibt daher durchaus Sinn, im Zuge der SAP S/4HANA-Conversion ausgewählte Fiori-Apps zu aktivieren. Nach der Umstellung können Unternehmen die Fiori-Nutzung dann sukzessive ausbauen. Die Fiori Apps Library liefert dafür einige Anregungen.

Was die benötigte Infrastruktur angeht, haben sich die Deployment-Optionen für Fiori-Apps im Laufe der Zeit etwas gewandelt. Die Apps laufen auf dem Fiori-Frontend-Server (SAP Gateway), der in der Vergangenheit häufig auf einem separaten System installiert wurde. Inzwischen geht die Empfehlung in den meisten Fällen jedoch dahin, den Fiori-Frontend-Server auf dem SAP S/4HANA-System mitlaufen zu lassen. Dieses Embedded Deployment führt zu einer Vereinfachung der Systemlandschaft.