Warum ERP-Projekte wirklich scheitern — 5 Gründe jenseits der Software

Die Zahl, die niemand gerne liest

Studien zu ERP-Implementierungen zeichnen ein ernüchterndes Bild: Je nach Quelle scheitern zwischen 30% und 75% aller Projekte an mindestens einem ihrer ursprünglichen Ziele — Zeitrahmen, Budget, Funktionsumfang oder Nutzerakzeptanz. Die Anbieter weisen gerne auf die erfolgreichen Projekte hin. Die gescheiterten werden selten öffentlich diskutiert.

Wir haben in den letzten Jahren mit mehreren Unternehmen gearbeitet, die ein gescheitertes ERP-Projekt hinter sich hatten. Die Muster wiederholen sich. Und sie haben fast nie mit der Software zu tun.

Der Mythos vom technischen Scheitern

Wenn Sie Geschäftsführer fragen, warum ihr letztes ERP-Projekt schiefging, kommen standardisierte Antworten: „Die Software konnte unsere Prozesse nicht abbilden.” „Der Dienstleister war unprofessionell.” „Die Schnittstellen haben nicht funktioniert.”

Manchmal stimmt das. Aber in 80% der Fälle, die wir im Detail untersucht haben, lag der wahre Grund woanders. Die Software war nur das sichtbare Symptom. Das eigentliche Problem war meist schon vor Projektstart in der Organisation angelegt — und wurde durch das Projekt lediglich offengelegt.

Grund 1: Niemand hat wirklich entschieden, was erreicht werden soll

Die meisten gescheiterten Projekte, die wir analysiert haben, starteten mit einem Ziel wie „Wir wollen unsere Prozesse digitalisieren” oder „Wir brauchen ein modernes ERP-System”. Das ist kein Ziel. Das ist ein Vorsatz.

Ein konkretes Ziel klingt anders: „Wir wollen die durchschnittliche Angebotserstellungszeit von drei Tagen auf vier Stunden reduzieren.” Oder: „Wir wollen in Echtzeit sehen, welche Aufträge profitabel sind und welche nicht.” Oder: „Wir wollen die manuelle Datenübertragung zwischen Vertrieb und Buchhaltung eliminieren.”

Je konkreter das Ziel, desto einfacher ist die Erfolgsmessung. Und — viel wichtiger — desto besser funktioniert die Priorisierung während des Projekts. Wer kein konkretes Ziel hat, kann keine Prioritäten setzen. Und wer keine Prioritäten setzt, versucht alles auf einmal umzusetzen. Das ist der Anfang vom Ende.

Konsequenz: Ohne klare Ziele wird jede Funktionalität gleich wichtig. Jede Abteilung bekommt ihre Wünsche. Der Projektumfang wächst, die Kosten auch, die Zeitlinie verschiebt sich. Irgendwann verliert die Geschäftsführung den Überblick und das Vertrauen — und zieht den Stecker. Das Projekt ist offiziell „gescheitert”. Tatsächlich ist es nur an seiner eigenen Ambition zerbrochen.

Grund 2: Die Geschäftsführung ist nicht wirklich dabei

ERP-Projekte sind Chefsache. Das hört man oft — und man sieht dennoch regelmäßig, dass die Geschäftsführung sich nach dem Kick-off zurückzieht und die Verantwortung an die IT oder den Projektleiter delegiert.

Das ist ein Kardinalfehler. Ein ERP berührt sämtliche Kernprozesse eines Unternehmens. Entscheidungen, die während der Implementierung getroffen werden, bestimmen für die nächsten fünf bis zehn Jahre, wie das Unternehmen arbeitet. Das ist keine operative Frage, das ist eine strategische. Wenn die Geschäftsführung nicht bei diesen Entscheidungen am Tisch sitzt, treffen sie Leute, die dazu eigentlich nicht mandatiert sind.

