Warum ERPs absichtlich so langsam und kostspielig implementiert werden

Joannes Vermorel

Alle paar Wochen treffe ich einen Entscheider, der immer noch das ERP einführt. Das Programm begann unter einem früheren Führungsteam. Das Budget ist zu einer Zahl geworden, über die niemand gerne laut spricht. Und die bereits halbgeschriebene Nachbetrachtung macht den Anbieter, den Integrator, den Widerstand gegen Veränderungen oder die Besonderheit des Geschäfts verantwortlich. Diese Geschichte ist so häufig, dass sie zum Hintergrundrauschen geworden ist.

Die unangenehme Wahrheit ist, dass die meisten ERP-Einführungen aus strukturellen Gründen langsam und teuer sind. Nicht, weil jedes beteiligte Team inkompetent wäre. Nicht einmal, weil die Anforderungen unklar waren. Sie sind langsam und teuer, weil die wirtschaftlichen und technischen Anreize, die ERP-Systeme über Jahrzehnte hinweg geprägt haben, sie als Kategorie langsam und teuer machen.¹

In meinem Buch Introduction to Supply Chain (Kapitel 5, „Information“, Abschnitt „Systems of records“) widme ich einer überraschend vernachlässigten Idee Aufmerksamkeit: Die Software, die Transaktionen aufzeichnet, ist sowohl unverzichtbar als auch grundlegend begrenzt. Ihre Aufgabe ist es, ein zuverlässiges Hauptbuch zu sein – und sonst nichts. Wenn Unternehmen das vergessen, zahlen sie bald „strategische“ Preise für das, was im Kern eine transaktionale Verwaltungsmaschine ist. Genau hier beginnt das Problem.

Der Entitätsdschungel und das Anbieter-Laufband

Beginnen wir damit, was ein ERP in der Praxis ist. Es ist ein transaktionales System, das auf einer relationalen Datenbank aufgebaut ist und die Ressourcen und Routineabläufe des Unternehmens über viele Module, zahlreiche Bildschirme und einen großen Katalog von „Entitäten“ (Produkte, Kunden, Rechnungen, Bestellungen usw.) verfolgt.¹

Nun, hier ist die Dynamik, die stillschweigend dafür sorgt, dass ERP-Einführungen schmerzhaft bleiben.

Ein ERP-Anbieter entwickelt die Software nicht „für Sie“. Er entwickelt sie für die Gesamtheit seiner Kundenbasis über Jahrzehnte hinweg. Das Produkt wächst allmählich. Jeder große Kunde bringt eine Handvoll „Must-have“-Konzepte, Ausnahmen, Arbeitsabläufe, regulatorische Eigenheiten und Vokabular mit, das als erstklassige Funktion gefordert wird. Anbieter können hinzufügen; sie entfernen fast nie etwas. Es gibt keinen kommerziellen Vorteil darin, obskure Entitäten zu entfernen, auf die sich ein Alt-Kunde verlässt. Das Ergebnis ist ein Produkt, das unaufhörlich wächst – eine Entität nach der anderen, ein Modul nach dem anderen.¹

Das ist wichtig, denn Komplexität skaliert nicht linear. Die Unterstützung von doppelt so vielen Funktionen kostet weit mehr als das Doppelte an Entwicklungsaufwand, und die interne „semantische Kohäsion“ des Produkts verschlechtert sich im Laufe der Zeit.¹

Bei der ersten Einführung wird dieses Wachstum durch den Vertriebsprozess verschleiert. ERP-Anbieter verkaufen nach Modulen; Kundenunternehmen übernehmen die Module einzeln. Ein Modul jetzt, ein weiteres in sechs Monaten, ein weiteres im nächsten Jahr. Das Unternehmen erhält die Illusion von schrittweisem Fortschritt, und der Integrator kann den Aufwand über mehrere Phasen verteilen.¹

Bei Upgrades bricht die Illusion zusammen.

Selbst wenn Sie beim gleichen Anbieter bleiben, sind Upgrades bekanntermaßen schwierig und dauern oft viele Monate, manchmal Jahre.¹ Der technische Grund ist nicht geheimnisvoll: Die Migration ist selten eine einfache Eins-zu-eins-Kopie. Die Bedeutung von Entitäten entwickelt sich weiter. Eine Tabelle, die einst „Kundenbestellungen“ bedeutete, wird umfunktioniert, um auch Retouren darzustellen; die „Lösung“ besteht aus negativen Mengen, zusätzlichen Flags, weiteren Joins, Sonderfällen und nachgelagerten Annahmen, die stillschweigend scheitern.¹

So entsteht das eigentliche Problem: das Mapping-Problem.

