ERP-Projekt Risiken: Die 8 häufigsten Stolpersteine und wie Sie sie vermeiden

ERP-Projekte gehören zu den komplexesten Vorhaben, die ein mittelständisches Unternehmen stemmen kann. Sie betreffen nahezu jeden Geschäftsprozess, binden erhebliche Ressourcen und verändern die Arbeitsweise ganzer Abteilungen. Trotzdem wird das systematische Risikomanagement in vielen Projekten stiefmütterlich behandelt – oder auf eine einmalige Risikoliste im Projekthandbuch reduziert, die nach dem Kick-off nie wieder angeschaut wird.

Das ist ein teurer Fehler. Denn die Risiken in ERP-Projekten sind keine abstrakten Bedrohungen. Sie sind konkret, wiederkehrend und in den meisten Fällen vermeidbar – wenn man sie frühzeitig erkennt und aktiv gegensteuert. In unserer Beratungspraxis sehen wir immer wieder dieselben Muster. Acht davon sind so häufig, dass sie in nahezu jedem Projekt auftreten, das wir begleiten oder nachträglich stabilisieren.

Diese Zahlen sind keine Naturgesetze. Sie spiegeln wider, was passiert, wenn Risiken nicht aktiv gemanagt werden. Die gute Nachricht: Wer die typischen Stolpersteine kennt, kann sie umgehen. Im Folgenden beschreiben wir die acht häufigsten Risiken, ihre Auswirkungen und die Gegenmaßnahmen, die sich in der Praxis bewährt haben.

Scope Creep ist der schleichende Tod vieler ERP-Projekte. Er beginnt harmlos: ein zusätzliches Reporting hier, eine Sonderanforderung dort, eine Schnittstelle, die eigentlich nicht im Pflichtenheft steht, aber ja nur ein kleiner Aufwand ist. Einzeln betrachtet erscheinen diese Ergänzungen vernünftig. In der Summe verschieben sie Budget und Zeitplan um Wochen oder Monate.

Die Ursache liegt fast immer in der Vorphase: Wenn Anforderungen nicht sauber erhoben und priorisiert wurden, fehlt dem Projektteam die Grundlage, um Änderungswünsche zu bewerten. Alles erscheint gleich wichtig, und die Fähigkeit, Nein zu sagen, geht verloren.

Gegenmaßnahmen: Etablieren Sie einen formalen Change-Request-Prozess ab Projektbeginn. Jede Änderung am vereinbarten Umfang muss hinsichtlich Aufwand, Kosten und Auswirkungen auf den Zeitplan bewertet werden, bevor sie genehmigt wird. Schaffen Sie ein Steering Committee, das regelmäßig über offene Change Requests entscheidet. Und vor allem: Dokumentieren Sie den vereinbarten Scope zu Projektbeginn verbindlich – als Referenzpunkt für alle weiteren Diskussionen.

Kaum ein ERP-Projekt beginnt mit dem Ziel, den Zeitplan zu verfehlen. Aber viele beginnen mit einem Zeitplan, der von Anfang an nicht realistisch ist. Die Gründe sind vielfältig: politischer Druck auf ein bestimmtes Go-Live-Datum, Unterschätzung der Projektkomplexität, fehlende Erfahrungswerte oder die Annahme, dass Parallelisierung von Arbeitspaketen den Zeitbedarf verkürzt.

Ein unrealistischer Zeitplan erzeugt Druck, der sich auf das gesamte Projekt auswirkt. Tests werden verkürzt, Schulungen gestrichen, Datenbereinigungen halbherzig durchgeführt. Das Ergebnis ist ein Go-Live, das technisch stattfindet, aber operativ nicht trägt.

Gegenmaßnahmen: Planen Sie den Zeitrahmen auf Basis vergleichbarer Projekte, nicht auf Basis von Wunschdenken. Berücksichtigen Sie Pufferzeiten für unvorhergesehene Verzögerungen – mindestens 15 bis 20 Prozent der Gesamtlaufzeit. Verankern Sie die Testphase und das Change Management als eigenständige Arbeitspakete im Projektplan, die nicht als Puffer dienen dürfen. Und prüfen Sie regelmäßig, ob der Zeitplan noch realistisch ist – mit der Bereitschaft, ihn anzupassen, wenn sich die Rahmenbedingungen ändern.

