Warum ERP Ihre supply chain niemals steuern wird

Joannes Vermorel

Anbieter von Unternehmenssoftware bezeichnen ihre Plattformen gerne als das „digitale Rückgrat“ des Unternehmens. In der supply chain-Welt bedeutet dieses Rückgrat in der Regel ERP, unterstützt von Systemen wie MRP, WMS, TMS, CRM und ähnlichen. Für viele Organisationen scheint der nächste logische Schritt klar: Wenn ERP bereits die Transaktionen abwickelt, warum sollte es dann nicht auch die Entscheidungen steuern? Fügen Sie einige Planungsmodule, eine Prognose-Engine, ein paar KI-Funktionen hinzu, und die supply chain sollte sich mehr oder weniger um sich selbst kümmern.

Nach fast zwei Jahrzehnten, in denen ich Software entwickelt habe, die genau das Gegenteil bewirkt, bin ich zu einem recht unhöflichen Schluss gekommen: Die üblichen transaktionalen Anbieter sind strukturell ungeeignet, jemals zufriedenstellende supply chain-Entscheidungssysteme zu liefern. Dies ist keine Kritik an ihrer Kompetenz. Es geht um die Kategorie der Software, die sie verkaufen, die wirtschaftlichen Anreize, denen sie ausgesetzt sind, und die Erwartungen, die der Markt an sie stellt.

Ich erläutere dieses Argument ausführlich in meinem Buch Introduction to Supply Chain, aber ich möchte hier einen Aspekt hervorheben: Warum es mehr darauf ankommt, „wo das Gehirn lebt“ in Ihrer Softwarelandschaft, als es die meiste Fachliteratur zuzugeben bereit ist.

Was wir von der Software wirklich verlangen

Moderne supply chains drehen sich nicht nur darum, Kisten effizient zu transportieren. Es geht darum, jeden einzelnen Tag Wetten unter Unsicherheit abzuschließen.

Sollten wir einen Container oder drei kaufen? Eine Promotion verzögern oder vorziehen? Knappen Bestand nach Europa oder in die USA versenden? Die Mindestbestellmenge dieses Lieferanten akzeptieren oder abweichen und das Risiko einer Unterbrechung eingehen? Jede Entscheidung ist eine kleine Wette mit ungleichen Konsequenzen. Einige Fehler kosten nur wenig; andere kosten viel und wirken über Monate hinweg.

Vor fünfzig Jahren konnten Menschen plausibel den Großteil dieser Wetten im Kopf behalten, unterstützt von Büchern und Tabellenkalkulationen. Heute verwalten selbst mittelständische Unternehmen Zehntausende von SKUs, Hunderte von Standorten, volatile Durchlaufzeiten und Nachfragemuster, die auf Preise, Wetter, Marketing, Wettbewerber und Lieferstörungen reagieren. Die Kombinatorik sprengt bei weitem die Möglichkeiten des ununterstützten menschlichen Urteilsvermögens.

Deshalb bitten wir die Software um Hilfe. Aber „Software“ ist nicht ein einziges Ding. In einem typischen Unternehmen koexistieren drei sehr unterschiedliche Arten von Systemen:

Zuerst gibt es die transaktionalen Systeme: ERP, MRP, WMS, TMS, OMS. Ihre Aufgabe ist es, alles zu erfassen, was passiert: Bestellungen, Wareneingänge, Versand, Rechnungen, Zu- und Abgänge an Standorten. Sie sind glorifizierte Bücher plus Arbeitsabläufe. Ihre Hauptvorteile sind Zuverlässigkeit, Nachvollziehbarkeit, Berechtigungen und Prüfungsfähigkeit. Wenn eine Sendung doppelt verschickt wird oder eine Zahlung verschwindet, verliert alles andere an Bedeutung.