Der Großteil der Arbeit besteht nicht im „Installieren“ der Software. Es geht darum, eine Entsprechung zwischen zwei inkompatiblen Vokabularen des Geschäfts herzustellen: der Semantik des alten ERPs und der Semantik des neuen ERPs. Und da beide Semantiken von der Vorgeschichte des Anbieters und nicht nur von Ihrem Unternehmen geprägt sind, spiegelt die Anzahl der zu vereinbarenden Konzepte die angesammelte Kundenbasis des Anbieters wider. Ihr Unternehmen zahlt dafür, ein von allen anderen errichtetes Labyrinth zu durchqueren.

Die Anpassung verschärft das Problem zusätzlich. Wenn der Kunde und sein Integrator maßgeschneiderte Entitäten, maßgeschneiderte Bildschirme, maßgeschneiderte Arbeitsabläufe hinzufügen – Dinge, die für den Anbieter nicht umsetzbar waren – werden diese kundenspezifischen Elemente zu einem lokalen Dialekt. Später, wenn der Anbieter refaktoriert (selbst auch nur geringfügig), sieht sich das Unternehmen zu einem zweiten, weit hässlicheren Mapping gezwungen: Vom alten kundenspezifischen Dialekt zum neuen Standarddialekt, plus alle neuen Anpassungen, die erforderlich sind, um die Lücken zu schließen.

Das ist kein Zufall. Es ist das, was passiert, wenn der kommerzielle Erfolg eines Produkts davon abhängt, seinen Umfang kontinuierlich zu erweitern, während die Abwärtskompatibilität für eine vielfältige Kundenbasis erhalten bleibt. Es ist die unvermeidliche Verlangsamung eines Entitätsdschungels.

Wenn ein System versucht, drei Aufgaben zu erfüllen

Das zweite strukturelle Problem ist noch allgegenwärtiger: Unternehmen verlangen routinemäßig, dass das ERP drei verschiedene Aufgaben gleichzeitig erfüllt.

Sie wollen, dass das ERP Transaktionen aufzeichnet (das Hauptbuch), Analysen und Dashboards bereitstellt (den „Spiegel“) und Entscheidungen trifft (das „Gehirn“). Anbieter fördern dies gerne, da Bündelung profitabel ist: Sobald das ERP als „die Plattform, die das Unternehmen steuert“ positioniert wird, wird jedes zusätzliche Modul zu einem „Must-have.“²

Doch aus der Perspektive des Softwaredesigns ziehen diese Aufgaben in entgegengesetzte Richtungen.

Die Transaktionsverarbeitung dreht sich um schnelle, zuverlässige Aktualisierungen und strenge Konsistenz. Die analytische Verarbeitung hingegen geht darum, große Datensätze zu durchsuchen, zu aggregieren, zu segmentieren und zu analysieren. Es handelt sich um unterschiedliche Arbeitslasten, die häufig mit verschiedenen Datenmodellen und unterschiedlichen Leistungskompromissen implementiert werden; die Branche hat für diese Unterscheidung seit Jahrzehnten Namen (OLTP vs OLAP).³

Wenn Sie versuchen, beides in einem einzigen Monolithen zu vereinen, schaffen Sie ein System, das ständig im Konflikt mit sich selbst steht. Die „fetten“ Operationen – Berichte, Analysen, Pseudo-Planungsfunktionen – konkurrieren mit den alltäglichen transaktionalen Vorgängen. Die Nutzer erleben dies als Langsamkeit, Zeitüberschreitungen, nächtliche Batch-Prozesse, fragile Integrationen und den ewigen Vorwurf, dass „das System das nicht kann.“ Inzwischen zahlt das Unternehmen einen Aufpreis für das Privileg, Widersprüche in die Architektur einzubetten.

Es hilft auch nicht, dass „ERP“ ein irreführender Name ist. Historisch gesehen klingt das „P“ für Planung wie ein Versprechen von Intelligenz. In Wirklichkeit ist Planung bestenfalls eine untergeordnete Angelegenheit bei ERPs, und prädiktive Analysen stehen im Widerspruch zu ihrem grundlegenden transaktionalen Design.¹

Mein Artikel aus dem Juni 2024 über Unternehmenssoftware argumentierte, dass die chronische Verschwendung in der Branche darauf zurückzuführen ist, dass diese Kategorien verwischt und exorbitante Summen für das Falsche gezahlt werden. Der grundlegende Punkt, ganz ohne Fachjargon, ist einfach: Ein Hauptbuch ist keine Strategie-Engine, und der Versuch, es dazu zu bringen, führt zu Komplexität, ohne den erhofften Nutzen zu liefern.²

