Schneller als “One‑Click”: Warum programmierbare supply chains in puncto Geschwindigkeit gewinnen

Joannes Vermorel

In supply chain sprechen wir viel über Geschwindigkeit. Geschwindigkeit der Bestandsauffüllung. Geschwindigkeit der Reaktion. Geschwindigkeit der Wiederherstellung, wenn etwas schiefgeht. Doch wenn es um die Systeme geht, die diese Entscheidungen unterstützen sollen, reduziert sich die Diskussion über Geschwindigkeit schnell auf eine einzige Kennzahl: Wie viele Wochen vergehen, bis man nach der Unterzeichnung eines Softwarevertrags „go live“ gehen kann?

Die meisten großen Anbieter von supply chain Software haben eine sehr klare Antwort auf diese Frage. Sie versprechen eine schnelle Wertschöpfung durch vorkonfigurierte Inhalte, standardisierte Datenmodelle und „industry best practices“. Betrachtet man das Marketing für integrierte Business-Planungssuiten und Advanced-Planning-Systeme, so ist die Erzählung bemerkenswert konsistent: Man startet mit dem Referenzmodell, wendet eine Sammlung von Vorlagen an, und schon kann man in „wenigen Wochen“ oder „in nur 12 Wochen“ in Produktion gehen, manchmal explizit „from Excel to advanced planning in weeks“.

Kürzlich habe ich in meinem Buch Introduction to Supply Chain versucht, einen Schritt zurückzutreten und diese Erzählung zu hinterfragen, indem ich supply chain als das Geschäft darstelle, Tag für Tag profitable Entscheidungen unter Ungewissheit zu treffen. Wenn man diesen Blickwinkel ernst nimmt, wird aus der Frage „Wie schnell können wir Software einsetzen?“ die Frage „Wie schnell können wir hochwertige, automatisierte Entscheidungen in die Produktion überführen – und sie im Einklang mit einem sich verändernden Geschäft halten?“ Das ist eine ganz andere Frage.

Daraus ziehe ich eine Schlussfolgerung, die dem Mainstream widerspricht: Für ernsthafte supply chain Initiativen ist ein programmierbarer Ansatz nicht nur leistungsfähiger als traditionelle vorgefertigte Software, sondern es ist tatsächlich schneller, sinnvolle Ergebnisse in die Produktion zu bringen.

Lassen Sie mich erklären, warum.

Das tröstliche Versprechen vorkonfigurierter supply chain Software

Traditionelle Anbieter von Enterprise-Planung bieten eine tröstliche Geschichte an.

Sie beginnen mit einem kanonischen Datenmodell für supply chain: Standorte, Produkte, Hierarchien, Stücklisten, Kalender, Durchlaufzeiten, Einschränkungen. Aufbauend auf diesem Modell liefern sie vorkonfigurierte Prozesse („best practices“), Beispieldatensätze, Vorlagen für Dashboards, Alarmmeldungen, Standardalgorithmen und Konfigurationsleitfäden aus. All dieses Material ist ausdrücklich darauf ausgelegt, die Implementierung zu beschleunigen und Projektrisiken zu verringern.

Die Logik ist vollkommen stimmig. Wenn die Daten und Prozesse jedes Kunden als eine bescheidene Variation eines gemeinsamen Templates beschrieben werden können, sollte ein Großteil der Arbeit wiederverwendbar sein. Das Implementierungsprojekt wird zu einer Frage der Zuordnung von ERP-Feldern zum Planungsmodell, dem Aktivieren der relevanten Funktionen, dem Abstimmen von Parametern und dem Einweisen der Nutzer in die Bedienung der Bildschirme.

In dieser Welt ist Individualisierung ein notwendiges Übel. Sie wird für „besondere“ Fälle akzeptiert, ist aber auch als Hauptursache für Verzögerungen, Kostenüberschreitungen und langfristige Komplexität bekannt. Daher der Drang nach „Konfiguration, nicht Individualisierung“ – und in jüngerer Zeit auch nach Low‑Code- und No‑Code-Tools – um innerhalb des sicheren Rahmens dessen zu bleiben, was die Software bereits leisten kann.

Unter diesen Annahmen ist die Vorstellung, dass vorgefertigte Software schneller implementiert werden kann, durchaus nachvollziehbar.

