Mechanische Sympathie: Die fehlende Zutat in supply chain Software

Joannes Vermorel

Als ich vor fast zwanzig Jahren anfing, an supply chain Problemen zu arbeiten, erwartete ich, dass der schwierige Teil in der Physik liegen würde: Lastwagen, Schiffe, Paletten, Container, Produktionslinien. Stattdessen sah ich mich mit Bildschirmen konfrontiert, die mehrere Sekunden zum Aktualisieren benötigten, mit nächtlichen Batches, die routinemäßig bis in den nächsten Morgen andauerten, und mit „Optimierungs“-Engines, die so weit vereinfacht werden mussten, dass sie kaum besser als eine Tabellenkalkulation waren.

Der eigentliche Engpass war nicht Stahl oder Beton. Es war Software. Genauer gesagt, es war unsere kollektive Gleichgültigkeit gegenüber der Maschine, die diese Software betreibt.

In meinem Buch Introduction to Supply Chain, behaupte ich, dass moderne supply chains vor allem Entscheidungsmaschinen in unsicheren Zeiten sind. Die Qualität dieser Entscheidungen hängt von der Qualität der Software ab, die sie vorbereitet, und diese Software ist wiederum durch die zugrunde liegende Rechenhardware begrenzt, von CPU-Caches bis zur Speicherbandbreite.

In den letzten zehn Jahren bin ich zu der Überzeugung gelangt, dass die supply chain Praxis nicht viel weiter fortschreiten kann, sofern wir nicht etwas entwickeln, was ich mechanische Sympathie nenne: ein instinktives Gespür dafür, wie Berechnungen tatsächlich ablaufen, sowie die Bereitschaft, unsere Methoden an dieser Realität auszurichten, anstatt sie zu ignorieren.

Was ich unter „mechanischer Sympathie“ verstehe

Der Ausdruck stammt ursprünglich aus dem Motorsport. Ein guter Fahrer beherrscht nicht nur die ideale Rennlinie; er spürt auch, was das Auto leisten kann und was nicht. Er vermeidet heftige Manöver, die die Bremsen überhitzen, hört auf den Motor und merkt, wann die Reifen zu rutschen beginnen. Er fühlt mit der Maschine.

Im Bereich der Informatik besteht das Äquivalent darin, zu verstehen, dass ein moderner Server kein magischer, reibungsloser Rechner ist, der abstrakt „Operationen pro Sekunde“ ausführt. Es handelt sich vielmehr um ein physisches Objekt mit Eigenarten: winzige Caches, die zwar schnell, aber klein sind, Hauptspeicher, der langsamer ist, Festplatten, die noch langsamer sind, und Netzwerke mit einer Latenz, die sich nicht einfach wegwünschen lässt. Der Unterschied zwischen der Beachtung dieser Einschränkungen und ihrer routinemäßigen Missachtung führt zu Leistungsgewinnen von ein oder zwei Größenordnungen.

Ein eindrucksvolles Beispiel finden wir in der Geschichte des Deep Learning. Die frühen Arbeiten zu neuronalen Netzen waren von biologischer Inspiration besessen: Neuronen, Synapsen, Lernregeln, die an die Neurowissenschaft erinnerten. Der Durchbruch gelang, als Forscher jeglichen Vorwand, das Gehirn nachzuahmen, aufgaben und stattdessen kompromisslos für GPUs und numerische Stabilität optimierten. Rectified Linear Units, Mini-Batches, dichte Schichten, gemischte Präzisionsarithmetik: Viele dieser Ansätze drehen sich weniger um die Neurowissenschaften als vielmehr um die Anpassung an die Hardware. Das Feld startete durch, sobald es mechanische Sympathie für Silizium zeigte.

Supply chain ist natürlich nicht die Bilderkennung. Aber es ist ebenso rechnerisch anspruchsvoll und hat genauso viel davon, die Maschine zu respektieren.

Supply chain als ein rechnerisches Problem

