Supply Chain braucht programmierbare Systeme, keine konfigurierbaren Produkte

Joannes Vermorel

Ich habe kürzlich Introduction to Supply Chain als ein kostenloses Online-Buch veröffentlicht. Darin argumentiere ich, dass supply chain Entscheidungen von programmatischen Systemen erzeugt werden sollten und nicht von „konfigurierbaren“ Softwareprodukten. Da das Buch absichtlich breit gefächert ist, möchte ich in diesem Beitrag einen speziellen Gedanken in den Mittelpunkt stellen: warum Lokad eine stark programmatische Haltung eingenommen hat und warum dies im Widerspruch zur Mainstream-Sichtweise von supply chain Software steht.

Ich werde keine spezifischen Anbieter besprechen. Was mich interessiert, ist die zugrunde liegende Philosophie: Welche Art von Software ist überhaupt geeignet für supply chain?

Warum generische Software mit konkreten supply chain kämpft

Die meisten Softwareprodukte, die heute für supply chain angeboten werden, folgen einer ähnlichen Geschichte.

Zuerst beginnt man mit einem transaktionalen Rückgrat: etwas, das Bestellungen, Eingänge, Lagerbewegungen, Rechnungen und Lieferungen erfasst. Diese Schicht ist relativ standardisiert. Sie arbeitet mit bekannten Entitäten: Kunden, Bestellaufträgen, SKUs, Standorten. Es wird erwartet, dass sie generisch und branchenübergreifend wiederverwendbar ist, was größtenteils zutrifft.

Auf diesem Rückgrat fügt man „Planungs-“ oder „Optimierungs“-Module hinzu. Diese Module versprechen, vergangene und aktuelle Daten in bessere Entscheidungen umzuwandeln: Bestellaufträge, Umlagerungen, Produktionspläne, Zuweisungen, Preise und so weiter. Anbieter präsentieren diese Fähigkeiten typischerweise als konfigurierbare Anwendungen. Man schreibt die Logik nicht; man konfiguriert sie. Man definiert Regeln. Man legt Parameter fest. Man optimiert Modelle. Man übernimmt Prozesse nach „Best-Practice“.

Auf den ersten Blick erscheint dieser Ansatz vollkommen vernünftig. Schließlich begegnet man überall im Großen und Ganzen ähnlichen Problemen: wie viel gekauft werden soll, wohin es gelegt wird, wann es bewegt wird, was versprochen wird, was rabattiert wird. Sicherlich kann eine generische Plattform diese Probleme auf wiederverwendbare Weise lösen.

Doch wenn man sich reale supply chain genauer anschaut, steht einem etwas Hartnäckigem im Weg: den Eigenheiten.

Ein Kabelverteiler stellt fest, dass zehntausend Meter Kabel nicht „eine Zahl“ sind; es kommt darauf an, wie diese Meter auf Rollen verteilt werden, welche Längen Kunden tatsächlich bestellen, welcher Schnittabfall akzeptabel ist und welche Schnitte versprochen werden können, ohne die Margen zu ruinieren.

Ein Luft- und Raumfahrtunternehmen stellt fest, dass „ein Teil auf Lager“ eine serialisierte Komponente verbergen kann, die ihre eigene Wartungshistorie, Zertifizierungsbeschränkungen und komplexe Austauschregeln besitzt.

Ein Modehändler erfährt, dass die Nachfrage nicht nur nach „SKUs“ besteht, sondern nach Sortimenten: Bestimmte Größen-Farb-Kombinationen müssen gemeinsam vorhanden sein, sonst schneidet die gesamte Kategorie unterdurchschnittlich ab, egal wie viele einzelne Teile auf Lager sind.

Wenn man versucht, diese Situationen in eine generische Entscheidungs-Engine zu quetschen, verhalten sie sich nicht wie Randfälle. Sie bilden das Kernstück des Geschäfts. Jedes Unternehmen hat seine eigene Version dieser „Kabel“: Einschränkungen und wirtschaftliche Rahmenbedingungen, die nicht in eine Schablone passen, aber dennoch die Rentabilität des gesamten Betriebs bestimmen.

Das Ergebnis ist in der Praxis bekannt: konfigurierbare Planungsmodule im Zentrum, Tabellenkalkulationen an den Rändern und menschliche Planer, die ständig die Lücken füllen.

Warum Konfiguration nicht ausreicht

