Ist Ihr ERP-Projekt gefährdet? 10 Warnsignale im Risiko-Check

ERP-Projekte scheitern selten spektakulär. Es gibt keinen lauten Knall. Kein einzelnes Ereignis, nach dem alle sagen: „Jetzt ist es passiert.“ Stattdessen gibt es eine schleichende Erosion. Termine verschieben sich um zwei Wochen. Dann um vier. Anforderungen, die längst geklärt sein sollten, tauchen in neuer Form wieder auf. Das Systemhaus liefert, aber das Gelieferte entspricht nicht den Erwartungen. Die Key-User sind überlastet, die Geschäftsführung bekommt widersprüchliche Signale.

In unserer Beratungspraxis bei Innovera sehen wir dieses Muster regelmäßig. Der Moment, in dem ein ERP-Projekt wirklich in Gefahr gerät, liegt fast immer Wochen oder Monate vor dem Moment, in dem die Beteiligten es sich eingestehen. Und genau diese Zeitspanne – zwischen erstem Warnsignal und bewusster Reaktion – entscheidet über den Preis der Korrektur.

Je früher ein Risiko erkannt wird, desto mehr Handlungsoptionen bleiben. Und desto günstiger ist die Lösung. Eine Scope-Korrektur im Konzept kostet einen Workshop. Dieselbe Korrektur nach dem Go-live kostet Monate und sechsstellige Beträge.

“Die teuersten Probleme in ERP-Projekten sind nicht die, die auftreten – sondern die, die zu spät erkannt werden.”

– Stefan Radau, Innovera Consulting

Diese Problemfelder sind keine Überraschungen. Sie sind vorhersehbar, messbar und in den meisten Fällen vermeidbar. Im Folgenden beschreiben wir zehn Warnsignale, die wir in der Praxis immer wieder sehen – und für jedes die Gegenmaßnahmen, die sich bewährt haben.

Es beginnt harmlos. In einem Workshop fällt jemandem auf, dass man „doch auch noch“ die Lagerverwaltung für Außenläger abbilden könnte. Oder dass der Vertrieb eine Provisionslösung braucht, die bisher nicht eingeplant war. Einzeln betrachtet sind das vernünftige Anforderungen. In Summe führen sie dazu, dass der Projektumfang um 30–50 % über den ursprünglichen Scope hinauswächst – ohne dass Budget oder Zeitplan angepasst werden.

Scope Creep ist das häufigste Risiko in ERP-Projekten. Nicht weil Unternehmen unvernünftig agieren, sondern weil ein ERP-Projekt Bedürfnisse sichtbar macht, die vorher unter der Oberfläche lagen. Das Problem entsteht nicht durch die Anforderungen selbst, sondern durch fehlende Priorisierung und fehlende Entscheidungsmechanismen.

Die besten Mitarbeiter im Fachbereich sind fast immer auch die, die im Tagesgeschäft am schwersten zu entbehren sind. Genau deshalb werden Key-User häufig nur mit halber Kraft ins ERP-Projekt eingebunden – oder mit Mitarbeitern besetzt, die im Fachbereich entbehrlich sind, aber nicht die notwendige Prozesstiefe mitbringen.

Das Ergebnis ist vorhersehbar: Workshops werden verschoben, Entscheidungen verzögert, Testergebnisse sind oberflächlich. Das ERP-System wird am Fachbereich vorbei konfiguriert. Wir haben Projekte gesehen, in denen ganze Module nach dem Go-live umgebaut werden mussten, weil die Key-User de facto nicht Teil des Projekts waren.

Ein ERP-Projekt ohne aktiven Sponsor in der Geschäftsführung ist wie ein Schiff ohne Kapitän. Es bewegt sich – aber niemand steuert. Management-Sponsorship bedeutet nicht, beim Kick-off eine motivierende Rede zu halten. Es bedeutet: Entscheidungen treffen, wenn das Projektteam nicht weiterkommt. Ressourcenkonflikte lösen. Öffentlich zum Projekt stehen, wenn Widerstände aufkommen.

Wenn die Geschäftsführung das ERP-Projekt an die IT-Abteilung delegiert und danach nicht mehr auftaucht, sendet das eine klare Botschaft an die Organisation: „Das ist kein strategisches Vorhaben, das ist ein IT-Projekt.“ Und IT-Projekte haben in den meisten mittelständischen Unternehmen nicht die Priorität, die ein ERP-Vorhaben braucht.

Eine einmalige Verschiebung kann passieren. Krankheit, unerwartete technische Hürden, externe Faktoren – das gehört zu Projekten dazu. Wenn aber der Zeitplan zum dritten Mal angepasst wird und die Begründung jedes Mal ähnlich klingt („Wir brauchen noch etwas mehr Zeit für die Abstimmung“), dann liegt das Problem nicht im Zeitplan. Dann liegt es in der Projektstruktur.

Wiederholtes Rutschen ist ein Symptom. Die Ursache ist fast immer eine Kombination aus: unklaren Verantwortlichkeiten, fehlenden Entscheidungsprozessen und unrealistischer Planung, die von Anfang an zu optimistisch war. Je länger das Muster anhält, desto größer wird die Frustration – und desto wahrscheinlicher der nächste Verzug.

Die Datenmigration ist das Stiefkind vieler ERP-Projekte. Sie wird systematisch unterschätzt – im Aufwand, in der Komplexität und in der Bedeutung für den Go-live. Wenn in der zweiten Projekthälfte noch keine einzige Testmigration gelaufen ist, steht das Projekt vor einem ernsthaften Problem.