Supply chains werden oft in Bezug auf physische Ströme beschrieben: Fabriken, Lager, Lastwagen und Geschäfte. Weniger offensichtlich ist jedoch, dass sich hinter jeder Palette, die bewegt wird, Dutzende kleiner Entscheidungen verbergen: Was soll eingekauft werden, was produziert werden, wie viel verschickt, wo gelagert, zu welchem Preis verkauft, wann rabattiert und welche Bestellung priorisiert werden soll.

Jede dieser Entscheidungen wird unter Unsicherheit getroffen. Die Nachfrage kann stark ansteigen oder einbrechen. Lieferzeiten können sich verschieben. Zulieferer scheitern. Transportkapazitäten können über Nacht verschwinden. Wenn wir diese Entscheidungen systematisch besser als bloße menschliche Schätzungen treffen wollen, benötigen wir Algorithmen, die viele Szenarien berücksichtigen – nicht nur eine einzelne Prognose –, die Optionen anhand des erwarteten Gewinns vergleichen und nicht nur den Servicegrad, und die Einschränkungen im gesamten Netzwerk propagieren, anstatt jedes Lager oder Geschäft isoliert zu behandeln.

All dies ist rechnerisch aufwendig. Ein probabilistischer Ansatz, der Tausende plausibler Zukunftsszenarien verfolgt und Entscheidungen gegen jedes von ihnen bewertet, führt weitaus mehr Rechenoperationen aus als eine vereinfachte Sicherheitsbestandsformel. Ein netzwerkweiter Ansatz, der Bestands-, Preis- und Kapazitätsplanung koppelt, lässt weitaus mehr Daten durch die Maschine fließen als eine lokale Nachbestellpunktberechnung.

Hier wird mechanische Sympathie entscheidend. Wenn der zugrunde liegende Software- und Hardware-Stack schlampig ist, jede Abfrage Dutzende von Round Trips zu einer transaktionalen Datenbank auslöst und die Algorithmen so geschrieben sind, dass sie Caching und Parallelverarbeitung untergraben, passen diese umfassenderen Methoden einfach nicht in das verfügbare Zeitfenster. Man schrumpft das Problem, bis es in die Maschine passt, anstatt die Maschine zu verbessern, damit sie das eigentliche Problem lösen kann.

Wenn ich ein Unternehmen sehe, dessen Nachschub-“Optimierung” um 18 Uhr beginnen muss, um bis 6 Uhr morgens abgeschlossen zu sein, weiß ich, dass die Organisation niemals ernsthaft mit Alternativen experimentieren wird. Jede neue Idee wird zu einem mehrwöchigen Projekt, weil allein ein Durchlauf einen halben Tag in Anspruch nimmt. Die Wirtschaftlichkeit von Experimenten bricht zusammen.

Die Mainstream-Sicht: Hardware als nachträglicher Gedanke

Wenn man sich die gängigen Lehrbücher der supply chain anschaut, findet man ausführliche Diskussionen über Netzdesign, Beschaffungsstrategien, Verträge, Bestandsrichtlinien, Transportarten und Leistungskennzahlen. Man findet auch Kapitel über „Informationstechnologie“, in denen ERP-Systeme, Planungstools und Integration beschrieben werden. Eine ernsthafte Diskussion darüber, wie die zugrunde liegende Rechnerarchitektur tatsächlich funktioniert, wird man jedoch fast nie finden.

IT wird als neutraler Ermöglicher betrachtet. Die Aussage ist in etwa, dass man sich, sobald man seine Software ausgewählt und die Daten integriert hat, auf die Prozessgestaltung und unternehmerische Stellhebel konzentrieren kann. Das Innenleben der Maschine – wie der Speicher angeordnet ist, wie Daten gespeichert werden, wie die Berechnung geplant wird – obliegt Anbietern und Technikern.

