Welche Probleme treten bei einer ERP-Umstellung typisch auf?

Die typischen Probleme einer ERP-Umstellung sind selten technischer Natur. Fast immer sind es dieselben fünf Muster: die Datenqualität wird unterschätzt, das Altsystem wird im neuen System nachgebaut, niemand hat die Verantwortung wirklich am Tisch, getestet wird zu spät und zu wenig, und der Go-live folgt dem Kalender statt messbaren Kriterien. Wer diese fünf Muster kennt, erkennt sie früh und kann gegensteuern, bevor aus einem Problem eine Krise wird.

Problem 1: Die Datenqualität wird unterschätzt

Das neue System übernimmt die Daten des alten, und mit ihnen jede Dublette, jede veraltete Preisliste und jeden mehrdeutigen Stammsatz. Die Umstellung macht schlechte Daten nicht besser, sie macht sie sichtbarer. Deshalb gehört die Bereinigung der Stammdaten vor die Migration, nicht dahinter. Wer sie auf „nach dem Go-live“ verschiebt, verschiebt sie erfahrungsgemäß auf nie.

Problem 2: Das Altsystem wird nachgebaut

Jede Anpassung des Altsystems hatte einmal einen Grund. Viele dieser Gründe sind längst verschwunden, die Anpassungen leben trotzdem weiter, weil niemand mehr weiß, wofür sie da waren. Wer sie ungeprüft ins neue System übernimmt, bezahlt die Umstellung doppelt: einmal für die Migration und einmal für den Nachbau von Ballast. Die bessere Frage je Anpassung lautet nicht „wie bauen wir das nach“, sondern „welches Geschäft hängt daran“. Häufig deckt der Standard des neuen Systems den echten Bedarf ab.

Problem 3: Die Verantwortung sitzt nicht am Tisch

Eine ERP-Umstellung ist ein Geschäftsprojekt, kein IT-Projekt. Wenn Scope-Fragen wochenlang offen bleiben, weil niemand entscheiden darf, staut sich das Projekt, und der Umsetzungspartner arbeitet an dem weiter, was gerade da ist. In DGP-Projekten wird deshalb zuerst geklärt, wer entscheidet und wie schnell: klare Entscheidungswege sind der günstigste Beschleuniger, den eine Umstellung haben kann. Wie das aufgesetzt wird, zeigt die Antwort zur Projekt-Governance.

Problem 4: Getestet wird zu spät und zu freundlich

Ein Testlauf kurz vor dem Go-live, mit ausgewählten Daten und wohlwollenden Testern, findet genau die Fehler, die er finden soll: keine. Belastbar wird eine Umstellung durch mindestens zwei vollständige Migrationsläufe mit echten Daten und durch Tests, die von den Menschen kommen, die später damit arbeiten. Jeder gefundene Fehler vor dem Go-live ist billig. Derselbe Fehler danach kostet Lieferungen, Rechnungen und Vertrauen.

Problem 5: Der Go-live folgt dem Kalender

„Wir gehen am Ersten live, das ist so kommuniziert“ ist keine Go-live-Bedingung, sondern eine Hoffnung. Tragfähig ist ein Termin, der an messbaren Kriterien hängt: Migrationsläufe fehlerfrei, Schlüsselprozesse durchgespielt, Anwender geschult, Rückfallplan vorhanden. Fehlt eines davon, ist ein verschobener Go-live die günstigere Entscheidung, auch wenn sie unangenehm ist.

Woran Sie früh erkennen, dass die Umstellung kippt

Drei Frühsignale tauchen fast immer zuerst auf: offene Entscheidungen stapeln sich, der Umsetzungspartner fragt nicht mehr nach, und die eigenen Leute sprechen vom Projekt in der dritten Person. Wer eines davon beobachtet, braucht keinen Neustart, sondern eine ehrliche Standortbestimmung. Die Warnsignale im Detail und der Weg zurück stehen in den verwandten Antworten.