Was typisch passiert: Die IT-Leiterin entscheidet gemeinsam mit dem externen Berater, dass bestimmte Prozesse „standardisiert” werden — weil das im System einfacher ist. Die Geschäftsführung bekommt das erst mit, wenn Verkaufsleiter und Produktionsleiter nach dem Go-Live frustriert sind, weil „ihre” Prozesse nicht mehr funktionieren.

Die Faustregel: In den ersten acht Wochen eines ERP-Projekts sollte die Geschäftsführung mindestens vier Stunden pro Woche aktiv involviert sein. Danach kann das auf ein bis zwei Stunden sinken — aber die Präsenz bei strategischen Entscheidungspunkten ist nicht delegierbar.

Grund 3: Die bestehenden Prozesse werden nicht hinterfragt

Hier kommt ein unbequemer Gedanke: Die Art, wie Ihr Unternehmen heute arbeitet, ist nicht der Goldstandard. Sie ist das Ergebnis von 10, 20 oder 30 Jahren organischen Wachstums. Manches davon ist sinnvoll. Vieles davon ist historisch gewachsen, Workaround auf Workaround, Kompromiss auf Kompromiss.

Ein ERP-Projekt ist die seltene Gelegenheit, diese Prozesse grundsätzlich zu hinterfragen. Viele Unternehmen nutzen sie nicht. Stattdessen wird die Anforderung an den Dienstleister formuliert: „Bilde unsere bestehenden Prozesse 1:1 im System ab.”

Das ist der sicherste Weg, ein teures System zu bekommen, das sich verhält wie das alte — nur mit moderner Oberfläche. Die Effizienzgewinne, die ein ERP theoretisch bringen könnte, werden vollständig vernichtet, weil die dahinterliegenden Prozesse nicht modernisiert wurden.

Das richtige Vorgehen: Vor der Systemauswahl eine Prozessanalyse durchführen. Nicht aus externer Beratersicht — aus Sicht der Nutzer. Welche Prozesse funktionieren, welche nicht? Wo wird doppelt gearbeitet? Wo entstehen Fehler? Wo werden Daten mehrfach erfasst? Das Ergebnis dieser Analyse sollte in die Anforderung an das ERP einfließen — nicht der Ist-Zustand.

Das kostet zusätzliche Zeit und Geld. Und es ist jede Stunde wert.

Grund 4: Die Datenqualität wird unterschätzt

In jedem Unternehmen, mit dem wir arbeiten, glaubt die Geschäftsführung, dass die Stammdaten „ganz ok” sind. In jedem Unternehmen, in dem wir dann reinschauen, sind sie es nicht.

Kundennummern sind inkonsistent vergeben. Artikel existieren mehrfach unter verschiedenen Bezeichnungen. Bei Lieferanten fehlen Bankverbindungen. In Projekten sind Stunden auf falsche Konten gebucht. Die Liste lässt sich beliebig verlängern.

Diese Probleme existieren im alten System seit Jahren — und niemand hat sich dran gestört, weil jeder Mitarbeiter „seine” Workarounds hatte. Wenn diese Daten ungereinigt ins neue System wandern, werden diese Workarounds unmöglich. Plötzlich fallen die Qualitätsprobleme auf. Rechnungen gehen an falsche Adressen, Lagerbestände stimmen nicht, Auswertungen liefern Unsinn.

Die Reaktion der Mitarbeiter: „Das neue System funktioniert nicht.” Die Wahrheit: Das neue System funktioniert zu gut — es macht sichtbar, was im alten System durch menschliche Kompensation versteckt wurde.

Das richtige Vorgehen: 20-30% des Projektbudgets für Datenbereinigung einplanen. Mehr zu realistischen Gesamtkosten: versteckte ERP-Kosten. Den Datenmigrationsprozess früh starten, idealerweise parallel zur Systemkonfiguration. Und akzeptieren, dass Datenbereinigung keine einmalige Aktion ist, sondern ein kontinuierlicher Prozess, der im neuen System weitergeht.

Grund 5: Das Change Management fällt hinten runter

Dies ist der Grund, der am seltensten als „Scheiterungsursache” genannt wird — und gleichzeitig einer der wichtigsten.

