Männer, Maschinen und die wahre Arbeit der supply chain

Joannes Vermorel

Wenn ich mich mit Führungskräften zusammensetze, um über supply chain zu sprechen, beginnen sie fast immer mit Lagern, Lastwagen, Menschen und manchmal Lieferanten. Computer treten irgendwo im Hintergrund auf: ein Planungssystem hier, eine Tabelle dort und natürlich das ERP „auf dem alles läuft.“ Das implizite Bild ist immer dasselbe: Menschen stehen im Mittelpunkt, Maschinen sind dazu da, zu helfen.

Ich habe in meinem Buch Introduction to Supply Chain ein ganz anderes Bild untersucht, in dem ich argumentierte, dass das meiste, was wir als “supply chain practice” bezeichnen, in Wirklichkeit ein verkleidetes Softwareproblem ist. In diesem Essay möchte ich diese Idee in klareren Worten wiederholen und sie direkt der Mainstream-Ansicht gegenüberstellen, die sowohl Lehrbücher als auch Vorstandsetagen dominiert.

Wie wir Computer stillschweigend herabgestuft haben

In einem großen Teil der Literatur und in den meisten Unternehmen werden Computer wie hochentwickelte Schaufeln behandelt.

Man soll sie natürlich besitzen. Niemand würde heute noch ein globales Netzwerk mit Papier und Fax verwalten. Systeme erfassen Transaktionen, speichern Stammdaten, erstellen Berichte und liefern Prognosen. Planer loggen sich jeden Morgen ein, schauen sich Dashboards an, kombinieren das, was das System sagt, mit ihrem „Geschäftssinn“ und entscheiden, was zu tun ist.

Der Tonfall ist immer ähnlich: Die Technologie bietet support. Sie sammelt Daten, führt Berechnungen durch, zeigt rote und grüne Anzeigen und schlägt vielleicht eine empfohlene Bestellmenge vor. Aber es wird erwartet, dass der Mensch die Entscheidung „in die Hand nimmt“. Die Software ist der Analyst; der Planer ist der decision-maker.

Auf dem Papier klingt das beruhigend. Es respektiert Erfahrung, Intuition und Verantwortlichkeit. Es vermeidet die Angst, dass „das System das Geschäft führt.“ Es entspricht unserer Intuition, dass ernsthafte Entscheidungen von ernsthaften Menschen getroffen werden sollten.

Das Problem ist, dass dieses Bild nicht mehr zum Ausmaß und zur Komplexität moderner supply chains passt.

supply chain als Geflecht kleiner Wetten

Täglich trifft Ihr Unternehmen eine erstaunliche Anzahl kleiner Verpflichtungen.

Sie entscheiden, wie viele Einheiten jedes Artikels von jedem Lieferanten zu kaufen sind. Sie wählen, welches Lager welche Mengen erhalten soll. Sie verteilen knappen Bestand zwischen Kanälen und Kunden. Sie nehmen Eilaufträge an oder lehnen sie ab. Sie entscheiden, welche Artikel Regalplatz verdienen und zu welchem Preis. Sie akzeptieren bestimmte Lieferzeiten von Transportunternehmen und lehnen andere ab.

Jede dieser Verpflichtungen ist eine kleine Wette auf eine unsichere Zukunft: eine Wette darauf, dass diese Bestellung rechtzeitig eintrifft, dass diese Promotion das Volumen steigert, dass dieser Sicherheitsbestand ausreichend, aber nicht zu hoch sein wird. Keine dieser Wetten ist für sich genommen besonders heldenhaft, aber zusammen entscheiden sie über Gewinn und Verlust (P&L).

Das Unterscheidungsmerkmal moderner supply chains ist nicht, dass sie global oder schnell sind; das ist bereits bekannt. Es ist, dass die Anzahl solcher Wetten explodiert ist. Produktpaletten wachsen. Kanäle vervielfachen sich. Lieferzeiten schwanken. Kundenerwartungen steigen. Die Entscheidungsfläche wird zu groß für jedes Team von Menschen, um sie zu überwachen – geschweige denn, per Hand zu optimieren.

