Vorgehensweise für eine qualitätsgesicherte Datenmigration

Eine Systemumstellung bedeutet jedoch in aller Regel, dass sich die Informations- und Datenarchitektur ändert [2]. Dies betrifft nicht nur die Definition der Datenobjekte (beispielsweise die Zusammenführung von Kunden und Lieferanten zu einem „Geschäftspartner“) und die Struktur der zugrunde liegenden Objekttabellen, sondern auch die Modellierung einzelner Informationen in entsprechenden Feldern [3]. Die vorhandenen Daten können meist nicht 1:1 kopiert werden, schon gar nicht ungeprüft. So wird jede ERP-Umstellung zwangsläufig zu einem grundlegenden Wissens-Transformationsprojekt.

Unbestritten bilden ERP-Systeme das zentrale Nervensystem jedes Unternehmens. Sie stellen Usern und Prozessen sämtliche Informationen zur Verfügung, die für die Durchführung und die Steuerung von Geschäftsprozessen benötigt werden – für die tägliche Auftragsabwicklung ebenso wie für Auswertungen und Berichte [1]. Eine Systemumstellung bedeutet jedoch in aller Regel, dass sich die Informations- und Datenarchitektur ändert [2]. Dies betrifft nicht nur die Definition der Datenobjekte (beispielsweise die Zusammenführung von Kunden und Lieferanten zu einem „Geschäftspartner“) und die Struktur der zugrunde liegenden Objekttabellen, sondern auch die Modellierung einzelner Informationen in entsprechenden Feldern [3]. Die vorhandenen Daten können meist nicht 1:1 kopiert werden, schon gar nicht ungeprüft. So wird jede ERP-Umstellung zwangsläufig zu einem grundlegenden Wissens-Transformationsprojekt.

Eine Datenmigration ist keine IT-Aufgabe

Weil es um Inhalte und fachliches Wissen geht, muss die Verantwortung für die Aufbereitung und Bereitstellung der Altdaten zwangsläufig bei den Fachbereichen liegen. Leider werden diese meist nur so weit eingebunden, wie es um prozessuale bzw. funktionale Anforderungen und deren Umsetzung in Prozessen und Workflows geht. Im Detail auf die Informations- und Datenbasis für einen reibungslosen und fehlerfreien Prozessablauf einzugehen, sie zu dokumentieren und zu hinterfragen, wird oft als überflüssig oder zu umständlich abgetan. Genau daraus resultieren aber zahlreiche fachliche Probleme, Verzögerungen und Mehraufwände in nahezu jedem ERP-Projekt.

Datenmigration: wie der Umzug in ein neues Haus

Die oft bemühte Analogie zu einem Umzug liegt auf der Hand: Das neue Haus ist anders als das alte. Es bietet andere Räume, andere Aufteilungen und andere Möglichkeiten, es einzurichten. Kaum jemand würde einen Umzug beginnen, ohne zuvor die wichtigsten Räume und Möbel auszumessen. Und sicherlich auch nicht, ohne den „Altbestand“ an Gegenständen zu sichten und zu sortieren. Übertragen auf die Datenmigration liegen hier die beiden größten Herausforderungen: Selektion und Mapping.

Bei der ersten Herausforderung geht es um inhaltliche Entscheidungen und Qualität. Sie bestimmt maßgeblich den Vorbereitungs- und Umsetzungsaufwand. Der erste Teilaspekt ist die Selektion nach Relevanz: Was wird überhaupt migriert? Welche Datensätze sind „aktiv“ und sollen auch künftig zur Verfügung stehen, und welche sind „inaktiv“, können also getrost mit dem Altsystem archiviert werden? Diese Entscheidung hängt von zahlreichen Faktoren ab, zum Beispiel: Wann wurde ein Artikel letztmalig bestellt? Gibt es noch Bestand? Wird der Artikel noch in Stücklisten verwendet? Muss er vielleicht als Ersatzteil für den Service vorgehalten werden? Ohne systematische Analyse sind diese Fragen nicht zu beantworten. Und leider wird – oft entgegen dem Ergebnis der Analyse – einfach „alles“ migriert aus Angst, irgendwelche Informationen zu verlieren. Wie eben bei einem Umzug, wo viele Kisten für weitere Jahrzehnte ungenutzt im Keller verstauben.

