Eine ERP-Datenmigration kann sichtbar beschäftigt wirken und trotzdem im Verzug sein. Mappings werden bearbeitet, Dateien ausgetauscht und Termine aktualisiert – doch kein wichtiges Datenobjekt erreicht einen Stand, den Fachbereich, IT und ERP-Partner gemeinsam prüfen können. Dann fehlt dem Projekt nicht unbedingt Einsatz. Es fehlt ein geschlossener Weg von der Datenquelle bis zum bestätigten Ergebnis im neuen System.
Die entscheidende Frage lautet deshalb nicht zuerst: „Wie viel Prozent sind fertig?“ Hilfreicher ist: Bis zu welchem Ergebnis ist ein konkretes Datenobjekt nachweislich gekommen – und an welcher Übergabe geht es nicht weiter? Wer vom letzten belastbaren Ergebnis aus sucht, kann den Engpass meist einer von vier Ursachen zuordnen: Eine Entscheidung fehlt, die technische Umsetzung stockt, eine Voraussetzung im Zielsystem ist offen oder die fachliche Prüfung kommt nicht hinterher.
Dieser Beitrag zeigt, wie eine ERP-Projektleitung diesen Engpass eingrenzt, mit einem repräsentativen Datenobjekt wieder einen vollständigen Ablauf herstellt und entscheidet, ob ein klar abgegrenztes externes Arbeitspaket das Projekt sinnvoll entlasten kann.
Verzug zeigt sich am fehlenden Ergebnis – nicht an einer langen Aufgabenliste
Unfertige Arbeit ist in einer Datenmigration normal. Datenumfang, Mapping, Transformation und Tests werden schrittweise präziser. Kritisch wird die Lage erst, wenn diese Schleifen keinen neuen Nachweis erzeugen. Dann beginnt Arbeit immer wieder, ohne die nächste Entscheidung zu ermöglichen.
Vier Beobachtungen sprechen dafür, dass die Migration nicht nur „noch in Arbeit“, sondern tatsächlich festgefahren ist:
- Dieselben offenen Fachfragen tauchen in mehreren Abstimmungen auf, ohne dass eine entscheidungsfähige Vorlage und ein Verantwortlicher feststehen.
- Fortschrittsangaben lassen sich nicht auf einen bestimmten Datenstand, eine Version der Transformationsregeln oder ein konkretes Prüfergebnis zurückführen.
- Technische Beteiligte warten auf fachliche Entscheidungen, während die Fachbereiche auf Daten im Testsystem warten.
- Der Go-live-Termin wird weitergeführt, obwohl niemand sagen kann, welches Datenobjekt als Nächstes vollständig geprüft werden soll.
Ein Prozentwert löst dieses Problem nicht. „Mapping zu 80 Prozent fertig“ kann bedeuten, dass viele einfache Felder zugeordnet sind, während die wenigen noch offenen Regeln sämtliche Testdaten blockieren. Umgekehrt kann ein Datenobjekt mit zahlreichen dokumentierten Befunden bereits wertvoller sein, wenn jeder Befund einen Verantwortlichen und einen nächsten Prüfschritt hat.
Beginnen Sie beim letzten belastbaren Ergebnis
Für die Diagnose braucht die Projektleitung zunächst keine neue Gesamtplanung. Sie nimmt ein priorisiertes Datenobjekt – etwa Kunden, Lieferanten, Materialien oder offene Aufträge – und verfolgt dessen Weg rückwärts. An jeder Station wird nicht nach Aktivität, sondern nach einem überprüfbaren Ergebnis gefragt.
| Station | Belastbares Ergebnis | Wenn es fehlt |
|---|---|---|
| Datenauswahl | Bestätigte Quelle, Filter, Organisationseinheiten und einbezogene Datensätze | Der Datenumfang oder die Auswahlregel ist noch nicht entschieden. |
| Mapping | Versionierte Zuordnungs- und Transformationsregeln sowie sichtbar gebliebene Fachfragen | Fachliche Bedeutung und technische Regel sind noch nicht zusammengeführt. |
| Aufbereitung | Ein reproduzierbar erzeugter Datenbestand für das Zielsystem | Extraktion oder Transformation ist nicht ausführbar oder nur manuell wiederholbar. |
| Import | Ein eindeutig protokollierter Lauf in einer bekannten Zielumgebung | Importschnittstelle, Reihenfolge oder Zielkonfiguration blockiert. |
| Fachliche Prüfung | Vorbereitete Mengen-, Inhalts- und Prozessprüfungen mit dokumentierten Befunden | Prüfkriterien, Keyuser-Kapazität oder Freigabeverantwortung fehlt. |
Microsoft führt Datenumfang, Mapping, Transformation, Tests, Validierung sowie Rollen ebenfalls als eigenständige Bestandteile der Migrationsplanung auf. Das ist für die Engpassanalyse wichtig: Ein grüner Status an einer Station beweist nicht, dass die Übergabe zur nächsten funktioniert. Erst die Verbindung der Ergebnisse macht den Ablauf steuerbar.
Die erste Station ohne belastbaren Nachweis markiert nicht automatisch die einzige Ursache. Sie zeigt aber, wo die weitere Analyse beginnen muss. So wird aus einem allgemeinen Gefühl von Verzug eine konkrete Frage, die jemand entscheiden oder umsetzen kann.
Vier Engpässe brauchen vier unterschiedliche Reaktionen
Wenn der blockierte Übergang feststeht, sollte das Projekt den Engpass fachlich einordnen. Mehr Termine oder zusätzliche Personen helfen nur, wenn sie genau an dieser Stelle ansetzen.
1. Der Entscheidungsengpass
Die Quelldaten sind bekannt, aber Umfang, Wertzuordnungen oder Ausnahmen bleiben offen. Häufig werden diese Fragen in einer technischen Mapping-Tabelle gesammelt, obwohl die zuständigen Fachbereiche ihre Folgen dort nur schwer erkennen können.
Die passende Reaktion ist keine weitere offene Fragerunde. Jede Entscheidung braucht eine kurze Vorlage: Welche Daten oder Prozesse sind betroffen? Welche zwei oder drei Möglichkeiten bestehen? Was bedeutet jede Möglichkeit für Zielsystem, Test und Go-live? Wer darf entscheiden und bis wann wird die Entscheidung für den nächsten Lauf benötigt? Auf dieser Grundlage kann der Fachbereich urteilen, während die technische Umsetzung vorbereitet bleibt.
2. Der Umsetzungsengpass
Die fachlichen Regeln sind ausreichend klar, werden aber nicht zuverlässig in einen neuen Datenbestand überführt. Extraktionen hängen von Einzelwissen ab, Transformationen werden manuell in Dateien nachgearbeitet oder Änderungen lassen sich keinem Regelstand zuordnen.
Hier braucht das Projekt eine reproduzierbare technische Kette. Derselbe bestätigte Quellstand muss mit denselben Regeln erneut dasselbe Ergebnis erzeugen. Erst dann kann ein Testbefund dauerhaft in der Extraktion oder Transformation behoben werden, statt bei jedem Lauf neu in einer Datei korrigiert zu werden.
3. Der Zielsystemengpass
Die Daten sind vorbereitet, doch Importstruktur, Reihenfolge oder Zielkonfiguration bleiben unklar. Dieser Engpass gehört gemeinsam mit dem ERP-Partner bearbeitet, weil er die Anforderungen des neuen Systems und das Verhalten der Importschnittstelle verantwortet.
Die Migrationsseite sollte dafür einen kleinen, bekannten Datenbestand, die verwendete Struktur und ein vollständiges Protokoll liefern. Der ERP-Partner kann dann eine konkrete Zielvoraussetzung klären, statt eine wechselnde Datei zu untersuchen. Die Abgrenzung zwischen Zielsystemkompetenz und Datenmigrationsarbeit beschreiben wir ausführlicher im Beitrag „Reicht der ERP-Anbieter für die Datenmigration?“.
4. Der Prüfengpass
Daten sind im Testsystem angekommen, aber die Rückmeldung aus den Fachbereichen dauert zu lange oder bleibt widersprüchlich. Oft fehlt nicht nur Zeit. Keyuser erhalten ungefilterte Datensätze und sollen gleichzeitig Vollständigkeit, fachliche Richtigkeit und Prozessfähigkeit beurteilen.
Prüfungen müssen deshalb vorbereitet werden. Mengenabgleiche und technische Auffälligkeiten lassen sich vorab bündeln. Der Fachbereich entscheidet anschließend über fachliche Werte, Beziehungen und konkrete Geschäftsvorgänge. So wird seine knappe Zeit für Urteile genutzt, die kein Skript und kein externer Dienstleister übernehmen kann.
Ein Referenzobjekt stellt den vollständigen Ablauf wieder her
Ist die Migration an mehreren Stellen gleichzeitig offen, wirkt ein neuer Gesamtlauf verlockend. Er produziert jedoch häufig nur eine größere Warteschlange. Besser ist zunächst ein Referenzobjekt: ein überschaubarer, aber ausreichend repräsentativer Datenbestand, an dem Datenauswahl, Mapping, technische Aufbereitung, Import und fachliche Prüfung vollständig durchlaufen werden.
Das Referenzobjekt darf nicht bloß das einfachste Objekt ohne Beziehungen sein. Es sollte mindestens eine für das Projekt wichtige Transformationsregel, eine echte Abhängigkeit zum Zielsystem und eine fachlich prüfbare Wirkung enthalten. Gleichzeitig muss es klein genug bleiben, damit offene Entscheidungen und technische Ursachen sichtbar werden.
Dieser vollständige Weg liefert drei Dinge, die eine Statusliste nicht leisten kann:
- Er zeigt, welche Übergabe tatsächlich blockiert und welche vermeintlichen Probleme nur Folge davon sind.
- Er macht Bearbeitungs-, Warte- und Prüfzeiten sichtbar, sodass der weitere Terminplan nicht allein auf Schätzungen beruht.
- Er erzeugt einen wiederholbaren Ablauf, auf den weitere Datenobjekte aufbauen können.
Wie aus diesem gemessenen Ablauf eine belastbarere Projektprognose entsteht, zeigt unser Beitrag zur Dauer einer ERP-Datenmigration.
Der Go-live braucht eine neue Prognose, aber nicht automatisch einen neuen Termin
Verzug in einem Teil der Datenmigration bedeutet noch nicht zwingend, dass der Go-live verschoben werden muss. Die Projektleitung braucht jedoch eine neue Prognose, sobald der bisherige Termin auf Voraussetzungen beruht, die nachweislich nicht erfüllt sind.
Dafür werden die offenen Arbeiten nicht pauschal neu geschätzt. Stattdessen betrachtet das Projekt für die geschäftskritischen Datenobjekte:
- welche Entscheidungen noch vor der technischen Umsetzung fehlen,
- welche Regeln bereits reproduzierbar laufen und welche nur als Zwischenlösung bestehen,
- welche Zielvoraussetzungen der ERP-Partner bis zum nächsten Test bereitstellen muss,
- welche Prüfer und Freigaben in den verbleibenden Testfenstern realistisch verfügbar sind,
- welcher nächste vollständige Datenlauf die Go-live-Entscheidung tatsächlich belastbarer macht.
Auch SAP empfiehlt, Voraussetzungen je Aufgabe transparent zu machen und den tatsächlichen Zeitaufwand fortlaufend zu erfassen. Für ein festgefahrenes Projekt bedeutet das: Der alte Terminplan wird nicht einfach um neue Kalenderwochen verlängert. Er wird mit den jetzt bekannten Entscheidungen, Durchlaufzeiten und Abhängigkeiten neu begründet.
Ist bereits ein vollständiger Testlauf technisch oder fachlich gescheitert, beginnt die Diagnose an einem späteren Punkt. Dann hilft unser gesonderter Beitrag „ERP-Datenmigration fehlgeschlagen: So wird der nächste Testlauf belastbar“.
Wann externe Unterstützung die Datenmigration wirklich entlastet
Ein zusätzlicher Dienstleister kann fehlende Entscheidungen im Unternehmen nicht ersetzen. Er kann aber die operative Verbindung herstellen, wenn die offene Arbeit zwischen Fachbereichen, IT, ERP-Partner und technischer Umsetzung liegen bleibt.
Externe Unterstützung ist besonders sinnvoll, wenn drei Bedingungen zusammenkommen:
- Die Projektleitung kann den blockierten Übergang benennen, hat aber keine durchgängige Kapazität, ihn bis zum Prüfergebnis zu führen.
- Fachliche Entscheider und Zielsystemverantwortliche sind grundsätzlich verfügbar, benötigen jedoch vorbereitete Fragen, Datenstände und Prüfergebnisse.
- Das externe Arbeitspaket kann mit einem überprüfbaren Ergebnis enden, statt nur zusätzliche Koordination zu erzeugen.
Ein sinnvoller Einstieg muss deshalb nicht die gesamte Datenmigration umfassen. Er kann zunächst einen bestätigten Status der priorisierten Datenobjekte, die Wiederherstellung eines Referenzobjekts, eine geordnete Liste offener Entscheidungen und den Plan für den nächsten aussagefähigen Test liefern. Wir können dabei Altdaten analysieren, Mapping- und Transformationsregeln vorbereiten, die technische Aufbereitung umsetzen und Prüfnachweise strukturieren. Die Leitung des ERP-Gesamtprojekts bleibt bei der bestehenden Projektleitung.
Wenn Sie für diese Aufgabe Anbieter prüfen, sollten deren Angebote genau diesen Engpass und das erwartete Ergebnis abbilden. Unsere zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern helfen bei der Abgrenzung.
Diese Verantwortung bleibt beim Unternehmen
Auch in einer kritischen Projektsituation dürfen Verantwortung und operative Entlastung nicht verwechselt werden. Das Unternehmen entscheidet, welche Daten für seine Geschäftsprozesse benötigt werden, welche fachlichen Ausnahmen akzeptabel sind und wann ein Testergebnis freigegeben wird. Ebenso bleibt die Go-live-Entscheidung Teil der internen Projekt- und Unternehmensverantwortung.
Ein externer Datenmigrationsspezialist kann diese Entscheidungen so vorbereiten, dass ihre Auswirkungen sichtbar werden. Er kann die bestätigten Regeln technisch umsetzen, Testdaten reproduzierbar erzeugen und Abweichungen für die fachliche Bewertung aufbereiten. Gerade diese Trennung verhindert, dass der Dienstleister Entscheidungen trifft, die nur das Unternehmen fachlich verantworten kann – oder dass Keyuser technische Rekonstruktionsarbeit übernehmen müssen.
Die nächste sinnvolle Frage lautet: Welches Ergebnis fehlt zuerst?
Wenn eine ERP-Datenmigration in Verzug gerät, sollte das Projekt nicht gleichzeitig an jeder offenen Baustelle ziehen. Es wählt ein priorisiertes Datenobjekt, sucht dessen letztes belastbares Ergebnis und benennt die erste fehlende Übergabe. Daraus ergibt sich der nächste Auftrag: eine Entscheidung vorbereiten, eine technische Regel reproduzierbar machen, eine Zielvoraussetzung klären oder eine fachliche Prüfung ermöglichen.
Kann niemand diesen Weg für ein einziges wichtiges Datenobjekt nachvollziehen, ist die Rekonstruktion des aktuellen Arbeitsstands das erste notwendige Ergebnis. Ist der blockierte Übergang dagegen bekannt, lässt sich Unterstützung gezielt beauftragen. So entsteht nicht einfach mehr Aktivität, sondern wieder ein nachweisbarer Weg zum nächsten Test und zu einer belastbaren Go-live-Entscheidung.