Das Problem ist, dass reale supply chains selten in diese Annahmen passen.

Wo Projekte wirklich ins Stocken geraten: Semantik, nicht Bildschirme

Wenn man genau hinsieht, wo in groß angelegten supply chain Systemdeployments tatsächlich Zeit investiert wird, dann nicht in der Installation der Software oder gar in der Schulung der Nutzer. Es geht darum, zu verstehen, was die Daten bedeuten.

Die meisten größeren Unternehmen verfügen über ein oder mehrere ERPs sowie über eine Vielzahl anderer Systeme – CRM, WMS, TMS, PIM, e‑Commerce und so weiter. Zusammen enthalten sie Tausende von Tabellen. Offiziell haben diese Entitäten dokumentierte Bedeutungen; in der Praxis sind ihre wirklichen Semantiken das Ergebnis jahrelanger Workarounds, lokaler Konventionen, Kompromisse und teilweiser Bereinigungen. Das tatsächliche Verhalten des Systems wird in der Art kodiert, wie es von den Menschen genutzt wird, und nicht so, wie der ursprüngliche Anbieter es vorgesehen hatte.

Wenn eine Planungssuite eintrifft, bringt sie ihr eigenes Datenmodell und eigene Erwartungen mit. Selbst wenn sie vom selben Anbieter wie das ERP stammt, passen die Semantiken nicht sauber zusammen. Ein Feld namens „location type“ oder „safety stock“ bedeutet in der Konfiguration, im täglichen Betrieb, im Reporting und in der Planung nicht dasselbe.

Jemand muss all dies in Einklang bringen.

Diese Aufgabe übernehmen in der Regel gemischte Teams aus IT, Consultants und fachlichen Stakeholdern. Sie müssen entscheiden, welche Tabellen maßgeblich sind, welche Felder vertrauenswürdig sind, wie Ausnahmen zu handhaben sind und wie die unordentliche Realität des Unternehmens in die sauberen Strukturen überführt werden kann, die von der Planungsoftware erwartet werden. Sie erstellen Extraktions- und Transformationsaufträge; sie fügen benutzerdefinierte Flags und Attribute hinzu; sie erfinden Konventionen, um Einschränkungen zu kodieren, die das Standardmodell nicht ausdrücken kann.

An diesem Punkt verwandelt sich die vermeintlich „one‑click“ Implementierung oft in einen ausufernden Integrationsaufwand. Die Software selbst mag am ersten Tag live sein, aber die Daten, die sie benötigt – die präzisen, vertrauenswürdigen, täglichen Daten, die eine ernsthafte Optimierungsengine erfordert – brauchen Monate oder Jahre, um sich wirklich zu stabilisieren.

Dies ist kein Implementierungsfehler. Es ist ein Symptom einer tieferen Tatsache: Semantik ist lokal, und es gibt keine universelle, einsatzbereite Darstellung der supply chain eines bestimmten Unternehmens.

Supply chain als Software, nicht als Konfiguration

Wenn wir akzeptieren, dass Semantik lokal ist und sich ständig weiterentwickelt, während sich das Geschäft ändert, dann wird die übliche Unterscheidung zwischen „Konfiguration“ und „Individualisierung“ irreführend.

Im Kern ist eine ambitionierte supply chain Initiative immer eine Software-Übung. Es geht darum, in präziser und ausführbarer Form festzulegen, wie das Unternehmen Entscheidungen in Bezug auf Einkauf, Produktion, Inventar, Preisgestaltung, Allokation usw. treffen möchte – basierend auf den vorliegenden Daten und Einschränkungen.

Im traditionellen vorgefertigten Modell besteht diese Software aus Konfigurationstabellen, Parametern, Ablaufdiagrammen, kundenspezifischen Konnektoren und gelegentlichen „user exits“, die in einer universellen Programmiersprache geschrieben sind. Die Hoffnung ist, dass der Großteil der Logik über Konfiguration ausgedrückt werden kann und nur die Randbereiche Code erfordern.

Meiner Erfahrung nach geschieht insbesondere in komplexen Umgebungen genau das Gegenteil. Die kritischste und differenzierendste Logik wird auf spröde Weise implementiert: durch Überladen von Feldern, das Hinzufügen von Excel-Tabellen und Python-Notebooks neben das offizielle System sowie durch das Schulen von Planern, die Dashboards auf eine spezifische Weise zu interpretieren, die eigentlich nirgends kodiert ist.