Ein ERP-System bildet Geschäftsprozesse ab. Wer diese Prozesse am besten kennt, sind die Mitarbeitenden in den Fachabteilungen. Trotzdem werden sie in vielen Projekten erst eingebunden, wenn die Konfiguration schon läuft – oder erst in der Testphase, wenn es zu spät ist, grundlegende Weichenstellungen zu korrigieren.

Die Konsequenzen sind vorhersehbar: Key User fühlen sich übergangen, das System passt nicht zu den gelebten Prozessen, und der Widerstand gegen das neue System wächst. Was als Effizienzsteigerung gedacht war, wird zum Reibungsverlust.

Gegenmaßnahmen: Binden Sie die Fachbereiche von Anfang an ein – idealerweise schon in der Anforderungserhebung. Definieren Sie klare Rollen für Key User und stellen Sie sicher, dass sie ausreichend Kapazität für das Projekt haben. Schaffen Sie regelmäßige Kommunikationsformate, die über den Projektfortschritt informieren und Raum für Feedback geben. Und nehmen Sie Bedenken aus den Fachbereichen ernst – sie sind oft die frühesten Warnsignale für versteckte Risiken.

Die Datenqualität ist eines der am meisten unterschätzten Risiken in ERP-Projekten. Viele Unternehmen gehen davon aus, dass ihre Stammdaten im Altsystem korrekt und vollständig sind. In der Praxis zeigt sich fast immer ein anderes Bild: doppelte Kundenstämme, veraltete Artikeldaten, inkonsistente Klassifizierungen, fehlende Pflichtfelder.

Diese Altlasten werden bei der Migration ins neue System mitgenommen – und dort potenziert. Denn ein modernes ERP-System arbeitet mit höheren Datenqualitätsanforderungen als das Altsystem. Was dort noch funktioniert hat, führt im neuen System zu Fehlern: Bestellvorschläge, die ins Leere laufen. Auswertungen, die unplausible Ergebnisse liefern. Schnittstellen, die Datensätze ablehnen.

Gegenmaßnahmen: Starten Sie die Datenbereinigung frühzeitig – nicht erst in den letzten Wochen vor dem Go-Live. Definieren Sie Datenqualitätsstandards für das neue System und gleichen Sie den Bestand im Altsystem dagegen ab. Planen Sie ausreichend Kapazität für die Bereinigung ein: Das ist keine Aufgabe, die ein Werkstudent nebenbei erledigen kann. Und führen Sie Testmigrationen durch, um Datenprobleme frühzeitig zu erkennen.

Ein neues ERP-System ist kein Software-Update. Es verändert Arbeitsweisen, verschiebt Zuständigkeiten und stellt langjährige Routinen infrage. Wer glaubt, dass eine zweitägige Schulung kurz vor dem Go-Live ausreicht, um die Organisation auf diese Veränderung vorzubereiten, unterschätzt die menschliche Seite des Projekts fundamental.

In der Praxis äußert sich mangelndes Change Management in stillem Widerstand: Mitarbeitende nutzen das neue System nur oberflächlich, bauen Workarounds auf oder fallen in alte Prozesse zurück. Die technische Einführung mag gelungen sein – die organisatorische Adoption bleibt auf der Strecke.

Gegenmaßnahmen: Betrachten Sie Change Management als integralen Bestandteil des ERP-Projekts, nicht als optionalen Zusatz. Beginnen Sie mit der Kommunikation vor dem Projektstart: Warum findet die Veränderung statt? Was bedeutet sie für die einzelnen Bereiche? Beziehen Sie Multiplikatoren aus den Fachabteilungen ein, die als Brücke zwischen Projektteam und Belegschaft fungieren. Und planen Sie nach dem Go-Live eine Begleitphase ein, in der Mitarbeitende Unterstützung erhalten und Feedback geben können.

ERP-Projekte werden häufig stark vom Systemhaus getrieben. Das Systemhaus konfiguriert, das Systemhaus berät, das Systemhaus steuert den Projektplan. Für das Unternehmen ist das zunächst bequem – es hat schließlich Experten beauftragt. Doch diese Bequemlichkeit hat einen Preis: Die eigene Steuerungskompetenz geht verloren.