Ein ERP-System funktioniert nur, wenn Menschen es nutzen. Wenn 20 der 30 Vertriebsmitarbeiter ihre Aufträge weiterhin in Excel-Listen führen und erst am Monatsende eintragen, nützt das modernste System nichts. Dieses Verhalten ist kein Zufall. Es entsteht, wenn die Veränderung nicht begleitet wird.

Typische Fehler im Change Management:

• Kommunikation zu spät: Die Mitarbeiter erfahren vier Wochen vor Go-Live, dass sich ihre Arbeitsweise ändert.
• Schulung zu kurz: Ein halber Tag Training — und dann soll das Team in den Echtbetrieb.
• Keine Key-User benannt: Es gibt keine internen Ansprechpartner, die bei Fragen helfen können.
• Widerstände ignoriert: Mitarbeiter, die gegen das System sind, werden als „ewig Gestrige” abgetan statt ernstgenommen.
• Erfolge werden nicht gefeiert: Wenn der erste Monat gut lief, wird das nicht kommuniziert — die Mitarbeiter fühlen sich nicht gesehen.

Die Faustregel: Planen Sie mindestens 15% des Projektbudgets für Change Management ein. Bestellen Sie 2-3 Key-User pro Abteilung und binden Sie sie von Tag 1 ein. Kommunizieren Sie kontinuierlich — nicht nur am Anfang. Und akzeptieren Sie, dass Widerstand zum Prozess dazugehört und durch Dialog aufgelöst werden muss, nicht durch Anweisung.

Was diese fünf Gründe gemeinsam haben

Keiner der fünf Gründe hat mit der ERP-Software zu tun. Alle fünf sind organisatorische, strategische oder menschliche Faktoren. Sie existieren unabhängig davon, ob Sie Odoo, SAP, Microsoft Dynamics oder ein anderes System einführen.

Das ist die gute Nachricht: Wenn Sie diese fünf Faktoren im Griff haben, ist die Software-Entscheidung fast zweitrangig. Wenn Sie sie nicht im Griff haben, wird jedes System an denselben Problemen scheitern.

Unser Rat, bevor Sie ein ERP-Projekt starten

Beantworten Sie ehrlich diese fünf Fragen:

1. Ziele: Haben wir drei bis fünf messbare Ziele definiert, die wir mit dem neuen System erreichen wollen?
2. Geschäftsführung: Ist die GF bereit, in den ersten acht Wochen wöchentlich vier Stunden Zeit in das Projekt zu investieren?
3. Prozesse: Haben wir unsere bestehenden Prozesse in den letzten zwölf Monaten ernsthaft hinterfragt?
4. Daten: Wissen wir, wie der Zustand unserer Stammdaten ist — oder vermuten wir es nur?
5. Change Management: Haben wir eine Vorstellung davon, wie wir unsere Mitarbeiter durch diese Veränderung begleiten wollen?

Wenn Sie bei zwei oder mehr Fragen „Nein” oder „Weiß nicht” sagen müssen, ist der Zeitpunkt für ein ERP-Projekt wahrscheinlich nicht optimal. Das heißt nicht, dass Sie es nicht durchziehen können. Es heißt nur, dass die Wahrscheinlichkeit des Scheiterns ohne Klärung dieser Fragen signifikant steigt.

Klären Sie sie zuerst. Die Software läuft nicht weg. Unsere Diagnose hilft dabei, diese Fragen strukturiert zu beantworten — bevor das Projekt startet.

Fazit

ERP-Projekte scheitern selten an der Software. Sie scheitern an Entscheidungen, die lange vor dem Projektstart getroffen wurden — oder nie getroffen wurden. Je klarer diese Entscheidungen im Vorfeld sind, desto reibungsloser läuft das Projekt. Und desto realistischer ist die Chance, dass am Ende tatsächlich das System steht, das Sie sich vorgestellt haben. Und nicht das Projekt, das irgendwann nur noch mit mehr Budget und mehr Zeit gerettet werden kann.