Warum ERP-Implementierungen im industriellen Betrieb scheitern

Gartner prognostiziert, dass bis 2027 mehr als 70% der kürzlich implementierten ERP-Initiativen ihre ursprünglichen Geschäftsziele nicht vollständig erreichen werden. Der 2026 ERP Report von Panorama Consulting ergab, dass mehr als 25% der Organisationen ihr Budget überschritten haben. Eine 2026er Analyse von Godlan (ein Infor-Partner, als Richtwert zu betrachten) bezifferte die Fehlerquote bei ERP-Projekten in der Fertigung auf 73%, mit durchschnittlichen Kostenüberschreitungen von 215%.

Wenn Sie einen Hafen, ein Yard, eine Mine oder einen anderen feldgetriebenen Betrieb führen, wirken diese Zahlen niedrig. Die Fehlerquote ist kein Projektmanagement-Problem. Sie ist strukturell. Dieselben fünf Dinge gehen in derselben Reihenfolge schief, bei jedem Engagement, das ich im Nachhinein betrachte.

Kurz zusammengefasst

• Gartner: Mehr als 70% der kürzlichen ERP-Projekte verfehlen bis 2027 ihre ursprünglichen Geschäftsziele.
• Panorama: Mehr als 25% der ERP-Implementierungen sprengen das Budget aufgrund zusätzlicher Technologieanforderungen.
• Godlan: 73% der ERP-Projekte in der diskreten Fertigung verfehlen ihre Ziele, bei Kostenüberschreitungen von 215%.
• Fünf Fehlermuster wiederholen sich bei industriellen Engagements: Template-Diskrepanz, OT-Integrationsschulden, Adoptionsklippe, Abbruch beim Übergang von Pilot zu Produktion, Sunk-Cost-Bindung.
• Hershey (100 Mio. USD an nicht erfüllten Bestellungen), Lidl (500 Mio. Euro abgeschrieben) und Revlon (64 Mio. USD Fehlbetrag im ersten Quartal) zeigen dieses Muster in großem Maßstab.
• Etwa 60% der operativen Realität existiert außerhalb des Systems, in Funk, WhatsApp und Schichtnotizen, die das ERP nie zu Gesicht bekommt.

Statistik-Überblick zum Scheitern von ERP-Implementierungen

Jede Zahl in den folgenden Abschnitten ist belegt. Diese Tabelle fasst die Primärbelege zum schnellen Nachschlagen an einem Ort zusammen.

Quelle	Kernaussage
Gartner	Mehr als 70% der kürzlich implementierten ERP-Initiativen verfehlen bis 2027 ihre ursprünglichen Geschäftsziele
Panorama Consulting 2026	Mehr als 25% der ERP-Projekte überschreiten das Budget, getrieben von zusätzlichen Technologieanforderungen
Godlan 2026	73% der ERP-Projekte in der Fertigung verfehlen ihre Ziele, durchschnittliche Kostenüberschreitung von 215%
CIO über Hershey	Rund 100 Mio. USD an Bestellungen für Halloween 1999 blieben nach überstürztem SAP-Go-Live unerfüllt
Handelsblatt über Lidl	Berichtete rund 500 Mio. Euro Abschreibung, nachdem ein siebenjähriges SAP-Projekt gescheitert war
Dolfing über Revlon	64 Mio. USD an Bestellungen im ersten Quartal 2018 konnten nach der SAP-Migration nicht erfüllt werden
Revlon 10-K 2018	Im Jahresbericht ausgewiesener Nettoverlust von 294,2 Mio. USD für das Gesamtjahr 2018

Oben referenzierte Primärquellen:

Die fünf Arten, wie ERP-Projekte im industriellen Betrieb scheitern

Fünf Muster wiederholen sich immer wieder. Sie treten in unterschiedlichen Kombinationen bei verschiedenen Betrieben und Anbietern auf. Jede gescheiterte Implementierung, die ich überprüft habe, lässt sich mindestens drei davon zuordnen. Jedes Muster erhält unten einen eigenen Abschnitt.

1. Scope Creep durch generische Templates

