ERP-Migration-Risiken werden meist nicht erst am Go-live sichtbar. Sie zeigen sich früher: Der Datenumfang bleibt beweglich, Entscheidungen kehren in Meetings wieder, Testdateien lassen sich nicht reproduzieren oder ein technisch erfolgreicher Import liefert keinen fachlichen Nachweis. Wer diese Warnsignale vor dem nächsten Test erkennt, kann noch gezielt handeln, bevor aus einer offenen Frage ein Terminproblem wird.
Entscheidend ist deshalb nicht, ob im Projekt viel gearbeitet wird. Entscheidend ist, ob für die kritischen Datenobjekte überprüfbare Ergebnisse entstehen. Genau an dieser Lücke lassen sich Risiken früher erkennen als an einer allgemeinen roten Ampel im Projektbericht.
ERP-Migration-Risiken zeigen sich als fehlende Nachweise
Ein Risiko ist zunächst eine mögliche Entwicklung, keine bereits eingetretene Störung. Für die Projektleitung wird es greifbar, wenn sie nach einem notwendigen Ergebnis fragt und dafür keinen belastbaren Nachweis erhält. Vor einem Test könnte das beispielsweise eine freigegebene Mapping-Regel, eine wiederholbar erzeugte Importdatei oder eine dokumentierte Sollmenge sein.
Diese Sicht verändert die Steuerung. Statt nur zu fragen, ob eine Aufgabe „in Arbeit“ ist, wird geprüft, welches Ergebnis bis zum nächsten Meilenstein vorliegen muss und wodurch es belegt wird. Dadurch werden allgemeine Risiken zu konkreten Entscheidungen.
Warnfeld 1: Der Datenumfang wächst leise weiter
Zu Beginn stehen im Plan vielleicht Kunden, Lieferanten und Materialien. Später kommen Ansprechpartner, Bankverbindungen, Mengeneinheiten, Einkaufsrollen, offene Vorgänge oder Bestände hinzu. Das ist nicht automatisch schlechte Planung, denn das Zielsystem und die künftigen Prozesse werden während der Einführung genauer verstanden.
Zum Risiko wird die Entwicklung, wenn neue Teilmengen nur in Besprechungsnotizen oder einzelnen Importvorlagen auftauchen. Dann wächst die Arbeit, ohne dass Termin, Verantwortlichkeit und Testumfang nachgezogen werden. Ein grober Objektname vermittelt weiterhin Stabilität, obwohl sein tatsächlicher Inhalt längst größer geworden ist.
Der notwendige Nachweis ist ein gepflegter Datenumfang, der auch Teilmengen und Abhängigkeiten sichtbar macht. Zu jedem Punkt sollte erkennbar sein, ob er automatisiert migriert, manuell ergänzt, bewusst ausgeschlossen oder noch entschieden wird. Wenn das vor dem nächsten Test nicht möglich ist, muss der Meilenstein neu bewertet werden.
Warnfeld 2: Dieselben Entscheidungen tauchen immer wieder auf
Ein Termin endet mit einem fachlich nachvollziehbaren Gespräch. Beim nächsten Termin wird dieselbe Frage erneut geöffnet. Das kann passieren, obwohl alle Beteiligten ihren Teil beigetragen haben: Der neue ERP-Anbieter beschreibt das Zielfeld, der alte Anbieter zeigt verfügbare Quellen und der Fachbereich erklärt die bisherige Nutzung. Was fehlt, ist eine eindeutige Regel, die diese Aussagen verbindet.
Ein Gesprächsprotokoll genügt dafür nicht immer. Die Entscheidung muss unmittelbar in das Mapping, die Exportanforderung oder die Transformationsregel überführt werden. Sonst bleibt unklar, welcher Wert technisch erzeugt werden soll und wer ihn fachlich bestätigt hat.
Das Warnsignal lautet daher nicht „zu viele Meetings“, sondern „keine umsetzbare Regel nach dem Meeting“. Wird es sichtbar, sollte die nächste Besprechung mit einer konkreten Entscheidungsfrage, bekannten Quellfeldern, Zielbedeutung und möglichen Varianten vorbereitet werden.
Warnfeld 3: Eine Datei funktioniert, der Prozess dahinter aber nicht
Eine manuell bearbeitete Datei kann einen ersten Import ermöglichen. Bei mehreren Testläufen entsteht jedoch ein Risiko, wenn niemand sicher sagen kann, wie dieselbe Datei mit einem aktuellen Datenstand erneut erzeugt wird. Dann stecken Regeln in kopierten Spalten, einzelnen Formeln oder den Handgriffen einer Person.
Spätestens wenn sich ein Mapping ändert, muss die Bearbeitung nachvollziehbar wiederholt werden können. Dazu braucht es eine unveränderte Quelle, dokumentierte Auswahl- und Transformationsregeln sowie eine eindeutige Version des erzeugten Bestands. Ob dafür SQL, ein geeignetes Werkzeug oder ein kontrollierter anderer Prozess verwendet wird, hängt vom Projekt ab. Der Nachweis bleibt derselbe: Ein zweiter Lauf mit denselben freigegebenen Regeln erzeugt ein erklärbares Ergebnis.
Fehlt dieser Nachweis vor dem ersten größeren Test, wächst das Risiko mit jedem späteren Korrekturlauf. Dann werden nicht nur Daten geändert; es verändert sich möglicherweise unbemerkt auch die angewendete Logik.
Warnfeld 4: Ein grüner Import ersetzt die fachliche Prüfung
Das Importwerkzeug meldet Erfolg und im Zielsystem sind Datensätze sichtbar. Damit ist bewiesen, dass der technische Ladevorgang funktioniert hat. Noch offen bleibt, ob alle vorgesehenen Datensätze angekommen sind, Beziehungen stimmen und die Werte in den künftigen Prozessen richtig verwendet werden.
Vor dem Test sollten deshalb Sollbestände und Prüfkriterien feststehen. Mengenabgleiche zeigen beispielsweise, ob eine Auswahl oder Verknüpfung Daten verloren hat. Stichproben können Transformationsregeln nachvollziehen. Prozessprüfungen zeigen schließlich, ob ein migrierter Lieferant bestellbar ist, ein Material disponiert werden kann oder ein offener Vorgang korrekt fortgeführt wird.
Der Beitrag Datenvalidierung bei der ERP-Migration erläutert, wie technischer Import, fachliche Richtigkeit und Abnahme voneinander getrennt werden.
Warnfeld 5: Der erste realistische Test kommt zu spät
Ein Test mit wenigen einfachen Musterdatensätzen kann den Importweg prüfen. Er zeigt jedoch nicht, ob gewachsene Datenstrukturen, Sonderfälle und Beziehungen des Unternehmens beherrscht werden. Bleiben reale Varianten bis kurz vor dem Go-live außen vor, werden notwendige Mapping- und Konfigurationsänderungen erst dann sichtbar, wenn die verbleibende Zeit knapp ist.
Ein früher Test muss noch nicht den vollständigen späteren Umfang enthalten. Er sollte aber gezielt schwierige und repräsentative Fälle enthalten: unterschiedliche Organisationseinheiten, abweichende Einheiten, mehrteilige Beziehungen, fehlende Werte und mindestens einen vollständigen Geschäftsprozess. Dadurch entsteht früh fachliches Lernen, das in den nächsten Lauf zurückfließen kann.
Welche Ergebnisse vor dem ersten ernsthaften Testlauf benötigt werden, fasst die ERP-Migrations-Checkliste für den ersten Testlauf zusammen.
Warnfeld 6: Für den letzten Datenstand gibt es noch keinen Plan
Zwischen einem erfolgreichen Test und dem produktiven Wechsel arbeiten die Mitarbeitenden im alten ERP weiter. Kunden ändern Adressen, neue Aufträge entstehen, Bestände bewegen sich und offene Posten werden ausgeglichen. Der letzte Lauf muss deshalb beantworten, welcher Datenstand gilt und wie Änderungen seit dem Test berücksichtigt werden.
Das kann je nach System ein vollständiger Schlusslauf, eine Delta-Übernahme oder eine Kombination mit einem Datenstopp sein. Delta bezeichnet hier die Veränderungen seit einem festgehaltenen Ausgangsstand. Riskant ist nicht die Wahl einer bestimmten Variante, sondern eine ungeklärte Variante: unbekannter Ausgangsstand, nicht getestete Auswahlregeln oder fehlende Zeit für den abschließenden Vergleich.
Der Cutover-Plan für die Datenmigration ordnet diese Aufgaben in den produktiven Wechsel ein.
Warnfeld 7: Verantwortung endet an Systemgrenzen
Der alte Anbieter liefert Daten, der neue Anbieter stellt eine Importvorlage bereit und der Kunde soll die fachliche Richtigkeit bestätigen. Jede dieser Zuständigkeiten ist für sich nachvollziehbar. Trotzdem bleibt eine Lücke, wenn niemand Quelle, Ziel, Transformation, Test und offene Entscheidung je Datenobjekt zusammenführt.
Diese Lücke lässt sich nicht durch einen allgemeinen Hinweis auf die Gesamtverantwortung des Kunden schließen. Der Kunde muss fachlich entscheiden und freigeben. Dafür benötigt er jedoch vorbereitete Entscheidungsgrundlagen und technisch prüfbare Ergebnisse. Die operative Verbindung zwischen den Systemgrenzen ist eine eigene Leistung.
Eine Risikomatrix muss zur nächsten Entscheidung führen
Ein Risikoregister ist sinnvoll, wenn es nicht bei allgemeinen Formulierungen stehen bleibt. Für die Datenmigration sollte jeder kritische Punkt mit einem betroffenen Datenobjekt, dem nächsten Meilenstein und einem fehlenden Nachweis verbunden werden.
| Beobachtung | Fehlender Nachweis | Nächste Entscheidung |
|---|---|---|
| Umfang wächst | Vollständige Teilmengen und Abhängigkeiten | Testumfang, Kapazität oder Termin anpassen |
| Frage kehrt wieder | Freigegebene Mapping- oder Transformationsregel | Entscheider und konkrete Varianten festlegen |
| Datei ist manuell entstanden | Wiederholbarer Erzeugungslauf | Regel dokumentieren und technisch reproduzieren |
| Import ist technisch grün | Vollständigkeits- und Prozessprüfung | Fachliche Abnahme vorbereiten |
| Go-live-Datenstand unklar | Getesteter Schlusslauf samt Abgleich | Voll-, Delta- und Stopplogik verbindlich wählen |
Damit wird aus „Datenmigration könnte sich verspäten“ eine steuerbare Aussage. Die Projektleitung sieht, welches Ergebnis fehlt, welche Folge droht und wer jetzt entscheiden oder umsetzen muss.
Mehr Ampeln, Meetings oder Werkzeuge lösen nicht jedes Risiko
Zusätzliche Statusberichte können Transparenz schaffen. Weitere Meetings können fachliche Entscheidungen ermöglichen. Ein Migrationstool kann wiederholbare technische Abläufe unterstützen. Keine dieser Maßnahmen ist grundsätzlich falsch.
Sie greift jedoch zu kurz, wenn die konkrete Ursache eine andere ist. Eine Ampel erzeugt keine Transformationsregel, ein Meeting ersetzt keine vorbereitete Entscheidungsfrage und ein Werkzeug bestimmt nicht den fachlich richtigen Zielwert. Bevor das Projekt eine Maßnahme verstärkt, sollte es deshalb klären, welcher Nachweis fehlt und warum er bisher nicht entstehen konnte.
Früh handeln heißt nicht, sofort alles neu zu planen
Wenn mehrere Warnsignale auftreten, braucht das Projekt zuerst ein ehrliches Lagebild je kritischem Datenobjekt. Welche Zielanforderungen sind geklärt? Wo sind die Quellen bekannt? Welche Regeln sind bestätigt? Kann der Bestand wiederholbar erzeugt werden? Was wurde technisch und fachlich getestet? Aus diesen Antworten ergibt sich, welche wenigen Lücken den nächsten Meilenstein tatsächlich gefährden.
Wir nutzen diese Sicht, um Risiken nicht nur zu benennen, sondern in konkrete Analyse-, Mapping-, Transformations- und Testarbeit zu übersetzen. Fachliche Entscheidungen und Freigaben bleiben beim Kunden. Wo intern Zeit oder technische Verbindungskompetenz fehlt, können wir die notwendigen Grundlagen vorbereiten und die Umsetzung bis zu einem prüfbaren Ergebnis führen.
ERP-Migration-Risiken werden dadurch nicht vollständig verschwinden. Sie werden aber früher sichtbar, klarer priorisiert und mit einer konkreten nächsten Entscheidung verbunden. Genau das verhindert, dass der erste eindeutige Befund erst am Testtag oder im Cutover entsteht.