Warum ERP-Migrationen aus dem Ruder laufen, lässt sich messen. Im ERP-Report 2024 von Panorama nannten 34,9 % der Projekte mit Budgetüberschreitung und 46,3 % der Projekte mit Zeitüberschreitung Datenprobleme als Ursache, in beiden Fällen unter den vier häufigsten Gründen. Diese Datenprobleme sind selten die Rohdaten, die sich nicht bewegen lassen. Es ist die Bedeutung, die sich nicht mitbewegt hat. Was folgt, ist: wo sich diese Bedeutung versteckt, warum sie darüber entscheidet, ob im neuen System am Ende die Zahlen stimmen, und wie man sie vor dem Go-Live wiederherstellt.
Der Export ist nicht das Problem
Fragt man Projektverantwortliche, was ihnen an der Migration Sorgen bereitet, ist der Datenexport selten die erste Antwort. Moderne ERP-Systeme, selbst alte auf einer SQL-Server-Datenbank, liefern die Tabellen. Die Sorge gilt der Bedeutung der Tabellen. Ein Feld namens status enthält die Ganzzahl 3, und nur das Altsystem, oder die Person, die es 2014 konfiguriert hat, weiß, dass 3 „zur Produktion freigegeben, aber noch nicht fakturiert“ bedeutet. Ein Custom Field, das vor fünf Jahren während einer Einführung ergänzt wurde, steuert eine Berechnung, von der die Hälfte der Berichte abhängt. Nichts davon ist dokumentiert. Es steckt im Verhalten der Software, und vielleicht in ein paar Köpfen, sofern diese Personen noch im Unternehmen sind.
Kryptische rohe Auftragsstatuscodes.
Ein Fertigungsunternehmen hat uns das bei der Planung seines Wechsels auf ein neues ERP-System beschrieben. Die Einschätzung war unverblümt: Nicht alles, was der Altanbieter modelliert hat, ist irgendwo abgebildet oder erklärt, also rechnete man damit, es umgehen zu müssen. Für eine echte ERP-Migration ist das der Normalzustand.
Was „undokumentiertes Mapping“ tatsächlich umfasst
„Geschäftslogik“ ist vage genug, um sie zu ignorieren, bis es zu spät ist, deshalb hilft es, konkret zu werden. In der Praxis sind es drei wiederkehrende Dinge:
- Status- und Typcodes. Jedes ERP-System kodiert den Zustand eines Auftrags, einer Lieferung oder einer Rechnung als Code, und was jeder Code bedeutet, ist eine lokale Entscheidung. Beim Wechsel auf ein neues System muss jemand festlegen, welcher alte Code welchem neuen entspricht, und das ist eine fachliche Entscheidung und kein einfacher Lookup.
- Custom Fields. Fast jede reale Einführung hat nach dem Go-Live Felder ergänzt, um etwas zu erfassen, das das Standardmodell nicht abdeckte. Sie speisen oft Berechnungen oder Filter, auf die es ankommt, und sie sind der am schlechtesten dokumentierte Teil des Systems, gerade weil sie unter Zeitdruck hinzugefügt wurden.
- Abgeleitete Logik und Workflow-Logik. Das Altsystem hat nicht nur Daten gespeichert, es hat Regeln angewendet. Dieser Auftragstyp überspringt einen Schritt, jener Kunde erhält eine andere steuerliche Behandlung, dieses Dokument kann nicht gebucht werden, solange ein anderes nicht existiert. Ein Teil dieser Logik muss die Migration überstehen, und in einem Rohexport ist sie unsichtbar.
Warum es undokumentiert bleibt
Nichts davon ist Nachlässigkeit. ERP-Anbieter modellieren dieses Verhalten selbstverständlich in ihrer Software und haben wenig Grund, jede kundenspezifische Konfiguration in Klartext zu erklären. Die Personen, die die Konfigurationsentscheidungen getroffen haben, wechseln weiter. Das verbleibende Wissen ist als Gewohnheit über das Team verteilt und nicht an einer Stelle festgehalten, die man nachlesen kann. Bei einem System, das ein Unternehmen ein Jahrzehnt lang betrieben hat, ist die Dokumentation das laufende System.
Die Logik in einer prüfbaren Form wiederherstellen
So geht Beetl vor: Wir behandeln die Daten und das Verhalten des Altsystems als Quelle der Wahrheit und rekonstruieren das Mapping daraus, statt aus einem Dokument, das es nicht gibt. Wir lesen die Tabellen, sehen uns an, wie sich die Werte tatsächlich verteilen, und schlagen ein Mapping vor: Dieser alte Code entspricht diesem neuen, dieses Custom Field speist diese Regel.
Rohdaten werden mit Mapping-Logik in verständliche Daten überführt.
Entscheidend ist, dass der Vorschlag prüfbar ist. Wir nutzen KI, um die Mapping-Definition zu entwerfen, denn sich durch Jahre angesammelter Konfiguration zu lesen, ist genau die Art von Arbeit, für die LLMs am besten geeignet sind. Das Ergebnis ist jedoch eine Definition, die ein Mensch lesen und freigeben kann, und keine Blackbox, die die Daten unsichtbar transformiert. Jemand, der das Geschäft kennt, sieht sich das vorgeschlagene Mapping an, korrigiert die Fälle, die die Daten allein nicht klären, und gibt es frei. Die Integration verschwindet nicht in einem undurchsichtigen Agenten. Sie wird zu einem expliziten, versionierten Artefakt, das festhält, was die Migration tun wird.
Der Abgleich ist die Nagelprobe
Ein wiederhergestelltes Mapping ist nur dann vertrauenswürdig, wenn die Zahlen stimmen. Für jede Gruppe von Datensätzen, die Kunden, die Produkte, die offenen Aufträge, die Forderungen, müssen die Summen auf der alten und der neuen Seite übereinstimmen, und die Ausnahmen müssen erklärt und nicht weggerundet werden. Dieser Abgleich zeigt, ob die undokumentierte Logik tatsächlich erfasst und nicht stillschweigend verloren wurde. Eine Migration, die ohne Fehler lädt, aber deren Zahlen nicht stimmen, hat meist genau die Geschäftslogik verloren, um die es in diesem Beitrag geht.
Vorher: 2 Zeilen tragen einen Statuscode ohne freigegebenes Mapping, deshalb schlägt die Gruppe Alarm, statt still durchzurutschen.
Nachher: Der nicht abgebildete Code ist aufgelöst, und eine Zeile bleibt zur Klärung durch einen Menschen in Prüfung.
Die Transformation explizit zu halten und das Ergebnis abgleichen zu können, statt einem Schritt zu vertrauen, in den man nicht hineinsehen kann, ist wie wir über Datenarbeit generell denken, nicht nur bei einer Migration.
Das Fazit
Wenn Sie eine ERP-Migration planen, legen Sie das Budget auf das Mapping statt auf den Export. Die Rohdaten werden umziehen. Ob das neue System die Wahrheit sagt, entscheidet sich daran, ob die undokumentierte Logik mitgekommen ist und ob Sie das überprüfen können. Die Datenprobleme, die in einem Drittel der Migrationen mit Budgetüberschreitung auftauchen, sind selten die Rohdaten. Es ist die Logik, die sich ohne ihre Bedeutung bewegt hat. Das Nützlichste, was wir bei einer Migration tun können, ist, diese verborgene Logik in etwas Explizites, Prüfbares und Abgeglichenes zu verwandeln, bevor sich jemand darauf verlässt.