Zweitens gibt es die Reporting- und Analysesysteme: BI-Tools, Dashboards, KPI-Portale, Tabellenkalkulationen, die von Data Warehouses gespeist werden. Ihre Aufgabe ist es, zusammenzufassen und zu visualisieren, was passiert ist und manchmal, was passieren könnte. Sie sind dafür gemacht, von Menschen überprüft zu werden: Diagramme, Tabellen, Ausnahmelisten, Abweichungsberichte.

Schließlich gibt es etwas, das in der Praxis weitgehend fehlt: eine echte Entscheidungs-Engine. Damit meine ich Software, deren Hauptaufgabe es ist, all diese Rohdaten aufzunehmen, ihre Muster zu erkennen, Optionen zu bewerten und dann konkrete, prüfbare Entscheidungen zu treffen: Bestellungen, Zuweisungsänderungen, Produktionspläne, Preisänderungen, Sortimentsanpassungen. Diese Entscheidungen sollten routinemäßig und unbeaufsichtigt erstellt und dann in die transaktionalen Systeme zurückgeschrieben werden, als hätte ein sehr konsequenter, sehr schneller Planer die Arbeit erledigt.

Die gängige Ansicht neigt dazu, diese drei Rollen miteinander zu vermischen. Wenn das ERP-Rückgrat bereits Daten integriert und Prozesse steuert, kann es sicherlich auch planen und optimieren. Falls nicht, wird eine andere Allzweckplattform einspringen: ein „digitaler Kern“, ein „Control Tower“ oder eine „unified planning suite“. In der Literatur wird ERP routinemäßig als das Herzstück der Geschäftsverarbeitung und als Rückgrat des Unternehmens beschrieben, wobei supply chain-Planung und -Ausführung als natürliche Erweiterungen derselben Plattform präsentiert werden.

Auf dem Papier klingt das verlockend. In der Praxis beginnt an genau dieser Stelle alles schiefzugehen.

Warum transaktionale Anbieter im falschen Geschäft sind, das Gehirn zu bauen

Um die Fehlanpassung zu verstehen, ist es hilfreich, sich von Markenbegriffen zu lösen und einen Blick darauf zu werfen, was ERP und seine verwandten Systeme tatsächlich sind.

Im Kern sind diese Systeme große, mehrbenutzerfähige Datenbanken mit strengen Regeln darüber, wer was und in welcher Reihenfolge ändern darf. Sie sind optimiert für viele kleine, einfache, gut strukturierte Vorgänge, die gleichzeitig ablaufen: diese Bestellung erfassen, jene Rechnung buchen, diesen Wareneingang bestätigen. Wenn ERP-Lehrbücher sie als das „Rückgrat“ des Unternehmens bezeichnen, meinen sie das wörtlich: Sie tragen die Nerven und Blutbahnen des täglichen Betriebs.

Im Gegensatz dazu ist eine echte Entscheidungs-Engine nicht für Tausende von leichten Klicks optimiert. Sie ist für intensives Denken ausgelegt.

Sie muss große Datenmengen aufnehmen, oft aus mehreren Systemen. Sie muss viele mögliche Zukunftsszenarien erkunden, anstatt nur eine einzelne Prognose hochzurechnen. Sie muss Optionen anhand wirtschaftlicher Kriterien bewerten, und nicht nur anhand von Dienstgüten oder Zielvorgaben für Lieferzeiten. Sie muss Berechnungen durchführen, die gelegentlich aufwendig sind: Wahrscheinlichkeitsmodelle, Simulationen, kombinatorische Optimierungen. Und all dies muss so erfolgen, dass es später geprüft werden kann: Warum haben wir an jenem Tag zwanzig Paletten dieses Artikels gekauft, statt fünfzehn oder gar keine?

Es ist keine Frage der Programmiersprache oder cleverer Optimierung. Es handelt sich um ein anderes Laufzeitprofil, andere technische Kompromisse und andere Formen der Verantwortlichkeit. Eine derartige Engine in derselben Umgebung zu platzieren, die Ihre täglichen Rechnungen und Lagerbildschirme steuert, ist, als würde man einen Düsenantrieb in einen Stadtbus einbauen. Das ist nicht nur überdimensioniert; es beeinträchtigt aktiv die Aufgabe des Busses.

