Migration von Daten und Beständen in SAP-Projekten

Wo fängst du an? Was gehört alles in dein Migrationskonzept? Wie möchtest du die Migration durchführen? Keine Panik, ich habe dir die wichtigsten Punkte zusammengefasst und strukturiert.

Bevor du dein Migrationskonzept erstellst, solltest du dir einen guten Überblick über die vorhandene Systemlandschaft und IT-Infrastruktur verschaffen. Du brauchst diese Informationen, damit du die zu migrierenden Daten identifizieren kannst und auch weißt, woher und über welche Schnittstelle du diese bekommst. Vielleicht gibt es in deinem Unternehmen dazu schon eine gute Dokumentation? Falls nicht, erstelle dir eine. Das kann eine simple Abbildung wie diese sein. Details kannst du nach und nach ergänzen.

Folgende Fragen kannst du dir stellen:

• Gibt es alte Systeme, die abgelöst werden sollen?
• Wie sehen die Schnittstellen aus? In welche Richtung?
• Welche Technik steckt hinter den Schnittstellen?
• Für Welche Systeme gibt es auch Entwicklungs- und Testsysteme?
• Gibt es ein Schulungssystem, eine Sandbox oder sogar ein eigenes SAP-System für die Migration?
• Welche IT-Systeme stehen bei euch, welche im Rechenzentrum?
• Welche Anbindung (MBit)?

Danach verschaffst du dir einen Überblick über deine Stakeholder. Wer ist alles im Projekt beteiligt? Die Fachbereiche können dir die Prozesse und Migrationsobjekte benennen. Die IT unterstützt dich bei der Beschaffung und Aufbereitung der Daten. Wenn du einige Systeme nicht im eigenen Hause betreibst, brauchst du auch einen guten Kontakt zum Rechenzentrum. Die Revision unterstützt dich später bei der Prüfung der migrierten Daten und bei der Abnahme.

Gibt es deinem SAP-Projekt eine Prozessdokumentation der Ist- und Soll-Prozesse? Falls nicht, gibt es vielleicht gute Business Blueprints, Schulungsunterlagen oder einen gut dokumentierten Testkatalog? Die Prozesse “Material anlegen” und “Rechnung buchen” weisen bspw. auf die Migrationsobjekte “Material” und “Rechnung” hin.

Mit all den gesammelten Informationen kannst du ableiten, welche Daten migriert werden müssen. Ich zeige dir im Folgenden ein paar Beispiele für Stammdaten, Bestände und Bewegungsdaten aus den Bereichen Logistik, Einkauf, Verkauf, Finanzwesen und Controlling. Mir hat es immer geholfen, zusätzlich ein Mengengerüst der Daten abzuschätzen. Damit kannst du den Aufwand und die Migrationszeiten später besser abschätzen. Beachte bitte auch die gesetzlichen Aufbewahrungsfristen (bspw. 10 Jahre). Wird das Altsystem später noch mit lesenden Berechtigungen zur Verfügung gestellt? Wenn nicht, musst du diese Altdaten ggf. in die neue Systemlandschaft übernehmen.

Beispiele für Stammdaten aus den Bereichen Logistik (LO), Einkauf (MM), Verkauf (SD), Finanzwesen (FI) und Controlling (CO).

Für deine Materialien existieren im alten Warenwirtschaftssystem auch Bestände, welche du auch migrieren möchtest? Sprich mit deinen Fachbereichen, welche Bestände migriert werden sollen. Sind die Bestände bewertet? Mit einem gleitenden Durchschnittspreis (GLD) oder einem Standardpreis? Sind unter deinen Beständen auch Chargen? Beispielsweise die am 01.06.2018 produzierten Joghurtbecher auf der Maschine 4711? Oder sind deine Materialien vielleicht sogar serialisiert? Beispielsweise hat das Navigationsgerät die Seriennummer 467295737. Eine Bestandsmigration wird oftmals zusammen mit einer Inventur durchgeführt. Was gibt es für einen besseren Zeitpunkt, als mit einem neuen IT-System auch direkt mit sauberen Beständen in die Zukunft zu starten. So eine Stichtagsinventur ist oftmals ganz schön aufwendig und zeitintensiv. Dies wird später noch wichtig, wenn du alle Migrationsobjekte identifiziert hast und dir Gedanken über das generelle Vorgehen machst.

Beispiele für Bewegungsdaten aus den Bereichen Einkauf (MM), Verkauf (SD) und Finanzwesen (FI).

Für die Migration verwenden wir einen Prozess, der eher aus dem Umfeld Business Intelligence oder Data-Warehouse bekannt ist: Extraktion, Transformation und Laden (ETL). Die zu migrierenden Daten werden aus verschiedenen Quellen extrahiert (bspw. aus dem alten Warenwirtschaftssystem), in das gewünschte Format transformiert und danach in das Zielsystem (SAP) geladen. Weitere Informationen zum ETL-Prozess kannst du auf Wikipedia nachlesen.

Die Migration sollte ganz eng mit dem Cut-over-Manager abgestimmt werden. Einige Aktivitäten der Migration starten ggf. schon sehr lange vor dem Go-Live des Projekts. Vielleicht kannst du einige Daten, die sich nicht mehr oder kaum noch ändern, vorab migrieren? Wenn du Hilfe bei der Erstellung eines Cut-over-Plans brauchst, empfehle ich dir meine Beiträge Detaillierter Cut-over-Plan mit Microsoft Excel und Einen Cut-over-Plan managementtauglich darstellen. In den detaillierten Cut-over-Plan kannst du bspw. die folgenden Aktivitäten eintragen:

