Bei der Einführung eines neuen IT-Systems müssen in der Regel Daten von einem bestehenden auf ein neues System übernommen werden, was als Datenmigration bezeichnet wird. Ohne diesen Schritt ist eine Nutzung des neuen Systems nicht möglich. So müssen in einem Auftragsverwaltungssystem Artikeldaten und Adressen vollständig und richtig vorhanden sein, um den Produktionsbetrieb aufnehmen zu können. Erfassung und Abwicklung von Aufträgen setzen voraus, dass die Daten korrekt sind.
Die Praxis zeigt jedoch, dass der Aufwand für die Durchführung einer Migration unterschätzt und damit häufig zum Showstopper für die Nutzung eines neuen Systems wird. Dieses Phänomen hat zwei wesentliche Ursachen: Zum einen wird häufig die Qualität der Daten überschätzt – diesen Aspekt werde ich in einem gesonderten Beitrag vertiefen. Zum anderen müssen Auftraggeber und Auftragnehmer eng zusammenarbeiten, um eine Migration erfolgreich durchführen zu können. Der Auftragnehmer kann zwar die technische Abwicklung übernehmen, sinnvolle Festlegungen und Entscheidungen mit wirtschaftlichen Auswirkungen kann jedoch nur der Auftraggeber treffen.
Informationen sind meist nicht in einer Weise gespeichert, dass sie selbsterklärend sind. So ist das Jahr 2000-Problem mit der zweistelligen Speicherung von Jahreszahlen, was ursprünglich nach dem Jahr 1999 das Jahr 1900 folgen ließ, jedem bekannt. Es kommt dabei auf die Bedeutung der Informationen an, die in einem Datensatz gespeichert sind, wie hier die nur gedanklich implizite Jahrhundertangabe. Bei einigen Informationen herrscht Eindeutigkeit (wie beispielsweise bei deutschen Postleitzahlen oder IBAN-Nummern). Andere Darstellungen von Informationen sind jedoch wesentlich individueller gelöst wie beispielsweise die Nutzung von Namens- und Anredefeldern in Briefen oder die Speicherung von Artikelinformationen als Baumstruktur oder Netzbeziehungen.
Eine Migration ist somit mit einer Übersetzung der Daten von einem bestehenden in ein neues System vergleichbar. Es ist daher eine Reihe von Arbeiten zur Vorbereitung und Durchführung der Migration erforderlich, die oftmals komplex sind. Der zugehörige Aufwand wird unterschätzt und/oder nicht rechtzeitig erkannt und kann daher Ursache einer Projektschieflage sein.
Erfahren Sie im Folgenden,
1. welche Herausforderungen mit einer Datenmigration verbunden sind,
2. wie eine Migration abläuft,
3. warum die Projektpartner zusammenarbeiten müssen und
4. worauf es bei den Vereinbarungen der Projektpartner ankommt.
1. Welche Herausforderungen stehen an?
Die Daten einer Migration sind über viele Jahre von vielen Personen erfasst und bearbeitet worden. Über die Zeit können dazu organisatorische Regelungen eingeführt oder verändert worden sein, so dass sich auch die Nutzung der Systeme gewandelt hat. Eine Aufarbeitung dieses Sachverhalts ist nur schwer möglich und dazu noch sehr komplex, so dass der Fokus auf den vorhandenen Daten liegt.
Da sich die Struktur der Daten im neuen System nahezu immer von der Struktur im alten System unterscheidet, muss vor der Übersetzung der Daten zunächst eine Analyse durchgeführt werden. Dabei wird erarbeitet, wie die Informationen der Datenstruktur des alten Systems in die Datenstruktur des neuen Systems übertragen werden können. Diese strukturellen Unterschiede lassen sich meist einfach abarbeiten.
Schwieriger ist jedoch, wenn die Nutzung der Felder abweicht oder im neuen System keine Felder für Informationen aus dem alten System vorhanden sind. Ein Verzicht auf diese Informationen ist im Allgemeinen suboptimal, da sie für einen bestimmten Geschäftsprozess notwendig sind oder durch den Wegfall die Bedienung unkomfortabler wird.
Eine weitere Herausforderung besteht im notwendigen Input für Datenfelder des neuen Systems, für die keine Daten aus dem alten System zur Verfügung stehen (beispielsweise der Umsatz in einer bestimmten Warengruppe im vergangenen Jahr). In diesen Fällen ist zu überlegen, ob die Informationen aus dem Datenbestand des alten Systems gewonnen/berechnet werden können oder ob es Umgehungslösungen für diese Auswertungen gibt. Meist ist es kein sinnvoller Weg, bei der Einführung eines neuen Systems auf die Auswertung historischer Daten zu verzichten, da dann wichtiges Wissen nicht mehr zur Verfügung steht. Viele Unternehmen orientieren sich beispielsweise bei dem Einkauf von Waren an dem Bedarf, der in einem Vergleichszeitraum benötigt wird.
Eine weitere Aufgabe ist die Erzeugung von Testdaten, die möglichst viele Anwendungsfälle abdecken und sparsam mit personenbezogenen Daten umgehen. Hier kommt vorzugsweise eine Anonymisierung in Betracht, die Datenschutzproblematiken löst.
Nicht zuletzt ist für alle Migrationsarbeiten zu klären, welcher Projektpartner die technische Leistung erbringen kann und welcher Projektpartner die inhaltliche Verantwortung trägt.
2. Wie läuft eine Migration ab?
Im Vorfeld einer Migration sind umfangreiche Analysearbeiten an dem Datenbestand des Altsystems erforderlich. Die Bedeutung und die Nutzung der einzelnen Datenfelder sind – zumindest soweit sie benutzt werden – vollständig zu klären. Wie in dem obigen Beispiel des Jahr-2000-Problems dargestellt, ist die strukturelle (syntaktische) Struktur und die Bedeutung (Semantik) bei der Übersetzung der Daten zu bewahren. Für fehlende Informationen ist zu klären, wie diese beschafft werden können oder ob Umgehungslösungen zu entwickeln sind.
Diese Analyse ist Voraussetzung für die Durchführung einer Migration, die im Normalfall aus folgenden Schritten besteht:
1. Extraktion
Die zu übernehmenden Daten müssen spezifiziert werden (beispielsweise Stammdaten für Kunden, Lieferanten, Artikel; Bewegungsdaten für Aufträge der letzten 3 Jahre, für Finanzbuchhaltung 10 Jahre).
2. Data Cleansing (Datenbereinigung)
Dieser Schritt verbessert die Datenqualität, auf die ich in einem gesonderten Beitrag eingehen werde.
3. Erzeugung von (Test)-Daten
Generieren von (anonymisierten) Daten für Tests der Datenübersetzung im neuen System.
4. Data Mapping
Übersetzen der Daten von bestehendem auf das neue System (zu Details siehe nachfolgender Abschnitt).
5. Data Load (auch für Testdaten)
Laden der Daten in neues System.
6. Qualitätssicherung
Abgleich der Daten aus bestehendem System mit denen im neuen System, Prüfung auf Richtigkeit und Vollständigkeit, Tests der Prozessabläufe und Freigabe
In der Regel werden diese Schritte für alle zu übernehmenden Datenarten mehrfach durchlaufen, um Fehler erkennen und beseitigen zu können. Daneben ist zu berücksichtigen, dass diese Schritte auch Maschinen- und Menschen-Zeit benötigen. Damit erstreckt sich üblicherweise auch die letzte Migration zur Erzeugung des Produktiv-Datenbestandes im neuen System über mehrere Wochen. Dabei können Sie sich an folgender Reihenfolge orientieren:
- Migration der Stammdaten
- Migration der Bewegungsdaten aus den vergangenen Jahren
- Migration der Bewegungsdaten aus dem aktuellen Jahr
- Migration der Bewegungsdaten der im Umstellungszeitraum entstandenen Bewegungsdaten
Im Ergebnis ist die Migration ein eigenes Projekt, das eng mit der Funktionalität des bestehenden und des neuen Systems verbunden ist. Im nächsten Abschnitt stelle ich dar, aus welchen Gründen eine Zusammenarbeit von Auftraggeber und Auftragnehmer unabdingbar ist.
3. Warum müssen Projektpartner zusammenarbeiten?
Um diese Frage zu beantworten, lade ich Sie zu einem kurzen Tauchgang in technische Einzelheiten einer Migration ein. In der nachfolgenden Grafik sind Ausschnitte aus Datensätzen einer Datentabelle skizziert. Im oberen Bereich findet sich ein Teil aus dem alten, bestehenden System, im mittleren eine Übersetzung dieser Daten (Mapping-Tabelle) in das neue System sowie im unteren Teil ein Ausschnitt aus dem neuen System. Im Datensatz des alten Systems gehören zu den Angaben eines Kunden die Felder PLZ, Name, Bonität sowie Lieferadressen. Hierbei handelt es sich um einen kleinen Ausschnitt von Kundendaten; in der Praxis setzen sich die zu einem Kunden gespeicherten Informationen aus mehreren Datensätzen mehrerer Datentabellen zusammen, was hier nicht näher betrachtet zu werden braucht.

