ERP Change Management: 3 Fehler, die Ihr Projekt trotz guter Software scheitern lassen

Ein mittelständisches Handelsunternehmen, rund 200 Mitarbeitende, hat 18 Monate in eine neue ERP-Einführung investiert. Budget: knapp siebenstellig. Ergebnis am Go-Live-Tag: Das System läuft technisch einwandfrei. Aber drei Wochen später arbeiten weite Teile des Einkaufs noch mit Excel-Tabellen neben dem neuen System. Der Vertrieb bucht Aufträge falsch, weil er die neuen Prozesse nicht versteht. Die Projektleiterin erhält täglich Eskalationen.

Das Systemhaus hat alles geliefert, was vertraglich vereinbart war. Trotzdem ist das Projekt gescheitert.

Diese Geschichte ist kein Einzelfall. Sie ist das Muster. Laut Standish Group Chaos Report scheitern über 60 Prozent aller ERP-Projekte daran, ihre ursprünglichen Ziele vollständig zu erreichen – Budgetüberschreitung, Terminverzug oder mangelnde Nutzerakzeptanz. Prosci, eines der führenden Change-Management-Forschungsinstitute, kommt in mehrjährigen Studien zu dem Ergebnis, dass Projekte mit strukturiertem Change Management sechsmal häufiger ihre Ziele erreichen als solche ohne.

Bevor wir zu den Fehlern kommen, eine kurze Einordnung – denn Change Management wird im ERP-Kontext oft missverstanden.

ERP Change Management bedeutet im Kern:

ERP Change Management bedeutet nicht:

In der Mehrzahl der ERP-Projekte, die ich begleitet oder übernommen habe, war Change Management kein eigenständiger Workstream vom Projektstart an. Es war ein Punkt auf der Agenda für die letzten sechs bis acht Wochen vor Go-Live. Sprich: Schulungen, Kommunikation, Trainings – alles aufgestaut auf einen Zeitraum, in dem das Projektteam ohnehin am stärksten unter Druck steht.

Das ist strukturell falsch.

Change beginnt nicht, wenn das System steht. Change beginnt mit der Entscheidung für ein neues System. Denn ab diesem Moment verändert sich etwas für die Menschen, die damit arbeiten werden – ob sie es wissen oder nicht. Wer dieses Fenster ungenutzt lässt, zahlt es später.

Ein konkretes Beispiel: Bei einem Projekt im Großhandel haben wir die Stakeholder-Analyse erst in Woche 14 von 52 durchgeführt. Dabei wurde sichtbar, dass zwei Abteilungsleiter grundlegend gegen das Projekt eingestellt waren, weil sie über ihre eigenen Prozessveränderungen nie informiert worden waren. Hätten wir das in Woche zwei gewusst, wäre ein gezieltes Einbindungsgespräch der richtige Schritt gewesen. In Woche 14 war das Verhältnis bereits beschädigt.

ERP-Projekte werden oft von einer kleinen Kerngruppe gesteuert: IT-Leitung, externer Berater, Projektleiter aus dem Business. Der Rest des Unternehmens hört davon über Flurgespräche, eine interne E-Mail oder – im schlechtesten Fall – erst bei der Erstschulung vier Wochen vor Go-Live.

Was fehlt, ist eine bewusst aufgebaute Schicht von internen Multiplikatoren: Key User, die frühzeitig eingebunden werden, das System kennen, Fragen aus dem Team beantworten können und das Projekt aktiv mittragen.

Gute Key User haben drei Eigenschaften: Sie genießen Vertrauen in ihrem Team (nicht nur fachliche Autorität), sie haben ein echtes Verständnis für die relevanten Prozesse, und sie kommunizieren klar. Es geht nicht darum, die enthusiastischsten Personen auszuwählen – sondern die glaubwürdigsten. Für ihre Einbindung sollte realistisch mit zehn bis zwanzig Prozent ihrer Kapazität in der intensiven Projektphase gerechnet werden. Wer das nicht einplant, bekommt Multiplikatoren auf dem Papier, die im Alltag keine Zeit haben.

Ich habe erlebt, wie ein einzelner Key User in der Logistik eines mittelständischen Unternehmens mehr zur Akzeptanz des neuen Systems beigetragen hat als alle offiziellen Schulungen zusammen. Er hat in der Pause Fragen beantwortet, nach der Schicht kurze Walkthroughs gemacht und früh gezeigt: Das System macht meinen Job einfacher, nicht schwerer. Diese Person war kein Change Manager. Sie war jemand, der frühzeitig eingebunden worden war und den Mehrwert persönlich erlebt hatte.

