Ein ERP-Projekt zu scheitern ist teuer. Nicht nur wegen der versenkten Beratungshonorare und Lizenzkosten. Sondern weil das Unternehmen für 12 bis 18 Monate an einem Vorhaben gebunden war, das am Ende weniger geliefert hat als der Ausgangszustand. Nach einem gescheiterten Einführungsversuch dauert es Jahre, bis jemand im Unternehmen bereit ist, das Thema wieder anzufassen.
In der Begleitung von ERP-Vorhaben – als Beobachter, Berater oder Interim-Projektleiter – sehen wir immer wieder dieselben Muster. Sie haben selten mit der Software zu tun.
Fehler 1: Die Softwarewahl zuerst
Der klassische Startpunkt eines gescheiterten Projekts: Der Geschäftsführer besucht eine Messe, sieht drei Anbieter, entscheidet sich für den überzeugendsten Vertriebler. Dann werden die eigenen Prozesse an die Software angepasst – nicht umgekehrt.
Was fehlt: die vorgeschaltete Frage, welche Prozesse überhaupt digital abgebildet werden sollen, wie die Zielarchitektur aussieht und welche Anforderungen wirklich betriebswirtschaftlich zwingend sind. Ohne dieses Zielbild ist jede Softwareauswahl ein Blindflug.
Die richtige Reihenfolge: Prozess vor Anforderung vor Auswahl. Nicht umgekehrt.
Fehler 2: Alle Prozesse abbilden statt gestalten
Ein ERP ist die Chance, veraltete Prozesse zu bereinigen. Die meisten Projekte nutzen sie nicht. Stattdessen wird der Ist-Zustand – inklusive aller Umwege, Sonderfälle und Excel-Anhängsel – 1:1 in die neue Software übertragen.
Das Ergebnis: ein modernes System, das eine alte Organisation abbildet. Statt Effizienz gibt es Wartungsaufwand. Statt Klarheit gibt es Komplexität. Und die Adoption in den Teams bleibt niedrig, weil sich für die Anwender nichts spürbar verbessert.
Die Alternative: Vor der Konfiguration eine bewusste Prozessarbeit. Welcher Prozess bleibt, welcher wird vereinfacht, welcher verschwindet? Diese Entscheidungen dauern zwei bis vier Wochen. Sie sind die höchste ROI-Investition eines ERP-Projekts.
Fehler 3: Individualisierung ohne Not
Moderne ERP-Systeme wie Odoo sind mächtig, weil sie einen breiten Standard bieten. Jede Abweichung vom Standard ist ein zukünftiger Wartungsaufwand – und häufig ein Update-Blocker.
In fast jedem gescheiterten Projekt finden wir eine Liste von 40+ „unbedingt notwendigen" Anpassungen, von denen bei näherer Betrachtung drei tatsächlich betriebswirtschaftlich zwingend sind. Der Rest lässt sich durch Prozessanpassung oder durch geringfügige Konfigurationsabweichung lösen – ohne Custom-Code.
Faustregel: Jede Custom-Anpassung sollte einen dokumentierten geschäftlichen Grund haben, der stärker wiegt als die Wartungslast über die nächsten 5–7 Jahre.
Fehler 4: Migration als „letzte Meile"
Die meisten Projekte behandeln Datenmigration als technischen Cleanup-Job am Ende. Kurz vor dem Go-Live werden die Daten aus dem Altsystem exportiert und in die neue Software geladen. Fehlt Datenqualität, verzögert sich der Go-Live. Sind die Daten unbrauchbar, scheitert das Projekt.
Migration ist eine eigenständige Disziplin. Sie beginnt zeitgleich mit der Prozessarbeit – nicht danach. Wer als Erstes fragt, welche Daten überhaupt in welche Zielstruktur überführt werden sollen, findet dabei oft Qualitätsprobleme, die man sonst erst am Go-Live-Wochenende entdeckt hätte.
Praxis-Tipp: Wir empfehlen einen ersten Migrationstest bereits nach Woche 4 des Projekts – mit einem 10-%-Datenauszug in eine leere Systeminstanz. Was dann sichtbar wird, prägt den gesamten weiteren Projektverlauf.
Was ein erfolgreiches Projekt anders macht
Erfolgreiche ERP-Projekte teilen eine erstaunlich unspektakuläre Eigenschaft: eine ehrliche Reihenfolge.
- Zielbild vor Softwarewahl. Zwei Wochen Analyse und Zielbild-Workshop, bevor überhaupt ein Anbieter angesprochen wird.
- Prozessarbeit vor Konfiguration. Was bleibt, was wird vereinfacht, was verschwindet.
- Standard vor Anpassung. Jede Custom-Anpassung braucht eine dokumentierte Begründung.
- Migration von Anfang an. Testmigration früh, nicht erst zum Go-Live.
- Sequenzielle Einführung. Kein Big Bang, sondern Module in Wellen – idealerweise mit einem Kernmodul, das schnell in den produktiven Betrieb geht.
Das Ergebnis: keine 24-Monats-Marathons mit unklarem Ergebnis. Sondern Einführungen in 8–14 Wochen für ein Kernmodul und 4–7 Monaten für einen umfassenden Rollout. Nach dem Go-Live steht ein System, das arbeitet – nicht eine Wunschliste, die auf Weiterentwicklung wartet.
Zusammenfassung
Der teuerste Aspekt eines ERP-Projekts ist selten die Software. Es ist die Reihenfolge. Wer den Prozess vor die Software stellt, den Standard vor die Anpassung, und die Migration von Anfang an mitdenkt, hat die drei größten Risiken schon vor dem ersten Klick im System entschärft.
Wenn Sie vor einer ERP-Entscheidung stehen – oder in einem Projekt sitzen, das nicht liefert – sprechen Sie uns an. Eine ehrliche Standortbestimmung dauert eine gute Stunde und spart häufig sechsstellige Beträge.