Jedes große ERP-System basiert auf Prozess-Templates. Es gibt eine Standardmethode, um eine Bestellung abzubilden, und einen Standard-Arbeitsauftrag. Einen Standard-Bestandsdatensatz. Diese Templates wurden für den breitestmöglichen Kundenkreis konzipiert.

Sie passen zu diesem Kundenkreis etwa so gut wie Einheitskleidung zu einem echten menschlichen Körper.

Das Implementierungsteam bildet den Kundenprozess auf das Template ab. Wo es nicht passt, treffen sie eine Wahl: das System anpassen oder den Prozess ändern. Anpassung ist teuer und schafft dauerhafte technische Schulden. Eine Prozessänderung verlangt von den Betreibern, anders zu arbeiten, als sie es gewohnt sind.

In der Praxis geschieht beides gleichzeitig. Der Scope wächst, um die Anpassung abzudecken. Die Betreiber werden trotzdem angewiesen, sich anzupassen. Die Baukosten steigen vor dem Go-Live erheblich. Das Ergebnis ist weder ein sauberes Template noch eine originalgetreue Abbildung des Workflows.

Maßgeschneiderte Software geht von Ihrem Workflow aus, nicht von einem Anbieter-Template. Es gibt keine Übersetzungsebene zwischen der Art, wie der Betrieb läuft, und der Art, wie das System es erwartet.

2. OT-Integrationsschulden

Operational Technology bedeutet SCADA, PLCs, MES, Telematik und Sensornetzwerke. Sie steuert den physischen Betrieb. Sie spricht kein ERP.

ERP-Systeme wurden für Geschäftsdaten gebaut: Transaktionen, Datensätze, Genehmigungen. OT erzeugt Echtzeitsignale in einem Umfang, für den die meisten ERP-Datenmodelle nie ausgelegt waren.

Die typische Lösung ist ein Konnektor. Middleware übersetzt OT-Signale in ERP-freundliche Datensätze, und Konnektoren funktionieren in Demos. In der Produktion werden sie zu einem eigenen, mehrjährigen Wartungsprojekt.

Ein Konnektor, der für eine bestimmte PLC-Firmware gebaut wurde, bricht, wenn die PLC aktualisiert wird. Einer, der auf 100 Ereignisse pro Sekunde abgestimmt ist, übersteht keine 10.000. Der sechsmonatige Integrationsrückstand ist zwei Jahre später immer noch offen. Das Ops-Team betreibt einen parallelen Prozess in Tabellenkalkulationen, weil das angebundene System nur etwa 60% der Zeit tatsächlich verbunden ist.

Ich habe dieses Muster in Betriebshallen auf Häfen und Yards immer wieder gesehen. Die Konnektoren sind keine schlechte Software. Sie sind die falsche Architektur für das Problem.

Maßgeschneiderte Software behandelt OT von Anfang an als erstklassige Anforderung, nicht als später angeflanschte Middleware. Wenn Ihre Integrationsebene SCADA, PLC und Telematik als native Datenströme verarbeitet, entstehen keine Konnektorschulden.

3. Die Adoptionsklippe

Die Adoptionsklippe trifft ein, wenn die Menschen, die das System täglich nutzen, entscheiden, dass sie produktiver sind, wenn sie es ignorieren, statt es zu erlernen. Terminalbetreiber, Schichtleiter, Disponenten, Wartungsteams.

Das ist nicht irrational. Es ist eine rationale Reaktion auf ein System, das in einem Konferenzraum von einem Projektteam entworfen wurde, das nie eine Schicht gefahren hat.

Die Klippe zeigt sich innerhalb von 90 Tagen nach dem Go-Live. Das Projektteam ist verschwunden. Das Ops-Team greift für die wirklich wichtigen Entscheidungen wieder auf WhatsApp, Funk und Tabellenkalkulationen zurück. Das ERP wird für die Berichte genutzt, die das Finanzwesen verlangt.

Aus dem System of Record wird ein System of Compliance.

Adoption ist kein Trainingsproblem. Mehr Schulung zu einem schlechten Workflow bleibt mehr Schulung zu einem schlechten Workflow. Adoption ist ein Designproblem. Die Menschen, die das System nutzen sollten, saßen nicht mit am Tisch, als der Workflow entworfen wurde.

