Wie viele Menschen braucht es, um eine supply chain Glühbirne zu wechseln?

Joannes Vermorel

Supply chains beinhalten einen Flickenteppich aus enterprise software. Diese Softwareschichten wurden in den letzten vier Jahrzehnten allmählich und manchmal planlos ausgerollt¹. Das ehrwürdige EDI (Electronic data interchange) könnte neben einem Blockchain-Prototyp stehen. Solche Systeme betreiben überwiegend alltägliche, aber wesentliche supply chain Aspekte: Produktion, Lagerung, Transport, Abrechnung, Compliance, etc.

Diese Systeme wurden nicht eingeführt, um eine saubere Datenumgebung für F&E-Zwecke zu bieten. Allein diese Tatsache erklärt, warum die meisten Prognoseinitiativen und allgemein die meisten Data-Science-Initiativen in der supply chain scheitern. Als anekdotischer Beleg ist es in der Regel schneller, alle in einem warehouse gelagerten Waren physisch an einen anderen Standort zu verlagern, als die gesamte IT-Infrastruktur an einen neuen Standort zu migrieren.

Infolge dieser Komplexität umfasst der Rollout moderner supply chain Initiativen zwangsläufig zu viele Spezialisten. Für ein großes Unternehmen beinhaltet das typische supply chain Projekt:

• Der Berater, der das Projekt steuert und das Top-Management unterstützt.
• Der IT-Infrastruktur-Spezialist, der die Risiken der zusätzlichen IT-Infrastruktur bewertet.
• Der Datenbankadministrator, der die relevanten Tabellen in den entsprechenden Systemen identifiziert.
• Der ETL-Spezialist, der die Pipeline entwickelt, die die Datenlogistik gewährleistet.
• Der IT-Berater, der mit den anspruchsvollen IT-Teilen eine zusätzliche helfende Hand bietet.
• Der Projektkoordinator, der die Schnittstelle zwischen den IT-Leuten und den supply chain Fachleuten bildet.
• 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 sich mit den Bugs der eingeführten Technologie auseinandersetzt.
• Der Vertriebsmitarbeiter des Anbieters, der die Erwartungen managt und unterwegs ‘Stuff’ upsellt.
• Der supply chain Praktiker, der die “Stimme des Kunden” repräsentiert.
• Der supply chain Executive, der die Initiative vorantreibt.

Allerdings bringt das Hinzuziehen vieler Spezialisten seine eigenen Probleme mit sich. Niemand, nicht einmal das Top-Management, versteht wirklich, was vor sich geht. Die IT-Bereiche sind für alle außer den IT-Leuten in der Regel undurchsichtig. Umgekehrt kämpft die IT in so vielen Bereichen – nicht nur in der supply chain – dass kaum noch Kapazitäten übrig bleiben, um das Kleingedruckte der Probleme, die sie zu lösen versuchen, herauszuarbeiten. Schließlich verschärft Data Science das Problem durch eine weitere Disziplin, die für Berater, IT und supply chain Praktiker gleichermaßen größtenteils undurchsichtig ist.

Darüber hinaus verfolgen Drittparteien, Berater, IT-Unternehmen und Technologieanbieter alle ihre eigenen Agenden, die nicht mit der des Unternehmens übereinstimmen. Es lässt sich Geld verdienen, indem an jeder Stelle des Prozesses für zusätzlichen Reibungswiderstand gesorgt wird². Dadurch kann das Ganze mit einem knappen vorläufigen Budget beginnen, das „überraschenderweise“ im Laufe der Zeit stetig wächst, da immer mehr Ressourcen in die Initiative investiert werden müssen.

Ein Teil der oben genannten Komplexität ist nicht reduzierbar, ein weiterer Teil ist aber durchaus zufällig. Der alte Witz, dass jeder CEO weiß, dass die Hälfte seines Unternehmens nichts Wertvolles leistet, aber nicht weiß, welche Hälfte.

In dieser Hinsicht war die Strategie von Lokad als Technologieanbieter, sich der zufälligen Komplexität frontal zu stellen. Der Kernpunkt ist einfach: Die Anzahl der beteiligten Spezialisten dramatisch zu reduzieren. Eine Person, nämlich der supply chain scientist, übernimmt die gesamte IT-Pipeline, die bei Rohdaten beginnt und mit finalisierten supply chain decisions endet. Der supply chain scientist trägt die volle Verantwortung für alles, was entlang der Pipeline passiert – inklusive intelligenter Komponenten wie Machine Learning.

