Im Statusbericht steht die ERP-Datenmigration bei 80 Prozent. Die Kundendatei wurde bereits erzeugt, beim Materialstamm läuft der zweite Import und für offene Bestellungen ist ein Termin mit dem Fachbereich geplant. Das klingt nach Fortschritt. Trotzdem kann die Projektleitung nicht beantworten, welches Datenobjekt für den nächsten Test tatsächlich bereit ist.
Wer den Fortschritt einer ERP-Datenmigration messen will, braucht deshalb mehr als erledigte Aufgaben und importierte Datensätze. Aussagekräftig wird der Status erst, wenn jedes Datenobjekt – etwa Kunden, Materialien oder Stücklisten – nach denselben nachweisbaren Ergebnissen beurteilt wird. So wird sichtbar, was wiederholbar funktioniert, wo eine Entscheidung fehlt und was nur auf den ersten Blick fertig aussieht.
ERP-Datenmigration: Fortschritt messen heißt zwei Statusarten trennen
Zunächst hilft eine einfache Unterscheidung. Ein Importwerkzeug kann den technischen Fortschritt eines Laufs anzeigen: Wie viele Datensätze wurden gelesen? Welche Verarbeitungsschritte sind abgeschlossen? Wie viele Meldungen sind aufgetreten? Dieser Status ist wichtig, beantwortet aber nur, was gerade im Werkzeug passiert.
Die Projektleitung braucht zusätzlich den fachlichen Migrationsfortschritt. Er zeigt, wie weit ein Datenobjekt auf dem gesamten Weg von der Quellanalyse bis zum geprüften Ergebnis im Zielsystem gekommen ist. Ein technisch erfolgreicher Upload kann dabei ein Zwischenschritt sein. Er beweist noch nicht, dass der Datenumfang vollständig ist, die Beziehungen stimmen oder ein Key-User mit den Daten seinen Geschäftsprozess ausführen kann.
Genau deshalb sollte die Statusfrage nicht lauten: „Wie viel Prozent haben wir schon?“ Hilfreicher ist: „Welches überprüfbare Ergebnis liegt für welches Datenobjekt vor?“
Warum pauschale Prozentwerte so schnell täuschen
Eine Prozentzahl wirkt präzise, obwohl ihre Grundlage häufig unklar bleibt. Wenn zehn Arbeitspakete existieren und acht als erledigt markiert sind, ergibt sich rechnerisch ein Fortschritt von 80 Prozent. Doch vielleicht betreffen sieben dieser Pakete nur die Vorbereitung einer Kundendatei, während das noch offene Stücklisten-Mapping den gesamten Produktionstest blockiert.
Auch eine reine Mengensicht greift zu kurz. Von 100.000 Artikeln können 99.000 technisch geladen sein. Wenn jedoch die Einheiten bei bestimmten Materialarten falsch umgerechnet werden, ist das Objekt fachlich noch nicht belastbar. Umgekehrt kann ein kleiner, klar abgegrenzter Fehlerbestand akzeptiert sein, wenn seine Ursache, Auswirkung und Behandlung freigegeben wurden.
Pauschale Prozentwerte sind deshalb nicht grundsätzlich falsch. Sie dürfen nur nicht vortäuschen, dass sehr unterschiedliche Ergebnisse addierbar seien. Bevor ein Gesamtwert gebildet wird, muss der Status jedes Datenobjekts nachvollziehbar sein.
Das Datenobjekt wird zur kleinsten sinnvollen Statuseinheit
Ein Datenobjekt bündelt die Informationen, die im neuen ERP gemeinsam eine fachliche Einheit bilden. Dazu gehören beispielsweise der Kundenstamm mit Adressen und Rollen oder ein Material mit seinen organisatorischen Sichten. Diese Einheit eignet sich besser für die Steuerung als eine einzelne Datei, Tabelle oder Aufgabe.
Denn für jedes Objekt lässt sich derselbe Weg betrachten:
- Der benötigte Umfang ist festgelegt.
- Die relevanten Quelldaten und Beziehungen sind belegt.
- Mapping- und Transformationsregeln sind ausreichend entschieden.
- Die Importdatei lässt sich wiederholbar erzeugen und vorprüfen.
- Ein Testimport wurde protokolliert durchgeführt.
- Mengen, Werte und Beziehungen wurden technisch abgestimmt.
- Der Fachbereich hat vereinbarte Prüffälle im Zielsystem bestätigt.
- Restfehler sind behoben oder bewusst entschieden.
Damit entsteht kein starres Phasenmodell, das jede Besonderheit ignoriert. Es entsteht vielmehr eine gemeinsame Sprache für nachweisbare Zwischenstände. Der ausführliche Fahrplan einer ERP-Datenmigration ordnet diese Ergebnisse in den gesamten Projektverlauf ein.
Ein praxistaugliches Statusmodell für jedes Datenobjekt
Zu viele Statusstufen erzeugen Pflegeaufwand; zu wenige verdecken Risiken. Für die operative Steuerung reichen häufig fünf klar definierte Zustände.
1. Abgegrenzt
Das Projekt weiß, welche fachlichen Teilmengen zum Datenobjekt gehören, welche nicht übernommen werden und welche Abhängigkeiten zu anderen Objekten bestehen. „Kundenstamm“ allein genügt noch nicht. Beispielsweise muss feststehen, ob Ansprechpartner, Lieferadressen, offene Posten oder historische Umsätze Teil desselben Vorhabens sind.
2. Umsetzbar
Quellen, Schlüssel und Zielanforderungen sind so weit geklärt, dass die technische Aufbereitung beginnen kann. Nicht jede Ausnahme muss schon gelöst sein. Offene Punkte dürfen den vereinbarten Testumfang jedoch nicht unbemerkt verändern.
3. Wiederholbar erzeugt
Aus einem eindeutig bezeichneten Quellstand wurde eine vorgeprüfte Importdatei erstellt. Die verwendeten Regeln sind dokumentiert und erneut ausführbar. Eine Datei, die nur durch nicht dokumentierte Handkorrekturen funktioniert, erreicht diesen Zustand nicht.
4. Technisch abgestimmt
Der Import ist erfolgt und sein Ergebnis wurde mit der Quelle beziehungsweise der erzeugten Datei verglichen. Erwartete, geladene, abgewiesene und bewusst ausgeschlossene Datensätze lassen sich erklären. Außerdem wurden Schlüssel, Pflichtfelder und wichtige Beziehungen geprüft.
5. Fachlich bestätigt
Verantwortliche Key-User haben zuvor vereinbarte Fälle im Zielsystem geprüft. Sie bestätigen nicht nur, dass Datensätze sichtbar sind, sondern dass die benötigten Prozesse mit ihnen funktionieren. Wie technische Abstimmung und fachliche Abnahme zusammenspielen, zeigt der Beitrag zur Datenvalidierung in der ERP-Migration.
„Bereit für den nächsten Test“ ist nicht dasselbe wie „bereit für den Go-live“
Der gewünschte Reifegrad hängt vom nächsten Verwendungszweck ab. Für einen frühen Prototyp kann ein bewusst kleiner Teilbestand ausreichen, obwohl mehrere Mappingfragen offen sind. Für einen Integrationstest müssen dagegen die benötigten abhängigen Objekte gemeinsam nutzbar sein. Vor dem Go-live kommen vollständiger Umfang, aktuelle Datenstände, abgestimmte Restfehler und ein wiederholbar geprobter Ablauf hinzu.
Darum sollte jeder Statusbericht auch das Ziel nennen, gegen das bewertet wird:
- bereit für den Prototyp: Die Grundstruktur und repräsentative Fälle können geprüft werden.
- bereit für den Fachtest: Der vereinbarte Testumfang ist technisch abgestimmt und bekannte Einschränkungen sind sichtbar.
- bereit für den Integrationstest: Abhängige Datenobjekte stehen gemeinsam und in der richtigen Reihenfolge zur Verfügung.
- bereit für den Go-live: Umfang, Qualität, Freigaben und Cut-over-Ablauf erfüllen die beschlossenen Kriterien.
Ein Objekt kann somit für den nächsten Test ausreichend sein, ohne bereits produktionsreif zu sein. Diese Formulierung ist ehrlicher und für die Projektentscheidung nützlicher als ein allgemeines „grün“.
Welche Kennzahlen die Projektleitung wirklich braucht
Ein leichtgewichtiges Statusbild benötigt keine große Software. Eine gemeinsame Tabelle kann genügen, wenn ihre Felder eindeutig definiert und mit Ergebnissen verknüpft sind. Sinnvoll sind insbesondere:
- aktueller Reifezustand je Datenobjekt,
- nächstes erwartetes Ergebnis und verantwortliche Person,
- offene Blockade mit notwendiger Entscheidung und Termin,
- letzter wiederholbar erzeugter und geprüfter Lauf,
- erwartete, importierte, abgewiesene und ausgeschlossene Mengen,
- Status der technischen Abstimmung und der fachlichen Prüfung,
- kritische Abhängigkeiten zu anderen Datenobjekten,
- und Restfehler, getrennt nach Ursache und Auswirkung.
Dadurch lässt sich nicht nur berichten, sondern steuern. Wenn drei Objekte im Zustand „umsetzbar“ stehen, aber bei allen dieselbe Zielentscheidung fehlt, wird ein gemeinsamer Engpass sichtbar. Wenn ein Objekt seit zwei Läufen dieselben Fehler erzeugt, fehlt vermutlich keine weitere Testwiederholung, sondern eine Korrektur an Mapping oder Transformation.
Ein kurzes Beispiel: Zwei grüne Dateien, zwei völlig verschiedene Risiken
Für Kunden und Stücklisten liegen Importdateien vor. Beide wurden vom Zielsystem technisch angenommen. In einer dateibasierten Übersicht könnten daher beide als erledigt erscheinen.
Beim Kundenobjekt stimmen die erwarteten und importierten Mengen überein. Adressen und Rollen sind verknüpft, fünf typische Kundenfälle wurden im neuen ERP geprüft und die zwei bekannten Ausnahmen sind fachlich freigegeben. Dieses Objekt ist für den vorgesehenen Test belastbar.
Bei den Stücklisten wurde dagegen nur die Kopfstruktur geladen. Mehrere Komponenten fehlen, weil die Beziehung zwischen alter Positionsstruktur und neuer Alternative noch nicht geklärt ist. Der Upload war erfolgreich, das Datenobjekt ist es nicht. Im Statusmodell bleibt es deshalb vor der technischen Abstimmung stehen – mitsamt der konkreten Entscheidung, die den nächsten Schritt blockiert.
Dieser Unterschied ist der eigentliche Nutzen der Messung: Sie zeigt nicht nur Aktivität, sondern den letzten belastbaren Punkt.
Vier typische Fehlmessungen
- Dateien zählen: Eine vorhandene Datei sagt nichts über ihren Umfang, ihre Wiederholbarkeit oder ihre fachliche Eignung aus.
- Importmeldungen gleichsetzen: „Technisch erfolgreich“ bedeutet nicht „vollständig und fachlich richtig“.
- Aufgaben mitteln: Zwanzig kleine Erledigungen können einen einzigen kritischen Engpass nicht ausgleichen.
- Dauerhaft gelb berichten: Ein offener Punkt ohne Entscheider, Termin und Auswirkung ist kein Status, sondern ein verdecktes Risiko.
Auch offene Punkte gehören daher an das konkrete Datenobjekt und an das Ergebnis, das sie verhindern. Wie solche Entscheidungen dauerhaft nachvollziehbar bleiben, beschreibt der Beitrag zur Dokumentation der ERP-Datenmigration.
So führen Sie das Modell ohne zusätzliches Projektwerkzeug ein
Beginnen Sie mit den Datenobjekten, die den nächsten gemeinsamen Test bestimmen. Definieren Sie für diese Objekte die fünf Reifezustände und benennen Sie pro Zustand das erwartete Ergebnis. Anschließend ordnet das Team vorhandene Dateien, Protokolle, Prüfungen und Entscheidungen zu.
Dabei werden Lücken meist schnell sichtbar. Vielleicht existiert ein Importprotokoll, aber kein erklärbarer Mengenvergleich. Vielleicht wurde fachlich getestet, ohne festzuhalten, welcher Datenstand zugrunde lag. Oder die technische Aufbereitung wartet auf eine Entscheidung, die in einem Besprechungsprotokoll verborgen ist.
Erst nach dieser Bestandsaufnahme lohnt sich eine zusammenfassende Ampel oder Prozentzahl. Grün bedeutet dann nicht „fühlt sich weit an“, sondern „erfüllt die für den nächsten Meilenstein vereinbarten Nachweise“. Gelb nennt eine begrenzte Abweichung und ihren Umgang. Rot bezeichnet eine Blockade, die das geplante Ergebnis verhindert.
Fortschritt entsteht durch nachweisbare, wiederholbare Ergebnisse
Eine ERP-Datenmigration bewegt sich nicht vorwärts, weil mehr Dateien im Projektordner liegen oder ein Importbalken 100 Prozent erreicht. Fortschritt entsteht, wenn ein Datenobjekt einen klaren, überprüfbaren Zustand erreicht und dieses Ergebnis mit einem neuen Datenstand wiederholt werden kann.
Die fachlichen Kriterien und Freigaben bleiben dabei beim Unternehmen. Externe Unterstützung kann den Objektstatus strukturieren, technische und fachliche Nachweise zusammenführen, Blockaden bis zu ihrer Ursache verfolgen und die Aufbereitung so organisieren, dass aus einzelnen Aktivitäten ein belastbarer Migrationsstand wird. Damit erhält die Projektleitung genau die Antwort, die ein pauschaler Prozentwert nicht geben kann: Was funktioniert bereits – und was muss als Nächstes entschieden oder geliefert werden?