Die Migration auf ein S/4HANA System stellt in einem SAP Implementierungsprojekt immer eine große organisatorische und technische Herausforderung dar. Schematisch zeigt Ihnen das nachfolgende Schaubild den Ablauf einer Migration.

Dabei ist es zunächst unerheblich, ob von einem bestehenden R/3 System oder einem anderen ERP (z.B. einer AS400) migriert werden soll. Damit eine solche Migration gelingt, sollte man sich definitiv näher mit den nachfolgenden Themen im Rahmen einer Migration auseinandersetzen.

Kennen Sie das Kerngeschäft des Unternehmens

Im Vorfeld einer Migration ist es wichtig, sich mit dem Kerngeschäft des Unternehmens zu befassen, welches seine Daten migriert haben möchte. Es macht später einen Unterschied, ob beispielsweise ein Handelsunternehmen die Migration durchführt oder ein produzierendes Unternehmen. Handelt es sich beispielsweise um ein Produktionsunternehmen, muss zum Beispiel im Rahmen von Tests sichergestellt sein, dass migrierte Rohmaterialien am Ende auch auf Basis einer Stückliste für die Produktion von Halbfertigwaren oder Fertigwaren tatsächlich genutzt werden können.

Gewinnen Sie einen Überblick über die zu migrierenden Objekte

Sie sollten auf jeden Fall die wesentlichen zu migrierenden Objekte kennen. In der Regel lassen sich diese in folgende Gruppen unterteilen:

Hierzu ziehen Sie unbedingt die verantwortlichen Fachbereiche mit in die Analyse ein. Diese kennen das Kerngeschäft des Unternehmens am besten und können Ihnen in jedem Fall wertvolle Informationen liefern. Dazu gehören auch Abhängigkeiten zu anderen Objekten oder Mengengerüste. Nur wenn Sie diese Informationen möglichst vollständig gesammelt haben, haben Sie überhaupt erst die Möglichkeit einen vernünftigen Migrationsplan aufzustellen.

Stimmen Sie ab, welche Objekte wie zu migrieren sind

Grundsätzlich können Objekte auf zwei verschiedene Weisen migriert werden – technisch oder manuell. Manuell bedeutet, dass ein/e Mitarbeiter/in per Hand Objekte anlegen muss. Das ist sehr zeitaufwändig und zusätzlich fehleranfällig. Es empfiehlt sich daher dies nur bei Objekten mit geringem Mengengerüst in Betracht zu ziehen.

Die technische bzw. Tool-gestützte Migration ist jedoch der Regelfall. Hier bieten sich drei verschiedene Wege an:

  • Per ALE-Verteilung: die ALE-Verteilung erlaubt einen Stammdatenaustausch zwischen verschiedenen SAP Systemen.
  • SAP Migration Cockpit (LTMC): State-of-the-Art Tool für die Migration in ein S/4HANA Zielsystem ist das eigens entwickelte Migration Cockpit der SAP. Aufgerufen wird dies über die Transaktion LTMC.
  • Eigenentwicklung: gut geeignet sind ebenfalls eigenentwickelte Reports. In der Regel lesen diese eine CSV-Datei ein und spielen die Daten ins SAP. Hier ist ein ausgiebiger Test unerlässlich.

Weiterhin besteht auch noch die Möglichkeit zur Migration über die Legacy System Migration Workbench (Transaktion LSMW). Da diese speziell für die Migration jedoch durch die LTMC abgelöst wurde, wird sie in diesem Beitrag nicht näher betrachtet.

Migrationstests & -mandanten

Die Tool-gestützte Migration eines jeden zu migrierenden Objekts muss unbedingt im Vorfeld intensiv getestet werden. Damit sollen mögliche Fehlerquellen bei der tatsächlichen Migration ausgeschlossen werden. Idealerweise bereitet man hierfür auch unterschiedliche Mandanten vor. Wir empfehlen folgendes Setup:

  • Mandant Migrationsspielwiese: hier kann komplett frei experimentiert werden.
  • Mandant Migrationstest: hier werden iterativ Migrationstestläufe durchgeführt. Erst mit einem kleinen Mengengerüst (1-3 Sätze), dann etwas ausgeweitet (< 10 Sätze), dann in größerem Umfang (< 100 Sätze) und am Ende der vollständige Satz, welcher auch ins Produktivsystem laufen soll.
  • Mandant Produktivsystem: hier wird nach Abschluss aller Tests am Ende final migriert.