Wenn das Unternehmen nicht in der Lage ist, die Leistungen des Systemhauses qualifiziert zu bewerten, entsteht eine Abhängigkeit, die sich in allen Projektphasen rächt. Entscheidungen werden verzögert, weil das Unternehmen die Implikationen nicht einschätzen kann. Kostenüberschreitungen werden akzeptiert, weil die Verhandlungsposition fehlt. Und die Qualitätskontrolle findet nicht statt, weil niemand intern die Ergebnisse bewerten kann.

Gegenmaßnahmen: Bauen Sie interne Projektkompetenz auf – oder holen Sie sich unabhängige Beratung, die ausschließlich Ihre Interessen vertritt. Etablieren Sie ein internes Projektmanagement, das den Fortschritt eigenständig bewerten kann. Verhandeln Sie transparente Vertragsbedingungen mit klar definierten Leistungen, Meilensteinen und Abnahmekriterien. Und schaffen Sie eine Eskalationsstruktur, die funktioniert, wenn die Zusammenarbeit nicht wie geplant läuft.

Die Testphase ist in vielen ERP-Projekten der erste Posten, der gekürzt wird, wenn der Zeitplan unter Druck gerät. Das ist paradox, denn die Testphase ist genau die Phase, die über die Qualität des Go-Live entscheidet. Wer sie beschneidet, spart an der falschen Stelle.

Häufige Fehler: Tests werden mit idealisierten Testdaten durchgeführt, die die reale Komplexität nicht abbilden. Key User haben keine dedizierte Testzeit und führen Tests zwischen Tagesgeschäft durch – oberflächlich und unvollständig. Es gibt keinen strukturierten Testplan, keine klaren Akzeptanzkriterien und kein systematisches Fehlermanagement.

Gegenmaßnahmen: Verankern Sie die Testphase als eigenständiges Arbeitspaket im Projektplan mit klarem Zeitfenster. Erstellen Sie einen Testplan, der die Kernprozesse vollständig abdeckt. Stellen Sie Key User für die Testphase vom Tagesgeschäft frei. Verwenden Sie realistische Testdaten und führen Sie mindestens einen vollständigen Integrations-Testlauf durch. Dokumentieren und priorisieren Sie alle gefundenen Fehler und verfolgen Sie deren Behebung systematisch nach.

Ein ERP-Projekt ohne aktiven Sponsor in der Geschäftsleitung ist ein Projekt ohne Rückhalt. Das zeigt sich vor allem in Momenten, in denen schwierige Entscheidungen getroffen werden müssen: Sollen Prozesse angepasst werden? Werden zusätzliche Ressourcen bewilligt? Wird der Zeitplan angepasst? Ohne einen Sponsor, der diese Entscheidungen trifft oder zumindest unterstützt, verlangsamt sich das Projekt – oder kommt zum Stillstand.

Fehlendes Executive Sponsorship zeigt sich oft subtil: Die Geschäftsleitung spricht sich verbal für das Projekt aus, nimmt aber nicht an Steering-Committee-Sitzungen teil. Budgetfreigaben dauern Wochen. Konflikte zwischen Abteilungen werden nicht eskaliert, weil niemand den Mut hat, die Geschäftsführung einzubeziehen. Das Projektteam arbeitet im Vakuum. Gegenmaßnahmen: Definieren Sie die Rolle des Executive Sponsors vor Projektbeginn – nicht als Ehrentitel, sondern mit konkreten Aufgaben und Zeitaufwand. Der Sponsor sollte an regelmäßigen Steering-Committee-Sitzungen teilnehmen, bei Eskalationen verfügbar sein und die strategische Richtung des Projekts aktiv mitgestalten. Wenn die Geschäftsleitung diese Rolle nicht ausfüllen kann oder will, ist das ein Risikofaktor, den Sie vor dem Projektstart adressieren müssen.

Nicht alle Risiken wiegen gleich schwer. In unserer Beratungspraxis bewerten wir jedes Risiko nach zwei Dimensionen: Eintrittswahrscheinlichkeit und Auswirkung auf das Gesamtprojekt. Die Kombination ergibt die Risikoschwere.

