Migration der Bewegungsdaten (Datenmigration 4/5)

Migration_der_Bewegungsdaten

Teil 4: Migration von Bewegungsdaten

In unserer Serie über die Datenmigration bei ERP-Einführungen zeigen wir Ihnen die grundlegende Herangehensweise und was es zu berücksichtigen gibt. Teil 4 behandelt die Migration der Bewegungsdaten in ERP-Systemen

Die Serie “Datenmigration” im Überblick:

Mit “Bewegungsdaten” in ERP-Systemen meint man in der Regel Daten, die sich schnell und laufend ändern. Dazu gehören beispielsweise Lagerbstände, Verbräuche oder Zahlungseingänge . Der Gegensatz dazu sind Stammdaten wie Adressdaten oder Vertragsdaten (Siehe Teil 3). Bewegungsdaten haben meist etwas mit Buchungen zu tun und sind mit einem Zeitstempel oder einer Gültigkeit versehen. Die Migration der Bewegungsdaten findet in den meisten Fällen zum Golive des neuen ERP-System statt. Diesen legt man gerne an das Ende des alten und den Anfang des neuen Geschäftsjahres. Der Migration geht dann ein Abschluss mit Inventur im Altsystem voraus. Ist das nicht möglich oder sinnvoll, wird im Altsystem unterjährig ein Abschluss gemacht.

1. Datenmigration schnell und gut

Im Bereich der Bewegungsdaten gibt es viele Datenbestände, deren Migration durch gesetzliche Vorgaben tangiert werden. Konkret heisst das, an die Migration werden bestimmte Anforderungen gestellt und Sie haben hier wenig Gestaltungsmöglichkeiten. Als Beispiel seien hier die Bestände in einem Lager genannt. Die Schlussbestände im Altsystem müssen mit den Anfangsbeständen im neuen ERP-System übereinstimmen. Gleiches gilt für Daten wie die offenen Posten oder die Arbeit im Umlauf. Anders gesagt, inhaltlich sind die Daten so in das neue ERP-System zu importieren, wie sie aus dem Altsystem exportiert wurden. Des Weiteren müssen die Bewegungsdaten in der Regel ihren Stammdaten zugeordnet werden. Im Beispiel der Lagerbestände müssen die Zahlen aus dem Altsystem im neuen System dem jeweils passenden Artikel korrekt zugeordnet werden. Die Bereinigung der Daten vor dem Import entfällt. Dagegen kann (und muss meistens) die Struktur der Daten so angepasst werden, dass sie für das neue ERP-System passt. Doch dazu unten mehr.

Da sich die Daten laufend ändern, müssen der Export aus dem alten und Import in das neue System unmittelbar nacheinander stattfinden. In der Zeit der Migration dürfen die Bewegungsdaten in den betroffenen Systemen nicht mehr geändert werden. Die Migration der Bewegungsdaten muss in kurzer Zeit realisiert werden können und erfordert daher eine gute Vorbereitung.

2. Frühe und gute Vorbereitung

In der Vorbereitung der Migration der Bewegungsdaten wird zunächst untersucht, welche Daten übernommen werden müssen. Als nächstes wird geprüft, wie die Daten übernommen werden müssen. Hier gibt es drei Grundansätze:

  1. einfacher Export/Import
  2. Export, Umstrukturierung, Import
  3. manuelle Übertragung

Einfach strukturierte Daten wie Lagerbestände oder Zahlungen werden i. d. R. über Ansatz 1 oder 2 migriert. Der ERP-Partner schaut sich die Datenbestände aus dem Altsystem hinsichtlich der benötigten Struktur im neuen System an. Anschliessend definiert er, ob und wenn ja wie die Struktur umgebaut und wie der Import durchgeführt werden muss. Die Migration der Bewegungsdaten kann leicht vorab getestet werden (z. B. durch Import in das Testsystem).

Bei umfangreicheren und komplexeren Datenstrukturen wie Offerten oder Aufträgen ist die Sache etwas schwieriger. Die Daten lassen sich meist nicht ohne Weiteres exportiert, umstrukturieren und wieder importieren. Die Strukturen in den beteiligten Systemen sind zu unterschiedlich. Hinzukommt, dass sich verknüpfte Datenstrukturen im neuen System oft grundlegend ändern (z. B. Stücklisten). Daher werden diese Daten häufig, sie ahnen es bereits, manuell übertragen.

Um bei dem Beispiel der Aufträge zu bleiben: Aufträge, die noch im alten System abgeschlossen werden können, werden nicht in das neue System migriert. Aufträge, die nur im neuen ERP-System benötigt werden, sind von einer Migration ebenfalls nicht tangiert. In der Praxis wird man versuchen, möglichst viele Aufträge in eine der beiden Gruppen einzuordnen. Übrig bleiben die Aufträge, die über den Stichtag des Golives laufen. Sie werden in beiden Systemen eröffnet und gepflegt (Parallelbetrieb). Am Stichtag wird jeder Auftrag im Altsystem abgeschlossen und mit den aktuellen Werten im neuen System weitergepflegt. Wann dieser Parallelbetrieb startet und wie lange er dauert, hängt von der Durchlaufzeit der Aufträge im Unternehmen ab.

Wie bereits im ersten Teil der Serie erwähnt, ist eine sauber Planung und Vorbereitung (inkl. Tests!) im Allgemeinen und bei der Migration der Bewegungsdaten im Sepziellen essenziell für einen reibungslosen Golive.

 

Veröffentlicht am 10. April 2015
2 Kommentare

Kommentar schreiben