Wenn Sie einen eindrucksvollen Beleg dafür wünschen, dass ich mit dieser Auffassung nicht allein bin, schauen Sie sich an, wie die großen Cloud-Anbieter Datensysteme erklären: Sie empfehlen ausdrücklich, transaktionale Systeme zur zuverlässigen Speicherung und Aktualisierung von Datensätzen zu nutzen, und analytische Systeme, um Berichte zu erstellen und komplexe Analysen durchzuführen. Sie tun nicht so, als ob ein Datenbankmodus in allem brilliert; vielmehr beschreiben sie ergänzende Rollen.³

ERP-Anbieter verkaufen den gegenteiligen Traum: ein System, das alles kann. Der Traum ist lukrativ. Der Kater wird vom Kunden bezahlt.

Die Falle namens „Anpassung“ und die Arbeit namens „Migration“

Fachliteratur von Dritten und Anbieter-Dokumentation laufen in einem Punkt zusammen, den Praktiker bereits in ihrem tiefsten Inneren wissen: Anpassung und Migration sind die Orte, an denen Projekte zugrunde gehen.

Ein ScienceDirect-Artikel über ERP-Anpassung beschreibt sie als ein „zweiseitiges Schwert“ und weist darauf hin, dass, obwohl Anpassungen die Passgenauigkeit verbessern können, sie auch zu erhöhten Implementierungskosten, gesteigerter Komplexität und Ausgaben für nachfolgende Upgrades führen.⁴ Das ist die akademische Version dessen, was Integratoren stillschweigend in jedes Angebot einpreisen: Jede Abweichung vom Standardpfad ist eine zukünftige Steuer.

Auch wenn wir uns im Kreis der Mainstream-Anbieter bewegen, bleibt die Geschichte gleich. Microsofts eigene Richtlinien für Dynamics 365-Implementierungen stellen unmissverständlich fest, dass „die Migration von Daten ein komplexer und zeitaufwändiger Prozess ist“, und fahren dann fort, die beteiligten Arbeiten aufzulisten: Quellen analysieren, Umfang definieren, Felder zuordnen und transformieren, laden, testen, sowie Datenqualität überprüfen und validieren.⁵

Lesen Sie diese Liste aufmerksam. Es handelt sich nicht um exotische Technologie. Es ist keine „Innovation.“ Es ist die Industrialisierung von Zuordnung und Abstimmung.

Dies ist genau der Grund, warum ERP-Programme sich zu mehrjährigen Unternehmungen ausweiten: Die Arbeit besteht nicht darin, neue Software zu entwickeln; sie besteht darin, ein lebendiges Geschäft in ein weitläufiges, sich ständig wandelndes, anbietergeprägtes Schema zu übersetzen und dann den Vorgang bei Upgrades zu wiederholen. Je mehr das ERP versucht, das Hauptbuch, den Spiegel und das Gehirn zu sein, desto mehr wird diese Übersetzung zu einem fortwährenden Projekt statt zu einer einmaligen Übung.

Eine gesündere Alternative: bauen Sie absichtlich ein kleines Hauptbuch

An dieser Stelle erscheint der offensichtliche Einwand: „Okay. ERPs sind chaotisch. Aber wir brauchen anspruchsvolle Funktionen. Wir brauchen Planung. Wir brauchen Optimierung. Wir können das nicht einfach selbst bauen.”

Dieser Einwand enthält denselben Kategorisierungsfehler wie der ERP-Pitch.

Wenn Sie den Umfang auf das Hauptbuch beschränken – die reine Transaktionsschicht, die die Geschäftsemantik erfasst und routinemäßige Arbeitsabläufe unterstützt – wird das Problem radikal einfacher. Nicht im Sinne, dass kein Denkaufwand erforderlich wäre, sondern insofern, als dass es überwiegend eine disziplinierte CRUD-Anwendung ist.

Und hier unterscheidet sich 2026 wirklich von 2015.

Es gibt jetzt Codierungsagenten, die speziell dafür entwickelt wurden, einen Codebestand, eine Reihe von Aufgaben zu übernehmen und schnell funktionierende Änderungen zu produzieren. Anthropics Claude Code ist ein agentenorientiertes Codierungstool, das im Terminal lebt und dabei hilft, Code über natürliche Sprachbefehle zu erzeugen. OpenAIs Codex wurde als ein Software-Engineering-Agent positioniert, der Aufgaben wie das Schreiben von Funktionen, das Beheben von Fehlern und das Vorschlagen von Pull Requests bewältigen kann. xAI stellt codierungsorientierte Grok-Modelle bereit, die über übliche Agent-Workflows in Code-Editoren verwendet werden können.

