Inhaltsverzeichnis

Die meisten Erklärungen für gescheiterte ERP-Einführungen beginnen am Ende: ein verspäteter go-live, ein überschrittenes Budget, ein Team, das das System nicht nutzen will. Meist beginnt das Projekt aber deutlich früher zu brechen.

In der Realität scheitern Enterprise-Resource-Planning-Projekte (ERP) selten an einem einzigen dramatischen Fehler. Die nützliche Frage lautet daher nicht nur, warum eine ERP-Einführung scheitert. Entscheidend ist, wo und wie das Projekt fragil wird, bevor es überhaupt als gescheitert gilt.

Die folgenden Abschnitte betrachten sechs Warnsignale, die vor dem go-live auftreten, und danach die Prüfungen, mit denen Hersteller das Risiko einer ERP-Einführung senken, bevor sich das Projekt um falsche Annahmen verhärtet.

Die Prozesslandkarte ist schon veraltet

Die meisten ERP-Einführungsprojekte beginnen mit Discovery. Das Team interviewt Abteilungsleiter, dokumentiert Workflows, definiert Anforderungen und bildet das Unternehmen als Prozesslandkarte ab.

Diese Arbeit ist notwendig, bringt aber eine Falle mit sich: Die Landkarte altert, sobald sie fertig ist.

Ein neuer Großhandelskunde ändert Lieferregeln. Eine Lieferanten-Lead-Time verschiebt sich von zwei auf sechs Wochen. Eine Produktionszelle wird umorganisiert, weil das alte Layout das neue Volumen nicht mehr bewältigt. Das Unternehmen passt sich weiter an, aber das ERP-Projekt führt weiter die Version des Geschäfts ein, die während der Workshops vor drei Monaten existierte.

Wenn das System bereit für Tests ist, sehen Bediener Oberflächen, die technisch zu den freigegebenen Anforderungen passen, aber praktisch verfehlen, wie Arbeit inzwischen abläuft. Dann muss das Projektteam entscheiden, ob es den go-live verschiebt, um das System neu zu konfigurieren, oder das Team auf Software zwingt, die sofort umgangen wird.

Das ist der erste Fehlermodus einer ERP-Einführung: operative Abläufe wie ein statisches Objekt zu behandeln.

Jede Ausnahme wird vorab modelliert

Die Einführung eines traditionellen ERP setzt voraus, dass das Unternehmen die meisten seiner Regeln vor dem go-live definiert. Dazu gehören Arbeitspläne, Einkaufslogik, Bestandsregeln, Qualitätsprüfungen, Freigabeflüsse, Kundenausnahmen, Preisfälle und Planungsrestriktionen.

In stabilen, standardisierten Umgebungen kann das funktionieren. Viele Hersteller arbeiten aber nicht mehr in dieser Welt, besonders mittelständische Fabriken, die sich schnell verändern. Produktlinien wachsen, Kunden verlangen mehr Varianten, Lieferanten werden weniger berechenbar und das Team erfindet kleine Ausnahmen, damit Aufträge weiterlaufen. Einige dieser Ausnahmen sollten zu formalen Regeln werden. Einige sollten verschwinden. Einige sind nur für einen Kunden, eine Saison oder eine Produktfamilie relevant.

Legacy-ERP-Projekte tun sich schwer, weil sie zu viel dieser lebendigen operativen Logik in feste Konfiguration zwingen. Berater bitten das Team, alles vorab zu entscheiden, weil spätere Änderungen langsam und teuer werden. Das Ergebnis ist entweder Übermodellierung oder Untermodellierung:

Übermodellierung schafft ein System, das so komplex ist, dass Nutzer es vermeiden.
Untermodellierung schafft ein System, das den Standardfluss abdeckt und das reale Geschäft zurück nach Excel schickt.

Deshalb kann eine ERP-Einführung die Benutzerakzeptanztests bestehen und im Alltag trotzdem scheitern. Die Testfälle decken den sauberen Prozess ab, aber die Fabrik läuft mit Ausnahmen.