In diesem Umfeld skaliert das Mainstream-Modell – Menschen im Zentrum, Maschinen, die decision support bieten – einfach nicht. Menschen werden zum Engpass am falschen Ort: nicht im Hafen oder im Lager, sondern vor Bildschirmen.

Warum Computer im Mittelpunkt stehen

Computer haben eine Superkraft: Sie sind sehr gut darin, eine große Anzahl kleiner, strukturierter Berechnungen immer wieder durchzuführen, ohne müde oder gelangweilt zu werden.

Supply chain ist genau solch ein Problem. Die meisten operativen Entscheidungen, die die Zeit der Planungsteams in Anspruch nehmen, sind repetitiv. Sie wiederholen sich Tag für Tag, mit Variationen in den Daten, aber mit einer ähnlichen Struktur. Sie haben klare Eingaben: Prognosen, Kosten, Kapazitäten, Beschränkungen, Geschäftsregeln. Sie haben klare Ausgaben: Mengen, Daten, Standorte, Preise. Sie sind nicht trivial, aber sie sind strukturiert.

Wenn man das akzeptiert, bietet sich eine andere Architektur an.

Anstatt Computer als Werkzeuge zu betrachten, die Informationen für den Menschen aufbereiten, beginnt man, sie als Maschinen, die tatsächlich Routineentscheidungen treffen zu sehen. Nicht als „Assistenten“-Maschinen, sondern als „Entscheidungs“-Maschinen.

Das bedeutet nicht, ein riesiges monolithisches Gehirn zu bauen, das alles steuert. Es bedeutet, absichtlich Software zu entwickeln, die unter normalen Umständen in der Lage ist:

• die relevanten Daten zu lesen,
• viele mögliche Optionen zu bewerten,
• eine auszuwählen, basierend auf einem expliziten wirtschaftlichen Ziel,
• und eine konkrete Anweisung zu erteilen: eine Bestellpositionszeile, eine Lagerübertragung, eine Zuteilung, einen Preis.

Menschen existieren in dieser Welt zwar weiterhin, aber sie verbringen ihre Tage nicht mehr damit, einzelne Aufträge anzustoßen. Sie arbeiten um die Entscheidungsmachinerie herum, statt durch sie hindurch.

Das ist die grundlegende Veränderung: von Computern, die Entscheidungen unterstützen, zu Computern, die Entscheidungen treffen an all den Stellen, wo Entscheidungen klein, zahlreich und repetitiv sind.

Wozu Menschen eigentlich da sind

Maschinen in den Mittelpunkt zu rücken, macht Menschen nicht weniger wichtig; es macht sie für andere Dinge verantwortlich.

Zuerst müssen die Menschen entscheiden, was die Software überhaupt tun darf. Das bedeutet, den Raum der zulässigen Möglichkeiten zu definieren. Ist Cross-Docking zwischen diesen Standorten erlaubt? Sind Substitutionen zwischen diesen zwei SKUs zulässig? Können wir Teillieferungen an diesen Kunden senden? Können wir Luftfracht für dieses Produkt in dieser Region einsetzen? Computer erfinden keine Optionen; sie wählen aus denen aus, die wir zur Verfügung stellen.

Zweitens müssen die Menschen entscheiden, was „gut“ bedeutet. Es geht dabei nicht um vage Bestrebungen wie „Service Excellence“ oder „Lean Inventory“, sondern um explizite Abwägungen. Wie schmerzhaft ist ein Fehlbestand, in finanziellen Begriffen, für unterschiedliche Produkte und Kunden? Wie teuer ist Obsoleszenz? Wie sehr schätzen wir tatsächlich die Lieferzeit im Vergleich zu den Kosten auf Streckenbasis? Wie sollen wir zwischen zwei Geschäftsbereichen vermitteln, die um dieselbe begrenzte Kapazität konkurrieren?

Wenn wir diese Fragen präzise beantworten, geben wir der Software eine Zielsetzung. Wir sagen ihr, was wir wollen, in einer Sprache, die sie auf jede Entscheidung anwenden kann.