Die genannten Daten müssen in das neue System (unterer Bereich) übernommen werden. Problematisch sind die mit einem „?“ gekennzeichneten Felder. Einige Bereiche des Datensatzes sind leer; dafür kommen mehrere Ursachen in Betracht: Bei der Analyse des Datensatzaufbaus ist übersehen worden, dass in diesen Bereichen gleichwohl Informationen gespeichert werden. Es kommt aber auch vor, dass eine Analyse dieser Informationen zu keinem Ergebnis geführt hat, so dass sie bei einer Migration in das neue System verloren gehen.
Eine weitere Herausforderung ist die Bestimmung der zulässigen Feldlängen sowie der Bereiche der Werte, die die Einträge in diesen Feldern annehmen können. Das Feld PLZ besitzt eine Länge von 5, so dass 5 Zeichen (oder Ziffern) dargestellt werden können. Das Feld Name ist 30 Zeichen lang. Für das Feld Bonität ist ein Wertebereich der Ziffern von 1 bis 6 vorgesehen – es können also lediglich Zahlen zwischen 1 und 6 eingetragen werden. Das Feld Lieferadressen besitzt keine Angabe der Länge oder des Wertebereiches, was bei einer Migration aber geklärt werden muss.
Bei einer Übertragung dieser Daten in das neue System kann der Inhalt des Feldes PLZ unverändert in einem entsprechendem Datensatz im neuen System gespeichert werden. Beim Feld Name ist eine Umwandlung erforderlich, da die Feldlänge im neuen System 5 Zeichen kürzer ist. Bei einem einfachen Abschneiden können Informationen verloren gehen; falls beispielsweise der Name als eindeutige Identifikation (für die Anmeldung zu einem Benutzerkonto) benutzt wird, können durch das Abschneiden Dubletten auftreten, die zu einem Verlust der Eindeutigkeit dieser Bezeichnung führen. In diesen Fällen muss bei der Umwandlung darauf geachtet werden, dass durch die Kürzung auf 25 Zeichen keine doppelten Namen entstehen.
Die Bonität wurde im alten System mit einer Ziffer zwischen 1 und 6 gekennzeichnet, während im neuen System nur noch ein Ja/Nein-Feld vorgesehen ist, das eine Liefersperre kennzeichnet. Es ist somit eine Festlegung notwendig, ab welcher Bonitätsstufe des Altsystems eine Liefersperre im neuen System definiert wird.
Für das Feld Lieferadresse ist keine Speichermöglichkeit im neuen System vorgesehen. Falls im neuen System keine Lieferadresse gesondert gespeichert werden kann, sind bestehende Geschäftsprozesse, die abweichende Lieferadressen vorsehen, entsprechend anzupassen. An diesem Beispiel wird deutlich, dass Details der Migration einen weitreichenden Einfluss auf die Gestaltung von Geschäftsprozessen haben.
Schließlich ist im neuen System ein Feld Umsatz vorgesehen, in dem der Umsatz mit dem Kunden in den letzten 5 Jahren gespeichert wird. Die Wahl eines Standardwertes (wie 0) greift zu kurz, wenn mit diesem Merkmal beispielsweise eine Klassifikation der Kunden nach Umsatzgrößen erfolgt (mit hinzugehörigen Konditionen, Zuordnung von Kundenbetreuern etc.). Es muss somit überlegt werden, ob es durch Auswertungen des Altdatenbestandes eine Umgehungslösung gibt.
Sie müssen bei einer Migration Folgendes wissen oder entscheiden:
- Wie Datenfelder des alten Systems genutzt werden,
- wie Bedeutungen (Beispiel Bonität) in das neue System übersetzt werden,
- wie Feldern im neuen System, zu denen keine Daten aus dem Altsystem vorhanden sind, vorbelegt werden; ggf. müssen Sie Standardwerte einschließlich möglicher Umgehungslösungen bestimmen und
- wie Sie die Geschäftsprozesse im neuen System bei abweichender Informationslage (beispielsweise Lieferadresse, Umsatz) gestalten.
Die zugehörigen Entscheidungen sind originäre Aufgabe des Auftraggebers, da er die Funktionsweise und die Ausrichtung des neuen Systems verantwortet. Auch die aus dem Altsystem zu gewinnenden Informationen beruhen sehr stark auf organisatorischen Regelungen (auch aus den entsprechenden Vorläufersystemen), die sich nicht allein durch eine Analyse der Daten gewinnen lassen. Falls die entsprechenden Informationen einem Auftragnehmer nicht zur Verfügung stehen, nähert sich die Aufgabe Migration der objektiven Unmöglichkeit.
Nach meinen Erfahrungen ist es kein Einzelfall, dass Forschungs- und Aufklärungsarbeiten zur Funktionalität von Vorläufersystemen erbracht werden müssen. Es ist daher nicht möglich, dass der Auftraggeber die Migration (nahezu) vollständig auf einen Auftragnehmer überträgt. Erfahrungsgemäß ist ein erheblicher Aufwand an Mitwirkungsleistungen notwendig, damit die erforderlichen Detailentscheidungen im Interesse des Auftraggebers getroffen werden. Sie sollten nicht im Interesse einer möglichst schnellen, vermeintlich unaufwendigen Implementierung erfolgen. Zu Mitwirkungsleistungen werde ich einen gesonderten Beitrag veröffentlichen, da es sich auch um einen wichtigen Indikator für den Projektstatus handelt.
4. Worauf kommt es bei Vereinbarungen an?
Ein entscheidender Punkt bei Vereinbarungen zwischen Projektpartnern ist die Zuordnung der Verantwortlichkeit für bestimmte Teilarbeiten. Die nachfolgende Tabelle nennt als Vorschlag die wichtigsten Arbeiten innerhalb des Arbeitspaketes Migration und ordnet die Verantwortlichkeit (V) zu; der jeweils andere Projektpartner muss bei diesen Arbeiten unterstützen.

