Als Gartner 2020 verkündete, dass bis zu 75 % der ERP-Projekte das Budget oder den Termin überschreiten und 55 % im Ergebnis scheitern, zeigte sich der Markt überrascht. 2026 sehen Sie diese Überraschung nicht mehr – die Zahlen haben sich sogar verschlechtert. Unsere eigene Analyse von 47 slowakischen KMU-Implementierungen zwischen 2023 und 2025 zeigt, dass 80 % der Projekte in einem von vier Zuständen enden: Budgetüberschreitung von mehr als 50 %, Terminüberschreitung von mehr als 6 Monaten, Nichterreichen der ursprünglichen Geschäftsziele oder vollständiges Aufgeben des Projekts vor dem Go-Live.
ERP-Scheitern ist jedoch kein Zufall. Es ist ein Prozess mit erkennbaren Mustern. In diesem Artikel benennen wir diese Muster, zeigen die fünf häufigsten Scheitergründe und – wichtiger – gehen die bewährten Praktiken durch, die die Erfolgswahrscheinlichkeit von 20 % auf über 70 % heben.
ERP-Scheitern ist kein Ereignis – es ist ein Prozess
Stellen Sie sich eine typische Geschichte vor. Das Unternehmen entscheidet sich im Januar für ein neues ERP. Im März unterzeichnet es den Vertrag. Im Mai beginnt die Konfiguration. Im September – Go-Live. Im November funktioniert die Hälfte der Funktionalität nicht so, wie sie sich vorgestellt hatten. Im Januar des Folgejahres trifft eine Rechnung über weitere 40.000 EUR für „Out-of-Scope-Anpassungen” ein. Im März des zweiten Jahres arbeitet immer noch die Hälfte der Mitarbeiter nicht im System.
Ist das ein Scheitern? Die meisten Unternehmen würden sagen: „Nein, das System läuft doch.” Aber nach jeder vernünftigen Definition ist das Projekt gescheitert – Verspätung, Budgetüberschreitung, unzufriedene Nutzer. Und entscheidend: Die Anzeichen des Scheiterns waren bereits im April sichtbar. Bereits im Juni war das Schicksal des Projekts besiegelt. Der September-Go-Live war nur die formale Bestätigung eines Zustands, der sich monatelang gebildet hatte.
Tipp: Der beste Indikator für die Projektgesundheit ist die Anzahl offener Fragen und Risiken. Wenn die wöchentliche Anzahl offener Risiken kontinuierlich steigt und Risiken höherer Schwere nicht geschlossen werden, scheitert das Projekt, auch wenn es scheinbar läuft. Prüfen Sie das bei jedem wöchentlichen Statusmeeting.
Fünf häufigste Gründe für das Scheitern
Aus der Analyse von 47 Projekten ergeben sich wiederkehrende Muster. Selten ist es eine einzelne Ursache – meist kombinieren sich zwei bis drei. Aber wenn wir sie nach Häufigkeit ordnen, erhalten wir:
Grund 1 – Unklare Geschäftsziele (88 % der gescheiterten Projekte)
„Wir brauchen ein modernes ERP.” Das ist kein Ziel. Das ist ein Wunsch. Ein Ziel klingt: „Verkürzung der Zeit von Bestellung zu Rechnung von 14 Tagen auf 3 Tage”, oder „Reduzierung der Lagerfehler von 2 % auf 0,3 %”, oder „Den Betriebsleitern ermöglichen, den Monatsabschluss bis zum 5. statt 18. des Monats fertigzustellen.”
Wenn Sie keine messbaren Ziele haben, weiß weder der Lieferant noch Ihr Team, wann es fertig ist. Das Projekt ufert aus, weil jede neue „gute Idee” relevant erscheint, und niemand hat ein Kriterium für „das machen wir nicht, weil es dem Ziel nicht dient”.
Lösung: Formulieren Sie 3 – 5 SMART-Ziele vor Vertragsunterzeichnung. Jedes Ziel erhält im Vertrag den Erfolg – wenn es nach dem Go-Live nicht erreicht wird, muss sich etwas im Projekt ändern.
Grund 2 – Unterschätzung des Change Managements (71 %)
Ein neues ERP ist in 80 % der Fälle technisch erfolgreich – Daten werden übertragen, Integrationen funktionieren, Transaktionen laufen. Es scheitert an den Menschen. Mitarbeiter nutzen es nicht, Manager glauben ihm nicht, Vertriebler kehren zu Excel zurück.
Grund: Change Management bekam 2 % des Projektbudgets und fand als eintägige Schulung am Tag vor dem Go-Live statt.
Lösung: Change Management verdient 15 – 25 % des Budgets. Es beginnt 3 Monate vor Go-Live. Es endet 6 Monate danach. Es enthält: Kommunikationsstrategie, Champions in jeder Abteilung, Schulungsmaterialien in mehreren Formaten, Sandbox zum Experimentieren, Post-Implementierungs-Support.
Grund 3 – Mangelhafte Datenmigration (68 %)
Die Daten aus dem alten System sind schmutzig. Duplikate, unvollständige Datensätze, inkonsistente Formate. Der Lieferant kippt sie irgendwie um und liefert. Ergebnis: Das neue System enthält alte Probleme und 3 Wochen nach Go-Live ruft die Buchhalterin an, dass „Rechnungen nicht entscheidbar sind, was Duplikat ist und was nicht”.
Lösung: Die Datenmigration beginnt 6 Monate vor Go-Live. Sie hat einen eigenen Plan mit Phasen: Audit, Bereinigung, Mapping, Testmigration, Validierung, scharfe Migration, Post-Migration-Reconciliation. Sie ist nie ein „Nebenprojekt” – oft ist sie der komplexeste Teil der gesamten Implementierung.
Tipp: Als Test der Datenqualität führen Sie einen „Report-Sprint” durch – erstellen Sie 5 Reports im neuen System mit migrierten Daten und vergleichen Sie sie mit identischen Reports im alten System. Wenn die Zahlen um mehr als 0,5 % abweichen, haben Sie ein Problem, das vor Go-Live gelöst werden muss.
Grund 4 – Schlechte Partnerwahl (54 %)
ERP-Anbieter und Implementierungspartner sind nicht dasselbe. Viele Unternehmen kaufen ein „System” und realisieren nicht, dass die eigentliche Arbeit der Partner leistet – ein kleines Unternehmen, das die Lizenz auf die Software vielleicht erst letztes Jahr erworben hat.
Anzeichen eines schlechten Partners:
- Projektmanager wechselt alle 3 Monate
- Berater kann branchenspezifische Fragen nicht beantworten
- Eskalation wird nicht gelöst oder über den Anbieter, nicht den Partner
- Dokumentation ist arm und inkonsistent
Lösung: Vor der Wahl des Partners finden Sie heraus: Wie viele Projekte haben sie in Ihrer Branche gemacht, wie viele Mitarbeiter haben sie, wie hoch ist die Beraterfluktuation, wer ist Ihr konkreter Projektmanager. Bitten Sie um Lebensläufe der Personen, die am Projekt arbeiten werden. Der Vertrag sollte mindestens die Kontinuität des Projektmanagers garantieren.
Grund 5 – Zu ambitionierter Scope (49 %)
Unternehmen sehen oft das neue ERP als Gelegenheit, „alles auf einmal zu lösen”. Sie fügen Module hinzu, die ursprünglich nicht geplant waren. Integrationen, die in Phase 2 sein könnten. Anpassungen, die den Standard erweitern. Ergebnis: Ein Projekt, das 4 Monate dauern sollte, dauert 12, und die zusätzlichen 8 kosten doppelt so viel.
Lösung: Phasieren Sie. Phase 1 – Core-Module (Finanzen, Lager, Fakturierung). Phase 2 – Erweiterungen (CRM, HR, Projektmanagement). Phase 3 – Spezialisierungen und Integrationen. Zwischen den Phasen mindestens 3 Monate Stabilisierung.
Anatomie einer erfolgreichen Implementierung – 7 Phasen
Erfolgreiche Implementierungen haben eine ähnliche Struktur. Lassen Sie uns sie zerlegen.
Phase 1 – Discovery und Ziele (2 – 4 Wochen, vor Vertragsunterzeichnung)
Sie kartieren den aktuellen Zustand der Prozesse, definieren 3 – 5 Geschäftsziele mit messbaren KPIs, identifizieren kritische Einschränkungen (Gesetzgebung, Integrationssysteme, Termine). Output ist ein Business Requirements Document (BRD) und Akzeptanzkriterien.
Phase 2 – Lösungs- und Partnerauswahl (4 – 8 Wochen)
Shortlist von 3 Anbietern/Lösungen, Demos mit denselben Szenarien bei jedem, Due Diligence der Referenzen, Proof of Concept für kritische Integrationen. Output ist ein unterzeichneter Vertrag mit Statement of Work (SoW), das die SMART-Ziele aus Phase 1 enthält.
Phase 3 – Projektplanung (2 – 3 Wochen)
Kick-off, Identifikation des Steering Committees, Ernennung des Projektmanagers beim Klienten, Teamzusammenstellung, detaillierter Arbeitsplan mit Meilensteinen, Kommunikationsplan, Risk Register. Ohne dies können Sie nur Chaos machen.
Phase 4 – Konfiguration und Anpassung (6 – 12 Wochen)
Wöchentliche Sprints, jeder mit konkretem Output und Demo. Beziehen Sie Schlüsselbenutzer (Power Users) von Anfang an ein – nicht erst zur Schulung. Jeder Sprint endet mit dem Testen von Business-Szenarien, nicht nur Unit-Tests.
Phase 5 – Datenmigration (parallel 8 – 16 Wochen)
Drei Migrationsdurchläufe – Mock 1 (3 Monate vor Go-Live), Mock 2 (1 Monat vor), scharfe Migration (Wochenende vor Go-Live). Zwischen den Durchläufen Datenvalidierung mittels Vergleichsreports.
Phase 6 – Testing und Schulung (4 – 6 Wochen)
User Acceptance Testing (UAT) mit echten Szenarien und echten Benutzern. Schulung in kleinen Gruppen (max. 8 Personen), mehrstufig, mit verfügbarer Sandbox-Instanz. Train-the-Trainer für interne Champions.
Phase 7 – Go-Live und Hyperkare (4 Wochen)
Cut-over-Plan mit konkreten Aufgaben und Verantwortlichen. Erste 4 Wochen intensiver Support – „Hyperkare”-Team beim Klienten, tägliche Status Calls. Schrittweise Übergabe an Standard Support.
Change Management – das Herz des Erfolgs
Wenn Sie aus diesem Artikel einen einzigen Insight mitnehmen, dann diesen: Der Erfolg eines ERP-Projekts ist zu 30 % Technologie und zu 70 % Menschen. Das am besten konfigurierte System scheitert, wenn die Menschen es nicht annehmen. Ein durchschnittlich konfiguriertes System wird erfolgreich, wenn die gesamte Organisation dahintersteht.
Elemente eines funktionierenden Change Managements
Executive Sponsor. Geschäftsführer oder Eigentümer, der die Kommunikation veröffentlicht, an Status Calls teilnimmt und Eskalationen löst. Ohne realen Sponsor hat das Projekt kein Gewicht.
Champion-Netzwerk. Eine Person aus jeder Schlüsselabteilung, die das Projekt „nach Hause bringt”. Erhält vorzeitigen Zugriff, schult andere, ist Filter für Feedback.
Kommunikationsplan. Monatliche Newsletter zum Projektstatus. Intranet-Seite mit FAQ. Open Office Hours mit dem Projektteam. Video-Demos des neuen Systems.
Verschiedene Schulungsarten. Klassisches Klassenraumtraining (für 30 % der Menschen). Video-Tutorials (für 40 %). Hands-on in der Sandbox (für 30 %). Niemals „alle lernen es gleich”.
Post-Live-Support. Hotline mit schneller Antwort, regelmäßige „Lunch & Learn”-Sessions, Sammeln von Feedback und schnelle Behebung von Friction Points.
Wie wählt man einen guten Partner – fünf Kriterien
Der Partner entscheidet mehr als die Lösung selbst. Unsere Fallstudien zeigen, dass dasselbe ERP, von verschiedenen Partnern implementiert, einen 50 % Unterschied im Erfolg hat. Worauf also achten?
1. Branchenspezialisierung. Ein Partner, der 20 Klienten aus Ihrer Branche hat, bringt Know-how, das man nicht studieren kann. Nicht zufällig leiten erfolgreiche Implementierungen in der Produktion Partner mit Produktionshintergrund, nicht Universalisten.
2. Größe des Partners relativ zum Projekt. Wenn Sie ein Projekt für 200.000 EUR sind und der Partner 5 Mitarbeiter hat, sind Sie für ihn 30 % der Kapazität – und jeder Ausfall gefährdet das gesamte Projekt. Ideal: Projekt 10 – 25 % der Partnerkapazität.
3. Teamstabilität. Bitten Sie um die Mitarbeiterrotation der letzten 2 Jahre. Mehr als 30 % ist ein Warnsignal.
4. Dokumentationskultur. Bitten Sie um ein anonymisiertes Beispiel von „Lessons Learned” aus einem vorherigen Projekt. Wenn der Partner keine schriftlichen Lehren hat, entwickelt er sich nicht weiter.
5. Referenzen. Rufen Sie 3 – 5 Klienten an und fragen Sie: „Würden Sie wieder dasselbe Team wählen?”
Numerischer Benchmark – wie sieht ein „gutes” Projekt aus
Aus unseren 47 Projekten hatten die erfolgreichen (oberste 20 %) folgende Charakteristika:
- Budgetüberschreitung durchschnittlich 8 % (gegenüber 65 % bei gescheiterten)
- Terminüberschreitung durchschnittlich 12 Tage (gegenüber 4 Monaten bei gescheiterten)
- User Adoption 3 Monate nach Go-Live: 85 %+ (gegenüber 35 % bei gescheiterten)
- ROI erreicht innerhalb von 18 Monaten nach Go-Live: 100 % (gegenüber 20 % bei gescheiterten)
- Change-Management-Budget: 18 % der Gesamtkosten (gegenüber 3 % bei gescheiterten)
- Phasenweise: 2 – 3 Phasen (gegenüber „Big Bang” bei gescheiterten)
Das Muster ist klar: Weniger Ambition auf einmal, mehr Investition in Menschen, bessere Planung.
Fazit – Scheitern ist vorhersehbar, Erfolg ist planbar
80 % der ERP-Implementierungen scheitern. Das ist die schlechte Nachricht. Die gute Nachricht: Scheitern ist kein Zufall, sondern Ergebnis vorhersehbarer Fehler. Wenn Sie die Fehler vermeiden – unklare Ziele, Unterschätzung des menschlichen Faktors, schlechte Migration, falscher Partner, übertriebener Scope – kommen Sie in die obersten 20 %, wo Projekte erfolgreich sind.
Der Schlüssel ist die Erkenntnis, dass ERP kein IT-Projekt ist. Es ist ein Business-Transformationsprojekt mit IT-Komponente. Wer es aus der IT-Abteilung ohne starken Business-Sponsor pilotiert, macht den ersten Fehler bereits vor der Unterschrift. Wer 3 % in Change Management und 97 % in Technologie investiert, macht den zweiten.
Wenn Sie vor einem ERP-Projekt stehen und die Erfolgswahrscheinlichkeit erhöhen möchten, melden Sie sich bei uns. In einer 60-minütigen kostenlosen Beratung gehen wir Ihren Plan durch, identifizieren Risikopunkte und schlagen Anpassungen vor. Von 80/20 kann man auf 30/70 kommen – aber Sie müssen mit den richtigen Fragen beginnen, nicht mit einer Softwarebestellung.