Drittens müssen die Menschen die Bedeutung der Daten schützen. Im Laufe der Zeit werden Felder in einem System wiederverwendet, neu interpretiert und missbraucht. Eine Spalte, die einst „zugesagtes Lieferdatum“ bedeutete, steht jetzt manchmal für „angefordertes Datum“. Eine Kennzeichnung, die einst auf eine Produktfamilie hinwies, wird leise umfunktioniert, um eine interne Promotion anzuzeigen. Wenn niemand darauf achtet, wird die Software weiterhin sehr präzisen Quatsch berechnen.

Schließlich müssen die Menschen eingreifen, wenn sich die Welt schneller verändert als die Modelle oder Regeln. Sie müssen in der Lage sein zu sagen: Diese Einschränkung ist nicht mehr gültig; diese Strafe ist zu hoch; diese Beschaffungsoption ist nun politisch inakzeptabel; diese Lieferzeit ist nicht mehr vertrauenswürdig. Sie greifen nicht ein, indem sie Tausende von Aufträgen manuell bearbeiten, sondern indem sie die Annahmen ändern, die diese Aufträge erzeugen.

Aus dieser Perspektive sind Menschen also keine Sachbearbeiter, die Tabellenkalkulationen auf Hochglanz polieren. Sie sind Designer, Ökonomen und Hüter der Entscheidungsmachinerie. Ihre Aufgabe ist es, das Spiel zu entwerfen, die Punkte zu vergeben und darauf zu achten, wenn das Spiel nicht mehr der Realität entspricht.

Die gängige Sichtweise, einfach gesagt

Lassen Sie mich nun die gängige Sichtweise so darlegen, dass sie die meisten Praktiker wiedererkennen.

In einem typischen Unternehmen verfügt die Softwarelandschaft über drei Ebenen.

Unten zeichnen Transaktionssysteme auf, was geschieht: Bestellungen, Eingänge, Lieferungen, Rechnungen. Darüber fassen Reporting-Tools und Dashboards diese Historie in vielen Facetten zusammen: nach Produkt, Kunde, Region, Zeitraum. Darüber hinaus finden Sie Planungssysteme, die Daten von unten übernehmen, Prognosen berechnen, Heuristiken oder Optimierungen durchführen und „Vorschläge“ erstellen.

Diese Vorschläge werden dann von Planern überprüft. Sie vergleichen sie mit ihrem Wissen über den Markt, den Eigenheiten der Lieferanten, der Politik der Kunden und der Realität der Lager. Einige werden akzeptiert, andere angepasst und den Rest überschrieben. In vielen Organisationen erfolgt ein Großteil dieses letzten Schritts in Tabellenkalkulationen, außerhalb eines formalen Systems.

Die implizite Philosophie ist klar: Systeme sollen informieren und unterstützen. Menschen, insbesondere Planer, sollen entscheiden. Wenn etwas schiefgeht, lautet die Erklärung oft, dass „das System nicht flexibel genug ist“, oder „die Daten fehlerhaft waren“, oder „der Algorithmus diesen Sonderfall nicht verstanden hat“, weshalb ein Planer zur Korrektur benötigt wurde.

Lehrbücher bestärken dieses Muster. Informationstechnologie wird als ein „Treiber“ oder „Enabler“ der supply chain-Performance beschrieben. Sie bietet Sichtbarkeit, Integration, Geschwindigkeit und analytische Raffinesse. Aber es gibt immer einen Schritt, bei dem der menschliche Entscheidungsträger an der Spitze der Pyramide wieder auftaucht, dem das System Bericht erstattet.

Dieses Bild ist nicht völlig falsch. Es spiegelte die Realität dessen wider, was lange machbar war. Systeme waren starr. Optimierung im großen Maßstab war teuer. Die Datenqualität war miserabel. Einen Menschen in den Prozess einzubinden, war eine sichere und pragmatische Entscheidung.

Aber wir haben an diesem Modell länger festgehalten, als es verdient hätte.

Wo ich mich vom Mainstream abgrenze

Mein Widerspruch zum Mainstream lässt sich in einem einfachen Satz zusammenfassen:

Für die meisten operativen Entscheidungen sollten wir nicht länger auf Entscheidungsunterstützung abzielen; stattdessen sollten wir auf Entscheidungsautomatisierung setzen.