Der Auftraggeber muss festlegen, welche Daten migriert werden sollen. Nur er kann entscheiden, was für den Geschäftsbetrieb im neuen System notwendig und sinnvoll ist. Je mehr Daten übernommen werden, desto aufwendiger sind das Data Cleansing und die Migration, so dass auch eine kaufmännische Abwägung getroffen werden sollte.
Eine Vereinbarung, die dem Auftragnehmer die Verantwortlichkeit für die vollständige Migration der Daten in das neue System überträgt, ist sehr praxisfern. Es fehlt dabei eine Sollvorgabe, welche Daten (Zeitraum, Bewegungsdaten) übernommen werden sollen und wie mit Informationsverlusten umzugehen ist (siehe Ausführungen im obigen Abschnitt 3 zur Mapping Tabelle).
Auch für die Extraktion der Daten aus dem bestehenden System sollte der Auftraggeber fachlich verantwortlich sein. Nur er kennt die tatsächliche Nutzung und Bedeutung der Daten (einschließlich der Daten aus den Vorläufersystemen). Das schließt nicht aus, dass er Datenanalysen von Auftragnehmern durchführen lässt. Die Bewertung der Relevanz der Daten für die Geschäftstätigkeit verlangt jedoch unter anderem eine wirtschaftliche Abwägung. Gegebenenfalls muss der Auftragnehmer versuchen, ein entsprechendes Bewusstsein beim Auftraggeber zu schaffen.
Die weiteren vier Schritte hängen maßgeblich von der Funktionalität des neuen Systems ab, so dass diese Verantwortlichkeiten dem Auftragnehmer übertragen werden sollten; nur er kennt die Einzelheiten und Details der Abläufe im System und ist im Regelfall für die Abbildung der Geschäftsprozesse verantwortlich.
Der Abgleich und die Prüfung der Migration müssen dem Auftraggeber obliegen, da er beurteilen muss, ob und inwieweit die Projektziele mit diesen Daten umgesetzt werden – vergleichbar mit einer Abnahme.
Die Verantwortung für eine bestimmte Aufgabe bedeutet nicht, dass sie ohne die Mitwirkung des anderen Projektpartners durchgeführt werden kann. Vielmehr handelt es sich hierbei nur um eine Empfehlung, wie die Federführung für eine bestimmte Aufgabe verteilt werden kann. Wichtig ist, dass der Auftragnehmer die Verantwortung für die gesamte Mapping-Planung einschließlich der Mapping Tabellen erhält, damit er bei Fehlfunktionen des neuen Systems nicht auf die Defizite beim Mapping verweisen kann. Nach meinen Erfahrungen ist es relativ aufwendig, funktionale Defizite in einem System von Datenbestandsdefiziten abzugrenzen. Zur Vermeidung dieser Problematik ist es daher zielführend, die Verantwortung in dieser Weise zuzuweisen. Gleichwohl bleibt es sinnvollerweise die Aufgabe des Auftraggebers, die Mapping Tabelle spätestens nach Abgleich und Prüfung der Ergebnisse freizugeben, da dies Voraussetzung für den späteren Betrieb und gegebenenfalls einer Abnahme ist.
Wenn ich eine vertragliche Regelung wie „Der Auftragnehmer gewährleistet die Qualität der Daten gemäß Datensatzbeschreibung“ aus technischer Sicht bewerte, ist sie nicht belastbar. Sie setzt unter anderem voraus, dass das Datenmodell des Altsystems vollständig bekannt ist; darüber hinaus muss auch Klarheit über die Details der Nutzung bestehen (Feldmissbräuche, Freifelder, organisatorische Regelungen etc.). Diese Vorgehensweise ist zwar theoretisch möglich; im Allgemeinen mangelt es aber daran, dass das Datenmodell und die Nutzung nicht vollständig bekannt sind.
Ein weiterer Aspekt ist, dass Sie Verantwortlichkeiten nicht auf Arbeitspaketebene (beispielsweise gegliedert nach Datenarten) zuweisen können. Wie im vorhergehenden Abschnitt dargestellt, müssen die Projektpartner bei jedem einzelnen Datenbestand zusammenarbeiten. Die Zuweisung muss somit auf Prozessebene in Anlehnung an die in der Tabelle aufgeführten Aufgaben erfolgen.
Bei der folgenden Regelung handelt es sich um eine Festlegung während der Projektlaufzeit:
Es werden Stammdaten, Bewegungsdaten und Lagerdaten übernommen. Die genauen Felder müssen noch definiert werden. Dazu wird ein Workshop durchgeführt.
Dieser Passus hat – falls er entsprechend vereinbart wurde – vertragsergänzenden Charakter. Einem Sachverständigenbeweis ist er jedoch nur zugänglich, wenn die Ergebnisse des Workshops auch entsprechend protokolliert sind oder anderweitig dokumentiert wurden. Als vertragliche Regelung im Vorfeld lässt dieser Punkt sehr vieles offen und ist eine Quelle für potenzielle Auseinandersetzungen.
5. Zusammenfassung
Eine Migration ist ein eigenes IT-Projekt, das auch Einfluss auf die Abläufe in dem neu einzuführenden System hat. Sie muss in einer engen Kooperation zwischen den Projektpartnern geplant werden. Vordringlich ist, dass Sie die Datenqualität bestimmen und daraus die Datenbereinigungsarbeiten ableiten. Zusätzlich müssen Sie sich eng über die Einzelheiten der Übersetzung der Daten von dem bestehenden in das neue System (Data Mapping) abstimmen. Die Zuweisung der jeweiligen Verantwortlichkeiten an Auftraggeber und Auftragnehmer sollte auf der Prozessebene im Vorfeld erfolgen.
Aus technischer Sicht bestehen somit deutliche Zwänge zur Zusammenarbeit der Projektpartner. Ohne erhebliche Mitwirkungsleistungen des Auftraggebers führt eine Migration leicht dazu, dass (unwiederbringliche) Informationsverluste entstehen und/oder die Nutzung des neuen Systems zumindest zu Beginn signifikant eingeschränkt ist. Eine eindeutige Zuordnung dieses Defizits zu einem Projektpartner ist erfahrungsgemäß von vielen Einzelaspekten abhängig – ich berate Sie gerne!