Maßgeschneiderte Software entsteht, indem man das Feld kennenlernt. Man setzt sich mit den Menschen zusammen, die die Schicht fahren. Man kartiert die tatsächlichen Ausnahmen und Grenzfälle. Man baut Workflows um das, was sie bereits können.

Das Ergebnis ist ein System, das zur Arbeit passt, sodass die Bediener es tatsächlich nutzen. Die Live-Operations-Ansicht sieht aus wie der Betrieb, weil sie aus dem Betrieb heraus gebaut wurde.

4. Der Abbruch zwischen Pilot und Produktion

ERP-Piloten gelingen. Der Proof-of-Concept läuft auf sauberen, kuratierten Daten und mit einer kleinen, betreuten Nutzergruppe. Ein eng gefasstes Prozessset, das das Implementierungsteam zu handhaben weiß.

Der Sponsor auf Führungsebene sieht die Demo. Das Projekt wird grün beleuchtet, und die vollständige Einführung beginnt.

Die Produktion ist ein anderes Tier. Sie hat unaufgeräumte Legacy-Daten, die vor der Migration nie vollständig bereinigt wurden. Sie hat Grenzfälle, die der Pilot nie berührt hat. Ein Frachtführer mit einem nicht standardisierten Frachtbrief-Format. Geräte mit einer Wartungshistorie in einem nicht eingebundenen System. Eine Schichtübergabe, die über Funk und WhatsApp läuft, weil sie es schon immer so getan hat.

Die saubere Pilotumgebung und die reale Produktionsumgebung sind nicht derselbe Ort.

Der Abbruch ist kein isoliertes Datenproblem. Es ist das, was passiert, wenn man an einer vereinfachten Version der Realität pilotiert und dann in die vollständige Version einführt, ohne das System anzupassen.

Maßgeschneiderte Software wird gegen das tatsächliche Verhalten des Betriebs validiert, einschließlich der Off-System-Daten. Die Status-Capture-Schicht verarbeitet, was über Funk, WhatsApp und E-Mail hereinkommt, nicht nur, was über strukturierte Integrationen ankommt. Die Produktionsumgebung ist die Designumgebung.

5. Sunk-Cost-Lock-in

Sobald ein Industrieunternehmen zwei bis fünf Millionen Dollar für ERP-Lizenzen, Beratung und Anpassung ausgegeben hat, wird der Ausstieg politisch unmöglich.

Der CFO hat die Summe genehmigt. Der Vorstand hat die Präsentation gesehen. Die Bediener, die früh Bedenken äußerten, wurden überstimmt. Bis klar wird, dass das System nicht liefern wird, ist die Organisation 18 Monate weiter.

Niemand möchte die Person sein, die das Memo unterzeichnet, das die Investition zum Abschreibungsposten erklärt.

Also legt die Organisation nach: mehr Anpassung. Mehr Beratung und mehr Change-Management. Die Gesamtkosten wachsen, und der Go-Live verschiebt sich. Das System, das am Ende ausgeliefert wird, ist ein Kompromiss, den niemand die Befugnis hat zu ersetzen.

Ich habe erlebt, wie Betriebsteams über Jahre hinweg Parallelsysteme fahren: ERP für die Compliance. WhatsApp und Tabellenkalkulationen für alles, was wirklich zählte.

Maßgeschneiderte Software kehrt das Risikomodell um. Man gibt nicht zwei Millionen Dollar aus, bevor man weiß, dass das System funktioniert. Man sieht eine echte, funktionierende Lösung auf den eigenen Daten, für ein selbst gewähltes Problem, und zahlt nur, wenn sie sich ihren Platz verdient. Das erste Risiko tragen wir.

Wie sich ERP-Fehlschläge im großen Maßstab auswirken

Die nächsten drei Fälle sind dokumentierte Fehlschläge mit realen Zahlen. Namentlich genannte Organisationen. Jeder lässt sich einem oder mehreren der oben genannten Muster zuordnen.