Diese Denkweise durchzieht die meisten Unternehmenssoftwares in unserem Bereich. Planungssysteme werden auf transaktionalen Datenbanken aufgebaut, die ursprünglich dafür konzipiert wurden, Bestellungen zu buchen und Lagerbestände zu aktualisieren – nicht dafür, über Nacht Milliarden probabilistischer Szenarien zu berechnen. Die Architektur ist in der Regel auf Bildschirme und Formulare ausgerichtet, die Datensätze erstellen, lesen, aktualisieren und löschen. Zusätzliche „Optimierungs-Module“ werden hinzugefügt: hier eine Prognose-Engine, dort ein Routing-Löser, irgendwo eine Bestandsheuristik.

Von außen betrachtet sieht das modern genug aus: Webschnittstellen, Cloud-Bereitstellung, APIs, vielleicht sogar „AI“ in der Marketingbroschüre. Im Inneren allerdings ist der rechnerische Kern oft unterversorgt. Berechnungen werden durch Abstraktionsschichten geleitet, die die Daten fragmentieren, die Arbeit zerstreuen und die Stärken der Hardware untergraben. Das Ergebnis ist Software, die trotz des Einsatzes von Maschinen, die tausendfach schneller sind als die von vor dreißig Jahren, Schwierigkeiten hat, mit den heutigen Datenmengen Schritt zu halten.

Niklaus Wirth bemerkte einst augenzwinkernd, dass Software schneller langsamer wird, als Hardware schneller wird. In supply chain kann man dies direkt beobachten: Es dauert in vielen großen Systemen immer noch mehrere Sekunden, um die „Details“-Seite für eine einzelne Produkt-Standort-Kombination zu öffnen, obwohl die zugrunde liegende Hardware in der Lage sein sollte, in derselben Zeit Millionen solcher Datensätze zu scannen. Wir haben es geschafft, nahezu den gesamten Fortschritt der Hardware in Ineffizienzniveaus zu verbrauchen.

Sobald Ineffizienz in die Architektur eingebaut ist, sind die Folgen nicht nur technischer Natur, sondern auch doktrinär. Wenn Ihre Plattform es sich nicht leisten kann, Tausende von Szenarien für jede SKU zu verfolgen, werden Sie Methoden bevorzugen, die nur eine einzelne Prognose erfordern. Wenn Ihre Engine die finanziellen Auswirkungen von Entscheidungen auf netzwerkweiter Ebene nicht bewerten kann, tendieren Sie zu lokalen Regeln und Schlüsselleistungsindikatoren, die isoliert berechnet werden können. „Theoretische“ Einschränkungen werden schnell zu „praktischem“ Dogma.

Was sich ändert, wenn man der Maschine Beachtung schenkt

Was passiert, wenn wir die Perspektive umkehren? Angenommen, wir gehen davon aus, dass die Maschine eine Rolle spielt.

Zunächst entwerfen wir Datenflüsse, die die Lokalität berücksichtigen. Anstatt Informationen über Dutzende von Tabellen zu verstreuen und die Datenbank bei jeder Berechnung darum zu bitten, sie wieder zusammenzufügen, organisieren wir die Daten so, dass ein einzelner Speicherzugriff alles liefert, was ein Algorithmus benötigt. Dies allein kann die Leistung um eine ganze Größenordnung steigern.

Zweitens bevorzugen wir Batch- und vektorisierte Operationen gegenüber gesprächigen, zeilenweisen Verarbeitungen. Die Hardware ist außergewöhnlich gut darin, dieselbe Operation immer wieder auf großen Arrays auszuführen. Sie ist jedoch schlecht darin, Tausenden winziger, nicht zusammenhängender Fragen zu beantworten, die erfordern, dass man im Speicher und im Netzwerk herumspringt. Wenn der analytische Teil eines supply chain systems als ein stimmiges Programm ausgedrückt wird und nicht als ein Schwarm formularbasierter Transaktionen, lässt sich diese Stärke viel besser nutzen.

Drittens betrachten wir die gesamte Entscheidungskette – von Rohdaten bis zu den Mengen, die in Bestellungen und Kommissionierlisten erscheinen – als etwas, das analysiert, optimiert und im Laufe der Zeit neu gestaltet werden kann und sollte. Wir hören auf, „das Modell“ als Blackbox zu betrachten, und fangen an, die Rezeptur als Software zu behandeln. Genau das ermöglichte es Bereichen wie Computergrafik und wissenschaftlichem Rechnen, sich von langsamen Prototypen zu industriellen Werkzeugen zu entwickeln: Ingenieure verbrachten jahrelang damit, Ineffizienzen auf jeder Ebene abzubauen.