Das Endergebnis ist, dass das „System“ teilweise in der Software und teilweise im Kopf der Menschen steckt.

Bei Lokad haben wir uns vor über einem Jahrzehnt dazu entschlossen, die softwarebasierte Natur des Problems anzunehmen, statt dagegen anzukämpfen. Wir haben unsere eigene domänenspezifische Sprache, Envision, entwickelt, die sich an supply chain Praktiker richtet und nicht an professionelle Softwareingenieure. Die Idee ist simpel: Alle Datenumwandlungen, alle Prognosen, alle Einschränkungen und alle Entscheidungen werden als Skripte dargestellt, die gelesen, versioniert, getestet und kontrolliert modifiziert werden können.

Von außen betrachtet sieht dies wie eine Programmierumgebung aus. Intern ist es unsere Antwort auf das semantische Problem: Anstatt die komplexe Realität in ein fertiges Modell zu zwängen, geben wir uns eine flexible Sprache, um diese Realität so zu beschreiben, wie sie tatsächlich ist.

Das führt uns zurück zum Thema Geschwindigkeit.

Was bedeutet es, in supply chain „schnell“ zu sein?

Wenn Geschwindigkeit definiert wird als „Zeit bis der Softwareanbieter gemäß seiner Checkliste einen go‑live erklären kann“, dann erscheinen vorkonfigurierte Suiten häufig schneller. Der Projektplan ist auf diesen Meilenstein optimiert. Das kanonische Modell ist darauf ausgelegt, schnell befüllt zu werden. Das Schulungsmaterial und die best practices sind auf dieses spezifische Ziel abgestimmt.

Wenn Geschwindigkeit jedoch definiert wird als „Zeit, bis wir einen Live-Flow automatisierter Entscheidungen haben, dem wir echtes Geld anvertrauen können“, ändert sich das Bild.

Bei einem programmierbaren Ansatz sieht die Projektsequenz typischerweise so aus:

Zuerst werden zuverlässige tägliche Extraktionen aus den bestehenden Systemen eingerichtet, ohne zu versuchen, diese in ein neues kanonisches Modell zu zwängen. Das ist zwar immer noch harte Arbeit, aber überwiegend geht es um die Datenleitungen: Die Rohdaten werden so herausgeholt, wie sie sind, mit all ihrer Unschönheit.

Dann wird in der programmierbaren Umgebung die Geschäftslogik Schritt für Schritt ausgedrückt: Bereinigung und Abstimmung der Daten; Festlegung von Einschränkungen und Prioritäten; Modellierung von Unsicherheiten; und schließlich die Berechnung konkreter Entscheidungen wie Bestellmengen, Produktionspläne oder Allokationsentscheidungen. Da diese Logik in einer maßgeschneiderten Sprache geschrieben ist, ist der Änderungszyklus kurz: Ein Supply Chain Scientist kann sie täglich oder wöchentlich verfeinern, sobald Randfälle und neue Anforderungen auftauchen.

Schließlich werden diese Entscheidungen in einen Dual‑Run überführt: Es wird verglichen, was die Skripte vorschlagen, mit dem, was die Planer tatsächlich tun, die finanziellen Auswirkungen werden gemessen und entsprechend angepasst. Wenn das Vertrauen hoch genug ist, überlassen Sie den Skripten die Kontrolle über gut ausgewählte Teile des Portfolios.

Der entscheidende Punkt ist, dass diese Sequenz iterativ ist. Wir erwarten nicht, dass die erste Version der Logik perfekt ist. Wir erwarten auch nicht, dass die Umgebung stillsteht. Stattdessen gehen wir davon aus, dass die Entscheidungsregeln alle ein bis zwei Jahre erheblich neu geschrieben werden müssen, während sich das Sortiment, das Netzwerk, die Serviceversprechen und das Wettbewerbsumfeld weiterentwickeln.

In einem solchen Umfeld ist der Hauptfaktor für „Geschwindigkeit“ nicht das Datum des ersten go‑live. Es ist die durchschnittliche Änderungsdauer: wie lange es dauert, das System anzupassen, wenn sich das Geschäftsbetrieb ändert.