Für integrative Tests oder ähnliches kann auch zusätzlich ins Q-System migriert werden.

Verantwortlichkeiten & Aufgabenliste

Mit dem Migrationsteam steht und fällt eine S/4HANA Migration. Folgende Rollen wirken mindestens für eine Migration mit:

  • Migrationskoordinator/in: sie oder er hat alle Fäden der Migration in der Hand und muss stets wissen, wer aktuell an welchen Themen arbeitet.
  • CutOver-Team: das CutOver-Team ist für die Koordination der Umstellung von Altsystem auf das neue SAP System zuständig und bildet eine wichtige Schnittstelle zum Migrationsteam.
  • Fachbereich: der Fachbereich ist zuständig für alle fachlichen Fragen rund um die Migration und besteht i.d.R. aus Projektmitgliedern der Abteilungen Einkauf, Vertrieb, Produktion, Logistik, Finanzen und Controlling.
  • IT: die IT ist Ansprechpartner für alle technischen Belange und hauptverantwortlich für ausreichende Tests.
  • Anwender Altsystem: Anwender, die viel Know-how aus dem abzulösenden Legacy System mit bringen sind wichtig für jede Migration. Häufig können nur Sie die Daten aus den Systemen so rausziehen und aufbereiten, damit diese auch bei der Vorbereitung der Migration verwendet werden können.
  • Inventurleitung: Migrationen gehen häufig mit einer Inventur daher und sollten ebenso sorgfältig vorbereitet und durchgeführt werden.
  • Wirtschaftsprüfer: der Wirtschaftsprüfer muss das Migrationsvorgehen im Vorfeld vorgestellt bekommen, es freigeben und ist üblicherweise auch am Tag der Inventur vor Ort.

Alle umzusetzenden Aufgaben müssen auch konsequent und vollständig in einer ToDo-Liste erfasst und nachgehalten werden. Nur so ist garantiert, dass alle Entscheidungen dokumentiert sowie alle Aufgabe zugeordnet und abgearbeitet werden.

Migrationsplan

Mit den gesammelten Informationen lässt sich dann schließlich eine Migrationsplanung aufsetzen. Darin ist aufgeführt, wann welche Objekte migriert werden und welche Abhängigkeiten gegebenenfalls bestehen. Um beispielweise im QS-Umfeld einen WE-Prüfplan migrieren zu können, müssen zuvor unter anderem Prüfmethoden und Stammprüfmerkmale migriert worden sein.

Der Migrationsplan wird dann idealerweise vom Datum des Go-Live rückwärtsterminiert. Um den Plan nicht extrem aufzublähen, können auch je Teilprojekt sogenannte Schattenmigrationspläne aufgesetzt werden. Die darin aufgeführten  Detailschritte werden dann im jeweiligen Projekt umgesetzt. Das entzerrt den übergreifenden Migrationsplan deutlich.

Belegmigration

Bei der Belegmigration ist vor allem zu klären, welche Belege in welchem System noch bearbeitet werden. Beispielsweise ist es möglich ausgewählte Belege noch im Altsystem vollständig zu bearbeiten und erst ab einem gewissen Stichtag neue Belege auch erst im neuen System zu erfassen. Auf diese Weise ist der Migrationsaufwand so gering wie möglich. Dieses Vorgehen hängt natürlich immer stark vom Tagesgeschäft ab und kann nicht pauschalisiert werden – Sie wissen ja selten im Voraus wann z.B. Ihre Kunden Ihnen einen Auftrag schicken 😊

Man sollte sich auch Gedanken machen, ob alte, bereits bearbeitete Belege migriert werden müssen oder ob es genügt, im S/4HANA System nur mit neuen Belegen zu arbeiten. Legen Sie sich auch einen Plan für den Umgang mit Retouren zu Recht. Folgendes Beispiel hierzu: Sie haben einen Kundenauftrag noch vollständig aus Ihrem Altsystem (z.B. einer AS400) heraus bedient und abgerechnet. Nach einer Weile retourniert Ihr Kunde die Ware. Sie haben jedoch zwischenzeitlich Ihr Unternehmen mit dem S/4HANA System produktiv gesetzt. Wo und wie verarbeiteten Sie nun die Retoure? Auch hier gibt es keinen pauschalen Ansatz, sondern dies muss Ihren Systemgegebenheiten angepasst sein. Sprechen Sie also lieber im Vorfeld einmal mehr darüber.

