Die lehrreichste Fallstudie über Lieferketten, die ich kenne, ist kein Erfolg. Im Juni 2017 erreichte die NotPetya-Malware Maersk und das Unternehmen baute in etwa zehn Tagen rund 4.000 Server und 45.000 PCs neu auf, was schätzungsweise 250 bis 300 Millionen Dollar kostete. Die Wiederherstellung funktionierte teilweise, weil ein Domain Controller in Ghana zum Zeitpunkt des Angriffs offline war und diese überlebende Kopie des Verzeichnisses den Wiederaufbau ermöglichte. Wir haben Der Maersk-Angriff in voller Länge separat behandelt.
Die meisten Sammlungen von Fallstudien lassen solche Details aus. Sie beschreiben ein Unternehmen, das ein System eingeführt hat und eine Kennzahl verbessert hat, was angenehm zu lesen ist und für die Planung nutzlos ist. Die unten aufgeführten Fälle sind diejenigen, die ich tatsächlich zitiere, ausgewählt, weil jeder eine öffentliche Zahl und eine Ursachenanalyse hat, über die man streiten kann.
Zehn Supply-Chain-Fälle mit angehängten Nummern
| Fall | Jahr | Veröffentlichte Auswirkung | Ursachenforschung ist lohnenswert |
|---|---|---|---|
| Maersk und NotPetya | 2017 | 250 bis 300 Millionen Dollar, 4.000 Server neu aufgebaut | Flaches Netzwerk, einzelnes gemeinsames Verzeichnis, aus Designgründen keine Offline-Wiederherstellungskopie |
| Nike und i2 Demand Planning | 2000 | Rund 100 Millionen Dollar an entgangenen Umsätzen | Prognosen werden eher den Filialleitern vertraut, die die tatsächliche Nachfrage sehen konnten |
| Hershey ERP Go-Live | 1999 | Rund 150 Millionen Dollar an nicht gelieferten Bestellungen | Big-Bang-Umstellung geplant für den Halloween-Höhepunkt |
| Lidl und SAP | 2018 | Rund 500 Millionen Euro nach rund sieben Jahren abgeschrieben | Kerninventurbewertungslogik angepasst statt übernommen |
| Kanada ansteuern | 2013 bis 2015 | Marktaustritt nach zwei Jahren, Verluste von rund 2 Milliarden Dollar | Stammdatenfehler in Dimensionen und blockierte Barcodes in den Distributionszentren |
| Ever Given in der Sueskanal | 2021 | 6 Tage auf Grund, etwa 400 Schiffe in der Warteschlange, versicherte Verluste geschätzt über 2 Milliarden Dollar | Single Point of Failure auf einer stark frequentierten Route, mit Lotsenführung bei starkem Wind als unmittelbare Ursache |
| Toyota nach dem Tohoku-Erdbeben | 2011 | Mehrstufige Datenbank für hunderttausende von Teilen | Tier-one-Sichtbarkeit war nie die Einschränkung, Tier-vier war es |
| TradeLens | 2018 bis 2022 | Nach 4 Jahren trotz 175 oder mehr Teilnehmern eingestellt | Die Technologie funktionierte und die Anbieter schlossen sich an, doch sie würden keine Daten auf der Plattform eines Konkurrenten preisgeben |
| Halbleitermangel bei Ford | 2021 | Unternehmen prognostiziert rund 2,5 Milliarden US-Dollar an Auswirkungen | Abgesagte Chipbestellungen aus dem Jahr 2020 konnten nicht nach Belieben wieder aufgenommen werden |
| Amazon Netzwerkregionalisierung | 2023 | Vereinigte Staaten Netzwerk in regionale Cluster umorganisiert | Reduzierung der zurückgelegten Strecke schlägt die Erhöhung der Kapazität |
Maersk 2017: der Fall, der meine Fragen veränderte
NotPetya gelangte über ein kompromittiertes Update der ukrainischen Steuersoftware ins System und verbreitete sich lateral, wobei es Maschinen schneller verschlüsselte, als jemand reagieren konnte. Maersk verlor seine Buchungssysteme und der Terminalbetrieb in einem großen Teil seines Netzwerks wurde manuell abgewickelt. Schiffe kamen weiterhin an, weil Schiffe nicht anhalten, und das ist der Teil, den Planer unterschätzen: Eine digitale Störung in der Schifffahrt stoppt nicht den physischen Fluss, sie raubt Ihnen die Fähigkeit zu wissen, was dieser Fluss enthält.
Zwei Lehren haben die Nacherzählung überdauert. Die Wiederherstellungsfähigkeit entschied mehr über den Ausgang als die Prävention, und die Wiederherstellung hing von einem Zufall ab und nicht von einem Design. Wenn ich jetzt Notfallpläne überprüfe, ist meine erste Frage nicht mehr, ob Backups existieren. Sie ist, ob jemand einen Verzeichnisdienst aus diesen Backups innerhalb eines Testfensters wiederhergestellt hat und wie lange das gedauert hat.
Hershey 1999 und Lidl 2018: der gleiche Fehler im Abstand von zwanzig Jahren
Hershey ersetzte Kernsysteme mit einem gleichzeitigen Umstellungsprozess und traf auf die Stoßzeit der Süßwarenindustrie mit einem Bestell-zu-Liefer-Prozess, den niemand in dieser Größenordnung zuvor durchgeführt hatte. Ungefähr 150 Millionen Dollar an Bestellungen konnten nicht ausgeliefert werden, und der Gewinn des Quartals fiel stark.
Lidl investierte etwa 7 Jahre in ein Inventur- und Warenwirtschaftsprogramm, bevor es aufgegeben und ein Schaden von rund 500 Millionen Euro verbucht wurde. Der gemeldete technische Hinderungsgrund war banal: Lidl bewertete den Lagerbestand zum Einkaufspreis, Standardsoftware ging vom Verkaufspreis aus, und anstatt die Geschäftspraxis zu ändern, änderte das Projekt die Software. Die Anpassung im Bewertungskern breitete sich dann nachgelagert aus. Die Entscheidung zum Abbruch war kommerzieller Natur und nicht technisch, getroffen, als der verbleibende Nutzen die noch benötigten Ausgaben des Programms nicht mehr rechtfertigte.
Beide Fälle plädieren für die gleiche Vorgehensweise. Verschieben Sie die Umstellung weg von der Spitzenzeit und betrachten Sie jede Anfrage zur Anpassung einer Kernberechnung als eine Entscheidung, die die Personen, die sie treffen, überdauern wird.
Toyota 2011: Sichtbarkeit auf der Ebene, die Sie nicht sehen können
Nach dem Erdbeben im März 2011 stellte Toyota fest, dass seine Abhängigkeiten weit unterhalb seiner direkten Zulieferer lagen, in spezialisierten Chemikalien und Komponenten, wo ein einzelnes Werk die gesamte Branche versorgte. Die Reaktion war eine Lieferkettendatenbank, die Teile und Zulieferer mehrere Ebenen tief abbildete und es dem Unternehmen ermöglichte, eine Frage zu beantworten, die die meisten Hersteller immer noch nicht beantworten können: Wenn diese Stadt überschwemmt wird, welche meiner Fahrzeuge stehen still.
Der Grund, warum ich diesen Fall immer wieder verwende, ist, dass er im Widerspruch dazu steht, wie die meisten Sichtbarkeitsprojekte konzipiert sind. Teams kaufen Werkzeuge, die Containerpositionen anzeigen, was Logistikdaten der ersten Ebene sind, während das Risiko, das eine Produktionslinie stoppt, vier Ebenen weiter stromaufwärts in einer Fabrik liegt, deren Name in keinem ihrer Systeme aufgeführt ist.
TradeLens: ein Fehlschlag, der nicht technischer Natur war
TradeLens war eine Blockchain-Plattform für Schiffsdokumente, die 2018 von Maersk und IBM gestartet und 2018 eingestellt wurde. Die Technologie funktionierte, und auch das Netzwerk war nicht leer: mehr als 175 Organisationen schlossen sich an, darunter fünf der sechs größten Containerreedereien. Dennoch wurde es eingestellt. Die Anmeldung und das Engagement erwiesen sich als unterschiedliche Entscheidungen, und konkurrierende Reedereien leiteten nie genügend kommerzielle Daten über eine Plattform, die ihrem größten Konkurrenten gehörte, um die Volumina rentabel zu machen.
Dies ist der Fall, der vor jeder branchenweiten Initiative zum Datenaustausch gelesen werden sollte. Das schwierige Problem bei gemeinsamer Transparenz ist die Steuerung und das Eigentum, nicht die Kryptografie, und Neutralität muss strukturell und nicht nur versprochen sein. Der Kontrast dazu ist DCSA Track-and-Trace-Standards, das von den Carriern übernommen wurde, weil kein einzelner Wettbewerber es besaß.
Wie man eine Fallstudie liest, ohne sich etwas verkaufen zu lassen
Die meisten veröffentlichten Fallstudien sind Marketingmaterial, das mit der Zusammenarbeit des Anbieters erstellt wurde, was sie nicht wertlos macht, aber die Art und Weise, wie Sie sie lesen sollten, verändert. Meine Checkliste:
- Finden Sie die Ausgangsbasis. Eine Behauptung von dreißig Prozent Verbesserung bedeutet nichts ohne die Ausgangszahl und das Messfenster.
- **Überprüfen Sie, wer es veröffentlicht hat.** Wenn der Softwarelieferant es geschrieben hat, fehlen die Ausfallmodi. Zulassungsanträge, Gerichtsunterlagen und Berichte nach Vorfällen enthalten die Details, die Pressemitteilungen weglassen.
- **Suchen Sie nach dem Kontrafaktischen.** Volumen, Preise und Nachfrage bewegten sich alle während des Zeitraums. Fragen Sie, was ohnehin passiert wäre.
- **Bevorzugen Sie Fälle mit Daten und Dollarbeträgen.** Alles, was nicht an ein Quartal und eine Zahl gebunden werden kann, ist eine Anekdote im Anzug.
- **Lesen Sie zuerst die Misserfolge.** Erfolgreiche Projekte sind vielfältig und schwer zu kopieren. Misserfolge wiederholen sich, was sie zu besseren Vorhersagen dafür macht, was mit Ihrem Projekt passieren wird.
- **Überprüfen Sie die Stufe.** Fragen Sie, welche Stufe der Kette der Fall tatsächlich behandelt, da die meisten einen End-to-End-Umfang beanspruchen und einen Stufe-Eins-Umfang liefern.
Diese Fälle in einem Business Case verwenden
Eine Fallstudie verdient ihren Platz in einem internen Vorschlag, wenn sie eine Zahl belegt, die man sonst erraten müsste. Maersk 2017 liefert eine begründbare Größenordnung für einen vollständigen Systemausfall bei einem großen Logistikbetreiber. Hershey und Lidl geben dem Go-live-Risiko einen Preis. Ford zeigt 2021, was die Streichung von Lieferantenverpflichtungen in einer Rezession kosten kann, wenn die Nachfrage schneller zurückkehrt als die Kapazität.
Was keiner von ihnen tun wird, ist zu beweisen, dass ein bestimmtes Werkzeug für Ihren Betrieb geeignet ist. Das Muster, das ich beobachtet habe, ist enger gefasst: Wählen Sie die beiden Fälle aus, deren Ausfallmodus Ihrem eigenen Schwachpunkt am ähnlichsten ist, quantifizieren Sie, was dieser Ausfall bei Ihren Mengen kosten würde, und lassen Sie den Vergleich das Budget festlegen. Dieses Argument hält einer Prüfung durch einen Finanzdirektor stand, was die meisten Benchmark-Decks nicht schaffen.