Der direkte Vorteil ist Geschwindigkeit. Eine Berechnung, die früher sechs Stunden dauerte, könnte nun sechs Minuten oder sechs Sekunden in Anspruch nehmen. Aber der tiefere Nutzen liegt nicht in der bloßen Zahl, sondern darin, was die Geschwindigkeit ermöglicht. Wenn Ihr Team anstatt einer Variante pro Woche hundert Varianten einer Nachschubpolitik an einem Tag durchlaufen kann, werden sie Ideen erkunden, die zuvor undenkbar waren. Sie werden Modelle als Reaktion auf Störungen verfeinern, alternative Annahmen testen und schrittweise die Grenzen dessen verschieben, was wirtschaftlich erreichbar ist.

Das ist keine Geek-Eitelkeit, sondern Ökonomie

Einige Leser mögen sich Sorgen machen, dass all dies nach der Besessenheit eines Ingenieurs von Eleganz um ihrer selbst willen klingt. Wen interessiert, wie viele Cache-Misses ein Algorithmus verursacht, solange die Regale gefüllt und die Lastwagen pünktlich abfahren?

Die Antwort lautet, dass Ineffizienz nicht kostenlos ist. Im Zeitalter der Cloud zahlt man doppelt dafür.

Man zahlt direkt in Form von überdimensionierter Infrastruktur. Falls Ihre Software zehnmal mehr Rechenleistung und Speicher benötigt, als nötig wäre, um dieselben Entscheidungen zu treffen, zahlen Sie zehnmal mehr an Ihren Cloud-Anbieter oder für Ihre Hardware – oder Sie akzeptieren zehnmal längere Laufzeiten, was einfach eine andere Kostenform darstellt.

Man zahlt auch indirekt, in Form einer schwächeren Entscheidungslogik. Da ineffiziente Systeme Schwierigkeiten haben, ausgefeilte Strategien in großem Maßstab zu berechnen, vereinfachen Anbieter die Mathematik, um sie an die Maschine anzupassen. Sie reduzieren Wahrscheinlichkeitsverteilungen auf einzelne Zahlen. Sie entkoppeln Prozesse, die in Wirklichkeit eng miteinander verknüpft sind, sodass diese in separaten Durchläufen berechnet werden können. Sie verstecken grobe Näherungen hinter glänzenden Dashboards. Möglicherweise sehen Sie die Abkürzungen nie, aber Sie werden sie in Form von übermäßigem Sicherheitsbestand, entgangenen Verkäufen und fragilen Reaktionen auf Schocks spüren.

Mechanische Sympathie hingegen ermöglicht es, Ihr rechnerisches Budget dort zu investieren, wo es am wichtigsten ist: bei der Erforschung von Unsicherheiten und Abwägungen. Ein effizientes System kann es sich leisten, tausende Zukunftsszenarien zu simulieren und Entscheidungen auszuwählen, die den erwarteten Gewinn maximieren und gleichzeitig das Risiko kontrollieren, anstatt sich auf Faustregeln zu verlassen. Es kann sich leisten, häufig neu zu berechnen, sodass Entscheidungen angesichts neuer Daten aktuell bleiben. Es kann sich leisten, das gesamte Netzwerk im Blick zu behalten, anstatt jeden Knoten isoliert kurzsichtig zu optimieren.

In diesem Sinne ist mechanische Sympathie keine technische Präferenz, sondern eine wirtschaftliche Haltung. Es bedeutet: Wir werden knappe rechnerische Ressourcen nicht für unnötigen Overhead verschwenden; wir werden sie für die Berechnungen einsetzen, die tatsächlich unseren Cashflow verändern.

Was ich von Supply Chain Führungskräften erwarte