Diese Tools sind keine Magie. Eine randomisierte kontrollierte Studie, die im Juli 2025 von METR veröffentlicht wurde, fand sogar heraus, dass – in einem bestimmten Umfeld (erfahrene Entwickler, die an bekannten Open-Source-Repositories arbeiten) – die Nutzung von KI-Tools die Entwickler im Durchschnitt verlangsamte, da die Zeit vom Schreiben auf das Überprüfen und Korrigieren verlagert wurde.⁶ Dieses Ergebnis ist eine wichtige Erinnerung daran: „agentisch“ bedeutet nicht „automatisch“.

Allerdings verdeutlicht es auch, wo der Vorteil am stärksten ist: wenn die Arbeit repetitiv, gut abgegrenzt und semantisch eingeschränkt ist – genau das, was ein absichtlich langweiliges Hauptbuch sein sollte.

Hier ist meine klare Empfehlung: Für jedes stattliche Unternehmen – sagen wir, ab einem Jahresumsatz von über 50 Mio. € – sollte die Standardvorgehensweise darin bestehen, die Hauptbuch-Schicht intern zu entwickeln, anstatt einen ERP-Monolithen zu kaufen und ein Jahrzehnt lang Miete an dessen Ökosystem zu zahlen.

Warum?

Weil der dominante Kostentreiber der ERP-“Modernisierung” das Schema-Mapping über Tausende von vom Anbieter geformten Entitäten und jahrelange angesammelte semantische Drift ist. Wenn Sie von Grund auf neu beginnen, können Sie eine Hauptbuch-Schicht aufbauen, die mit Ihrer eigenen Semantik übereinstimmt – nicht ein Kompromiss, der darauf ausgelegt ist, in jedes Unternehmen im Portfolio des Anbieters zu passen. In der Praxis ist das resultierende Datenmodell oft um ein oder zwei Größenordnungen kleiner. Nicht, weil Ihr Geschäft trivial ist, sondern weil Sie aufhören, für den semantischen Schutt anderer Kunden zu zahlen.

Der Rollout ändert ebenfalls seine Form. Anstatt nach jahrelanger Spezifikation einen heroischen Systemwechsel vorzunehmen, können Sie wie ein vernünftiges Ingenieurteam iterieren. Sie importieren einen frischen Schnappschuss der Altdaten. Sie lassen die Mitarbeiter mit dem neuen System interagieren. Sie melden Unstimmigkeiten zwischen der Software und den realen Arbeitsabläufen. Sie passen den Code an. Sie importieren erneut. Sie wiederholen den Vorgang, bis das Hauptbuch passt. Dieser Ansatz ist schlicht die disziplinierte Version dessen, was die Richtlinien von Microsoft bereits implizieren: Migration benötigt Mapping, Tests, Validierung und Probedurchläufe.⁵

Ja, es erfordert Programmierkenntnisse. Diese Fähigkeit kann intern vorhanden sein oder ausgelagert werden, aber sie muss echt sein. Außerdem erfordert es, was ich oft mechanische Sympathie nenne: genügend Verständnis seitens der Führung, um ein technisches Projekt zu steuern, ohne von den Darstellungen der Anbieter hypnotisiert zu werden. Das Vergleichsbild, das ich anderweitig genutzt habe, ist, dass großartige Piloten keine Maschinenbauingenieure sind, aber sie wissen genug über die Maschine, um das Beste daraus herauszuholen.⁷

Dies ist der Teil, den viele Unternehmen zu vermeiden versuchen. Sie würden lieber das Denken zusammen mit der Umsetzung auslagern. Sie ziehen es vor, die Illusion von Sicherheit zu kaufen.

Aber das Outsourcing des Hauptbuchs eines Unternehmens an einen Monolithen, dessen Anreiz darin besteht zu wachsen, zu bündeln und Kunden zu binden, ist keine Sicherheit. Es ist der langsamste Weg, Software zu kaufen, die Sie letztendlich ohnehin ersetzen müssen.

Wenn Sie Planung und Optimierung wünschen, behandeln Sie diese als getrennte Belange, die auf einem sauberen Hauptbuch aufbauen. Zwingen Sie das Hauptbuch nicht dazu, zum Optimierer zu werden. Ziehen Sie die Optimierung nicht in das Migrationsprojekt hinein. Machen Sie zunächst die Aufzeichnungen genau, schnell und langweilig. Erst danach bauen Sie Entscheidungssysteme auf, die verbessert werden können, ohne dass jedes Mal das gesamte Unternehmensgedächtnis neu geschrieben werden muss.

ERP-Einführungen sind langsam und teuer, weil sich die ERP-Kategorie unter Anreizen entwickelt hat, die sie langsam und kostspielig machen. Der Ausweg liegt nicht in einem besseren Projektmanagement innerhalb derselben Falle. Der Ausweg besteht darin, aufzuhören, von einem Hauptbuch zu verlangen, ein Orakel zu sein, und aufzuhören, das historische Gepäck eines Anbieters zu bezahlen, als wäre es Ihres.