Es gibt kaum ein Thema in ERP-Projekten, welches so ungern diskutiert wird wie das Thema Datenmigration / Datenübernahme (ich verwende beide Begriffe synonym). Nicht selten wirkt dieses Thema unübersichtlich und erschlagend, insbesondere in größeren Projekten. Dabei ist es nicht nur so, dass die meisten wissen, wie wichtig das Thema ist, sondern viele kennen auch ERP-Projekte, die allein aufgrund dieses Themas gescheitert sind. Aus diesem Grund soll dieser Beitrag dazu dienen, einige Ängste abzubauen, verschiedene Optionen aufzuzeigen und zu erklären, wann man welche Themen im Detail diskutieren und entscheiden sollte.
Was bedeutet Datenmigration?
Unter Datenmigration versteht man grundsätzlich den Prozess der Übertragung von Daten aus einem System in ein anderes. Im ERP-Kontext bedeutet dies, dass Daten nicht nur vom alten ERP-System, sondern gegebenenfalls auch aus verschiedenen anderen isolierten Systemen in das neue ERP-System migriert werden. Mit anderen Worten umfasst dieser Prozess sowohl den Datenexport aus den Quellsystemen – inklusive der gegebenenfalls notwendigen Datentransformationen – als auch den Import der Daten in das neue ERP-System (ETL-Prozess). Was sich in dieser Definition auf den ersten Blick wie eine stark technisch geprägte Aufgabe anhört, ist in der Praxis jedoch wesentlich komplexer und erfordert daher eine intensive Planung sowie strategisches Denken. Tatsächlich ist, nach meiner Erfahrung, der technische Part am Ende oft das weitaus kleinere Problem, da die eigentlichen Herausforderungen häufig in der Identifizierung aller wichtigen Daten und dem Erstellen des Konzepts liegen.
Datenarten in ERP-Systemen / Begriffsklärung
Die Daten, die in ERP-Projekten migriert werden, sind oft sehr vielfältig, lassen sich jedoch vor allem in einige wenige Kategorien unterteilen:
- Stammdaten: Diese Daten sind von zentraler Bedeutung für den Geschäftsbetrieb, da sie grundlegende Informationen wie Kunden-, Lieferanten- und Materialstammdaten umfassen. Ohne diese Basisdaten wäre es nahezu unmöglich, einen reibungslosen Ablauf der Prozesse im ERP-System sicherzustellen.
- Bewegungsdaten / Transaktionsdaten: Diese Daten umfassen Geschäftsvorfälle wie z.B. Bestellungen, Rechnungen, Aufträge und Fertigungsaufträge. Darüber hinaus beinhalten sie auch die komplexe Logik der Verkettung der Belege untereinander, wie beispielsweise Reservierungen und Buchungen, die eng miteinander verknüpft sind.
- Historische Daten: Diese Daten betreffen vergangene Geschäftstransaktionen, die für Analysen und rechtliche Anforderungen notwendig sind. Zu diesen Daten können jedoch auch solche gehören, die im neuen ERP-System für bestimmte Transaktionen verwendet werden. Ein Beispiel dafür sind historische Verkaufsmengen von Artikeln, die im neuen ERP-System, gerade im Zeitraum nach dem GoLive, die automatisierte Disposition steuern können.
- Konfigurationsdaten: Diese Daten dienen der Einrichtung des ERP-Systems und umfassen z.B. Kontenpläne, Zahlungsbedingungen oder Kalender. Oft wird der Bereich der Konfigurationsdaten jedoch auch in den Bereich der Stammdaten integriert, da sie in vielen Fällen eine vergleichbare Funktion im System erfüllen
Herausforderung bei der Datenmigration: Die Konzepterstellung
Theoretische Umsetzung der Migration
Das aus meiner Sicht größte Problem bei dem Thema Datenübernahme ist, dass Sie als Kunde das neue ERP-System noch nicht kennen und der Anbieter Ihr Altsystem nicht in seiner ganzen Komplexität einschätzen kann (und oft auch nicht will). Dennoch wird erwartet, dass beide Seiten sich frühzeitig zusammensetzen, um entsprechende Strategien für eine erfolgreiche Migration zu vereinbaren. Schließlich geht es hierbei nicht nur um den Projektzeitplan, der unbedingt eingehalten werden muss, sondern auch um Themen wie Verantwortung und Budget.
An dieser Stelle möchte ich Ihnen vorschlagen, sich das Thema Datenmigration als ein Buch vorzustellen. Zu einem bestimmten Zeitpunkt im Projekt müssen bestimmte Kapitel dieses Buches bereits fertiggestellt sein. Zu Beginn des Projektes, idealerweise schon direkt innerhalb der ERP-Auswahl, befasst man sich daher mit dem Inhaltsverzeichnis, also mit der grundlegenden Struktur des Buches, anstatt hektisch zu versuchen, einzelne Kapitel vorzeitig zu beenden. Ich persönlich gliedere ein Migrationskonzept daher in Teile, Kapitel und Abschnitte. Diese Struktur hilft dabei, den Überblick zu behalten und sicherzustellen, dass alle relevanten Themen im richtigen Zeitpunkt adressiert werden.
Beispiel
Verdeutlichen wir es mal an einem Beispiel:
Teil |
Kapitel |
Abschnitt |
|
1 Stammdaten |
1.1 Artikel |
1.1.1 |
Generelle Strategie zur Artikelübernahme |
1.1.2 |
Generelle Artikelinformationen |
||
1.1.3 |
Artikeleinheiten |
||
1.2 Debitoren |
1.2.1 |
Generelle Strategie zur Debitorenübernahme |
|
1.2.2 |
Generelle Debitorinformationen |
||
1.2.3 |
Debitorenpreislisten |
||
2 Bewegungsdaten |
2.1 Offene Aufträge |
2.1.1 |
Generelle Strategie zur Übernahme offener Aufträge |
|
2.1.2 |
Abgrenzung der zu übernehmende Aufträge |
|
|
2.1.3 |
Mengengerüst |
|
|
2.1.4 |
Auftragsarten |
|
|
2.2 Offene Fertigungsaufträge |
2.2.1 |
Generelle Strategie zur Übernahme offener Fertigungsaufträge |
|
2.2.2 |
Mengengerüst |
|
|
2.2.3 |
Übernahme der Reservierungen zwischen Fertigung und Vertrieb |
|
|
2.2.4 |
Auftragsarten |
|
3 Historische Daten |
3.1 Beendete Fertigungsaufträge |
||
|
3.2 Historische Artikelumsätze |
Sie sollten nun eine klare Vorstellung davon haben, wie ein gutes Datenübernahmekonzept aufgebaut sein sollte. In diesem Konzept empfehle ich, nicht nur die Daten aufzunehmen, die (teil)automatisiert übernommen werden sollen, sondern auch diejenigen, die beispielsweise vor dem Echtstart manuell eingegeben werden müssen – eine gängige Vorgehensweise bei offenen Aufträgen. Ziel ist es, dass das Migrationskonzept sowohl vollständig als auch verständlich ist. Letztlich sollten alle Keyuser und Stakeholder in der Lage sein, das Konzept zu lesen, zu verstehen und es entsprechend auch kritisch zu hinterfragen. Wir verzichten an dieser Stelle also bewusst (und hoffentlich auch an allen anderen Stellen) auf eine übertrieben akademische Ausdrucksweise, um die Verständlichkeit zu fördern und sicherzustellen, dass alle Beteiligten das Konzept effektiv nutzen können.
Technische Umsetzung der Migration
In der oben genannten Auflistung finden Sie bisher noch keine Hinweise zur technischen Umsetzung der Migration. Dies hat zwei wesentliche Gründe:
- Erstens befinden wir uns je nach Projekt entweder gerade in der ERP-Auswahl oder zumindest noch sehr früh im Projekt. Die konkreten technischen Umsetzungen spielen an der Stelle noch keine Rolle und Sie sollen sich hier auch nicht in Details verlieren. Meiner Meinung nach reicht es an diesem Punkt aus, zunächst die Teile und Kapitel des „Buches“ zu erstellen. Zu den wichtigsten Kapiteln sollte außerdem zusätzlich eine grobe Ermittlung des Mengengerüsts erfolgen. Daraus lässt sich dann sehr gut ableiten mit welchem groben Umfang man im Bereich der Datenübernahme zu rechnen hat. Es ist übrigens kein Problem, für das vorläufige Konzept – das im Verlauf des Einführungsprojekts sicherlich noch angepasst wird – das Wording aus dem Altsystem zu verwenden. Dadurch wird es einfacher, diese Aufgabe zu bewältigen.
- Die technische Umsetzung, also die Feinspezifikation der einzelnen Übernahmen, sollte in einem separaten Dokument untergebracht werden, denn die technische Beschreibung mit Tabellen, Schlüsselfeldern und Feldnamen beeinträchtigt die Lesbarkeit des Migrationskonzepts immens.
Migrationsverantwortung im ERP-Projekt
Zu dem Thema Verantwortung sei gesagt, dass es grundsätzlich notwendig ist, die Verantwortung vor Projektstart sauber zu klären, und zwar am besten anhand einer RACI-Matrix, oder oder einer ähnlichen Methode. Das folgende Beispiel verwendet dabei lediglich den Buchstaben V für Verantwortlich, sowie den Buchstaben U für Unterstützung.
Kunde | ERP-Anbieter | |
Erstellung Datenmigrationskonzept | U | V |
Vorab Datenbereinigung im Altsystem | V | |
Datenexport aus Altsystem | V | |
Datenübernahme in das Testsystem | V | |
Überprüfung der übernommenen Daten im Testsystem | V | U |
Freigabe der Datenübernahme in das Testsystem | V | |
Durchführung Stammdatenübernahme für Integrationstests | V | |
Durchführung Bewegungsdatenübernahme für Integrationstests | V | |
Datenübernahme Stammdaten in das Produktivsystem | V | |
Datenübernahme Bewegungsdaten in das Produktivsystem | V | |
Überprüfung der übernommenen Daten im Produktivsystem | V | U |
Freigabe der Datenübernahme in das Produktivsystem | V | |
Manuelle Datenübernahmen, Fehlerbearbeitung und nachträgliche Datenpflege | V | U |
Der Vorteil einer solchen Matrix ist, dass Missverständnisse bzgl. der Zuständigkeiten sehr früh geklärt werden können und sich dadurch nicht durch das gesamte weitere Projekt ziehen. Die obige Liste kann natürlich noch weiter ausgebaut werden.
Prinzipiell sollte eine derartige Matrix, egal ob nach RACI, DEMI oder einem anderen System, für alle Bereiche des ERP-Projekts erstellt und als Vertragsbestandteil aufgenommen werden. Denn eine klare Struktur der Aufgaben und Verantwortlichkeiten verbessert die Kommunikation und Zusammenarbeit aller Beteiligten.
Nächste Schritte im Projekt und Einbindung in den Projektplan
Wie wir bereits festgestellt haben, wird die erste Version des Migrationskonzepts sehr früh im Projekt erstellt. Um in der Buchmetapher zu bleiben: es wird zunächst sichergestellt, dass das Inhaltsverzeichnis vollständig ist. An der Stelle sollte man sich den Stand des Konzepts schon mal „absegnen“, bzw. freigeben, lassen, indem man das Konzept allen Keyusern zur Verfügung stellt und ihre Fragen und Anregungen erwartet. Dies ist wichtig für den weiteren Verlauf, denn ich möchte nicht ständig die Buchstruktur ändern, wenn ich anfange die Kapitel meines Buches zu schreiben. Es wird in der Praxis natürlich vorkommen, dass noch weitere Themen auffallen, die berücksichtigt werden müssen, aber es sollte sich dabei trotzdem um Ausnahmen handeln.
Parallel zum weiteren Projektverlauf arbeiten Ihre Keyuser mit den Beratern daran, das Migrationskonzept weiter zu verfeinern. Es werden entsprechend die einzelnen Kapitel und Abschnitte des Buches ausformuliert.
„Keyuser Datenmigration“
An dieser Stelle möchte ich gerne ein paar Worte zur Besetzung der Rolle des „Keyusers Datenmigration“ verlieren:
Ich persönlich halte es für äußerst sinnvoll, für diesen Bereich einen dedizierten Keyuser zu benennen, der auf Ihrer Seite alle Fäden in der Hand hält und die Verantwortung für diesen wichtigen Bereich übernimmt. Dieser Keyuser wird sich allerdings zu den einzelnen Fachthemen immer wieder Rat und Meinungen sowie sicherlich auch viele Entscheidungen von anderen Keyusern oder Vorgesetzten einholen müssen.
Oftmals ist der Keyuser in dem Bereich Datenmigration derjenige, der in der Lage ist, die benötigten Daten aus dem Altsystem zu exportieren. Welche Daten das im Einzelfall genau sind, also z.B. ob bestimmte Artikel migriert oder welche Aufträge übernommen werden, wird er im Projekt in den meisten Fällen allerdings nicht entscheiden. Vielmehr ist er derjenige, der die Vorgaben technisch umsetzt, die von den Fachbereichen gemacht werden.
Darüber hinaus ist er aber auch derjenige, der dafür verantwortlich ist, dass einzelne Teile der Datenmigration zum richtigen Zeitpunkt fertig sind und die Daten im System zur Verfügung stehen
Ein paar Tipps aus der Praxis
Verlassen Sie sich nicht auf Excelmagie zwischen Export und Import
Ich bin absolut kein Freund davon, Daten aus dem alten ERP-System zu exportieren, und sie dann aufwändig in Excel umzuwandeln, um sie schließlich zu importieren. Denn in meinen Augen ist das viel zu gefährlich, zumal selten die Wege und Formeln in Excel wirklich nachvollziehbar sind. Entweder liegt programmierte Logik im Altsystem oder im neuen ERP-System, aber bitte nicht dazwischen. Allerdings gibt es, wie immer, Ausnahmen:
Erstens, wenn Sie die Daten nur einmal brauchen, das heißt, diese ins neue System importieren und bis zum Echtstart diesen Teil der Datenübernahme nicht wiederholen müssen, ist dies natürlich kein Problem.
Zweitens, wenn nach eingehender Analyse das Ergebnis ist, dass bestimmte Datentransformationen zwischen den Systemen gemacht werden müssen, kann man das tun. Allerdings sollte dies dann so detailliert dokumentiert werden, dass auch andere in der Lage sind, sich in den Themenkomplex einzuarbeiten.
Sprechen Sie mit Ihrem Wirtschaftsprüfer
Sprechen Sie unbedingt mit ihrem Wirtschaftsprüfer über das Thema Datenübernahme und den Echtstart, da es meistens gerade im Finanzbereich Dinge gibt, die im Nachgang nachgewiesen werden müssen. Dies kann außerdem auch Lagerwerte oder ähnliche Bereiche betreffen. Aus diesem Grund sollten diese Themen von Anfang an mitbedacht werden, damit sie später nach dem Echtstart sofort parat stehen. Notwendige Listen die sowohl erstellt als auch verglichen werden müssen, sollten außerdem Bestandteil der Integrationstests sein.
Hochrechnungen für manuelle Tätigkeiten
Oftmals wird entschieden, bestimmte Daten zum Echtstart manuell zu übernehmen. Dies ist grundsätzlich eine gute Möglichkeit, um einerseits Budget einzusparen und andererseits gleichzeitig die Anwender zu schulen. Allerdings sollte der Prozess der manuellen Datenanlage, z.B. für offene Bestellungen, im Vorfeld intensiv getestet werden. Dazu gehört auch, dass mit einer Stoppuhr festgehalten wird, wie lange die manuelle Anlage im Schnitt dauert. So kann man eine geschätzte Dauer für die manuelle Übernahme ermitteln und bewerten, ob man sich die automatisierte Übernahme wirklich ersparen kann.
Datenbereinigung und Bereitstellung systemspezifischer Zusatzinformationen
Wann immer es möglich ist, sollten notwendige Datenbereinigungen sowie die Bereitstellung von zusätzlichen Informationen direkt im Altsystem vorgenommen werden. Grundsätzlich setzt das Vorgehen jedoch voraus, dass Sie technisch in der Lage sind, Änderungen an Tabellen im Altsystem vorzunehmen.
Um die Vorgehensweise besser nachvollziehbar zu machen, möchte ich diese an einigen Themen aus dem Bereich Artikel verdeutlichen:
- Wenn Sie alte Artikel nicht mit übernehmen möchten, können Sie ein neues Feld namens „Keine Übernahme“ im Artikelstamm erstellen und dieses Feld auf Basis einer Auswertung automatisiert füllen lassen. Auf diese Weise können Sie dann direkt beim Datenexport auf dieses Feld filtern und sicherstellen, dass die entsprechenden Artikel gar nicht erst exportiert werden.
- Falls das neue System Artikelstammdaten benötigt, die im Altsystem nicht existieren, können Sie die erforderlichen Felder im Artikelstamm des Altsystems anlegen und dort füllen. Diese Felder haben dann im Altsystem keine Funktionalität und werden möglicherweise nur in einer speziellen Ansicht dargestellt. Dennoch hat dieses Vorgehen den Vorteil, dass die Daten sukzessive gefüllt werden können und somit bei jedem Datenexport bereits zur Verfügung stehen.
Zeitliche Planungen
Es macht definitiv Sinn, sich frühzeitig Gedanken darüber zu machen, welche Daten zu welchem Zeitpunkt im Projekt zur Verfügung stehen sollten, beispielsweise für Workshops und Key-User-Tests. Ebenso wichtig ist es, festzulegen, welche Daten wann in ihrer finalen Version in der Echtdatenbank zur Verfügung stehen können, insbesondere im Hinblick auf die Problematik der Doppelpflege von Daten. Wenn Sie eine nahezu vollautomatisierte Datenmigration anstreben, muss diese zwingend bis zum ersten Integrationstest abgeschlossen sein, damit sie entsprechend mitgetestet werden kann.
Da die Datenmigration in den meisten Fällen eine komplexe Aufgabe darstellt, wird es einige Monate dauern, bis die ersten vollständigen Daten im neuen ERP-System, idealerweise in einem Testsystem, vorliegen. Für Workshops und erste Tests ist es jedoch essenziell, dass diese mit Ihren eigenen Daten durchgeführt werden. Beispielartikel und -kunden, die mit dem eigenen Geschäft nichts zu tun haben, sorgen nicht selten dafür, dass sich die Anwender in den ersten Terminen nicht wiederfinden. Dies kann jedoch ganz einfach vermieden werden, indem man bereits zu Beginn des Projekts erste Beispieldaten übernimmt – auch wenn dies im Zweifel natürlich bedeutet, dass diese manuell angelegt werden müssen.
Fazit
Die Datenmigration ist ein zentraler, jedoch oft unterschätzter Aspekt in ERP-Projekten. Eine gut geplante und durchgeführte Migration kann letztlich den entscheidenden Unterschied zwischen dem Erfolg oder aber dem Misserfolg eines ERP-Projekts ausmachen.
Durch den frühzeitigen Start der entsprechenden Konzeptionierung und eine kontinuierliche Bereitstellung neuer Datenstände kann das Thema jedoch sehr gut kontrolliert und entschärft werden. Dies ermöglicht es, potenzielle Probleme frühzeitig zu erkennen und entsprechend gegenzusteuern, sodass die Migration letztlich effizient und reibungslos verläuft