• Vorbereitungen durch Fachbereiche, bspw. Sicherheitsbestände aufbauen
• Inventur zum Stichtag
• Entwicklungsstopp
• Keine Warenbewegungen zu einem bestimmten Zeitpunkt
• Keine offenen Belege zu einem bestimmten Zeitpunkt
• …

Bevor du mit dem ETL-Prozess startest, kannst du die Datenqualität im alten System prüfen und vorab bereinigen:

• Sind alle Pflichtfelder gefüllt
• Stichproben, ob alle Felder korrekt gepflegt sind bspw. bei Kreditoren die Straße und Hausnummer in einem Feld statt in zwei Feldern
• Fehlerhafte Daten korrigieren
• Redundante Daten zusammenführen
• Daten Archivieren, bspw. alte Materialstammdaten ohne Bestände, die nicht mehr benötigt werden

Für die Extraktion aus den alten Systemen benötigst du Programme und Schnittstellen. Möglicherweise gibt es diese bereits, ansonsten lasse den Programmieraufwand schätzen und plane die Entwicklung der Programme ein. Prüfe neben den Migrationsobjekten auch, ob es Programme zur Extraktion der Bestände gibt. Ein typisches Format für den Output sind CSV-Dateien.

Für die Transformation der Daten empfehle ich dir, Mapping-Tabellen anzulegen. Definiere die Tabellen und Felder des Quell- und Zielsystems und stelle Transformationsregeln auf:

Beispiele für Transformationsregeln:

• Datumsformat 2018-06-01 nach 20180601
• Groß- und Kleinschreibung
• Datentyp INT in CHAR
• Datensatz vorne oder hinten mit 0en auffüllen
• Ein Präfix setzen
• Felder mit Festwerten/Konstante füllen (bspw. Auftragsart immer TA)
• Steuerkennzeichen alt/neu
• Sachkonten alt/neu Statt 1-zu-1 auch möglich, dass mehrere Konten aus Alt-System in ein Konto SAP überführt werden, oder umgekehrt.
• Kumulierte Werte oder einzelne Buchungen?

Für das Laden der Daten in das SAP-System gibt es mehrere Möglichkeiten. Mit SAP S/4HANA steht dir das Migration Cockpit zur Verfügung. Mit SAP ECC kannst du das Tool LSMW (Legacy System Migration Workbench) verwenden, um strukturierte Daten (bspw. CSV-Dateien oder IDocs) zu importieren. Oder du lässt dir entsprechende Reports in SAP direkt entwickeln.

Achte beim Datenimport auf die Reihenfolge. Du brauchst zum Beispiel zunächst die Stammdaten, bevor du die Bestände oder Bewegungsdaten migrieren kannst. Es kann von Vorteil sein, wenn du deine Daten in mehrere “Happen” aufteilst. Bestände kannst du bspw. je Standort (Werk/Lagerort) aufteilen und Stück für Stück migrieren. Dadurch hast du gleich zwei Vorteile: du kannst jeden migrierten Datenhappen direkt prüfen und somit Fehler frühzeitig erkennen. Zudem kannst du Zeit durch Parallelisierung einsparen.

In meinen Migrationsprojekten hat es sich immer als Vorteil erwiesen, den ETL-Prozess zu mehreren Zeitpunkten im Vorfeld durchzuspielen. Wichtig ist, dass du einen repräsentativen Querschnitt deiner Daten getestet hast. Ziel ist dabei nicht nur Fehler aufzudecken, sondern auch die Laufzeit einschätzen zu können (Performancetests). “Reich die Nacht aus” – könnte dich der Cut-over-Manager fragen 😉 Im besten Fall hast du natürlich alle Daten im Vorfeld zum Test migriert, wenn es der Zeitplan und das Budget zulassen. Sind die Testdaten migriert und verfügbar, übergibst du diese an das Testteam (Integrationstest). Funktionieren die neuen Prozesse auch mit den migrierten Daten? Das ist nicht selbstverständlich. Möglicherweise hast du Felder nicht oder fehlerhaft migriert, die in den Prozessen benötigt werden. Unterstützen kannst du das manuelle Testen auch mit automatisierten ABAP Unit-Tests. Datensicherheit: Achtung bei personenbezogenen Daten. Diese müssen ggf. für einen Test unkenntlich gemacht werden. Es gibt eine Reihe an Tools, mit dessen Hilfe du die Daten für Testzwecke anonymisieren kannst.

Bei der quantitativen Datenprüfung vergleichst du die Summen aus dem alten mit dem neuen System. Hierdurch stellst du sicher, dass der Umfang der migrierten Daten korrekt ist. Beispiele:

• Anzahl der Bestellungen
• Bestände in Stück (ST) an einem Standort (Werk/Lagerort)
• Wert der Bestände
• Bilanz vor und nach der Migration

Für den Vergleich der Daten kannst du im SAP auf Standardreports zurückgreifen. Für die Bereiche Logistik und Vertrieb habe ich zwei Beiträge veröffentlicht: Logistik-Reports der SAP und Vertrieb-Reports der SAP.

Bei qualitativen Prüfungen pickst du dir einzelne Daten heraus und analysierst diese bis ins kleinste Detail. Suche dir beispielsweise drei Aufträge der Auftragsart Terminauftrag (TA) heraus, einer mit einem alten Belegdatum, einer in der Mitte und ein neuer Auftrag. Prüfe jetzt die Kopf- und Positionsdaten. Kannst du über den Belegfluss in die Lieferung und Faktura abspringen? Passen die Preise und Mengen? Sind die korrekten Materialien enthalten?