Daraus ergeben sich mehrere strukturelle Probleme.

Das erste Problem ist operativer Natur. Wenn Sie versuchen, schwere Analysen und große Optimierungsaufgaben direkt auf Ihrer transaktionalen Plattform auszuführen, drosseln Sie entweder die analytische Arbeit, um eine Verlangsamung des Betriebs zu vermeiden, oder Sie riskieren, die Reaktionszeiten zu beeinträchtigen, wenn Menschen arbeiten wollen. Je mehr es Ihnen gelingt, „Intelligenz“ einzubetten, desto mehr verschlechtern Sie die primäre Aufgabe des Systems: keine Transaktion verlieren und keinen Benutzer blockieren.

Das zweite Problem ist semantischer Natur. Moderne Unternehmen arbeiten selten mit einem einzelnen Monolithen. Sie verfügen über ERP für Finanzen und Kernprozesse, WMS für Lager, TMS für Transport, CRM für Kundeninteraktionen, E‑Commerce-Plattformen und manchmal spezialisierte Systeme für Produktion oder Einzelhandel. Jedes dieser Systeme verfügt über einen eigenen Wortschatz und seine eigene Version der Wahrheit. Eine nützliche Entscheidungs-Engine muss jedoch alle diese Systeme erfassen. Die natürliche Tendenz der ERP-Anbieter besteht jedoch darin, ihr eigenes Schema als Mittelpunkt des Universums zu betrachten. Alles andere wird entweder verlustbehaftet hineingemappt oder ignoriert.

Das dritte Problem ist wirtschaftlicher Natur. Große transaktionale Anbieter werden meist durch Lizenzen, Benutzerplätze, Module und Speicher bezahlt; in der Cloud-Ära kommen Abonnementstufen und Verbrauch hinzu. Sie werden nicht dafür bezahlt, wie viele Entscheidungen sie sicher automatisieren können oder wie viel Geld sie wieder in Ihre Gewinn- und Verlustrechnung einfließen lassen. Im Gegenteil: Eine wirklich effektive Entscheidungs-Engine würde die Zahl der „Planner“-Sitze reduzieren und viele Arbeitsabläufe vereinfachen. Das ist nicht das, wofür ihr Preismodell ausgelegt ist.

Legt man dazu noch das Zertifizierungs-Ökosystem, wird das Bild noch klarer. Das APICS/ASCM CPIM-Programm wird zum Beispiel explizit als globaler Standard für Planung und Bestandsmanagement präsentiert, und Schulungsmaterialien weisen offen darauf hin, dass ERP-Systeme Geschäftsregeln einbetten, die aus diesem Wissenskorpus abgeleitet sind.

Mit anderen Worten: Es wird angenommen, dass die standardisierte Planungslogik innerhalb des ERP lebt. Von den Anbietern wird erwartet, dass sie sie kodifizieren; von den Anwendern, dass sie sie konfigurieren und befolgen. Ziel ist es, die Praxis mit dem Kanon in Einklang zu bringen, und nicht, die Softwarearchitektur oder die Wirtschaftlichkeit von Entscheidungen neu zu überdenken.

Schließlich spielt auch die Kultur eine Rolle. Der Aufbau von Buchhaltungssystemen zieht typischerweise eine bestimmte Ingenieursmentalität an, belohnt und fördert sie: eine, die Stabilität, Abwärtskompatibilität und die Abdeckung von Randfällen hoch schätzt. Über Jahrzehnte sammeln diese Systeme Schichten von Funktionalitäten, Modulen, Anpassungen und Integrationen an. Sie werden äußerst leistungsfähig, aber auch extrem komplex. Ein weiteres Planungsmodul oder eine weitere KI-Funktion hinzuzufügen, ist kulturell leichter, als etwas zu entfernen. Das Ergebnis ist eine ständig wachsende Masse an Konfigurationsbildschirmen und Parametern, verwoben in Arbeitsabläufe, die ohnehin schon fragil sind.