Unternehmen messen in ERP-Projekten sehr viel: Meilensteine, Budgetverbräuche, Testabdeckung, Schulungsteilnehmer. Was sie fast nie messen: Wie hoch ist die tatsächliche Bereitschaft und Befähigung der Belegschaft, mit dem neuen System zu arbeiten?

Eine strukturierte Befragung unter Key Usern vier bis sechs Wochen vor Go-Live liefert mehr handlungsrelevante Information als jedes Statusmeeting. Drei Fragen, die dabei regelmäßig die stärkste Signalwirkung haben:

Wenn auf Frage drei mehrheitlich Nein kommt, ist das kein Schulungsproblem. Es ist ein Führungsproblem.

Diese Erkenntnisse sind die Grundlage für eine fundierte Go-Live-Entscheidung: Wenn die Readiness-Messung unter einem definierten Schwellenwert liegt, ist ein verschobener Go-Live fast immer günstiger als ein chaotischer. Ein Projekt, das eine Woche später startet, aber sauber läuft, kostet weniger als ein Go-Live-Tag, der drei Monate Nacharbeiten nach sich zieht.

Es geht nicht darum, Mitarbeitende für das neue System zu begeistern. Es geht darum, Reibungsverluste zu minimieren und die Arbeitsfähigkeit des Unternehmens am und nach dem Go-Live zu sichern.

Widerstände früh sichtbar machen. Widerstand gegen Veränderung ist normal. Er ist kein Zeichen von schlechtem Willen, sondern von menschlicher Reaktion auf Unsicherheit. Wer ihn ignoriert, verstärkt ihn. Wer ihn früh adressiert – durch Einbindung, Information und ehrlichen Dialog – kann ihn kanalisieren.

Führungskräfte als Enabler positionieren. Die mittlere Führungsebene ist in ERP-Projekten die entscheidende Schnittstelle. Wenn diese Ebene nicht überzeugt ist, scheitert die Umsetzung in der Breite – unabhängig davon, was die Geschäftsführung kommuniziert.

Trainings auf Prozesse ausrichten, nicht auf Klickpfade. Der klassische Fehler in ERP-Schulungen: Es wird gezeigt, wo man was klickt. Nicht erklärt, warum ein Prozess so gestaltet ist, wie er gestaltet ist. Mitarbeitende, die den Prozess verstehen, kommen mit Varianten im Alltag zurecht. Mitarbeitende, die nur Klickpfade gelernt haben, rufen beim ersten unerwarteten Fall den Helpdesk an. Wie die Prozesslogik sauber dokumentiert und aufgesetzt wird, ist deshalb idealerweise bereits Teil der ERP-Vorbereitung mit ERPulse360 – bevor das Systemhaus mit der Konfiguration beginnt.

ERP-Systeme sind heute technisch ausgereift. Die Ursache für Projektversagen liegt fast nie in der Funktionalität. Sie liegt in der Organisation, die das System nutzen soll – und die in den meisten Projekten zu spät, zu oberflächlich und ohne strukturierte Methodik auf die Veränderung vorbereitet wird.

Wer das ernst nimmt, gibt einem ERP-Projekt eine deutlich bessere Ausgangslage.

Diese Frage lässt sich beantworten – bevor es kritisch wird. In einem kostenlosen 30-minütigen Change-Readiness-Gespräch analysieren wir gemeinsam, wo Ihr Projekt steht: Welche Risikofelder im Bereich Akzeptanz und Befähigung bereits sichtbar sind – und welche Schritte als nächstes sinnvoll wären.

Idealerweise mit dem Projektstart – spätestens aber in den ersten vier bis sechs Wochen. Wer Change Management erst kurz vor Go-Live beginnt, kann Widerstände nicht mehr strukturiert bearbeiten, sondern nur noch reagieren.

Die direkten Kosten entstehen durch verlängerten Support-Bedarf, Fehleingaben, Parallelarbeit in Excel und verzögerte Prozessstabilisierung. Erfahrungswerte aus der Praxis zeigen, dass Projekte ohne strukturiertes Change Management im Schnitt drei bis sechs Monate länger brauchen, bis sie stabil laufen – bei gleichzeitig höherer Mitarbeiterfluktuation in betroffenen Bereichen.

Mit einem strukturierten Kurzfeedback unter Key Usern und Führungskräften, das Befähigung, Orientierung und Vertrauen in das Projekt abfragt. Drei bis fünf Fragen reichen, wenn sie die richtigen Dimensionen treffen. Entscheidend ist nicht die Methodik, sondern dass die Ergebnisse tatsächlich zu Konsequenzen führen.

Quellen: Standish Group CHAOS Report (2020/2023); Prosci Best Practices in Change Management (11. Auflage, 2023)