Daten sind das Fundament jedes ERP-Systems. Stammkunden, Artikeldaten, Stücklisten, offene Posten, Lagerbestandsdaten – all das muss nicht nur migriert, sondern vorher bereinigt, harmonisiert und im neuen System validiert werden. Das dauert länger als jeder denkt. Und die Qualität der Daten im Altsystem ist fast immer schlechter als angenommen.

Unter Zeitdruck ist die Testphase das Erste, was gekürzt wird. Die Argumentation klingt logisch: „Wir haben die Prozesse im Workshop durchgesprochen, die Key-User kennen das System.“ In der Realität zeigen sich die wirklich kritischen Probleme erst im Integrations- und End-to-End-Test – wenn Prozesse modulübergreifend zusammenspielen müssen.

Wir haben Projekte erlebt, in denen der Go-live um Monate verschoben werden musste, weil zentrale Prozesse – Auftragsabwicklung, Fakturierung, Bestandsführung – im Zusammenspiel nicht funktionierten. Die Einzeltests hatten keine Probleme gezeigt. Die Integration war nie getestet worden.

Ein neues ERP-System verändert die tägliche Arbeit von Dutzenden oder Hunderten von Mitarbeitern. Neue Oberflächen, neue Prozessschritte, neue Verantwortlichkeiten. Wer glaubt, dass eine Rundmail zwei Wochen vor dem Go-live und eine zweistündige Schulung ausreichen, unterschätzt die menschliche Seite der Veränderung fundamental.

Change Management ist kein Kommunikationsplan. Es ist ein systematischer Prozess, der Betroffene zu Beteiligten macht. Wer das nicht aktiv gestaltet, bekommt nach dem Go-live passiven Widerstand: Mitarbeiter nutzen Workarounds, pflegen Excel-Listen neben dem neuen System, oder gehen in die innere Emigration. Das System steht – aber niemand arbeitet wirklich damit.

Am Anfang war die Kommunikation offen, lösungsorientiert und konstruktiv. Jetzt dauern Antworten länger. Tickets bleiben liegen. Meetings werden einseitig verschoben. Der Berater vor Ort wechselt zum dritten Mal. Oder umgekehrt: Das Unternehmen reagiert nicht auf Rückfragen des Systemhauses, Entscheidungen verzögern sich, Abnahmen werden nicht erteilt.

Eine verschlechterte Anbieter-Kommunikation ist fast immer ein Symptom tieferliegender Probleme: unausgesprochene Unzufriedenheit, unterschiedliche Erwartungen an den Leistungsumfang oder ein wachsendes Vertrauensdefizit. Wenn dieses Warnsignal ignoriert wird, eskaliert die Situation meist bis zur Vertragsauseinandersetzung.

Dass ein ERP-Projekt teurer wird als geplant, ist keine Seltenheit. Die Frage ist: Wissen Sie, warum? Wenn die Antwort lautet „Es hat halt länger gedauert“, fehlt die entscheidende Analyse. Budgetüberschreitungen ohne klare Ursachenzuordnung sind ein Zeichen dafür, dass das Projekt-Controlling nicht funktioniert – oder dass niemand unbequeme Wahrheiten aussprechen will.

In der Praxis sehen wir häufig, dass Unternehmen einfach mehr Budget freigeben, ohne die Ursache der Überschreitung zu verstehen. Das führt dazu, dass dieselben Muster sich wiederholen: Die nächste Phase wird wieder teurer als geplant, wieder ohne klare Erklärung. Irgendwann ist das Vertrauen in die Projektzahlen komplett zerstört.

Wenn motivierte Teammitglieder plötzlich einsilbig werden, Krankheitstage zunehmen oder Schlüsselpersonen das Projekt verlassen, ist das ein spätes, aber unmissverständliches Warnsignal. ERP-Projekte sind Marathon-Veranstaltungen – sie dauern 12–24 Monate, oft länger. Wenn die Menschen, die das Projekt tragen, ausbrennen, bricht das Fundament weg.

Das Problem verstärkt sich selbst: Wenn erfahrene Teammitglieder gehen, steigt die Last für die Verbleibenden. Wissen geht verloren, Einarbeitung kostet Zeit, die niemand hat. In besonders schweren Fällen führt die Abwanderung von Know-how-Trägern dazu, dass ganze Arbeitspakete von vorne begonnen werden müssen.

Der Unterschied zwischen einem beherrschbaren Risiko und einer Projektkrise liegt selten im Risiko selbst. Er liegt im Zeitpunkt der Erkennung. Die folgende Gegenüberstellung zeigt, was frühe Risikoerkennung konkret bedeutet – und was späte Erkennung kostet.

Risiken zu erkennen ist der erste Schritt. Aber Erkennen allein reicht nicht. Was zählt, ist ein strukturierter Prozess, der aus Erkenntnissen Handlungen macht. In unserer Beratungspraxis hat sich ein Fünf-Schritte-Modell bewährt, das pragmatisch genug für den Mittelstand ist und gleichzeitig die nötige Systematik sicherstellt.

Risiken in ERP-Projekten lassen sich in vier Dimensionen kategorisieren. Ein wirksamer Risiko-Check deckt alle vier ab – weil sie sich gegenseitig beeinflussen. Ein Scope-Problem führt zu Zeitdruck, Zeitdruck zu oberflächlichen Tests, oberflächliche Tests zu technischen Schulden, und technische Schulden zu frustrierten Anwendern.

Die zehn Warnsignale in diesem Artikel sind keine Theorie. Sie sind das Destillat aus Dutzenden von ERP-Projekten, die wir begleitet, stabilisiert oder gerettet haben. Wenn Sie mehr als drei dieser Warnsignale in Ihrem eigenen Projekt wiedererkennen, ist das kein Grund zur Panik – aber ein klares Signal, dass strukturiertes Handeln notwendig ist.

Denn die beste Projektrettung ist die, die nie nötig wird.