Kontakt
- Let’s connect!
- +49 931 784957-25
- hello@ososoft.de
- Kontaktformular
18.03.2021 | Fabian Ott
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.
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.
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.
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:
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.
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:
Für integrative Tests oder ähnliches kann auch zusätzlich ins Q-System migriert werden.
Mit dem Migrationsteam steht und fällt eine S/4HANA Migration. Folgende Rollen wirken mindestens für eine Migration mit:
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.
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.
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.
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:
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.
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.
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.
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!