Das alles bedeutet nicht, dass jeder supply chain Executive ein Systemprogrammierer werden muss. Aber ich bin überzeugt, dass Führungsteams ein grundlegendes Gespür für Größenordnung und Richtung benötigen. Man muss keine Engine entwerfen, um zu wissen, dass ein Lastwagen, der für dieselbe Strecke dreimal so viel Kraftstoff verbraucht wie seine Kollegen, ein Problem darstellt. Man muss auch kein Chip-Designer sein, um zu erkennen, dass ein System, das Stunden benötigt, um eine Berechnung durchzuführen, die vernünftigerweise in Sekunden erledigt werden könnte, ein Problem ist.

Wenn Sie Software oder einen Anbieter auswählen, sollten Sie sich wohl dabei fühlen, Fragen wie die folgenden zu stellen:

Wie oft können wir realistisch alle wichtigen Entscheidungen für das gesamte Netzwerk neu berechnen?

Was passiert, wenn wir die Anzahl der SKUs oder Standorte verdoppeln – verdoppeln sich die Laufzeiten oder explodieren sie?

Wie viel Hardware benötigt diese Plattform, um unsere Daten zu verarbeiten, und wie sicher sind wir, dass diese Anforderungen in zwei Jahren nicht ins Unermessliche steigen?

Wenn die Antworten ausweichend sind oder wenn niemand im Raum auch nur annähernd Größenordnungen abschätzen kann, stimmt etwas nicht. In dem LokadTV-Gespräch über rechnerische Ressourcen verglich ich dies mit der Grundgeographie: Man muss nicht die genaue Höhe jedes Berges kennen, aber man sollte wissen, ob eine bestimmte Straße die Alpen oder eine flache Ebene überquert.

Ebenso sollten interne Teams ermutigt werden, ihre analytische Arbeit als Code zu betrachten, der profiliert und verbessert werden kann, und nicht als statische „Modelle“, die entweder richtig oder falsch sind. Die Fähigkeit, über Leistung nachzudenken, gehört zur beruflichen Kompetenz, ebenso wie die Fähigkeit, über die Wirtschaftlichkeit einzelner Einheiten zu schlussfolgern, zum Finanzwesen.

Eine andere Art von Sympathie

Mechanische Sympathie ist letztlich eine Form des Respekts.

Es ist der Respekt vor der Maschine: die Anerkennung, dass unsere Server nicht unendlich sind, dass ihre Eigenheiten und Grenzen real sind und dass wir sie auf eigene Gefahr ignorieren.

Es ist der Respekt vor den Menschen, die auf diese Maschinen angewiesen sind: Planer, die zeitnahe und verlässliche Empfehlungen benötigen; Manager, die Freiraum für Experimente brauchen; Führungskräfte, die auf der Grundlage der Software Kapital zusagen müssen.

Und es ist der Respekt vor der Disziplin der supply chain selbst. Wenn wir behaupten, dass unser Fachgebiet darauf abzielt, unter Unsicherheit bessere Entscheidungen zu treffen, können wir die Qualität der Maschinen, die diese Entscheidungen erzeugen, nicht einfach ignorieren. Wir sind es uns – und den Unternehmen, die uns vertrauen – schuldig, rechnerische Ressourcen genauso ernst zu nehmen wie Lagerhäuser und Flotten.

Die vorherrschende Ansicht war, Hardware- und Software-Interna als eine Angelegenheit hinter den Kulissen zu behandeln, etwas, das „IT es regeln wird.“ Ich glaube, dass diese Sichtweise ihren Nutzen verloren hat. Je mehr unsere supply chains von Algorithmen und Daten abhängen, desto mehr müssen wir die Maschine ins Rampenlicht rücken.

Mechanische Sympathie bedeutet nicht, jeden Planer in einen Programmierer zu verwandeln. Es bedeutet, auf jeder Ebene eine fundierte Neugier dafür zu entwickeln, wie unsere Werkzeuge tatsächlich funktionieren – und die Weigerung, Langsamkeit, Undurchsichtigkeit und Verschwendung als unvermeidlich hinzunehmen.