Supply Chains umfassen eine Patchwork von Unternehmenssoftware. Diese Software-Schichten wurden im Laufe der letzten vier Jahrzehnte allmählich und manchmal planlos eingeführt1. Das ehrwürdige EDI (Electronic Data Interchange) kann neben einem Blockchain-Prototypen stehen. Solche Systeme dominieren vor allem alltägliche, aber wesentliche Aspekte der Supply Chain: Produktion, Lagerung, Transport, Abrechnung, Compliance usw.

Wie viele Personen braucht es, um eine Supply Chain-Glühbirne zu wechseln?

Diese Systeme wurden nicht mit der Absicht implementiert, eine saubere Datenumgebung für Forschungs- und Entwicklungsprojekte bereitzustellen. Diese Tatsache erklärt, warum die meisten Prognoseinitiativen und im Allgemeinen die meisten datenwissenschaftlichen Initiativen in der Supply Chain scheitern. Als belegbare Anekdote ist es in der Regel schneller, alle Waren, die von einem Lagerhaus gehalten werden, an einen anderen Standort zu transportieren, als alle IT-Infrastrukturen an einen neuen Standort zu migrieren.

Als Folge dieser Komplexität sind bei der Einführung von “modernen” Supply Chain-Initiativen zwangsläufig zu viele Spezialisten beteiligt. Für ein mittelgroßes Unternehmen umfasst ein typisches Supply Chain-Projekt:

  • Der Berater, der das Projekt leitet und das Top-Management unterstützt.
  • Der IT-Infrastrukturspezialist, der die mit der zusätzlichen IT-Infrastruktur verbundenen Risiken bewertet.
  • Der Datenbankadministrator, der die relevanten Tabellen in den relevanten Systemen identifiziert.
  • Der ETL-Spezialist, der die Pipeline entwickelt, die die Datenlogistik gewährleistet.
  • Der IT-Berater, der bei den komplizierten IT-Teilen unterstützt.
  • Der Projektkoordinator, der die IT-Experten mit den Supply Chain-Experten verbindet.
  • Der Business Analyst, der die meisten Berichte für das Management erstellt.
  • Der Data Scientist, der den Teil der prädiktiven Modellierung übernimmt.
  • Der technische Support des Anbieters, der die Probleme der eingeführten Technologie bewältigt.
  • Der Vertriebsmitarbeiter des Anbieters, der Erwartungen verwaltet und “Zeug” entlang des Weges verkauft.
  • Der Supply Chain-Praktiker, der die “Stimme des Kunden” repräsentiert.
  • Der Supply Chain-Manager, der die Initiative unterstützt.

Allerdings führt die Beteiligung vieler Spezialisten zu eigenen Problemen. Niemand, nicht einmal das Top-Management, versteht wirklich, was vor sich geht. Die IT-Teile sind für alle außer den IT-Experten undurchsichtig. Umgekehrt kämpft die IT so sehr und auf so vielen Fronten - nicht nur in der Supply Chain -, dass sie nur noch wenig Kapazität hat, um die Feinheiten der Probleme zu lösen, die sie zu lösen versucht. Schließlich verschärft die Datenwissenschaft das Problem mit einer weiteren Disziplin, die für Berater, IT-Experten und Supply Chain-Praktiker gleichermaßen undurchsichtig ist.

Darüber hinaus haben Dritte, Berater, IT-Unternehmen und Technologieanbieter alle ihre eigenen Interessen, die nicht mit denen des Unternehmens übereinstimmen. Es gibt Geld zu verdienen, indem man an jeder Stufe des Prozesses zusätzliche Reibung erzeugt2. Dadurch kann das Ganze mit einem dünnen vorläufigen Budget beginnen, das sich “überraschenderweise” im Laufe der Zeit stetig erhöht, da immer mehr Ressourcen in die Initiative investiert werden müssen.

Ein Teil der oben genannten Komplexität ist unvermeidbar, aber ein anderer Teil ist ziemlich zufällig. Der alte Witz, dass jeder CEO weiß, dass die Hälfte seines Unternehmens nichts von Wert tut, aber er nicht weiß, welche Hälfte.

In dieser Hinsicht besteht die Strategie von Lokad als Technologieanbieter darin, diese zufällige Komplexität frontal anzugehen. Das Wesentliche daran ist einfach: Die Anzahl der beteiligten Spezialisten dramatisch reduzieren. Eine Person, nämlich der Supply Chain Scientist, kümmert sich um die gesamte IT-Pipeline, die mit Rohdaten beginnt und mit finalisierten Supply Chain Entscheidungen endet. Der Supply Chain Scientist trägt die volle Verantwortung für alles, was entlang der Pipeline passiert - einschließlich intelligenter Komponenten wie Machine Learning.

Klassische Unternehmenssoftware ist nicht kompatibel mit der Supply Chain, da ein “Konfigurator” nicht ausdrucksstark genug ist, um mit der enormen Vielfalt der Probleme umzugehen, mit denen sich Lieferketten konfrontiert sehen. Es wird eine Programmiersprache3 benötigt. Leider sind generische Programmiersprachen wie Python nicht kompatibel mit der Rolle des Supply Chain Scientists. Die Anforderungen sind zu hoch und diese Rollen werden innerhalb des Unternehmens zu Softwareingenieuren. Es ist nichts falsch daran, Softwareingenieure zu haben, aber das Supply Chain Know-how muss auf dem Weg durch Spezialisten, die keine Softwareingenieure sind, wieder eingeführt werden. Früh genug sind die meisten der oben genannten Rollen Teil der Initiative.