Klassische Enterprise-Software ist nicht kompatibel mit supply chain, weil ein ‚Konfigurator‘ nicht ausdrucksstark genug ist, um die schiere Vielfalt der Probleme, mit denen supply chains konfrontiert sind, zu bewältigen. Eine Programmiersprache³ ist notwendig. Leider sind generische Programmiersprachen, wie Python, nicht kompatibel mit der Rolle des supply chain scientist. Die Anforderungen an die Fähigkeiten sind zu hoch, und diese Rollen entarten innerhalb des Unternehmens zu Softwareingenieuren. An sich ist nichts falsch daran, Softwareingenieure zu haben, aber das supply chain Fachwissen muss im Laufe der Zeit durch Spezialisten, die keine Softwareingenieure sind, wieder eingebracht werden. Schon bald werden die meisten der oben genannten Rollen Teil der Initiative.

Damit der supply chain scientist so viele Hüte tragen kann, ist eine dedizierte Programmierumgebung notwendig: eine, die es dem Scientist ermöglicht, sich den Herausforderungen der prädiktiven Optimierung einer supply chain mit möglichst wenig Aufwand zu stellen⁴. Lokads technologische Antwort auf dieses Problem war Envision, a domain-specific language.

Das Konzept von Envision beruht auf der Idee, dass es besser ist, annähernd richtig zu sein, als genau falsch zu liegen. Ein Experte, der die gesamte supply chain Situation im Kopf behalten kann, wird mit ziemlicher Wahrscheinlichkeit eine sinnvolle Lösung erarbeiten, als 10 Experten, von denen jeder nur mit einer Facette der Situation vertraut ist. Zudem ist die von einem einzelnen Geist produzierte Lösung – verglichen mit der von einem Komitee erarbeiteten – fast immer einfacher und wartungsfreundlicher.

In den meisten Ingenieursdisziplinen gleicht der Vorteil, ein Komitee, das an dem Problem arbeitet, die zusätzliche Reibung, die allein durch dessen Existenz entsteht, aus. In supply chain ist dies jedoch selten der Fall. Die End-to-End Konsistenz der Strategie, die als Produkt eines einzelnen Geistes – oder zumindest weniger – erzielt wird, übertrifft in der Regel die meisten ‚lokalen‘ Optimierungen, die ein Komitee zwangsläufig liefert. Die Abstimmung von Angebot und Nachfrage ist grundsätzlich eine systemische Herausforderung⁵.

Der Hauptnutzen des supply chain scientist liegt darin, auf Systemebene zu arbeiten und die gesamte supply chain zu erfassen, von den rohen elektronischen Aufzeichnungen bis hin zur von der Unternehmensführung entwickelten Strategie. Doch weit davon entfernt, ein Einzelgänger zu sein, erhält der Scientist viel Unterstützung. Die IT erleichtert den Zugang zu den relevanten Daten (ohne zu versuchen, die Daten vorzuverarbeiten). Der operative Bereich dokumentiert die bestehenden Prozesse, die operativen Einschränkungen und die verschiedenen Gemeinkosten. Das Marketing verdeutlicht die Opportunitätskosten, die nicht aus den Büchern der Buchhaltung ablesbar sind, z. B. stock-out Kosten. Das Top-Management kristallisiert die Vision, klärt, was überhaupt optimiert werden soll, usw.

Letztendlich sind supply chain decisions⁶ nicht das Produkt eines „Systems“, in dem die Verantwortung auf viele, oft Dutzende von Personen verteilt wird. Diese Entscheidungen, alle, sind das Ergebnis der numerischen Rezepte, die vom supply chain scientist, einem einzelnen Geist, implementiert wurden, der die volle Verantwortung für deren Leistung in Bezug auf das gesamte Unternehmen übernimmt. Diese Person ist fehlbar, aber sie erhält viel Unterstützung, einschließlich von Kollegen, die bereitstehen, falls die Notwendigkeit besteht. Meiner Erfahrung nach ist dies der einzige Weg, überhaupt damit zu beginnen, eine supply chain zu optimieren, selbst wenn ein größeres Komitee zwangsläufig alle Beobachter mit KPIs, Diagrammen und Berichten erdrückt, um das Gegenteil zu beweisen.