Von dieser Maschine zu verlangen, sich als scharfsinnige, entscheidungsfreudige Entscheidungs-Engine neu zu erfinden, ist bestenfalls optimistisch.

Die Mainstream-Erzählung in eigenen Worten

Wenn Sie Anbietermaterialien, Whitepaper und einen Großteil der akademischen und fachlichen Literatur lesen, werden Sie feststellen, dass dieselbe Geschichte mit kleinen Variationen immer wieder erzählt wird.

ERP wird als eine einheitliche Plattform präsentiert, die alle Daten und Prozesse integriert, indem sie Beschaffung, Bestandsführung, Auftragsabwicklung und Distribution ‚harmonisiert‘ und gleichzeitig Analyse- und Planungstools einbettet. Sie wird als die Softwarebasis des Unternehmens beschrieben, als der ‚digitale Kern‘, der alles von Finanzen über Fertigung bis hin zur supply chain untermauert. Auf dieser Basis werden uns zunehmend fortschrittlichere Funktionen versprochen: Nachfragprognosen, unterstützt von prädiktiver Analyse, Szenariomodellierung, integrierte Geschäftsplanung und mehr.

Parallel dazu liefert der Operations-Management-Kanon die Denkmuster: den CPIM-Wissenskorpus, S&OP-Rahmenwerke, Sicherheitsbestandsformeln, MRP-Logik. Diese werden als Best Practices, Prüfungslehrpläne und Reifegradmodelle kodifiziert. Das zugrunde liegende Versprechen ist einfach: Wenn Sie das richtige ERP implementieren, es gemäß diesen Standards konfigurieren und Ihre Planner entsprechend schulen, wird sich Ihre supply chain wie erwartet verhalten.

Wenn die Realität nicht dem Versprechen entspricht, sind die üblichen Erklärungen bekannt: Datenqualität, Change Management, Projektumfang, fehlende Führungsebene, unzureichende Schulung. Die Lösung besteht immer in demselben: sorgfältigere Implementierungen, diszipliniertere Prozesse und eine umfassendere Übernahme des standardisierten Wissenskorpus.

Beachten Sie, was selten in Frage gestellt wird: die Annahme, dass das „Gehirn“ der supply chain in denselben Systemen leben sollte, die Bestellungen erfassen und Rechnungen drucken.

Was tatsächlich vor Ort passiert

Vor Ort enden die meisten Organisationen mit einem Muster, das branchen- und regionsübergreifend erschreckend einheitlich ist.

Die transaktionalen Systeme erledigen ihre Aufgaben in angemessenem Maße. Bestellungen fließen, Bestände bewegen sich, Rechnungen werden verschickt und Finanzabschlüsse erfolgen. Es gibt immer Besonderheiten und Frustrationen, aber im Großen und Ganzen stimmen die Bücher.

Um diesen Kern herum schießt das Reporting in die Höhe. BI-Tools verbinden sich mit Data Warehouses, die aus dem ERP und seinen Satelliten extrahieren. Teams erstellen Dashboards, Scorecards, Cockpits und Control Towers. Planner verbringen einen wachsenden Teil ihrer Zeit damit, diese Bildschirme zu durchforsten, Diskrepanzen zwischen ihnen abzugleichen, Daten in Tabellenkalkulationen zu exportieren und „angepasste“ Zahlen wieder zu importieren.

Planungs- und Optimierungsmodule existieren in vielen dieser Systeme. Sie erzeugen Prognosen, schlagen Nachfüllmengen vor und lösen Warnungen aus. Dennoch bleibt der Großteil der schweren Arbeit manuell. Prognosen werden überschrieben. Vorgeschlagene Bestellungen werden einzeln „überprüft“. Die Ausnahmelisten wachsen so lang, dass sie von niemandem an einem Arbeitstag vernünftig abgearbeitet werden können, weshalb die Menschen lokale Heuristiken entwickeln: Diesen Indikatoren vertrauen, jene ignorieren, diesen Anbieter stets bevorzugen, jene Artikel niemals anfassen.