Die Daten werden einmal bereinigt und driften dann wieder

Die meisten ERP-Einführungsprojekte enthalten eine Phase zur Datenbereinigung. Der Artikelstamm wird korrigiert, Stücklisten werden importiert, Lieferantencodes werden abgeglichen, Bestände werden abgestimmt und offene Aufträge in das neue System übertragen.

Diese Arbeit zählt, aber sie beweist nur, dass die Daten am Migrationstag sauber waren.

Die schwierigere Frage ist, wie die Daten vertrauenswürdig bleiben, sobald die Produktion mit dem ERP arbeitet. Wenn Bestandsbewegungen weiterhin verspätet erfasst werden, wenn Bediener Papiernotizen brauchen, bevor sie das System aktualisieren, oder wenn Vertrieb und Produktion ihre eigenen Versionen desselben Auftrags pflegen, driften die Zahlen wieder auseinander.

An diesem Punkt wird der go-live gefährlich. Das neue ERP wirkt offiziell, aber die Fertigung weiß vielleicht bereits, welche Zahlen nur Näherungswerte sind. Die Planung beginnt, Entscheidungen aus Beständen, Arbeitsplanzzeiten oder Auftragsstatus abzuleiten, die Menschen still umgehen.

Nach einigen schlechten Erfahrungen bauen Teams das parallele System wieder auf, das sie eigentlich verlassen wollten. Bediener behalten die Papiernotiz oder Tabelle, die ihnen hilft, die Schicht zu steuern, und aktualisieren das ERP später. Bis dahin hat die Planung die Echtzeitsicht bereits verloren, die sie gebraucht hätte.

Nutzer werden auf Oberflächen geschult, nicht auf Entscheidungen

ERP-Schulungen zeigen oft, wo geklickt wird: hier einen Fertigungsauftrag anlegen, dort Bestand einbuchen, den Batch auf dieser Oberfläche schließen, über diesen Workflow eskalieren.

Das ist nützlich, beantwortet aber nicht die Fragen, die Nutzer während der Produktion tatsächlich haben.

Welcher Bestandszahl soll ich trauen, wenn ERP und Regal nicht übereinstimmen? Was passiert, wenn das Material zu spät kommt, der Kundenauftrag aber dringend ist? Wer darf einen Arbeitsplan ändern? Wann halte ich die Linie wegen eines Qualitätsproblems an? Was soll ich tun, wenn das System eine Information verlangt, die ich nicht habe?

Wenn diese Entscheidungen unklar sind, schützen Nutzer den Betrieb auf die Weise, die sie bereits kennen. Sie behalten eine Papiernotiz, schreiben der Planung, aktualisieren die Tabelle oder warten auf die eine Person, die die Ausnahme versteht.

Die ERP-Einführung scheint dann ein Akzeptanzproblem zu haben, obwohl sie in Wirklichkeit ein Problem im Entscheidungsdesign hat. Menschen lehnen Systeme nicht ab, weil sie Veränderung nicht mögen. Sie lehnen Systeme ab, die es schwerer machen, die Fabrik am Laufen zu halten.

Integrationen kommen zu spät

Ein Fertigungs-ERP lebt selten allein. Aufträge können aus Shopify, einem Kundenportal, Electronic Data Interchange, einem CRM oder einem Vertriebstool kommen. Rechnungen können in Finanzsoftware fließen. Prognosen können in einer anderen Planungsdatei liegen. Versanddaten können von Transporteuren oder Lagerwerkzeugen kommen.

Wenn Integrationen als späte technische Aufgabe behandelt werden, verfehlt die ERP-Einführung den täglichen Rhythmus des Unternehmens.

Das Vertriebsteam verkauft weiter in einem System, die Produktion plant in einem anderen, die Finanzabteilung schließt in einem dritten, und alle nehmen an, dass das ERP später alles verbindet. Dann kommt dieses "später" mit Grenzfällen: Kundencodes passen nicht zusammen, Auftragsstatus bedeuten unterschiedliche Dinge, Mengeneinheiten sind uneinheitlich und niemand hat entschieden, welches System welches Feld besitzt.