Bestandsmigration

Die Bestandsmigration ist ein kritischer Punkt in einem SAP Implementierungsprojekt, findet dieser doch erst direkt vor dem Go-Live statt und erlaubt damit quasi keinen Spielraum für Fehler. Daher ist eine Detailplanung für genau die Tage der Migration von größter Bedeutung.

Wir empfehlen dies auch stundengenau zu planen und parallelisierbare Abläufe zu berücksichtigen. Dabei sind u.a. folgende Aspekte zu berücksichtigen:

  • Zeitpunkt der Bereitstellung der Downloads aus dem Altsystem
  • Zeitpunkt der Bereitstellung der Downloads aus dem SAP System
    Anmerkung: hiermit soll sichergestellt werden, dass beispielsweise alle zu migrierenden Materialien auch im SAP System angelegt sind
  • Information in das Unternehmen, dass keine Buchungen mehr im Altsystem durchgeführt werden dürfen, die Bestands- oder Wertänderungen nach sich ziehen
  • Migrationsablauf der Migration jeder Materialart: zählen, prüfen, ins Migrationsfile pflegen, migrieren, Mengen & Werte prüfen, neuetikettieren, ausbuchen der Bestände aus dem Altsystem

Zusätzlich finden sich noch weitere Schritte, die berücksichtigt werden müssen, wie das Öffnen & Schließen des Migrationsbuchungskontos (Bereich FI) oder der Berechtigungserteilung für den Migrationsuser (Bereich Berechtigungsmanagement). Diese können aber nur einen Ausschnitt der ToDos darstellen.

Ein ganz wesentlicher Aspekt der Bestandsmigration ist die Fragestellung, welche Materialien (bzw. Materialarten) mit welchen Preisen migriert werden. Werden diese mit dem Standardpreis (S-Preis), dem gleitenden Durchschnittspreis (GLD) oder ohne Wert migriert? Dazu können Ihnen die Kollegen aus den Abteilungen Finance & Controlling am besten weiterhelfen.

Sicherheitskopien

Vor jedem Go-Live sollten Sie noch eine Sicherheitskopie des letzten Systemstands anlegen. Sollte im Worst Case durch Ihre Migration etwas schief gehen, können Sie wieder auf den letzten Stand zurückdrehen und Ihr Vorgehen nochmal analysieren. Ein solches Szenario hätte voraussichtlich auch negative Auswirkungen auf den Go-Live. Testen Sie daher lieber einmal mehr und lieber etwas ausgiebiger.

Inventur & Wirtschaftsprüfung

Eine Bestandsmigration findet häufig im Zusammenspiel mit einer Inventur statt. Dann steht in der Regel der Betrieb still, es finden keine Buchungen statt und die Bestände bleiben unverändert. Machen Sie sich klar, was alles gezählt werden muss und das Differenzen ausgebucht werden müssen.

Keine Bestandsmigration ohne Wirtschaftsprüfer – das ist ein zentraler Aspekt bei der Migration. Sie als Unternehmen müssen sich attestieren lassen, dass die ins S/4HANA System migrierten Werte mit denen des Altsystems übereinstimmen. Sprechen Sie daher auch bereits ausreichend im Vorfeld der Bestandsmigration mit Ihrem verantwortlichen Wirtschaftsprüfer und lassen Sie sich das Vorgehen abnehmen. Nachträgliche Korrekturen sind immer unangenehmen und zeitraubend. Der Wirtschaftsprüfer ist mindestens am Tag der tatsächlichen Inventur im Haus und überwacht alle Vorgänge.

Fazit

Wenn Sie die oben genannten Schritte berücksichtigen, haben Sie gute Chancen auf eine erfolgreiche Migration. Sollten Sie Fragen haben oder konkrete Unterstützung bei der Migration benötigen, kommen Sie gerne auf unsere Experten bei der ososoft zu. Die ososoft hat zur Unterstützung von Migrationen mit dem S4T Business Partner Migrator und dem S4T WM to EWM Migrator auch eigene Tools entwickelt, die Sie bei der Umstellung unterstützen. Sprechen Sie uns jederzeit gerne darauf an!