Hershey, 1999. Hershey führte im Sommer 1999 einen gleichzeitigen Go-live von SAP, Manugistics und Siebel durch. Der Zeitplan wurde um etwa sechs Monate verkürzt, um Halloween zu erreichen. Das System ging live, während die Halloween-Bestellungen hereinströmten. Es konnte Bestellungen im Wert von rund 100 Millionen Dollar für Kisses und Jolly Ranchers nicht rechtzeitig erfüllen. Die Hershey-Aktie fiel an einem Tag um rund 8 Prozent. Die Ursache war ein Pilot-zu-Produktion-Abbruch in einer Größenordnung von 100 Millionen Dollar.

Lidl, 2018. Nach rund sieben Jahren und geschätzten 500 Millionen Euro Ausgaben brach Lidl seine SAP-Implementierung ab. Laut Berichterstattung des Handelsblatts lag das Grundproblem in einer Diskrepanz des Datenmodells. Das Standard-Einzelhandelsbestandsmodell von SAP arbeitet mit Verkaufspreisen. Der Betrieb von Lidl arbeitet mit Einkaufspreisen. Lidl weigerte sich, seinen Prozess zu ändern, also wurde stattdessen SAP angepasst. Die Anpassung lief jahrelang, ohne Wert zu liefern. Weder Lidl noch SAP haben die berichteten Zahlen offiziell bestätigt. Scope Creep durch generische Vorlagen, in einer Größenordnung von 500 Millionen Euro.

Revlon, 2018. Die SAP-Migration von Revlon in seiner Anlage in Oxford, North Carolina, störte die Lieferungen im ersten Quartal. Das Unternehmen konnte allein im ersten Quartal Bestellungen im geschätzten Wert von 64 Millionen Dollar nicht erfüllen. Die Zahl tauchte in Sammelklagen von Investoren auf, die aus Gewinnmitteilungen abgeleitet wurden. Revlon meldete in seinem Jahresbericht 10-K für das Gesamtjahr 2018 einen Nettoverlust von 294,2 Millionen Dollar. Die 64-Millionen-Dollar-Zahl wird auf LinkedIn manchmal mit der Schuldenlast von 3 Milliarden Dollar verwechselt, die der späteren Insolvenz von Revlon vorausging. Das sind unterschiedliche Ereignisse. Der ERP-Fehlschlag von 2018 war ein Fehlschlag bei der OT-Integration und der Produktionsreife.

Der rote Faden: Keiner dieser Fälle war ein Technologieproblem. Es waren Architektur- und Validierungsprobleme. Jede Organisation setzte ein System ein, das in einer kontrollierten Umgebung funktionierte und im realen Betrieb versagte.

Der dritte Weg

Auf die obige Liste von Fehlschlägen gibt es zwei naheliegende Reaktionen.

Die erste besteht darin, intern zu bauen und ein Entwicklungsteam einzustellen. Anforderungen von Grund auf spezifizieren. Software bauen, die exakt zum Betrieb passt, was gelegentlich funktioniert. Es erfordert außerdem ein mehrjähriges Engineering-Engagement, technische Führung, die die meisten Betreiber nicht haben, und laufende Investitionen, um das Gebaute zu erhalten.

Wenn Ihre Kernaufgabe darin besteht, einen Hafen, einen Yard oder eine Mine zu betreiben, ist der interne Softwarebau eine Ablenkung.

Die zweite besteht darin, ein besseres ERP oder eine spezialisiertere vertikale SaaS-Lösung zu kaufen und die Implementierung sorgfältiger zu steuern. Das ist dieselbe Wette, nur mit besserer Projektsteuerung erneut platziert. Die strukturellen Probleme verschwinden nicht, nur weil der Projektmanager erfahrener ist.

Der dritte Weg unterscheidet sich in der Art, nicht im Grad. Maßgeschneiderte Software: gebaut für Ihre spezifischen Ziele, verdrahtet mit Ihren spezifischen Systemen und Daten, validiert gegen das tatsächliche Verhalten Ihres Betriebs. Über ihren gesamten Lebenszyklus hinweg am Laufen gehalten und weiterentwickelt.

Opsima ist die KI-native Software-Fabrik für industrielle Betriebe. Sie baut die CMMS-, TMS-, TOS-, EAM-, ERP-, Geräteüberwachungs- und Dokumentenverarbeitungs-Software, auf der Ihr Betrieb tatsächlich läuft, zugeschnitten auf die Art, wie Ihr Betrieb arbeitet.