Einzelne Risiken zu kennen ist der erste Schritt. Der entscheidende zweite Schritt ist die systematische Bewertung und Steuerung. Ein wirksames Risikomanagement in ERP-Projekten folgt einem einfachen Ablauf: Risiken identifizieren, bewerten, Maßnahmen definieren und deren Umsetzung regelmäßig überprüfen.

In der Praxis hat sich ein vierwöchiger Rhythmus bewährt: In jedem Steering-Committee-Meeting wird die Risikoliste aktualisiert. Neue Risiken werden ergänzt, bestehende neu bewertet, abgeschlossene Maßnahmen dokumentiert. Das klingt einfach – und ist es auch. Die Herausforderung liegt nicht in der Methode, sondern in der Disziplin, sie konsequent durchzuhalten. Ein weiterer Erfolgsfaktor ist die Offenheit im Umgang mit Risiken. In vielen Projektkulturen werden Probleme so lange verschwiegen, bis sie nicht mehr zu übersehen sind. Ein gutes Risikomanagement belohnt Frühwarnung statt Optimismus. Wer ein Risiko benennt, bevor es zum Problem wird, verdient Anerkennung – nicht Kritik.

Die acht beschriebenen Risiken sind keine Überraschungen. Sie sind bekannte Muster, die in der Fachliteratur beschrieben, in Studien belegt und in der Praxis hundertfach beobachtet wurden. Dass sie trotzdem in so vielen Projekten auftreten, liegt nicht an mangelndem Wissen – sondern an mangelnder Konsequenz in der Umsetzung.

Professionelles Risikomanagement kostet vergleichsweise wenig: regelmäßige Reviews, transparente Kommunikation, klare Eskalationswege und die Bereitschaft, unbequeme Wahrheiten auszusprechen. Was es spart, ist um ein Vielfaches mehr: Budgetüberschreitungen, Terminverschiebungen, gescheiterte Go-Lives und verlorenes Vertrauen zwischen den Projektbeteiligten.

Die Frage ist nicht, ob Risiken auftreten werden. Sie werden auftreten. Die Frage ist, ob Sie darauf vorbereitet sind.

In einem kostenlosen 30-minütigen Erstgespräch analysieren wir gemeinsam, welche der acht Risikofaktoren in Ihrem Projekt relevant sind – und welche Maßnahmen jetzt den größten Hebel haben.

In unserer Beratungspraxis ist Scope Creep das häufigste Risiko. Fast jedes Projekt, das wir begleiten oder nachträglich stabilisieren, leidet unter einer unkontrollierten Ausweitung des Projektumfangs. Die Ursache liegt fast immer in einer unzureichenden Anforderungserhebung zu Projektbeginn und einem fehlenden Change-Request-Prozess. Eng damit verbunden ist fehlendes Executive Sponsorship: Ohne einen aktiven Sponsor, der Priorisierungsentscheidungen trifft und trägt, fehlt dem Projektteam die Rückendeckung, um Anforderungen abzulehnen.

Ein vierwöchiger Rhythmus hat sich in der Praxis bewährt – idealerweise im Rahmen der Steering-Committee-Sitzung. In kritischen Projektphasen, etwa kurz vor dem Go-Live oder während der Datenmigration, kann eine wöchentliche Aktualisierung sinnvoll sein. Entscheidend ist nicht die Frequenz allein, sondern die Qualität: Werden Risiken ehrlich bewertet? Werden Maßnahmen tatsächlich umgesetzt? Gibt es Konsequenzen, wenn Maßnahmen nicht greifen?

Nicht zwingend, aber ein externer Blick hat entscheidende Vorteile. Interne Projektbeteiligte sind oft zu nah am Geschehen, um blinde Flecken zu erkennen. Politische Konstellationen im Unternehmen können die Offenheit im Umgang mit Risiken einschränken. Ein unabhängiger Berater bringt Erfahrungswerte aus vergleichbaren Projekten mit, benennt Risiken ohne interne Rücksichtnahmen und stärkt die Glaubwürdigkeit des Risikomanagements gegenüber der Geschäftsleitung.

Quellen: Standish Group CHAOS Report (2020/2023); Panorama Consulting Group ERP Report (2023); Gartner, Why ERP Implementations Fail, 2022; eigene Projekterfahrung aus ERP-Begleitungen im Handel und Großhandel