Der Traum hinter konfigurierbarer Planungssoftware ist, dass man Komplexität durch Optionen zähmen kann: mehr Parameter, mehr Schalter, mehr Regeltypen, mehr Vorlagen. Man sollte nicht programmieren müssen; man sollte in der Lage sein, der Software durch Konfiguration beizubringen, was sie tun soll.

Leider hat Konfiguration strenge Grenzen.

Konfiguration funktioniert, wenn man bereits die Gestalt des Problems kennt. Wenn jedes Unternehmen dieselbe Struktur von Einschränkungen und wirtschaftlichen Rahmenbedingungen, dasselbe konzeptuelle Modell davon, wie Nachfrage reagiert und wie Bestände sich verhalten, teilen würde, dann wäre es ausreichend, Werte für einen vordefinierten Satz von Regeln zu wählen.

Aber eine echte supply chain ist nicht ein festes Puzzle, das nur auf die richtigen Parameter wartet. Sie ist ein sich ständig bewegendes Ziel, geformt durch Wettbewerber, Vorschriften, Logistiknetzwerke und sich ständig ändernde Kundengewohnheiten. Außerdem sind die einflussreichsten Einschränkungen oft genau diejenigen, die in kein standardmäßiges Modell passen.

Wenn das in der Software eingebettete Weltmodell nicht mit der Welt übereinstimmt, in der man operiert, bleiben nur zwei Optionen.

Entweder passt man sein Geschäft an die Software an. Das ist gelegentlich sinnvoll für rein administrative Prozesse, aber riskant, wenn es den eigenen Wettbewerbsvorteil berührt.

Oder man kompensiert außerhalb des Systems: Neben-Tabellenkalkulationen, manuelle Anpassungen, Ausnahmebehandlungen, Last-Minute-Änderungen. Die Kernsoftware wird zu einer Art ausgeklügelter Vorschlagsmaschine, während die eigentliche Kontrolle wieder in die Köpfe der Menschen und in Excel-Dateien zurückkehrt.

Je mehr man versucht, ein generisches Planungsprodukt anzupassen, um die eigenen Spezifika zu berücksichtigen, desto mehr kommt man letztlich zu einer verworrenen Konfiguration, die niemand vollständig versteht und die schwer weiterzuentwickeln ist. Man ist der Komplexität nicht entkommen; man hat sie in Metadaten vergraben.

Warum Programmierbarkeit unvermeidlich ist

Wenn Konfiguration nicht ausreicht, bleibt nur das Programmieren übrig.

Das Wort „Programmierung“ wird hier oft missverstanden. Ich behaupte nicht, dass jeder Planer ein Softwareingenieur werden sollte, noch dass jedes Unternehmen einen kompletten Technologie-Stack von Grund auf neu aufbauen sollte. Ich stelle lediglich etwas fest, von dem ich glaube, dass es unausweichlich ist:

Wenn man ein System möchte, das die Verantwortung für supply chain Entscheidungen übernimmt, muss man in der Lage sein, präzise die Logik auszudrücken, nach der diese Entscheidungen getroffen werden.

Diese Logik umfasst:

• Wie mit Unsicherheit umgegangen wird: Nachfrage, Lieferzeiten, Zuverlässigkeit von Lieferanten, Werbeaktionen, Störungen.
• Wie wirtschaftliche Faktoren kodiert werden: Kosten bei Fehlbeständen, Kosten bei Überschuss, Lagerkosten, Kapitalbeschränkungen, Serviceverpflichtungen, Strafgebühren.
• Wie Einschränkungen durchgesetzt werden: Verpackung, Mindestbestellmengen, LKW- und Containerkapazitäten, Haltbarkeit, Austauschregeln, regulatorische Beschränkungen.
• Wie Kompromisse zwischen widersprüchlichen Zielen gefunden werden.

Jedes dieser Elemente ist geschäftsspezifisch. Jedes verändert sich im Laufe der Zeit. Und jedes interagiert mit den anderen in einer Weise, die kein Katalog von Konfigurationsoptionen voraussehen kann.

Deshalb sage ich, dass Programmierbarkeit keine stilistische Präferenz ist. Es ist eine Anerkennung der Realität. Die Frage lautet nicht „Sollten wir programmieren?“, sondern „Wo und mit welchen Werkzeugen?“