Zwei Service-Modi: (1) Overlay auf Ihrem bestehenden System (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) ohne Rip-and-Replace, oder (2) Aufbau des Ersatzsystems von Grund auf, wenn das Legacy-System ausgewachsen ist. Lieferung in Wochen. Sie zahlen nur, wenn Sie den Wert sehen.

Das ist der dritte Weg, über den wir schon einmal geschrieben haben. Er adressiert die Fehlschlagsmuster an ihrer Wurzel, nicht an ihren Symptomen.

Das Opsima-Modell macht das konkret. Wir lernen, wie der Betrieb tatsächlich läuft, Grenzfälle inklusive. Wir bauen Software, die um diesen Workflow herum entworfen ist. Sie integriert sich in das ERP, EAM, TMS, TOS oder WMS, das Sie bereits betreiben, statt es zu ersetzen. Wir verarbeiten die Daten, die nie in Ihren Systemen of Record ankommen: die Funksprüche, die WhatsApp-Threads, die handschriftlichen Schichtnotizen. Das sind auf den meisten Betriebsflächen, die ich besucht habe, rund 60 Prozent der operativen Realität.

Dann gehen wir live, validieren gegen das reale Produktionsverhalten und halten das System am Laufen und in Weiterentwicklung, während sich der Betrieb verändert.

Das kommerzielle Modell spiegelt die Umkehrung des Risikos wider. Sie verpflichten sich nicht zu einem mehrere Millionen Dollar schweren Lizenzdeal, bevor Sie gesehen haben, dass das System funktioniert. Wir bauen eine echte, funktionierende Lösung für ein von Ihnen gewähltes Problem, auf Ihren Daten, auf Ihrer Infrastruktur. Sie sehen sie laufen. Sie bewerten sie gegen Ihren Betrieb, und dann entscheiden Sie.

Die Details stehen auf der Preisseite. Kurz gesagt: Wir übernehmen das erste Risiko.

Die Case Studies zeigen, wie das in der Praxis aussieht. Eine davon ist PNCT.

Wie es aussieht, wenn es funktioniert

Das Port Newark Container Terminal wickelt jährlich rund 1,65 Millionen TEU über eine Flotte von mehr als 100 Straddle Carriern ab. Die Flotte läuft 24 Stunden am Tag, sieben Tage die Woche. Die Verfügbarkeit der Straddle Carrier ist der begrenzende Faktor. Wenn ein Carrier ausfällt, sinkt der Durchsatz. Jede Stunde ungeplanter Ausfallzeit hat reale Kosten.

Das Problem, das PNCT zu Opsima brachte, war nicht exotisch. Gerätedaten, Wartungshistorie und Betriebsprotokolle lagen in Systemen, die nicht miteinander kommunizierten. Techniker trafen Wartungsentscheidungen auf Basis unvollständiger Informationen. Ausfälle waren reaktiv, nicht vorausschauend.

Opsima baute eine Lösung, die mit den Systemen verbunden war, die PNCT bereits betrieb. Telemetrie, Wartungsaufzeichnungen und Betriebsdaten flossen in eine Live-Operations-Schicht, die das Wartungsteam tatsächlich nutzen konnte.

Das Ergebnis: +5 Prozent Verfügbarkeit der Straddle-Carrier-Flotte und eine Reduzierung ungeplanter Ausfälle um rund 15 Prozent.

Bei einer Flotte von 100 Carriern entsprechen 5 Prozent Verfügbarkeit rund fünf zusätzlichen Einheiten, die pro Schicht online sind. Diese fünf Einheiten erfordern keine neuen Geräteanschaffungen. Sie erfordern keine neuen Investitionsausgaben. Sie erfordern kein neues Personal. Sie sind Durchsatzkapazität, die durch bessere Information aus der bestehenden Flotte zurückgewonnen wurde.

Das Team bei PNCT brachte es auf den Punkt: „Sie waren nicht einfach nur ein weiterer großer Softwareanbieter. Sie kamen bereits mit einem Konzept und einer Can-do-Einstellung.“

Das ist der Unterschied zwischen einem System, das für tausend Kunden gebaut wurde, und einem, das für Sie gebaut wurde.

