Kunden, Lieferanten, Materialien, Stücklisten, offene Bestellungen und Bestände stehen gleichzeitig auf der Migrationsliste. Für alle fehlen noch Entscheidungen, und die verfügbaren Key-User können nicht alles parallel klären. Also beginnt das Projekt mit dem Objekt, dessen Importvorlage zuerst geliefert wurde – oder mit dem komplexesten Risiko. Beides kann dazu führen, dass viel gearbeitet wird, ohne früh ein belastbares Ergebnis zu erzeugen.
Welche Daten Sie zuerst migrieren sollten, entscheidet sich nicht allein nach Stammdaten vor Bewegungsdaten. Ein guter Start verbindet zwei Ziele: Ein überschaubares, relevantes Datenobjekt wird früh bis zu einem sichtbaren Testergebnis geführt. Gleichzeitig werden besonders kritische Objekte rechtzeitig analysiert, damit versteckte Risiken nicht erst kurz vor dem Go-live auftauchen.
Welche Daten zuerst migrieren? Zwei verschiedene Reihenfolgen trennen
Die Frage nach der Reihenfolge enthält eigentlich zwei Entscheidungen.
Die technische Importreihenfolge richtet sich nach Abhängigkeiten im Zielsystem. Ein offener Auftrag benötigt beispielsweise bereits angelegte Kunden und Materialien. Diese Vorgängerobjekte müssen im Testlauf zuerst geladen werden. ERP-Dokumentationen und Importwerkzeuge geben dafür häufig feste oder optionale Abhängigkeiten vor.
Die Bearbeitungsreihenfolge im Projekt bestimmt dagegen, welches Objekt zuerst analysiert, gemappt, aufbereitet und mit Key-Usern geprüft wird. Sie darf nicht erst am Tag des Imports entschieden werden. Für diese Reihenfolge zählen neben Abhängigkeiten auch Risiko, Sichtbarkeit, Zielsystembereitschaft und verfügbare Fachkapazität.
Ein Objekt kann deshalb sehr früh analysiert werden, obwohl es erst später vollständig importiert wird. Genau diese Trennung verhindert, dass das Team entweder am schwierigsten Thema stecken bleibt oder es bis zum Schluss verdrängt.
Der zweigleisige Start: ein sichtbares Ergebnis und ein früher Risikobeleg
In einem belasteten ERP-Projekt braucht die Projektleitung schnell zwei Arten von Sicherheit.
Erstens soll ein vollständiger kleiner Datenweg zeigen, dass Quelle, Mapping, Transformation, Import und fachliche Prüfung grundsätzlich zusammenspielen. Dafür eignet sich häufig ein bekanntes Objekt mit überschaubaren Beziehungen – etwa ein begrenzter Kunden- oder Lieferantenstamm mit seinen Kernfeldern.
Zweitens muss das Projekt wissen, ob ein geschäftskritisches, komplexes Objekt grundsätzlich beherrschbar ist. Bei einem Produktionsunternehmen können Stücklisten, Arbeitspläne, Rezepturen oder Variantenlogik entscheidend sein. Diese Objekte müssen früh untersucht werden. Sie müssen aber nicht zwingend als erstes in voller Breite fertig migriert werden.
Der Start besteht somit aus zwei parallelen Spuren:
- Ergebnisspur: Ein überschaubares Objekt durchläuft früh den gesamten Weg bis zu einem fachlich prüfbaren Zielstand.
- Risikospur: Ein kritisches Objekt wird so weit analysiert und prototypisch belegt, dass Quellen, Beziehungen, Zielbedarf und große Lücken sichtbar werden.
Sechs Kriterien für die Priorisierung der Datenobjekte
1. Fachliche Abhängigkeit
Welche anderen Datenobjekte benötigt der Zielprozess? Kundenaufträge setzen typischerweise Kunden, Materialien, Organisationseinheiten und gültige Werte voraus. Diese Beziehungen bestimmen sowohl die technische Importreihenfolge als auch die sinnvolle Vorbereitung.
Eine Abhängigkeit bedeutet jedoch nicht immer, dass das gesamte Vorgängerobjekt fertig sein muss. Für einen frühen Test kann ein bewusst begrenzter, zusammenhängender Teilbestand genügen.
2. Geschäftsrisiko
Welche Daten würden den Go-live oder einen zentralen Prozess gefährden, wenn ihre Struktur nicht rechtzeitig verstanden wird? Ein Objekt erhält eine hohe Risikopriorität, wenn seine Quelldaten unbekannt, seine Beziehungen komplex oder seine Zielanforderungen noch in Entwicklung sind.
Hohe Risikopriorität heißt zunächst: früh analysieren. Sie heißt nicht automatisch: als erstes vollständig umsetzen.
3. Sichtbarkeit und Prüfbarkeit
Erkennen Key-User ihre eigenen Daten im Zielsystem und können sie ein Ergebnis verständlich beurteilen? Kunden, Lieferanten und einfache Materialkerndaten besitzen häufig eine hohe Sichtbarkeit. Ein früher Erfolg schafft Vertrauen und liefert zugleich konkrete Rückmeldungen zur Zielkonfiguration.
4. Zielsystembereitschaft
Kann das neue ERP das Objekt bereits aufnehmen? Fehlen noch eine individuelle Entwicklung, eine organisatorische Struktur oder wichtige Auswahlwerte, kann die vollständige Migration blockiert sein. Trotzdem sind Quellanalyse, Mappingentwurf und ein begrenzter Prototyp oft schon möglich.
5. Verfügbare Fachkapazität
Welcher Key-User kann in den nächsten Wochen tatsächlich Entscheidungen treffen und Ergebnisse prüfen? Eine theoretisch ideale Reihenfolge hilft wenig, wenn der zuständige Fachbereich erst kurz vor dem Integrationstest verfügbar ist. Umgekehrt sollte ein Objekt nicht nur deshalb vorgezogen werden, weil gerade jemand Zeit hat; Abhängigkeit und Risiko bleiben maßgeblich.
6. Erkenntnisnutzen
Welches Objekt macht weitere Anforderungen sichtbar? Ein früher Kundenlauf kann fehlende Zahlungsbedingungen, Rollen oder Adressstrukturen offenlegen. Eine Stücklistenanalyse kann zeigen, ob Komponentenbeziehungen im Altsystem vorhanden sind und welche Materialgrundlagen zuvor benötigt werden.
Damit wird Datenmigration auch zur Systemerkundung: Echte Daten schärfen Anforderungen, die in allgemeinen Workshops noch abstrakt geblieben sind.
Warum das einfachste Objekt allein nicht genügt
Ein einfacher Kundenstamm kann schnell ein sichtbares Ergebnis liefern. Wenn die Produktion am ersten Tag jedoch vollständige Stücklisten und Arbeitspläne braucht, darf der frühe Erfolg nicht von diesem Risiko ablenken.
Deshalb sollte jedes Projekt neben dem ersten Umsetzungsobjekt mindestens ein kritisches Prüfobjekt benennen. Für dieses wird eine begrenzte Risikofrage beantwortet, zum Beispiel:
- Existieren Artikel-Komponenten-Beziehungen im Altsystem?
- Lassen sich Arbeitsgänge eindeutig ihren Arbeitsplänen zuordnen?
- Welche Variantenmerkmale werden im Zielprozess tatsächlich benötigt?
- Fehlen fachliche Informationen oder sind sie nur anders strukturiert?
- Welche noch nicht fertige Zielentwicklung beeinflusst das Mapping?
Ein kleiner technischer Nachweis oder eine strukturierte Datenvorschau kann hierfür ausreichen. Das Projekt gewinnt früh Gewissheit, ohne Wochen in einer vollständigen Ausarbeitung festzustecken.
Warum das schwierigste Objekt nicht vollständig zuerst kommen sollte
Das komplexeste Objekt besitzt meist viele Abhängigkeiten. Zielsystem, Fachentscheidung und Quellverständnis sind gleichzeitig noch unreif. Wird es zum einzigen Startpunkt, kann eine offene Frage den gesamten Migrationsfortschritt blockieren.
Dann erlebt das Projekt über Wochen Tabellenanalysen und Abstimmungen, aber noch keine eigenen Daten im neuen System. Key-User können kaum lernen, Rückmeldungen bleiben abstrakt und das Vertrauen sinkt.
Die bessere Grenze lautet: Das kritische Objekt wird so weit bearbeitet, bis seine größten Risiken beantwortet, seine Abhängigkeiten bekannt und ein realistischer nächster Schritt planbar sind. Danach kann die Ergebnisspur weiterlaufen, während fehlende Zielentwicklungen oder Fachentscheidungen gezielt nachgezogen werden.
Beim ersten Durchlauf reichen klare Kernfelder
Auch das erste sichtbare Objekt muss nicht sofort vollständig sein. Ein Kundenstamm kann zunächst Kundennummer, Name, Anschrift, Land und eindeutig zuordenbare Kommunikationsdaten enthalten. Unklare Rollen, seltene Merkmale oder noch fehlende Zielwerte bleiben als benannte Klärungspunkte sichtbar.
Diese Begrenzung ist kein unsauberes Weglassen. Sie braucht einen ausdrücklich festgelegten Testzweck und eine Liste der noch nicht abgedeckten Anforderungen. Der frühe Lauf soll beweisen, dass der Grundweg funktioniert und neue Erkenntnisse erzeugen – nicht eine finale Abnahme vortäuschen.
Wenn eine offene Frage den aktuellen Testzweck nicht verhindert, wird sie dokumentiert und später wieder aufgenommen. Wenn sie dagegen einen Schlüssel, eine notwendige Beziehung oder den betrachteten Geschäftsprozess betrifft, bleibt sie eine echte Blockade.
Eine einfache Priorisierungsmatrix statt Bauchgefühl
Für jedes Datenobjekt kann die Projektleitung sechs Kriterien mit „niedrig“, „mittel“ oder „hoch“ bewerten:
- Geschäftskritikalität zum Go-live,
- Unsicherheit in Quelle und Ziel,
- Zahl und Stärke der Abhängigkeiten,
- Zielsystem- und Importbereitschaft,
- Prüfbarkeit durch verfügbare Key-User,
- Nutzen eines frühen sichtbaren Ergebnisses.
Aus diesen Angaben wird keine scheinpräzise Gesamtpunktzahl benötigt. Stattdessen erhält jedes Objekt eine nächste Bearbeitungsart:
- vollständigen frühen Datenweg aufbauen,
- Risikoanalyse oder Prototyp vorziehen,
- notwendiges Vorgängerobjekt vorbereiten,
- auf benannte Zielvoraussetzung warten und parallel weiterarbeiten,
- für einen späteren Cut-over-Schritt vormerken.
So bleibt sichtbar, warum ein Objekt jetzt bearbeitet wird – und was das erwartete Ergebnis ist.
Beispiel: Kundenstamm und Stückliste gleichzeitig richtig beginnen
Ein Produktionsunternehmen führt ein neues ERP ein. Die Kundenstruktur ist weitgehend bekannt; bei Stücklisten besteht dagegen die Sorge, dass das Altsystem keine klassische Stücklistentabelle besitzt.
Auf der Ergebnisspur wird ein begrenzter Kundenbestand aufbereitet. Kernfelder, Anschriften und eindeutige Zuordnungen gelangen in das Testsystem. Key-User prüfen vertraute Kunden und entdecken früh, dass eine Zielrolle und zwei Zahlungsbedingungen noch fehlen.
Parallel untersucht die Risikospur die Produktionsdaten. Dabei zeigt sich, dass Komponenten nicht unter dem Namen „Stückliste“, wohl aber über Beziehungen zu Artikeln gespeichert sind. Damit ist noch keine vollständige Stücklistenmigration fertig. Das zentrale Risiko ist jedoch eingegrenzt: Die benötigte Grundbeziehung existiert, ihre Transformation und die noch fehlende Zielentwicklung können geplant werden.
Das Projekt gewinnt damit sowohl sichtbaren Fortschritt als auch frühe Risikosicherheit. Würde es nur Kunden bearbeiten, käme die Stücklistenfrage zu spät. Würde es ausschließlich an der kompletten Stückliste arbeiten, fehlte lange jedes prüfbare Ergebnis.
Iterative Objektrotation statt starrer Einbahnstraße
Nach dem ersten Lauf wird nicht zwangsläufig ein Objekt endgültig abgeschlossen. Häufig ist eine Rotation sinnvoll:
- Kundenkerndaten erzeugen und prüfen.
- Stücklistenbeziehungen analysieren und offene Zielanforderung benennen.
- Lieferantenkerndaten auf demselben technischen Weg aufbauen.
- Mit neuem Zielsystemverständnis zum Kundenmapping zurückkehren.
- Materialgrundlage für einen kleinen Stücklistenprototyp ergänzen.
- Erkenntnisse, Fehler und Laufzeiten in den nächsten gemeinsamen Test übernehmen.
Diese Arbeitsweise heißt nicht, ständig unfertige Themen zu wechseln. Jeder Wechsel erfolgt nach einem vorher benannten Zwischenergebnis: eine Datenvorschau, ein bestätigter Mappingstand, ein wiederholbarer Prototyp oder ein fachlich geprüfter Testbestand.
Der Beitrag Fortschritt einer ERP-Datenmigration messen zeigt, wie solche Ergebnisse je Datenobjekt als belastbarer Status geführt werden.
Cut-over-Daten früh markieren, aber zeitnah laden
Bestände, offene Aufträge, offene Bestellungen und Salden besitzen eine besondere Zeitlogik. Ihre Daten ändern sich bis kurz vor der Umstellung und müssen deshalb meist später als stabile Stammdaten final extrahiert werden. Trotzdem gehören sie früh in Analyse und Planung.
Schon während der Objektpriorisierung muss geklärt werden, welche Stammdaten sie voraussetzen, wie offene Vorgänge abgegrenzt werden und zu welchem Stichtag ihre Werte gelten. Sonst taucht kurz vor dem Go-live ein vermeintlich neues Datenobjekt auf, das zahlreiche bereits bearbeitete Bereiche verbindet.
Die operative Reihenfolge des Produktivlaufs gehört in den ERP-Cut-over-Plan der Datenmigration. Die fachliche Vorbereitung beginnt deutlich früher.
Woran die nächste richtige Priorität erkennbar ist
Vor jeder neuen Objektrotation sollte die Projektleitung drei Fragen beantworten:
- Welches konkrete Ergebnis benötigen wir für den nächsten Test?
- Welches Risiko wird gefährlich, wenn wir es in den kommenden Wochen nicht untersuchen?
- Welche Zielvoraussetzung und welche fachliche Person sind tatsächlich verfügbar?
Ein sinnvoll priorisiertes Objekt besitzt damit nicht einfach den höchsten abstrakten Rang. Es liefert jetzt ein benötigtes Ergebnis, klärt ein zeitkritisches Risiko oder schafft eine notwendige Voraussetzung für mehrere nachgelagerte Objekte.
Die Reihenfolge ist eine Projektentscheidung, keine Standardliste
„Stammdaten vor Bewegungsdaten“ bleibt eine nützliche Grundregel für Abhängigkeiten. Sie beantwortet aber nicht, womit ein konkretes Team morgen beginnen sollte. Dafür müssen Geschäftsrisiko, Zielreife, Datenlage, Key-User-Kapazität und Erkenntnisnutzen zusammen betrachtet werden.
Externe Unterstützung kann die Datenobjekte und ihre Abhängigkeiten erfassen, ein geeignetes frühes Umsetzungsobjekt auswählen, kritische Quellstrukturen parallel analysieren und die Objektrotation bis zu prüfbaren Ergebnissen führen. Der Kunde entscheidet, welche Prozesse zum Go-live geschäftlich unverzichtbar sind und gibt fachliche Regeln frei.
So entsteht weder eine bequeme Reihenfolge, die das größte Risiko verdrängt, noch ein heroischer Start am schwierigsten Objekt. Es entsteht eine Arbeitslogik, die schnell Vertrauen schafft und gleichzeitig die Überraschungen reduziert, die ein ERP-Projekt später teuer machen.