Tabellenkalkulationen sind eine Form der Programmierung. Sie sind in supply chain äußerst beliebt, gerade weil sie es Anwendern ermöglichen, Logik auszudrücken, die in keine Standardanwendung passt. Leider skalieren sie schlecht, fördern die Duplizierung von Logik und eignen sich nicht für eine robuste Automatisierung.

Programmiersprachen für allgemeine Zwecke können alles ausdrücken, bringen jedoch ein weiteres Problem mit sich: Wenn man versucht, die gesamte supply chain Intelligence in einem generischen Stack aufzubauen, findet man sich schnell darin wieder, ein Softwareproduktunternehmen in Verkleidung zu betreiben. Man muss Datenbanken, verteilte Rechenleistung, Schnittstellen, Sicherheit und Deployment-Pipelines zusammenstellen und pflegen, die wenig mit dem eigentlichen Geschäft zu tun haben.

Die Herausforderung besteht also darin, die Programmierung zu nutzen, während man sowohl die Brüchigkeit von Tabellenkalkulationen als auch den Aufwand, eine generische Plattform von Grund auf neu zu bauen, vermeidet.

Wie dies die technologischen Entscheidungen von Lokad beeinflusst

Bereits 2012 haben wir eine bewusste Entscheidung getroffen: Wir würden nicht versuchen, ein universelles „Planungsprodukt“ zu entwickeln, das allein durch Konfiguration sofort einsatzbereit sein soll.

Stattdessen haben wir uns daran gemacht, ein Umfeld zu schaffen, in dem die supply chain Entscheidungslogik als Code ausgedrückt werden kann, und zwar auf eine Weise, die:

• Leistungsstark genug ist, um die reale Komplexität eines Unternehmens abzubilden.
• Kompakt genug, um verständlich und prüfbar zu sein.
• Betriebsfähig genug, um täglich, in großem Maßstab, auf bestehenden transaktionalen Systemen zu laufen.

Konkret hat uns das zu einigen Prinzipien geführt.

Zunächst behandeln wir die Daten, die aus ERPs und anderen transaktionalen Systemen stammen, als Rohmaterial, nicht als etwas, worüber lediglich berichtet wird. Wir gehen davon aus, dass der eigentliche Wert darin besteht, diese Daten in konkrete Entscheidungen umzuwandeln: Bestellaufträge, Lagertransfers, Produktionspläne, Preis- und Rabattpolitiken, Sortimentsentscheidungen.

Zweitens drücken wir diese Umwandlung als eine Sammlung von Skripten aus, die in einer domänenspezifischen Sprache geschrieben sind, die speziell für supply chain entwickelt wurde: große tabellarische Datensätze, probabilistische Nachfrage, wirtschaftliche Optimierung und so weiter. Diese Sprache ist keine generische Enterprise-Programmiersprache; sie ist ein fokussiertes Umfeld, das darauf abzielt, numerische Entscheidungsrezepte prägnant und lesbar zu machen.

Drittens bestehen wir darauf, dass das Ergebnis unserer Berechnungen nicht ein Dashboard ist, sondern eine Reihe vorgeschlagener Maßnahmen, die auf die transaktionalen Systeme angewendet werden können. Wenn unsere Arbeit nicht zu geänderten Aufträgen, geänderten Beständen, geänderten Preisen führt, hat sie keinen Grund, in der Produktion zu existieren.

Schließlich strukturieren wir alles so, dass es neu geschrieben werden kann. Wenn sich die Welt ändert, wenn eine Pandemie die Nachfrage neu gestaltet, wenn sich eine neue Produktkategorie unerwartet verhält, zielen wir darauf ab, den Code schnell und sicher zu ändern, anstatt jahrelang auf eine neue Version eines Produkts zu warten.

Das ist eine völlig andere Denkweise, als zu versuchen, in einem Softwareprodukt immer mehr generische „Features“ anzusammeln. Wir wollen nicht für jeden alles sein. Wir wollen ein präzises Instrument bereitstellen, das verwendet werden kann, um die Logik auszudrücken, die für ein bestimmtes Unternehmen wirklich zählt.

Die Mainstream-Sichtweise und wo wir abweichen

Der Mainstream-Ansatz in der supply chain Technologie basiert auf einer vernünftigen Zielsetzung: Planungsprozesse zu standardisieren und zu industrialisieren. Er legt Wert auf integrierte Suites, vorab definierte Best Practices und benutzerfreundliche Konfiguration. Er verspricht schnellere Implementierung und eine reduzierte Abhängigkeit von knappen technischen Fähigkeiten.