Wenn es sechs Monate dauert, eine Preispolitik in einer monolithischen Planungssuite zu kodieren, spielt es keine Rolle, dass die ursprüngliche Implementierung vor drei Jahren pünktlich abgeschlossen wurde.

Warum Programmierbarkeit über die gesamte Lebensdauer des Systems schneller wird

Von außen betrachtet wirkt Programmierbarkeit wie eine Bürde. Sicherlich muss es langsamer sein, Code zu schreiben, als einen bestehenden Bildschirm zu konfigurieren?

In einfachen Fällen kann dies zutreffen. Wenn die supply chain relativ klein, stabil und nahe am Referenzmodell des Anbieters ist, könnte eine vorkonfigurierte Lösung tatsächlich schnell einen akzeptablen Betriebszustand erreichen. Viele Unternehmen fordern ihre Planungstools nicht stark heraus; sie nutzen sie als strukturierte Tabellenkalkulationen mit ansprechenderen Benutzeroberflächen und einigen Alarmmeldungen. In diesem Zusammenhang kann der vorgefertigte Ansatz ausreichend und, in einem engen Sinne, schneller sein.

Das Bild ändert sich dramatisch, sobald wir uns Umgebungen zuwenden, die:

• groß und heterogen (mehrere ERPs, verschiedene Geschäftsbereiche, viele Arten von Produkten und Kanälen),

• volatil (Sortimente, Durchlaufzeiten und Serviceversprechen ändern sich häufig),

• und ambitioniert sind (Streben nach hohem Automatisierungsgrad, nicht nur Entscheidungshilfe).

In diesen Fällen stehen vorgefertigte Lösungen vor drei strukturellen Herausforderungen.

Erstens: Die semantische Lücke ist zu groß. Je mehr Ausnahmen und lokale Konventionen es gibt, desto mehr muss das kanonische Modell angepasst werden, um sie zu berücksichtigen. Jede Anpassung wird zu einem Konfigurationstrick, einer kundenspezifischen Erweiterung oder einem Nebenprozess. Mit der Zeit häuft das System Schichten von Spezialfällen an, die schwer zu verstehen und noch schwerer zu bereinigen sind.

Zweitens: Die Kosten für Veränderungen werden extern gesteuert. Das Ändern der Logik einer großen Planungssuite umfasst in der Regel mehrere Ebenen: interne IT, externe Consultants und manchmal den Anbieter selbst. Es gibt Release‑Zyklen, Testprotokolle und Governance‑Prozesse, die auf Sicherheit statt auf Agilität ausgelegt sind. Das ist nachvollziehbar, bedeutet aber, dass selbst sinnvolle, moderate Änderungen Monate dauern können.

Drittens: Die Logik altert schnell. Supply chain Regeln, die vor drei Jahren noch sinnvoll waren, sind heute selten optimal. Wenn die Kosten für eine Überarbeitung hoch sind, neigen Organisationen dazu, den Aufwand zu verschieben. Sie flicken an den Rändern mit Tabellenkalkulationen, Überschreibungen und Ad‑hoc‑Lösungen.

Im Gegensatz dazu zahlt ein programmierbarer Ansatz einen Großteil der Kosten im Voraus: Man muss akzeptieren, dass man im Wesentlichen Software schreibt. Aber sobald man eine dedizierte Umgebung für diese Software hat – eine, die spezialisiert genug ist, um supply chain Experten zugänglich zu sein, und gleichzeitig ausdrucksstark genug, um die Realität des Geschäfts zu beschreiben – kehrt sich die Ökonomie der Veränderung um.

Das Hinzufügen einer neuen Einschränkung, die Integration einer neuen Datenquelle oder die Überarbeitung der Art und Weise, wie Sie Werbeaktionen handhaben, wird zu einer Aufgabe des Skripteditierens, statt eine neue Implementierungsphase auszuhandeln. Da die Entscheidungslogik explizit ist, kann man sie versionieren, testen und zurückrollen. Da sie zentralisiert ist und nicht über Konfigurationstabellen und Nebendateien verteilt, lässt sie sich als Ganzes betrachten.

Dies ist keine Ablehnung der Mainstream-Software

