Warum ERP-Projekte scheitern: acht Fehler und Gegenmittel
Kurz gesagt
ERP-Einführungen scheitern an der Vorbereitung: an Anforderungen, die nicht aus den eigenen Abläufen stammen, an einer Auswahl ohne Test mit eigenen Daten, an ungeprüften Schnittstellen und an Mitarbeitenden, die erst spät dazukommen. Gegenmittel sind eine priorisierte Prozessliste, ein Lastenheft als gemeinsamer Maßstab, Testkriterien mit Go-No-Go und eine eingeplante Stabilisierungsphase.
Das Wichtigste
- Die Marktstudie Digital in NRW (2021) nennt eine fundierte Anforderungsanalyse die wichtigste Grundlage von Auswahl und Einführung.
- Laut der Marktstudie 2021 hängt der Erfolg davon ab, ob die Mitarbeitenden mit dem System arbeiten können.
- Nach der Studie prüft die Vorabnahme Prozesse, Schnittstellen und Individualprogramme mit Komponenten-, Integrations- und Performancetests.
- Nach dem Go-live nennt die Studie eine Stabilisierungsphase, weil Nachbesserungen zu erwarten sind.
- Release-Wechsel: Die Mehrzahl der für den deutschen Markt 2020 befragten Anbieter empfahl zwei Jahre; die Dienstleistungsaufwände dafür sind nach der Marktstudie 2021 in der Regel nicht in Aufwandsabschätzungen oder Angeboten enthalten.
- Eine Rangfolge der Ursachen veröffentlichen die Quellen nicht; die Reihenfolge in der Tabelle ist eine redaktionelle Einschätzung.
Der Tag des Go-live entscheidet nicht, ob eine ERP-Einführung geglückt ist. Der Bruch zeigt sich später: Bestände stimmen nicht, Aufträge werden weiterhin doppelt erfasst, oder das Projekt wird nach der zweiten Testrunde verschoben, ohne dass jemand entscheidet. Ob die Einführung ihre Ziele erreicht hat, lässt sich an den Anforderungen messen, die vorher dokumentiert wurden.
Woran sich ein Fehlverlauf zeigt
Die Marktstudie von Digital in NRW (Fraunhofer IML, erste Auflage März 2021) empfiehlt, die betrieblichen Abläufe aufzunehmen, die Soll-Prozesse darzustellen und einen Schwachstellenkatalog zu führen. Dieser Katalog dient nach der Einführung der Prüfung, ob alle Anforderungen erfüllt wurden oder weiterer Optimierungsbedarf besteht (Kapitel 4.1). Ohne diese Aufzeichnung fehlt der Maßstab, und das Projekt endet dort, wo es begonnen hat: bei Eindrücken.
Ein dokumentierter Fall zeigt, wie sich ein unpassendes System im Alltag äußert. Bei der Rossbach-Wojtun GmbH bediente das bisherige System wichtige Schnittstellen nicht mehr, die das erweiterte Geschäftsmodell brauchte. Daraus entstanden Medienbrüche mit zusätzlichem Zeit- und Kostenaufwand (Best Practice Rossbach-Wojtun, Projektlaufzeit Q3 bis Q4 2019). Bleiben solche Medienbrüche auch nach der Umstellung bestehen, ist das Ziel der Einführung nicht erreicht.
Fehlerursachen und Gegenmittel im Überblick
Die Tabelle nennt acht Ursachen mit einem Gegenmittel und einem Prüfschritt. Die Ursachen stammen aus den drei genannten Dokumenten; eine Reihenfolge nach Häufigkeit enthalten sie nicht, die Anordnung ist deshalb eine redaktionelle Einschätzung. Die Dokumente beschreiben Projekte in Deutschland; die Prüfschritte hängen nicht an einem Land oder an einer Rechtsordnung.
| Ursache | Gegenmittel | Prüfschritt vor dem Go-live |
|---|---|---|
| Anforderungen stammen aus Funktionslisten statt aus den eigenen Abläufen | Arbeitsschritte vor Ort aufnehmen, priorisieren und daraus das Lastenheft schreiben (Studie, Kapitel 4.1; Best Practice Rossbach-Wojtun) | Kann jede Anforderung auf einen aufgenommenen Arbeitsschritt verweisen? |
| Auswahl ohne Test mit eigenen Daten | Ein Beispieldatenset aus dem eigenen Alltag an die Anbieter geben und prüfen lassen, wie ihr System es verarbeitet; alle am selben Lastenheft messen (Best Practice Rossbach-Wojtun) | Deckt das Beispieldatenset Preisfindung, Rabatt, Bestandsbuchung und eine Storno ab? |
| Schnittstellen und Datenübernahme nicht geprüft | Soll-Systemlandschaft vor der Auswahl zeichnen und jede Schnittstelle mit Testfall und Verantwortlichem belegen (Studie, Kapitel 4.1) | Stimmen Summen, Salden und Stichproben zwischen Altsystem und Testmigration? |
| Mitarbeitende kommen erst zur Schulung dazu | Fachbereiche in Prozessaufnahme und Systemdemonstration holen und Schlüsselpersonen für die Testzeit freistellen (Studie, Kapitel 4.1; Best Practice Held-Drucklufttechnik: Aufnahme der wichtigsten Prozessschritte durch die Mitarbeitenden) | Hat je Arbeitsplatz eine Person das System vor dem Go-live selbst bedient? |
| Kein Abbruchkriterium | Testkriterien festlegen und eine Go- oder No-Go-Entscheidung auf Basis der Testergebnisse vorsehen; Nachbesserung und Stabilisierung einplanen (Studie, Kapitel 4.1) | Welches Testergebnis führt zu No-Go, und wer entscheidet? |
| Fortschritt wird nicht verfolgt | Feste Berichtsrunde mit Soll-Ist-Vergleich je Phase und Nachziehen von Termin und Budget (Studie, Kapitel 4.1) | Wann gab es den letzten Fortschrittsbericht mit Abweichungen? |
| Release- und Betriebskosten fehlen in der Planung | Release-Wechsel mit Aufwand und Preis in den Vertrag; die Gesamtkosten über fünf Jahre rechnen (Studie, Kapitel 4.2.1; ERP-Kosten über fünf Jahre) | Steht der Preis für den nächsten Release-Wechsel im Vertrag? |
| Bindung an den Anbieter ohne Ausstiegsweg | Datenexport, Formate und Fristen regeln und einmal vollständig testen (Studie, Kapitel 4.3.2; Ausstieg aus dem ERP-Vertrag) | Haben Sie eine vollständige Sicherung außerhalb des Systems erzeugt und wieder gelesen? |
Nach unserer Einschätzung wiegen zwei Punkte schwerer als die übrigen. Die Studie nennt die fundierte Anforderungsanalyse die wichtigste Grundlage einer erfolgreichen Auswahl und Einführung (Fazit, Kapitel 5); ein dort gemachter Fehler wirkt, solange das System genutzt wird. Und der Ausstieg ist laut derselben Studie bei einer Cloud-Lösung nur schwer rückgängig zu machen, weil die eigene IT-Kompetenz mit der Zeit abnimmt und der Betrieb vom Anbieter abhängt (Kapitel 4.3.2, Literaturpositionen der Studie).
Beispielrechnung: Fehler früh oder spät entdeckt
Beispielrechnung mit erfundenen Annahmen. Ein Betrieb rechnet mit 60 Euro je interner Arbeitsstunde und 120 Euro je Beratungsstunde. Ein Fehler in der Preisfindung fällt in drei Fällen zu unterschiedlichen Zeitpunkten auf; die Stundenansätze sind Annahmen, keine Angaben der Quellen.
| Entdeckt in | Arbeit | Stunden | Kosten in Euro |
|---|---|---|---|
| Feinkonzept | Klärung, Anpassung im Konzept | 4 intern, 4 Beratung | 240 + 480 = 720 |
| Test | Fehlerbeschreibung, Analyse, Umkonfiguration, erneuter Test | 16 intern, 24 Beratung | 960 + 2.880 = 3.840 |
| Nach dem Go-live | wie im Test, dazu Nacharbeit betroffener Belege und Bestandskorrektur | 46 intern, 34 Beratung | 2.760 + 4.080 = 6.840 |
Die Zahlen folgen der Annahme, dass dieselbe Ursache im Test rund fünfmal und nach dem Go-live rund neunmal so viel Aufwand kostet wie im Feinkonzept (3.840 ÷ 720 ≈ 5,3; 6.840 ÷ 720 = 9,5). Die Rechnung zeigt keine Statistik, sondern den Zusammenhang zwischen Zeitpunkt und Aufwand.
Warnsignale im Projektverlauf
Diese vier Beobachtungen gehen Sie an, bevor Sie das Go geben:
- Die Testfälle stammen vom Anbieter. Schreiben Sie drei Vorgänge aus Ihrem Alltag mit, etwa Auftragsannahme, Lieferschein und Rechnung, und lassen Sie sie danach im System abbilden.
- Der Fortschrittsbericht fehlt. Die Studie nennt es als Aufgabe der Implementierung, den Fortschritt regelmäßig zu überwachen (Kapitel 4.1); ohne Zahlen entscheiden Sie über den Go-live nach Gefühl.
- Die Schlüsselpersonen arbeiten weiter im Tagesgeschäft. Die Studie nennt die interne Arbeitszeit als eigene Kostenkomponente und fragt ausdrücklich, ob Mitarbeitende das Projekt neben ihrer regulären Tätigkeit bearbeiten können (Kapitel 4.2.1). Klären Sie vor dem Start, wer wofür freigestellt wird.
- Der Datenexport ist ungetestet. Verlangen Sie eine vollständige Sicherung in einem Format, das Sie ohne das System lesen können.
So gehen Sie vor
- Halten Sie vor dem Angebotsvergleich fest, welche Abläufe das System tragen soll, und schreiben Sie daraus ein Lastenheft (Lastenheft und Pflichtenheft).
- Geben Sie jedem Anbieter denselben Datensatz aus Ihrem Alltag zur Verarbeitung; nur Anbieter, die ihn zufriedenstellend verarbeiten, kommen in die Auswahl (Best Practice Rossbach-Wojtun).
- Legen Sie Testkriterien und die Personen fest, die abnehmen, und planen Sie Nachbesserung und Stabilisierungsphase ein (Studie, Kapitel 4.1).
- Regeln Sie Release-Wechsel, Betrieb und Ausstieg im Vertrag und rechnen Sie die Kosten über fünf Jahre (ERP-Auswahl in sieben Schritten, ERP-Kosten über fünf Jahre).
- Prüfen Sie drei Monate nach dem Go-live den Schwachstellenkatalog: Welche Anforderung ist erfüllt, welche offen, und wer bearbeitet sie (Projektplan der ERP-Einführung)?