Automatisierung erfolgt hauptsächlich in Form bedingter Logik innerhalb der transaktionalen Systeme: Wenn die Verfügbarkeit über einem bestimmten Niveau liegt, wird diese Bestellung freigegeben; liegt sie darunter, wird sie in eine Ausnahmewarteschlange gestellt. Aus der Ferne kann dies wie intelligentes Verhalten aussehen. Aus nächster Nähe handelt es sich jedoch um brüchige Regeln plus menschliche Bewältigungsstrategien.

Ich nenne diese Situation manchmal „Automatisierung als Bürokratie“: Die Systeme sind aufwendig, geschäftig, ja sogar beeindruckend, tragen aber selten die volle Verantwortung für eine Entscheidung, die echtes finanzielles Gewicht hat. Es wird immer ein Mensch erwartet, irgendwo auf „OK“ zu klicken, auch wenn dieser Klick zu einem Ritual geworden ist.

So sieht keine ausgereifte Entscheidungs-Engine aus.

Eine andere Trennung der Aufgabenbereiche

Wenn wir die Idee ernst nehmen, dass supply chain eine tägliche Praxis wirtschaftlicher Entscheidungsfindung unter Unsicherheit ist, dann sollten wir die Softwarelandschaft entsprechend gestalten.

In dieser Landschaft übernehmen transaktionale Systeme weiterhin das, was sie am besten können: Sie bleiben der maßgebliche Nachweis dessen, was passiert ist und was aktuell verplant ist. Ihre Schemata und Arbeitsabläufe werden sich weiterentwickeln, und sie bleiben kritisch, aber wir hören auf, von ihnen Schlauheit zu erwarten.

Reporting-Systeme machen weiterhin das, was sie am besten können: Sie helfen den Menschen, zu sehen, zu verstehen und zu diskutieren, was passiert. Gute Dashboards und Analysen bleiben von unschätzbarem Wert. Aber wir hören auf, Veranschaulichung mit Optimierung zu verwechseln.

Dann führen wir separat eine dedizierte Entscheidungs-Engine ein.

Diese Engine erhält regelmäßige Zufuhr von Rohdaten aus allen relevanten transaktionalen Systemen: Bestellungen, Lagerbestände, Kapazitäten, Durchlaufzeiten, Preise, Einschränkungen. Es ist ihr egal, ob diese Daten aus ERP, WMS, TMS oder einem anderen System stammen. Sie stellt aus diesen Fakten eine kohärente Sicht auf die Welt zusammen, erkennt die Unsicherheit bei Nachfrage und Angebot ausdrücklich an und bewertet alternative Maßnahmen anhand ihrer finanziellen Konsequenzen: erwartete Marge, Risiko eines Lieferengpasses, Kosten der Veralterung, Opportunitätskosten bei begrenzten Ressourcen.

Die Ausgabe dieser Engine ist kein Dashboard. Es ist ein Strom vorgeschlagener Maßnahmen: Kaufen Sie diese Menge von jenem SKU von diesem Lieferanten an diesem Datum; versenden Sie diese Paletten heute Nacht von diesem Lager zu jenem; erhöhen Sie den Preis dieses Artikels um zwei Prozent; eliminieren Sie diese Variante im Laufe des nächsten Monats. Jede Maßnahme wird von genügend Kontext begleitet, sodass ein Mensch sie bei Bedarf überprüfen kann: welche Daten verwendet wurden, welche Muster erkannt wurden, welche Kompromisse eingegangen wurden.

Entscheidend ist, dass diese Aktionen mithilfe klar definierter Schnittstellen in die Transaktionssysteme zurückgeschrieben werden. Die Bestellung wird im ERP erzeugt, als hätte ein Planer sie eingegeben. Die Lagerübertragung erscheint im WMS, als hätte ein Lagerverwalter sie initiiert. Die Preisänderung landet im Preissystem mit einem klaren Gültigkeitsdatum.