Das ist ein häufiger Grund, warum ERP-Einführungsprojekte in Modultests gut aussehen und in durchgängigen Tests brechen. Der Prozess jeder Abteilung funktioniert innerhalb seiner eigenen Grenze. Das Geschäft scheitert an den Übergaben.

In der Fertigung sind diese Übergaben der Betrieb: Vertrieb an Produktion, Produktion an Einkauf, Einkauf an Bestand, Bestand an Logistik und Logistik an Finanzen. Wenn diese Flüsse erst am Ende getestet werden, kommen Integrationsprobleme zu einem Zeitpunkt, an dem wenig Zeit bleibt, Verantwortlichkeiten, Status oder Datenfluss zu korrigieren.

Der Zeitplan arbeitet gegen das Unternehmen

Eine lange Einführung gibt dem Unternehmen mehr Zeit, sich von der Version zu entfernen, die gerade konfiguriert wird.

Ein 12-Monats-Projekt gibt dem Unternehmen 12 Monate, sich zu verändern, bevor das System live ist. Ein 18-Monats-Projekt gibt ihm 18 Monate. Für einen Hersteller, der 20 %, 30 % oder 50 % pro Jahr wächst, ist diese Verzögerung erheblich. Auftragsvolumen verändert sich, der Produktkatalog wächst, das Team wird größer und die Prozessannahmen hinter dem Projekt werden schwächer.

Lange Zeitpläne zehren auch an interner Energie. Die ersten Workshops bekommen Aufmerksamkeit vom Management. Die vierte Validierungsrunde bekommt müde Antworten. Wenn die Schulung beginnt, sind die Menschen, die das Projekt tragen sollten, vielleicht mit einem neuen Lager, einem neuen Kunden oder einem Produktionsproblem beschäftigt, das nicht warten kann.

Deshalb wirkt das Scheitern einer ERP-Einführung von außen oft plötzlich und von innen langsam. Das Projekt bricht nicht auf einmal zusammen. Es verliert Monat für Monat an Relevanz.

Was eine bessere ERP-Einführung früh prüft

Eine bessere ERP-Einführung beginnt mit einigen unbequemen Prüfungen.

Kann das System die unordentlichen 20 % der Abläufe abbilden oder nur den sauberen Prozess?
Kann das Team Regeln nach dem go-live ändern, ohne ein Beratungsprojekt zu starten?
Kann ein Auftrag von Vertrieb zu Produktion, Bestand, Versand und Finanzen laufen, bevor jedes Team sein eigenes Modul abzeichnet?
Verbindet sich das ERP mit den Werkzeugen, die das Unternehmen bereits nutzt?
Sehen Bediener, warum das System sie zu etwas auffordert, oder füttern sie nur eine weitere Datenbank?

Die wichtigste Prüfung ist das Timing. Wenn die Einführung länger dauert, als das Unternehmen stillstehen kann, ist das Projekt bereits gefährdet.

Wenn ein ERP-Anbieter diese Prüfungen nicht besteht, sollte das nicht als normaler Preis einer ERP-Einführung gelten. Es sollte ein Grund sein, nach einem System zu suchen, das schnell eingeführt werden kann, sich nach dem go-live anpassen lässt und den realen Arbeitsfluss verbindet.

Heute gibt es bessere Optionen. Eine Einführung über 12 bis 18 Monate ist kein Gesetz für Fertigungssoftware. Sie ist ein Symptom von Systemen, die das Unternehmen verlangsamen, standardisieren und warten lassen, während das Projekt aufholt. Die erste Live-Version sollte die wichtigsten Flüsse abdecken und sich dann mit dem Team verbessern, während das Unternehmen sich weiterentwickelt.

Bonx ist ein KI-natives Fertigungs-ERP, das Kunden in Wochen und nicht in Monaten einführen, während das System nach dem go-live anpassbar bleibt. Einführung wird nicht als einmaliger Versuch behandelt, das Unternehmen einzufrieren, sondern als Start eines Systems, das weiter aus realen Betriebsbedingungen lernt.