Damit der Supply Chain Scientist so viele Aufgaben übernehmen kann, ist eine dedizierte Programmierumgebung erforderlich: eine, die es dem Wissenschaftler ermöglicht, die Herausforderungen der prädiktiven Optimierung einer Supply Chain mit möglichst geringem Aufwand anzugehen4. Lokads technologische Antwort auf dieses Problem war Envision, eine domänenspezifische Sprache.

Das Konzept von Envision basiert auf der Idee, dass es besser ist, ungefähr richtig zu sein als genau falsch. Ein Experte, der die gesamte Situation der Supply Chain im Kopf behalten kann, ist weitaus wahrscheinlicher, eine vernünftige Lösung zu produzieren als 10 Experten, von denen jeder nur mit einem Aspekt der Situation vertraut ist. Darüber hinaus ist die Lösung, die von einem einzigen Verstand produziert wird - im Vergleich zur Lösung, die von einem Ausschuss produziert wird - fast immer einfacher und leichter zu warten.

In den meisten Ingenieurdisziplinen mildert der Vorteil, dass ein Ausschuss an dem Problem arbeitet, die zusätzliche Reibung, die durch die bloße Existenz des Ausschusses eingeführt wird. Dies ist jedoch in der Supply Chain selten der Fall. Die End-to-End-Konsistenz der Strategie, die als Produkt eines einzigen Verstandes - oder zumindest weniger - erzielt wird, übertrifft die meisten “lokalen” Optimierungen, die ein Ausschuss zwangsläufig liefert. Die Abstimmung von Angebot und Nachfrage ist grundsätzlich eine Herausforderung auf Systemebene5.

Der Hauptwert des Supply Chain Scientists besteht darin, auf Systemebene zu arbeiten und die gesamte Supply Chain von den Rohdatensätzen bis zur von der Unternehmensleitung entwickelten Strategie zu umfassen. Der Wissenschaftler ist jedoch keineswegs ein Einzelgänger und erhält viel Unterstützung. Die IT erleichtert den Zugang zu den relevanten Daten (ohne die Daten zu vorverarbeiten). Die Betriebsabteilung dokumentiert die vorhandenen Prozesse, die betrieblichen Einschränkungen und die verschiedenen Overheads. Das Marketing klärt die Opportunitätskosten, die nicht aus den Buchhaltungsunterlagen abgelesen werden können, z.B. Fehlbestandskosten. Die Unternehmensleitung kristallisiert die Vision und klärt, was der Wissenschaftler überhaupt optimieren sollte, usw.

Am Ende sind Supply Chain-Entscheidungen6 nicht das Ergebnis eines “Systems”, bei dem die Verantwortung auf viele, oft dutzende, Personen verteilt ist. Diese Entscheidungen, alle von ihnen, sind das Ergebnis der numerischen Rezepte, die vom Supply Chain Scientist implementiert werden, einer einzigen Person, die die Verantwortung für ihre Leistung im Hinblick auf das gesamte Unternehmen übernimmt. Diese Person ist fehlbar, aber sie erhält viel Unterstützung, einschließlich Kollegen, die bereit sind einzuspringen, wenn es nötig ist. Meiner Erfahrung nach ist dies der einzige Weg, um überhaupt damit zu beginnen, eine Supply Chain zu optimieren, auch wenn ein beliebiges Komitee zwangsläufig alle Beobachter unter KPIs, Diagrammen und Berichten begraben wird, um das Gegenteil zu beweisen.


  1. Um einen Einblick zu bekommen, wie die Supply Chain-Software in ein paar Jahrhunderten aussehen könnte, empfehle ich A Deepness in the Sky (1999) von Vernor Vinge, eines der besten Bücher von ihm. Das Aufkommen von Programmierarchäologen als etabliertem Beruf könnte sogar in unserem Leben geschehen. ↩︎

  2. Häufig beginnt die zusätzliche Reibung sogar schon vor der eigentlichen Supply Chain-Initiative. Wenn Berater dem Unternehmen bei RFI- und RFQ-Prozessen “helfen”, werden sich die Verzögerungen und Budgets mit nahezu Sicherheit verdoppeln. ↩︎

  3. Dieses Bedürfnis nach Programmierbarkeit wird heutzutage durch Microsoft Excel erfüllt. Die überwiegende Mehrheit der heutigen Supply Chains wird über Tabellenkalkulationen abgewickelt, auch wenn angeblich fortschrittlichere Systeme wie APS (Advanced Planning and Scheduling) im Einsatz sind. ↩︎

  4. Viele IT-Konzepte sollten von den Supply Chain Scientists abstrahiert werden. Zum Beispiel: objektorientierte Programmierung, Textcodierung, Paketverwaltung, Netzwerkverwaltung, Festplattenverwaltung, Speicherverwaltung, Linux-Administration, Datenbankadministration, Notfallwiederherstellung, API-Protokolle, verteiltes Computing, Multithreading, Injection-Angriffe, Side-Channel-Angriffe, usw. ↩︎

  5. Russell Ackoff veranschaulicht das Denken auf Systemebene am Beispiel des Designs eines Autos. Wenn der CEO eines Automobilherstellers sein Personal bitten würde, für jedes Autoteil das beste auf dem Markt erhältliche Teil zu identifizieren (die besten Bremsbeläge, die besten Achsen, …), würde die Zusammenstellung all dieser Teile nicht einmal zu einem tatsächlichen Auto führen. Die Teile würden nicht passen. Das “beste” Teil macht nur Sinn, wenn man das Auto als Ganzes betrachtet, nicht isoliert. ↩︎

  6. Wie viel soll man kaufen? Wie viel soll man produzieren? Wann soll man den Preis erhöhen / senken? Wie viel Lagerbestand soll man bewegen? usw. ↩︎