Menschen verschwinden nicht aus dem Kreislauf. Ihre Rolle ändert sich. Sie werden zu Verwaltern des numerischen Rezepts: Sie entscheiden, welche Kosten einzubeziehen sind, wie Risiken bewertet werden, welche Einschränkungen real sind und welche Szenarien akzeptabel sind. Sie überprüfen und verfeinern das Verhalten der Engine, anstatt jede ihrer Zeilen mikromanagen zu müssen.

Diese Architektur klingt nur exotisch, wenn man zu viel Zeit in der ERP-zentrierten Darstellung verbracht hat. Aus der Perspektive von Softwaretechnik und Wirtschaft ist es einfach eine saubere Trennung der Verantwortlichkeiten: Hauptbücher für Fakten, Dashboards für Verständnis, Entscheidungsmaschinen für Entscheidungen.

Wie dies der Mainstream-Meinung entgegensteht

Aus diesem Blickwinkel ist die Mainstream-Erzählung nicht so sehr „falsch“ wie vielmehr unvollständig.

Es ist vollkommen vernünftig, sich ein integriertes, transaktionales Rückgrat zu wünschen. Unternehmen profitierten enorm vom Übergang von fragmentierter Buchhaltung, Lagerhaltung und Fertigungssystemen hin zu einem integrierten ERP. Ebenso ist es berechtigt, sich gute Berichte zu wünschen und Terminologie sowie Prozesse in der gesamten Branche zu standardisieren. Initiativen wie CPIM haben eine wichtige Rolle dabei gespielt, den Menschen eine gemeinsame Sprache und ein grundlegendes Werkzeugset zu bieten.

Wo ich mich vom Mainstream unterscheide, liegt in der stillschweigenden Annahme, dass, wenn wir das transaktionale Rückgrat weiterhin mit mehr Planungsmodulen, mehr Prognosefunktionen, mehr Analysen und weiteren Konfigurationsoptionen anreichern, wir letztlich zu effektiven, automatisierten supply chain decisions gelangen werden.

Ich glaube nicht, dass diese Konvergenz eintreten wird.

Solange erwartet wird, dass das „Gehirn“ in Systemen lebt, deren Hauptaufgabe und Geschäftsmodell die Führung von Aufzeichnungen, rollenbasierte Workflows und generische Best Practices sind, werden wir in einem Muster beeindruckender Schnittstellen und zaghafter Automatisierung stecken bleiben. Wir werden weiterhin Organisationen vorfinden, in denen Planer ihre Tage damit verbringen, Alarmlisten zu pflegen, anstatt die ökonomische Logik zu gestalten, die diese Alarme erzeugt.

Die Alternative besteht nicht darin, ERP komplett über Bord zu werfen oder etablierte Methoden zu ignorieren. Es geht darum, sie als das zu betrachten, was sie sind: notwendige Infrastruktur und wertvolles fachliches Erbe, aber nicht der Ort, an dem die eigentlichen Entscheidungen getroffen werden sollten.

Sobald wir diesen Unterschied akzeptieren, wird ein ehrlicheres Gespräch möglich. Wir können von unseren transaktionalen Anbietern exzellente Hauptbücher und saubere Schnittstellen verlangen, anstatt „KI-gestützte Optimierung“. Wir können von unseren BI-Teams einfache, wahrheitsgetreue Ansichten der Realität einfordern, statt animierte Dashboards, die so tun, als wären sie Kontrollräume. Und wir können unsere Entscheidungsmaschinen – und die Menschen, die sie bauen und betreiben – nach höheren Maßstäben bewerten: nächtliche, unbeaufsichtigte Entscheidungen, in Bargeld messbar, kontinuierlich verbessert.

Dies ist die Richtung, die wir bei Lokad seit vielen Jahren verfolgen. Es ist nicht der einzige Weg, aber er beruht auf einer einfachen Beobachtung: Wenn Ihre supply chain effektiv von Software begrenzt wird, dann macht es den entscheidenden Unterschied, wo Sie das Gehirn dieser Software platzieren.