Dies bedeutet nicht blinde Automatisierung. Es heißt, dass wenn eine Entscheidung klein, häufig und in vielen Fällen strukturell ähnlich ist, wir Software so entwickeln sollten, dass sie diesen Prozess von Anfang bis Ende übernimmt, während sich die Menschen auf das Design und die Überwachung des Mechanismus konzentrieren, anstatt ihn täglich auszuführen.

Aus dieser einfachen Aussage ergeben sich mehrere Auseinandersetzungen.

Der Mainstream investiert stark darin, mehr Dashboards und mehr Planer hinzuzufügen. Ich würde lieber in weniger Planer investieren, die sich eher wie quantitative Product Owner verhalten, und in mehr Ingenieure, die Geschäftslogik in Code statt in Konfiguration umsetzen können.

Der Mainstream versucht, Systeme zu kaufen, die „konfigurierbar“ genug sind, um die meisten Situationen sofort bewältigen zu können. Ich erwarte, dass jede ernsthafte supply chain viele unternehmensspezifische Eigenheiten und Einschränkungen aufweist, die nicht allein durch Kontrollkästchen und Parametertabellen sinnvoll erfasst werden können. Irgendwann muss jemand Code schreiben.

Der Mainstream betrachtet die Kombination von ERP, Planungssystemen und BI als einen abgeschlossenen Stack: Daten an der Basis, Einsichten in der Mitte, Entscheidungen an oberster Stelle. Ich sehe diesen Stack als nur halb gebaut an. Die fehlende Ebene ist jene, die für den Großteil der tatsächlichen Verpflichtungen im Geschäft verantwortlich ist.

Vor allem besteht der Mainstream darauf, dass Menschen diejenigen sind, die die Entscheidungen treffen. Ich beharre darauf, dass bei der überwiegenden Mehrheit routinemäßiger Entscheidungen Menschen besser daran eingesetzt werden, zu entscheiden, wie Entscheidungen getroffen werden sollten, anstatt sie einzeln zu fällen.

„Aber was ist, wenn das System falsch liegt?“

Ein häufiger und berechtigter Einwand lautet: Was passiert, wenn das System falsch liegt?

Wenn wir die Software Bestellungen platzieren, den Bestand zuweisen und Preise festlegen lassen und die Software einen Fehler macht, können die Konsequenzen schwerwiegend sein. Mit einem Menschen im Prozess hätte zumindest jemand den Fehler bemerken können.

Ich glaube, dieser Einwand ist wichtig, aber er hat zwei Seiten.

Wenn man sich darauf verlässt, dass Menschen die Ergebnisse von Systemen korrigieren, die im Grunde falsch spezifiziert sind, tauscht man die eine Art von Fehler gegen eine andere. Einzelne Fehler mögen erkannt werden, aber strukturelle Fehler bleiben bestehen. Niemand hat die Zeit oder die kognitive Kapazität, um zu bemerken, dass die gesamte Logik des Systems leicht fehlerhaft ist, dass eine Strafe falsch kalibriert ist oder dass eine Einschränkung abgewichen ist. Die Menschen löschen Brände; sie gestalten selten neu.

In einem automatisierten Setup sind Sie gezwungen, dieses Risiko explizit zu behandeln.

Sie benötigen ein Monitoring, das nicht nur die Servicelevels und den Lagerumschlag betrachtet, sondern Fehler spezifischen Annahmen zuordnen kann. Sie brauchen die Möglichkeit, die Automatisierung für einen Teil der Produkte oder Regionen anzuhalten, wenn eine Anomalie festgestellt wird. Sie benötigen Prüfprotokolle: klare Aufzeichnungen darüber, warum das System eine bestimmte Entscheidung getroffen hat, mit welchen Eingaben und welcher internen Logik.

Am wichtigsten ist, dass Sie eine Kultur pflegen, die akzeptiert, dass Software ein erstklassiges Gut ist. Sie verdient Design, Testing, Refactoring und Governance. Sie kann nicht eine undurchsichtige Black Box sein, die „vom Anbieter verwaltet“ oder „von der IT betreut“ wird. Wenn die Software das Tagesgeschäft steuert, gehört die Verbesserung und Korrektur ihres Verhaltens zu den Kernaufgaben der supply chain-Organisation.