Es wäre ein Fehler, dies als Argument gegen alle vorgefertigten supply chain Software zu lesen. Diese Systeme lösen viele Probleme sehr gut. Sie bieten robuste Transaktionsverarbeitung; sie integrieren sich in ein breites Ökosystem; sie bieten Benutzeroberflächen, Sicherheitsmodelle, Auditierbarkeit und Compliance‑Funktionen, deren Neuerstellung von Grund auf kostspielig wäre.

Ebenso ist dies kein Aufruf an jedes Unternehmen, alles intern mithilfe allgemeiner Programmiersprachen zu entwickeln. Dieser Weg führt schnell zu einer eigenen Art von Fragilität, bei der maßgeschneiderte Skripte undiszipliniert proliferieren.

Was ich vertrete, ist etwas anderes: ein programmatic core für die Entscheidungslogik, umgeben von den besten vorgefertigten Systemen für alles andere.

Mit anderen Worten: Nutzen Sie Ihr ERP, WMS und TMS für das, worin sie gut sind – das Festhalten dessen, was tatsächlich passiert ist, das Durchsetzen einfacher Geschäftsregeln und das Orchestrieren von Workflows. Verwenden Sie spezialisierte Planungssuiten, wenn deren Standardfunktionen wirklich Ihren Bedürfnissen entsprechen. Aber erwarten Sie nicht, dass diese vorgefertigten Tools der Ort sind, an dem Ihre wichtigste, dynamischste und differenzierendste Entscheidungslogik liegt.

Für diesen Zweck benötigen Sie etwas, das von Anfang an akzeptiert, dass Ihre supply chain einzigartig ist, dass sie sich ändern wird, und dass jede ernsthafte Initiative letztlich auf semantische Details stößt, die kein Template vorausgesehen hat.

Eine domänenspezifische Sprache wie Envision ist eine mögliche Antwort. Es ist die, die wir über viele Jahre bei Lokad entwickelt und verfeinert haben, um supply chain Experten die Möglichkeit zu geben, ihre eigene Logik direkt auszudrücken und zu pflegen, ohne dass sie durch Schichten von Vermittlern gehen müssen.

Andere Anbieter haben ähnliche Ideen in unterschiedlichen Formen verfolgt; worauf es ankommt, ist nicht das Etikett „DSL“, sondern das zugrunde liegende Prinzip: Entscheidungslogik muss erstklassig, programmierbar und im Besitz derjenigen sein, die die wirtschaftlichen Zusammenhänge des Geschäfts verstehen.

Geschwindigkeit neu denken

Wenn wir Geschwindigkeit als „wie schnell können wir robuste, automatisierte Entscheidungen in Produktion bringen, und wie schnell können wir sie bei Bedarf überarbeiten?“ neu definieren, ist das Ergebnis unumgänglich.

Kurzfristig erscheinen vorkonfigurierte Suiten oft schneller, weil sie die sichtbare Arbeit zu Beginn minimieren und auf einen feierlichen Go‑Live optimiert sind. Mittel- und langfristig jedoch führen ihre Starrheit und die Kosten der Änderung dazu, dass sie gerade dort langsamer sind, wo Geschwindigkeit am meisten benötigt wird: wenn sich das Geschäftsumfeld verändert.

Ein programmatischer Ansatz erfordert zunächst mehr Arbeit, zahlt sich aber jedes Mal aus, wenn die Realität von den anfänglichen Annahmen abweicht – das heißt, ständig. In einer Welt, in der Unsicherheit die Norm und nicht die Ausnahme ist, zählt genau diese Art von Geschwindigkeit mehr als die Anzahl der Wochen auf einer Implementierungsslide.

Die Frage ist also nicht, ob Sie Software für Ihre supply chain schreiben möchten. Wenn Ihr Unternehmen groß und komplex genug ist, tun Sie das bereits – durch Konfigurationen, durch Tabellenkalkulationen, durch lokale Skripte und manuelle Konventionen. Die einzige wirkliche Frage ist, ob Sie möchten, dass diese Software explizit, kohärent und unter Ihrer Kontrolle ist.

Meine Antwort ist klar: Wenn uns Geschwindigkeit in irgendeinem sinnvollen Sinne wichtig ist, muss die supply chain programmierbar sein.