Der zweite Teilaspekt der Selektion ist die Prüfung und Aufbereitung der vorhandenen Daten. Nachdem zuvor festgelegt wurde, was zu migrieren ist, kann anhand von Datenqualitätsregeln geprüft werden, welche dieser Daten unvollständig, falsch oder nicht mehr aktuell sind. Entsprechende Datensätze sollten frühzeitig ergänzt oder überarbeitet werden, um sie korrekt zu migrieren und künftig besser mit ihnen arbeiten zu können.
Die zweite Herausforderung der Datenmigration fordert neben fachlichen Kenntnissen auch IT-Verständnis, ohne jedoch eine Aufgabe für die IT zu sein. Es ist unverzichtbar, den vorhandenen Datenbestand systematisch zu erfassen und mit Möglichkeiten und Restriktionen des Zielsystems abzugleichen. Dies geschieht auf drei Ebenen: Objekte bzw. Tabellen von Quell- und Zielsystem werden gegenübergestellt (gewissermaßen die „Räume“). Auf Feldebene werden die Definitionen und Metadaten der Felder verglichen (die „Abmessungen“ der Gegenstände). Und schließlich sollten sogar die Werte der einzelnen Felder überprüft werden, denn erfahrungsgemäß beinhalten insbesondere Freitextfelder eine Vielzahl an Informationen, die bestenfalls zerlegt und im Zielsystem dedizierten Feldern zugeordnet werden (gewissermaßen der „Schubladeninhalt“).

Es geht um nichts weniger als das gesamte gespeicherte Wissen des Unternehmens

Wie beim Umzug geht es bei der Datenmigration darum, sämtliche über Jahre und Jahrzehnte zusammengetragene Gegenstände bzw. Informationen adäquat zu bewerten, zu sortieren, instand zu setzen und verlustfrei in eine neue Umgebung zu transportieren. Nicht selten treten dabei im Projekt unerwartete oder vergessene Dinge zutage, manchmal sogar Parallel- und Schattensysteme, die ebenfalls entscheidende und relevante Informationen und Daten enthalten und während der Migration integriert werden müssen. Der Aufwand, nahezu das gesamte explizite Wissen verarbeiten zu müssen, sollte keinesfalls unterschätzt werden.

Weitere Komplexität gewinnt die Datenmigration durch die Tatsache, dass im Rahmen der Transformation die Einführung neuer Konzepte möglich oder sogar notwendig wird. Die Ablösung historischer Zahlungsbedingungen, die Zusammenführung unterschiedlicher Warengruppen-Systematiken oder die Umstellung auf nichtsprechende Artikelnummern sind nur einige Beispiele, die die Vielfalt und Tragweite der konzeptionellen Änderungen verdeutlichen.

Der Übertragungsweg der Daten

Die Aufgabe der Datenmigration ist es, Daten aus einer oder mehreren Datenquellen in ein Zielsystem zu übertragen. Dazu wird eine klassische ETL-Strecke genutzt: vom Export der Daten aus den Quellen, der Transformation und Bereitstellung bis zum Import, dem sogenannten Load.

In aller Regel wird der Import in das Zielsystem vom Anbieter oder Implementierungspartner des (ERP-) Systems vorgenommen. Um eine reibungslose und effiziente Abarbeitung zu ermöglichen, nutzen die meisten Anbieter für jedes einzelne Datenobjekt vordefinierte und standardisierte Dateiformate bzw. Datensatzstrukturen (Schema), auf die die Importroutinen und -programme abgestimmt sind. Diese mit Daten befüllten Dateien werden meist „Load Files“ genannt. Sie enthalten meist nur die zu im-portierenden Daten des jeweiligen Datenobjektes in der geforderten Struktur. Aufgrund ihrer leichten Verarbeitbarkeit werden überwiegend TXT-, CSV- oder XLS-Formate genutzt.

Leer, also ohne mit Daten befüllt zu sein, werden diese Dateien vielfach als „Templates“ bezeichnet. Sie enthalten in der Regel außer dem zu befüllenden Schema die notwendigen Datensatz- und Feldbeschreibungen mit deren Metainformationen (z. B. Datentypen und Feldlängen), in Einzelfällen auch Beispieldatensätze im vorgegebenen Schema.

Die Spezifikation der Templates definiert somit die formalen Anforderungen an die Datenbereitstellung und ist der entscheidende „Übergabepunkt“ der Datenmigration. Formale Fehler der angelieferten Daten (z. B. Datentyp- oder Formatfehler) führen im Allgemeinen zu Fehlern beim Import oder sogar zu dessen Abbruch.

Die Überwindung der Migration Gap

Die Verantwortung, die Daten für den Import im geforderten Schema bereitzustellen, liegt in der Regel ausschließlich beim Anwenderunternehmen. Während der Export der Daten noch als klassische IT-Aufgabe gelten kann, ist deren Transformation meist eine ungewohnte Herausforderung. Bereits das Profiling, also die systematische Analyse und Qualitätssicherung der vorhandenen Daten, ist methodisch anspruchsvoll und, sofern dem Unternehmen keine erfahrenen Datenexperten zur Verfügung stehen, nicht alltäglich.

Mit der umfangreichen Aufbereitung und strukturellen Transformation der Daten auf Feld- und Werte-Ebene lastet ein großer Teil des Projektrisikos auf den Fachbereichen, die diese Aufgabe häufig unvorbereitet, ohne ausreichende methodische Unterstützung und unter Zeitdruck bewältigen müssen („migration gap“, siehe Bild 1).