Den mest lärorika fallstudien i leveranskedjan jag känner till är inte en framgång. I juni 2017 slog NotPetya-skadeprogrammet till mot Maersk, och företaget fick bygga om cirka 4 000 servrar och 45 000 persondatorer på ungefär tio dagar, till en uppskattad kostnad av 250 till 300 miljoner dollar. Återhämtningen fungerade delvis för att en domänkontrollant i Ghana hade varit offline när attacken inträffade, och den överlevande kopian av katalogen gjorde ombyggnaden möjlig. Vi har täckt fullständigt Maersk-angrepp separat.
De flesta samlingar av fallstudier hoppar över den sortens detaljer. De beskriver ett företag som införde ett system och förbättrade en metrik, vilket är behaglig läsning och värdelös för planering. Fallen nedan är de jag faktiskt refererar till, valda eftersom vart och ett har ett publikt nummer kopplat och en grundorsak som man kan argumentera för.
Tio logistikfall med nummer kopplade
| Fall | År | Publicerad effekt | Grundorsak värd att studera |
|---|---|---|---|
| Maersk och NotPetya | 2017 | 250 till 300 miljoner dollar, 4 000 servrar återuppbyggda | Platt nätverk, en enda delad katalog, ingen offline-återställningskopia per design |
| Nike och i2 efterfrågeplanering | 2000 | Cirka 100 miljoner dollar i förlorad försäljning | Prognoser som litar på butikschefer som kunde se den faktiska efterfrågan |
| Hershey ERP go-live | 1999 | Cirka 150 miljoner dollar i outnyttjade beställningar | Big-bang-övergång planerad till högtrafiken runt Halloween |
| Lidl och SAP | 2018 | Cirka 500 miljoner euro skrivits av efter ungefär sju år | Kärninventeringsvärderingslogik anpassad snarare än antagen |
| MålkCanada | 2013 till 2015 | Marknadsutträde efter två år, förluster på cirka 2 miljarder dollar | Felaktiga masterdata i dimensioner och igensatta streckkoder blockerade distributionscentralerna |
| Ever Given i Suezkanalen | 2021 | 6 dagar på grund, omkring 400 fartyg i kö, försäkrade förluster uppskattas till över 2 miljarder dollar | Enskild felpunkt på en hårt trafikerad rutt, med lotsning i hög vind som den direkta orsaken |
| Toyota efter jordbävningen i Tohoku | 2011 | Databaser med flera nivåer som täcker hundratusentals delar | Siktbarhet på nivån "tier one" var aldrig begränsningen, det var nivån "tier four". |
| TradeLens | 2018 till 2022 | Stängdes ner efter 4 år trots 175 eller fler deltagare | Tekniken fungerade och operatörer anslöt sig, men skulle inte binda data till en konkurrents plattform |
| Ford-brist på halvledare | 2021 | Företaget guidade till cirka 2,5 miljarder dollar i påverkan | Inställda chipbeställningar 2020 kunde inte återaktiveras hur som helst |
| Amazon nätverksregionalisering | 2023 | Amerikanskt nätverk omorganiserat till regionala kluster | Att minska restiden slog ut att lägga till kapacitet |
Maersk 2017: fallet som ändrade mina frågor
NotPetya trängde sig in via en komprometterad uppdatering av ukrainsk skatteprogramvara och spred sig lateralt, krypterade maskiner snabbare än någon kunde reagera. Maersk förlorade bokningssystem, och terminalverksamheten i en stor del av deras nätverk blev manuell. Fartyg fortsatte att anlända eftersom fartyg inte stannar, vilket är den del som planerare underskattar: ett digitalt avbrott inom sjöfarten pausar inte det fysiska flödet, det tar bort din förmåga att veta vad flödet innehåller.
Två lärdomar överlever återberättandet. Återhämtningsförmågan avgjorde utgången mer än förebyggande gjorde, och återhämtningen berodde på en slump snarare än en design. När jag nu granskar kontinuitetsplaner är min första fråga inte längre om säkerhetskopior finns. Det är om någon har byggt upp en katalogtjänst från de säkerhetskopiorna inom ett testfönster, och hur lång tid det tog.
Hershey 1999 och Lidl 2018: samma misstag med tjugo års mellanrum
Hershey ersatte kärnsystemen med en samtidig övergång och nådde konfektyrindustrins högsäsong med en order-till-leveransprocess som ingen hade kört i stor skala. Cirka 150 miljoner dollar i ordrar kunde inte levereras, och kvartalets vinst sjönk kraftigt.
Lidl spenderade ungefär 7 år på ett lager- och merchandisingprogram innan de övergav det och skrev av cirka 500 miljoner euro. Den rapporterade tekniska stötestenen var trivial: Lidl värderade lager till inköpspris, standardprogramvara antog återförsäljningspris, och istället för att ändra affärspraxis ändrades programvaran i projektet. Anpassning i kärnan för värdering spreds sedan nedströms. Beslutet att stoppa var kommersiellt snarare än tekniskt, och togs när den återstående nyttan inte längre motiverade de utgifter som programmet fortfarande behövde.
Båda fallen argumenterar för samma disciplin. Planera bortkopplingen bort från högtrafik, och behandla varje begäran att anpassa en kärnberäkning som ett beslut som kommer att överleva de personer som fattar det.
Toyota 2011: synlighet på den nivå du inte kan se
Efter jordbävningen i mars 2011 upptäckte Toyota att deras exponering låg långt under deras direkta leverantörer, inom specialiserade kemikalier och komponenter där en enda anläggning betjänade en stor del av industrin. Svaret var en databas för leveranskedjan som kartlade delar och leverantörer flera nivåer djupt, vilket lät företaget svara på en fråga som de flesta tillverkare fortfarande inte kan: om den här staden översvämmas, vilka av mina fordon stannar.
Anledningen till att jag fortsätter att använda det här fallet är att det strider mot hur de flesta synlighetsprojekt är omfattade. Team köper verktyg som visar containerpositioner, vilket är logistikdata på nivå ett, medan risken som stoppar en produktionslinje finns fyra nivåer uppströms i en fabrik vars namn inte finns i något av deras system.
TradeLens: ett misslyckande som inte var tekniskt
TradeLens var en blockkedjeplattform för sjöfartsdokumentation, lanserad av Maersk tillsammans med IBM 2018 och avslutad 2022. Teknologin fungerade, och nätverket var inte heller tomt: över 175 organisationer anslöt sig, inklusive fem av de sex största containerrederierna. Det lades ändå ner. Att registrera sig och att engagera sig visade sig vara olika beslut, och konkurrerande rederier dirigerade aldrig tillräckligt med kommersiella data genom en plattform som ägdes av deras största konkurrent för att volymerna skulle fungera.
Detta är det fall man bör läsa innan ett branschövergripande datadelningsinitiativ. Det svåra problemet med delad insyn är styrning och ägande, inte kryptografi, och neutralitet måste vara strukturell snarare än utlovad. Kontrasten är DCSA spårningsstandarder, som operatörer accepterade eftersom ingen enskild konkurrent ägde dem.
Hur man läser en fallstudie utan att bli övertalad
De flesta publicerade fallstudier är marknadsföringsmaterial som producerats i samarbete med leverantören, vilket inte gör dem värdelösa men ändrar hur du bör läsa dem. Min checklista:
- **Hitta baslinjen.** Ett påstående om trettio procents förbättring betyder ingenting utan startvärdet och mätperioden.
- Kontrollera vem som publicerade det. Om mjukvaruleverantören skrev det, kommer feltyperna att saknas. Regulatoriska handlingar, domstolshandlingar och rapporter efter incidenter innehåller den detalj som pressmeddelanden tar bort.
- **Leta efter det kontrafaktiska.** Volymer, priser och efterfrågan rörde sig under perioden. Fråga vad som skulle ha hänt ändå.
- Föredra fall med datum och dollarbelopp. Allt som inte kan kopplas till ett kvartal och ett nummer är en anekdot i kostym.
- **Läs om misslyckanden först.** Framgångsrika projekt är varierande och svåra att kopiera. Misslyckanden upprepas, vilket gör dem mer prediktiva för vad som kommer att hända med ditt projekt.
- **Kontrollera nivån.** Fråga vilken nivå i kedjan som fallet faktiskt behandlar, eftersom de flesta hävdar att de täcker hela kedjan men bara levererar nivå ett.
Att använda dessa fall i ett affärscase
En fallstudie förtjänar sin plats i ett internt förslag när den etablerar ett antal som man annars skulle behöva gissa sig till. Maersk 2017 ger en försvarbar uppskattning av storleksordningen för ett totalt systemavbrott hos en stor logistikoperatör. Hershey och Lidl ger en prislapp på riskerna vid driftsättning. Ford visar 2021 vad det kan kosta att avbryta leverantörsåtaganden under en nedgång när efterfrågan återvänder snabbare än kapaciteten.
Vad ingen av dem kommer att göra är att bevisa att ett specifikt verktyg passar din verksamhet. Mönstret jag har sett fungera är smalare: välj de två fall vars felmetod mest liknar din egen svaghet, kvantifiera vad det felet skulle kosta i dina volymer och låt jämförelsen sätta budgeten. Det argumentet överlever granskning från en ekonomichef, vilket är mer än de flesta benchmark-presentationer klarar av.