Die meisten ERP-Migrationen starten mit einem Zieltermin und enden mit einer Überraschung. Die Überraschung steckt fast immer im Bestand: Custom-Felder, die niemand mehr erklären kann, Schnittstellen, die nur eine Person kennt, Datenbestände mit Duplikaten und Lücken, die erst beim Mapping auffallen. Discovery heißt, diese Überraschungen vorzuziehen, solange sie planbar sind statt teuer.
Deshalb beginnt jeder ERP-Wechsel bei mir mit einer dokumentierten Bestandsaufnahme. Sie erfasst, was wirklich läuft, nicht, was die Systemdokumentation behauptet. Die liegt in gewachsenen Umgebungen selten vollständig vor.
Was die Discovery dokumentiert
Drei Ebenen. Erstens die Altsysteme selbst: Erweiterungen, Sonderfälle, Konfigurationsstände. Zweitens die Schnittstellen, einschließlich manuell gepflegter Übersetzungstabellen und Datei-Exporte, die in keiner Architektur-Skizze auftauchen. Drittens die Datenbestände: Duplikate, Lücken, Felder, deren Bedeutung sich über die Jahre verschoben hat. Wie weit das gehen kann, zeigt eine M&A-Integration aus meiner Projektpraxis: Die Legacy-Systeme des übernommenen Unternehmens waren nicht dokumentiert, die Discovery lief als Reverse-Engineering, jede Schnittstelle wurde einzeln nachvollzogen und festgehalten.
Der Zieltermin folgt aus dem Befund
Wer den Go-Live-Termin vor der Discovery fixiert, plant gegen unbekannte Risiken. Der Befund zeigt, welche Bestände migrationsfähig sind, wo Mapping-Risiken liegen und was das für Aufwand und Reihenfolge bedeutet. Erst danach ist ein Termin belastbar; unrealistische Zeitpläne gehören zu den fünf häufigsten Fehlern in ERP-Migrationen.
Bereinigen im Projekt, nicht davor
Discovery bedeutet nicht, monatelang Daten zu putzen und dann zu starten. Wer die Bereinigung dem Projekt vorschaltet, bereinigt Bestände, die währenddessen weiter veralten. Warum diese Data-First-Reihenfolge Projekte ausbremst, habe ich ausführlich beschrieben. Die Discovery macht Datenprobleme sichtbar und priorisiert sie; bereinigt wird im Projektkontext, dort, wo ein Feld tatsächlich gebraucht wird. Das Ergebnis ist die Arbeitsgrundlage für das anschließende Feld-für-Feld-Mapping.