Das mag riskanter klingen, als von Planern zu fordern, „die Vorschläge im Auge zu behalten“, aber in der Praxis reduziert es häufig das Risiko, anstatt es zu erhöhen. Fehler lassen sich besser nachvollziehen. Korrekturen sind systemisch statt lokal. Lernen sammelt sich im Code, anstatt zu verschwinden, wenn ein erfahrener Planer das Unternehmen verlässt.

Wo ich dem Mainstream noch zustimme

Trotz dieser Differenzen gibt es Bereiche, in denen ich mit der Mainstream-Sichtweise voll und ganz übereinstimme.

Ich bin der Meinung, dass Information zentral ist. Ohne zeitnahe, zuverlässige Daten ist jede Ambition zur Automatisierung reine Fantasie.

Ich stimme zu, dass organisationale Silos ein großes Hindernis darstellen. Wenn sich Einkauf, Logistik, Vertrieb und Finanzen nicht auf grundlegende Definitionen und gemeinsame Ziele einigen können, wird kein System sie retten.

Ich stimme zu, dass supply chain nicht nur aus Mathematik und Maschinen besteht. Beziehungen zu Lieferanten, Vertrauen unter den Partnern, regulatorische Einschränkungen und geopolitische Schocks sind von enormer Bedeutung. Eine hervorragend arbeitende Entscheidungsmaschine kann kein Schiff in einem blockierten Kanal erscheinen lassen.

Mein Punkt ist präziser: Wenn es darum geht, im Tagesgeschäft Mengen, Zeitpunkte und Zuteilungen in großen Netzwerken zu entscheiden, nutzen wir die uns bereits zur Verfügung stehenden Maschinen dramatic unzureichend. Wir fangen talentierte Menschen in bürokratischen Schleifen ein, in denen sie nur einen sehr geringen Grenznutzen erbringen, dabei aber eine enorme Menge an organisatorischer Energie verbrauchen.

Ein anderes Ziel

Wenn Sie meine Ansicht ernst nehmen, sieht das angestrebte Ziel in etwa so aus.

Die meisten operativen Entscheidungen des täglichen Geschäfts – was bestellt wird, wo zugewiesen wird, wie viel versendet wird, wann nachbestellt wird – werden unter normalen Umständen automatisch von Software getroffen. Die Software operiert nach klaren, expliziten Regeln und wirtschaftlichen Zielen, und ihr Verhalten ist sichtbar und prüfbar.

Planer beginnen ihren Tag nicht damit, durch Ausnahmelisten zu scrollen. Sie beginnen ihren Tag damit, das Verhalten der Entscheidungsmotorik selbst zu betrachten: wo sie gut funktioniert, wo sie unberechenbar ist, wo Annahmen möglicherweise veraltet sind. Sie arbeiten mit Ingenieuren zusammen, um die Logik zu verfeinern, die Daten zu verbessern und die ökonomischen Abwägungen anzupassen.

Wenn Störungen auftreten, greifen Menschen ein – nicht, indem sie einzelne Aufträge mikromanagen, sondern indem sie die Parameter des Spiels ändern: bestimmte Transportarten verbieten, temporäre Beschaffungsoptionen eröffnen, Strafen und Prioritäten anpassen. Das System berechnet dann die unzähligen kleinen Wetten neu, die mit diesen neuen Bedingungen einhergehen.

Karrieren in supply chain entwickeln sich entsprechend. Weniger Zeit wird darauf verwendet, „gegen das System zu kämpfen“ und „den Plan zu reparieren.“ Mehr Zeit wird darauf verwendet, die Wirtschaftlichkeit des Geschäfts zu verstehen, dieses Verständnis in Software zu codieren und widerstandsfähige Optionssätze für eine unsichere Welt zu entwerfen.

In einer solchen Organisation sind die Computer keine Schaufeln mehr. Sie sind die Maschinerie der supply chain. Die Menschen sind die Architekten, Ökonomen und Verwalter dieser Maschinerie.

Das ist die Perspektive, die ich hier klarstellen wollte. Sie unterscheidet sich deutlich von der Mainstream-Erzählung von IT als Unterstützung und Menschen als primäre Entscheidungsträger. Aber ich glaube, dass sie näher an der Realität dessen liegt, wohin supply chains als nächstes gehen können und sollten.