Ein ERP-System soll Schluss mit Excel-Chaos, Doppelpflege und widersprüchlichen Beständen machen. Trotzdem beginnen viele Vorhaben mit hohen Erwartungen und enden mit verschobenen Go-Lives, Zusatzkosten und frustrierten Teams. Warum scheitern ERP Projekte so oft? Selten liegt es allein an der Software. Meist treffen unklare Abläufe, gewachsene Datenbestände und zu spät getroffene Entscheidungen aufeinander.
Gerade im Mittelstand ist das nachvollziehbar: Prozesse haben sich über Jahre entwickelt, Fachwissen steckt in Köpfen, und Shop, Lager, Buchhaltung sowie Vertrieb nutzen unterschiedliche Systeme. Ein neues ERP legt diese Realität offen. Das ist unbequem, aber notwendig. Wer ein ERP-Projekt als reinen Softwarekauf behandelt, verlagert bestehende Probleme lediglich in ein neues System.
Warum scheitern ERP Projekte so häufig?
Ein ERP-Projekt betrifft nicht nur die IT. Es verändert, wie Aufträge angelegt, Artikel gepflegt, Bestände gebucht, Rechnungen gestellt und Informationen zwischen Abteilungen weitergegeben werden. Deshalb ist die Einführung immer auch ein Organisationsprojekt.
Das eigentliche Risiko entsteht, wenn Geschäftsführung, Fachbereiche und Technik von unterschiedlichen Zielbildern ausgehen. Der Vertrieb erwartet schnellere Angebotsprozesse, das Lager verlässliche Bestände, die Buchhaltung saubere Belege und die IT wartbare Schnittstellen. Diese Ziele passen zusammen, aber sie müssen vor der Konfiguration konkret abgestimmt werden.
1. Es gibt kein klares Zielbild
„Wir brauchen ein neues ERP“ ist noch kein Projektziel. Soll die Lösung manuelle Auftragsübertragungen aus dem Onlineshop beenden? Mehrere Lager abbilden? Einkauf und Produktion besser planen? Oder die Finanzbuchhaltung entlasten? Ohne eine priorisierte Antwort wird jede Anforderung gleich dringend - und der Projektumfang wächst mit jeder Besprechung.
Ein gutes Zielbild beschreibt nicht zuerst Funktionen, sondern messbare Verbesserungen im Betrieb. Beispielsweise: Bestandsdaten werden nur noch an einer Stelle gepflegt, Webshop-Aufträge fließen automatisch ins ERP, oder Freigaben für Bestellungen sind nachvollziehbar dokumentiert. Solche Ziele helfen auch bei schwierigen Entscheidungen. Nicht jede gewohnte Sonderlösung muss in das neue System übernommen werden.
2. Bestehende Prozesse werden ungeprüft digitalisiert
Ein ERP kann fehleranfällige Abläufe nicht automatisch verbessern. Wenn ein Auftrag heute drei Excel-Listen, eine E-Mail-Freigabe und manuelle Nacharbeit benötigt, ist die richtige Frage nicht: Wie bildet man das exakt nach? Die bessere Frage lautet: Warum existieren diese Schritte, und welche davon sind fachlich wirklich nötig?
Hier braucht es Fingerspitzengefühl. Nicht jeder Sonderprozess ist Ballast. Manche Anforderungen sind kundenrelevant, regulatorisch notwendig oder ein echter Wettbewerbsvorteil. Andere sind nur entstanden, weil ein altes System bestimmte Informationen nicht sauber verarbeiten konnte. Diese Unterschiede vorab zu erkennen, spart später Entwicklungskosten und verhindert, dass das neue ERP zur nächsten Insellösung wird.
3. Datenqualität wird zu spät ernst genommen
Stammdaten sind der Treibstoff eines ERP-Systems. Artikelnummern, Varianten, Preise, Kundendaten, Lieferanten, Stücklisten und Steuersätze müssen konsistent sein. In der Praxis finden sich jedoch Dubletten, uneinheitliche Einheiten, fehlende Pflichtangaben und historische Datensätze, die niemand mehr nutzt.
Eine Migration ist keine bloße technische Übertragung. Zunächst muss entschieden werden, welche Daten tatsächlich gebraucht werden, wer sie fachlich verantwortet und welche Regeln künftig gelten. Ein Artikelstamm mit 40.000 Einträgen ist nicht automatisch ein Qualitätsmerkmal. Wenn ein großer Teil davon inaktiv, unvollständig oder doppelt gepflegt ist, wird jede Auswertung und jeder Folgeprozess schwieriger.
Besonders kritisch wird es bei integrierten Handelslandschaften. Wenn Shopware-Shop, ERP, Lager und Marktplätze verschiedene Produktinformationen führen, kann ein Import allein die Ursachen nicht lösen. Notwendig ist eine klare Datenführerschaft: Welches System ist für Preise, Verfügbarkeiten, Produkttexte oder Auftragsstatus verbindlich?
4. Schnittstellen werden unterschätzt
Viele ERP-Projekte funktionieren im Testsystem gut, bis die reale Systemlandschaft dazukommt. Dann müssen Shop, CRM, Versanddienstleister, Zahlungsanbieter, Lagertechnik, Zeiterfassung oder Buchhaltung angebunden werden. Jede Schnittstelle braucht eindeutige Datenfelder, Regeln für Fehlerfälle und Verantwortlichkeiten im Betrieb.
Eine Integration ist erst dann belastbar, wenn nicht nur der Idealfall funktioniert. Was passiert, wenn ein Shop-Auftrag unvollständig übertragen wird? Wenn ein Artikel im ERP deaktiviert ist, aber noch im Shop angezeigt wird? Wenn der Versanddienstleister keine Rückmeldung liefert? Diese Fälle müssen fachlich entschieden und technisch sichtbar gemacht werden. Sonst bemerkt das Team Probleme erst, wenn Kunden nach ihrer Bestellung fragen.
Der vernünftige Weg ist, Schnittstellen früh zu priorisieren und mit echten Daten zu testen. Nicht alle Integrationen müssen am ersten Go-Live-Tag fertig sein. Entscheidend ist, dass die kritischen Prozesse verlässlich laufen und spätere Ausbaustufen von Anfang an mitgedacht werden.
5. Fachbereiche werden zu spät eingebunden
Das ERP wird täglich von Menschen genutzt, die Aufträge bearbeiten, Ware buchen, Rechnungen prüfen oder Reklamationen lösen. Werden diese Personen erst kurz vor dem Go-Live informiert, entsteht Widerstand nicht aus Bequemlichkeit, sondern aus berechtigter Sorge: Funktioniert mein Arbeitstag noch?
Key User aus den Fachbereichen gehören deshalb früh ins Projekt. Sie bringen Detailwissen ein, prüfen Prozessentscheidungen und können später als erste Ansprechpartner im Unternehmen helfen. Dabei sollte ihre Rolle verbindlich geplant werden. Wer neben dem Tagesgeschäft ein ERP-Projekt begleitet, braucht Zeit und Rückendeckung durch Führungskräfte.
Schulungen sollten sich ebenfalls an realen Aufgaben orientieren. Eine allgemeine Systemdemo schafft wenig Sicherheit. Besser ist es, typische Vorgänge durchzuspielen: Auftrag aus dem Shop prüfen, Teillieferung buchen, Rechnung korrigieren, Rücksendung bearbeiten oder einen fehlenden Artikel nachbestellen. So werden offene Fragen sichtbar, bevor sie den Betrieb ausbremsen.
6. Der Go-Live wird als Endpunkt behandelt
Ein Go-Live ohne Schweißperlen ist selten das Ergebnis eines perfekten Plans. Er entsteht durch realistische Vorbereitung, klare Zuständigkeiten und eine Phase, in der das Team schnell reagieren kann. Trotzdem wird der Start oft als Abschluss verstanden: System online, Projekt erledigt, externe Unterstützung beendet.
Tatsächlich beginnt dann der Teil, in dem sich die Qualität der Umsetzung zeigt. Mitarbeitende entdecken Sonderfälle, Auswertungen müssen nachjustiert werden, Berechtigungen werden angepasst und Schnittstellen brauchen Monitoring. Auch Updates, Backups und Sicherheitsfragen gehören dauerhaft auf die Agenda.
Für den Start empfiehlt sich eine klar definierte Stabilisierungsphase. Sie regelt, wer Fehler entgegennimmt, wie kritisch sie bewertet werden und wann Entscheidungen getroffen werden. Ein fester Ansprechpartner verhindert, dass offene Punkte zwischen Fachbereich, IT und Dienstleistern liegen bleiben.
7. Budget und Entscheidungen sind nicht planbar organisiert
ERP-Einführungen scheitern selten daran, dass während des Projekts neue Erkenntnisse auftauchen. Das ist bei komplexen Prozesslandschaften normal. Problematisch wird es, wenn jede Änderung ungeprüft aufgenommen wird oder Entscheidungen wochenlang offenbleiben.
Transparenz bedeutet nicht, einen Festpreis für jede Unbekannte zu versprechen. Sie bedeutet, Annahmen sichtbar zu machen, Prioritäten konsequent zu steuern und Auswirkungen auf Zeit, Aufwand sowie Betrieb offen zu benennen. Ein sinnvoller Projektplan unterscheidet daher zwischen Muss-Prozessen für den Start, wichtigen Erweiterungen und Ideen für spätere Phasen.
Auch die Geschäftsführung sollte nicht nur zum Kick-off und zur Abnahme beteiligt sein. Regelmäßige Entscheidungen zu Prioritäten, Ressourcen und Prozessstandards halten das Projekt handlungsfähig. Gerade dann, wenn einzelne Bereiche unterschiedliche Anforderungen anmelden.
Was erfolgreiche ERP-Projekte anders machen
Erfolgreiche Teams starten nicht mit einer langen Liste von Funktionen, sondern mit einem belastbaren Blick auf die Realität. Sie erfassen, wie Daten und Aufträge heute durch das Unternehmen laufen, wo Medienbrüche entstehen und welche Prozesse den größten Nutzen versprechen. Daraus entsteht eine Reihenfolge, die zum Geschäft passt.
In der Umsetzung bewährt sich ein schrittweises Vorgehen. Zuerst werden Kernprozesse wie Artikel, Aufträge, Bestände, Einkauf und Rechnungsstellung stabil aufgebaut. Anschließend folgen komplexere Automatisierungen, weitere Standorte oder besondere Auswertungen. Das reduziert Risiko, ohne die langfristige Architektur aus den Augen zu verlieren.
Wichtig ist außerdem ein Partner, der nicht nur Module konfiguriert, sondern Geschäftsprozesse, Daten und Integrationen zusammen denkt. Bei Odoo-Projekten etwa entscheidet nicht allein die Auswahl der Apps über den Erfolg. Entscheidend ist, ob die Lösung zu Shop, Logistik, Buchhaltung und den tatsächlichen Arbeitsabläufen passt - und nach dem Start dauerhaft betreut werden kann.
Der richtige Start liegt vor der Softwareauswahl
Bevor Anbieter verglichen oder Funktionen abgehakt werden, lohnt sich ein nüchterner Projektcheck: Welche Abläufe verursachen heute den größten Aufwand? Wo entstehen Fehler durch Doppelpflege? Welche Daten müssen verlässlich zwischen welchen Systemen fließen? Und wer übernimmt im Unternehmen fachliche Verantwortung?
Wer diese Fragen ehrlich beantwortet, reduziert die Zahl der Überraschungen erheblich. Nicht, weil ein ERP-Projekt dadurch einfach wird, sondern weil Entscheidungen auf einer tragfähigen Grundlage getroffen werden. Ein gutes ERP ist kein großer technischer Wurf für die Präsentation. Es ist ein System, das am Montagmorgen funktioniert, wenn der erste Auftrag eingeht.