Es gibt Situationen, in denen dieser Ansatz Wert liefert, insbesondere wenn das Geschäft relativ nahe an den vom Softwareprodukt angenommenen Standardmodellen liegt und die primären Ziele Sichtbarkeit, Governance und grundlegende Koordination sind.

Wo wir abweichen, liegt in der Antwort auf eine spezifische Frage:

Wo sollte ein Unternehmen die Intelligenz hinterlegen, die tatsächlich entscheidet, was zu tun ist?

Die Mainstream-Antwort lautet: Innerhalb eines konfigurierbaren Produkts, das vom Anbieter gepflegt und durch Parameter, Workflows und Erweiterungen angepasst wird.

Unsere Antwort bei Lokad lautet: In einer kompakten, programmierbaren Schicht, betrieben von einem kleinen Team, das die Entscheidungslogik besitzt und sie anpassen kann, wenn sich die Realität ändert.

Aus diesem Unterschied ergeben sich viele praktische Konsequenzen.

In einer produktzentrierten Sichtweise besteht die zentrale Schwierigkeit darin, das richtige Produkt auszuwählen und umzusetzen, und dann die Organisation an dessen Prozesse und Funktionen anzupassen. Sobald das Produkt implementiert ist, verlagert sich der Fokus darauf, es korrekt zu nutzen: sicherzustellen, dass die Menschen die Dashboards betrachten, den Workflows folgen und die Eingaben ausfüllen.

In einer programmatischen Sichtweise besteht die zentrale Schwierigkeit darin, ein gutes numerisches Rezept zu erstellen und zu pflegen: eines, das die reale Wirtschaftlichkeit des Geschäfts widerspiegelt, Unsicherheiten sinnvoll handhabt und bei Bedarf schnell angepasst werden kann. Die Softwareplattform wird danach beurteilt, wie gut sie dieses Vorhaben unterstützt: Können wir komplexe Einschränkungen ausdrücken, ohne dass die Logik zu einem Durcheinander wird? Können wir die Entscheidungen von gestern erneut ausführen, um zu verstehen, was passiert ist? Können wir sicher mit neuen Ideen experimentieren?

Beide Ansätze beinhalten Algorithmen, Prognosen, Optimierung und ansprechende Interfaces. Der Unterschied liegt darin, wer letztlich die Kontrolle über die Logik hat und wie anpassungsfähig diese ist.

Ein schmaler Pfad, aber ein notwendiger

Der programmatische Pfad ist nicht der einfachste zu erklären. „Du wirst Code haben, der deine supply chain Entscheidungen ausdrückt“ klingt weniger glamourös als „Du wirst ein intelligentes System mit konfigurierbaren Best Practices haben.“ Er erfordert zudem eine gewisse Disziplin: klare Zuständigkeiten, strenge Versionskontrolle, ordnungsgemäße Instrumentierung, sorgfältige Implementierung.

Dennoch sehe ich nach fast zwei Jahrzehnten der Beobachtung von supply chain Software in der Praxis keine tragfähige Alternative, wenn wir Automatisierung ernst nehmen.

Wenn wir Systeme wollen, die mehr als nur vorschlagen und visualisieren; wenn wir wollen, dass sie die Verantwortung für Entscheidungen übernehmen, die Waren im Wert von Milliarden von Dollar bewegen; wenn wir wollen, dass sie Schocks überstehen und sich an neu entdeckte Einschränkungen anpassen, dann müssen wir uns die Mittel geben, Logik präzise auszudrücken und sie ohne Angst zu revidieren.

Genau das bietet Programmierbarkeit.

Lokad existiert, weil ich glaube, dass supply chain zu wichtig ist, um sie undurchsichtigen Konfigurationen und starren Produkten zu überlassen. Sie verdient Software, die die chaotische, eigentümliche Realität jedes Unternehmens anerkennt, und die jenen, die die supply chain betreiben, die Werkzeuge an die Hand gibt, die sie benötigen, um ihr Verständnis in eine Form zu kodieren, die wirklich handeln kann.

Diese Perspektive erklärt sowohl die technologischen Entscheidungen, die wir getroffen haben, als auch unsere Arbeitsweise mit unseren Kunden. Wir verkaufen keine Box, die vorgibt, Intelligenz zu enthalten. Wir bieten einen Weg, sie zu bauen, zu verfeinern und lebendig zu halten.