Der Beleg liegt in den Kundeneinführungen. Féroce ging mit Bonx in 42 Tagen live, ohne den Betrieb zu unterbrechen, bevor ein Auftritt im nationalen Fernsehen die Bestellungen an einem einzigen Tag verzehnfachte. Bei L'Atelier du Ferment, als Produktion, Verwaltung von Mindesthaltbarkeiten und Rückverfolgbarkeit komplexer wurden, führte das Unternehmen Bonx ein, um Vertrieb, Beschaffung und Fertigung zu strukturieren, einschließlich Verbindungen mit Sidely und Pennylane. Bonx hilft außerdem, Fertigungsaufträge und Beschaffungsvorschläge auf Basis von Verkäufen, Haltbarkeit und Kühlkapazität zu generieren.

Diese Beispiele zeigen mehr als Geschwindigkeit. Sie zeigen, was eine ERP-Einführung beweisen muss: Das Unternehmen kann weiterlaufen, das System kann den realen Arbeitsfluss verbinden und das Team kann sich nach dem go-live weiter anpassen.

Für einen tieferen Blick auf die Architektur hinter diesem Wandel lesen Sie KI-ERP vs. traditionelles ERP.

FAQ zur ERP-Einführung

Warum scheitern ERP-Einführungen?

ERP-Einführungen scheitern, wenn das Projekt eine saubere Version des Unternehmens modelliert, die nicht zu den täglichen Abläufen passt. Traditionelle ERP-Anbieter, darunter SAP, haben dieses Problem normalisiert, indem sie lange Zeitpläne, starre Konfiguration, späte Integrationen und aufwendige Beratung als Kosten einer ERP-Einführung darstellen. Das sind sie nicht. Sie sind die Gründe, warum viele Projekte schon vor dem go-live fragil werden.

Wie lange sollte eine ERP-Einführung dauern?

Zeitpläne für ERP-Einführungen hängen von Umfang und Komplexität ab, aber lange Laufzeiten erhöhen das Risiko für wachsende Hersteller. Traditionelle Projekte ziehen sich oft über viele Monate, weil die meisten Regeln vorab modelliert werden müssen. Bonx-Kunden sehen meist in weniger als einem Monat ersten Nutzen und erreichen eine vollständige Einführung in ein bis drei Monaten, abhängig von der operativen Komplexität.

Was ist das größte Risiko bei einer ERP-Einführung?

Das größte Risiko ist, ein System einzuführen, das im Projektraum funktioniert und in der Fabrik scheitert. Wenn Bediener weiterhin Tabellen, Papiernotizen oder inoffizielle Umgehungen brauchen, um die Produktion am Laufen zu halten, ist das ERP nicht zum Betriebssystem des Unternehmens geworden.

Wie können Hersteller das Risiko einer ERP-Einführung senken?

Das Risiko einer ERP-Einführung sinkt, wenn Sie echte Flüsse früh testen, Bediener vor der Schulung einbinden, Integrationen vor dem go-live nachweisen und ein System wählen, das Ihr Team nach der Einführung anpassen kann. Bonx ist um dieses Modell herum gebaut: Es passt zu Ihren Abläufen, verbindet sich mit den Werkzeugen in Ihrer bestehenden Systemlandschaft und kann verändert werden, ohne jede Prozessaktualisierung in ein Beratungsprojekt zu verwandeln.

Wann sollte ein Hersteller eine ERP-Einführung starten?

Ein Hersteller sollte eine ERP-Einführung starten, bevor das aktuelle System zum Engpass wird. Warnsignale sind Bestandszahlen, denen niemand vollständig traut, manuell neu aufgebaute Produktionspläne, Auftragsverzögerungen mit unklaren Ursachen, Rückverfolgbarkeit über Papier und Tabellen hinweg und ein oder zwei Personen, die zu viel operatives Wissen tragen.