Ein klar umrissenes Problem und ein ausgeliefertes System. Wochen, nicht Jahre.

Eine 10-Fragen-Diagnose zur ERP-Passgenauigkeit

Bevor Sie sich auf eine ERP-Implementierung festlegen, oder bevor Sie akzeptieren, dass die aktuelle Lösung die beste verfügbare Option ist, beantworten Sie diese zehn Fragen ehrlich. Jede lässt sich einem der fünf oben genannten Fehlschlagsmuster zuordnen.

Zur Passgenauigkeit der Vorlage:

1. Kann Ihr Operations-Team einen Workflow beschreiben, den das ERP exakt so abwickelt, wie er konzipiert wurde, ohne Anpassung oder Workaround?
2. Wenn sich ein Prozess im Feld ändert: Wie lange dauert es, bis diese Änderung im System abgebildet ist? Stunden, Wochen oder Monate?

Zur OT-Integration:

1. Werden Ihre SCADA- und PLC-Datenströme als erstklassige Daten behandelt, oder werden sie über einen Connector außerhalb der Kernarchitektur eingebunden?
2. Gilt Ihr Integrationsprojekt seit mehr als sechs Monaten als „fast abgeschlossen“?

Zur Akzeptanz:

1. Hatten die Menschen, die Ihre Schichten leiten, echten Einfluss auf die Gestaltung des Workflows? Oder wurden sie erst zum UAT hinzugezogen, nachdem das Design bereits feststand?
2. Welcher Anteil der operativen Entscheidungen wird tatsächlich im System getroffen, und welcher Anteil daneben, per Funkspruch, WhatsApp und Excel-Tabelle?

Vom Pilotprojekt zum Produktivbetrieb:

1. Lief Ihr Pilotprojekt auf einem bereinigten, kuratierten Datensatz oder auf einem echten, unaufbereiteten Ausschnitt der Produktivdaten?
2. Bewältigt das System Ausnahmefälle genauso gut wie den Standardfall? Den untypischen Frachtführer, die lückenhafte Wartungshistorie, die Funkübergabe?

Zum kommerziellen Risiko:

1. Haben Sie eine funktionierende Lösung anhand Ihrer eigenen Daten gesehen, bevor Sie sich zu den Ausgaben verpflichtet haben? Oder haben Sie sich auf Basis einer Vendor-Demo mit Vendor-Daten entschieden?
2. Hängt die Preisgestaltung davon ab, ob das System für Ihren Betrieb funktioniert, oder wird der Anbieter unabhängig davon bezahlt?

Wenn Sie drei oder mehr Fragen mit Nein beantwortet haben, beschreiben Sie kein ERP-Fit-Problem. Sie beschreiben ein Problem, das maßgeschneiderte Software erfordert.

Das Fazit

ERP-Implementierungen scheitern in industriellen Betrieben aus strukturellen Gründen, und diese Gründe wiederholen sich.

Generische Vorlagen zwingen den Betrieb, sich anzupassen, und die OT-Integrationsschuld wächst weiter an. Die Akzeptanz bricht zusammen, wenn die Menschen, die den Betrieb führen, bei der Gestaltung des Workflows nicht im Raum waren. Pilotprojekte gelingen mit sauberen Daten und scheitern an der Produktivrealität. Versunkene Kosten machen einen Kurswechsel politisch unmöglich.

Die Alternative ist Software, die um Ihren Betrieb herum gebaut wird. Ihr Workflow, Ihre Systeme, Ihre Daten. Über den gesamten Lebenszyklus hinweg am Laufen gehalten und weiterentwickelt, statt übergeben und vergessen.

Maßgeschneiderte Software, gebaut für Ihren Workflow, bezahlt erst, wenn Sie den Wert sehen. Genau das sollte ERP eigentlich sein.

Nennen Sie uns den Prozess, dessen Behebung Sie aufgegeben haben. Wir bauen eine echte, funktionierende Lösung auf Basis Ihrer Daten, für ein Problem Ihrer Wahl. Sie zahlen nur, wenn sie sich bewährt. Um die nächste Implementierung mit maßgeschneiderter Software, gebaut um Ihren Betrieb herum, risikoärmer zu machen, vereinbaren Sie eine Arbeitssitzung mit Opsima.