L'étude de cas la plus instructive sur la chaîne d'approvisionnement que je connaisse n'est pas une réussite. En juin 2017, le malware NotPetya a atteint Maersk et l'entreprise a reconstruit environ 4 000 serveurs et 45 000 ordinateurs personnels en une dizaine de jours, pour un coût estimé entre 250 et 300 millions de dollars. La reprise a partiellement fonctionné parce qu'un contrôleur de domaine au Ghana avait été hors ligne lorsque l'attaque a frappé, et cette copie survivante de l'annuaire a rendu la reconstruction possible. Nous avons traité l'attaque Maersk en intégralité séparément.
La plupart des collections d'études de cas négligent ce genre de détail. Elles décrivent une entreprise qui a adopté un système et amélioré une métrique, ce qui est agréable à lire et inutile pour la planification. Les cas ci-dessous sont ceux que je cite réellement, choisis parce que chacun a un chiffre public associé et une cause profonde sur laquelle vous pouvez argumenter.
Dix études de cas de chaîne d'approvisionnement avec des numéros joints
| Cas | Année | Impact publié | Cause profonde qui mérite d'être étudiée |
|---|---|---|---|
| Maersk et NotPetya | 2017 | 250 à 300 millions de dollars, 4 000 serveurs reconstruits | Réseau plat, répertoire partagé unique, pas de copie de récupération hors ligne par conception |
| Nike et i2 planification de la demande | 2000 | Environ 100 millions de dollars de ventes perdues | Prévisions fiables par rapport aux directeurs de magasin qui pouvaient voir la demande réelle |
| Mise en production de Hershey ERP | 1999 | Environ 150 millions de dollars de commandes non livrées | Migration Big-bang prévue pendant le pic d'Halloween |
| Lidl et SAP | 2018 | Environ 500 millions d'euros passés par pertes et profits après environ sept ans | Logique de valorisation des stocks de base personnalisée plutôt qu'adoptée |
| Cible Canada | 2013 à 2015 | Sortie du marché après deux ans, pertes d'environ 2 milliards de dollars | Erreurs dans les données de référence des dimensions et des codes-barres ont bloqué les centres de distribution |
| Ever Given dans le Canal de Suez | 2021 | 6 jours échoué, environ 400 navires en attente, pertes assurées estimées à plus de 2 milliards de dollars | Point unique de défaillance sur une route très fréquentée, le pilotage par vent fort en étant la cause immédiate |
| Toyota après le tremblement de terre de Tohoku | 2011 | Base de données multi-niveaux couvrant des centaines de milliers de pièces | La visibilité de niveau un n'a jamais été la contrainte, c'était celle de niveau quatre |
| TradeLens | 2018 à 2022 | Fermé après 4 ans malgré 175 participants ou plus | La technologie a fonctionné et les transporteurs ont adhéré, mais n'ont pas voulu s'engager à fournir des données sur la plateforme d'un concurrent. |
| Pénurie de semi-conducteurs chez Ford | 2021 | L'entreprise vise environ 2,5 milliards de dollars d'impact | Les commandes de puces annulées en 2020 n'ont pas pu être rétablies à volonté. |
| Amazon réseau régionalisation | 2023 | Réseau des États-Unis réorganisé en clusters régionaux | Réduire la distance parcourue vaut mieux qu'augmenter la capacité |
Maersk 2017 : le cas qui a changé mes questions
NotPetya est entré par une mise à jour compromise d'un logiciel fiscal ukrainien et s'est propagé latéralement, chiffrant les machines plus vite que quiconque ne pouvait réagir. Maersk a perdu ses systèmes de réservation, et les opérations des terminaux sur une grande partie de son réseau sont passées au manuel. Les navires continuaient d'arriver car les navires ne s'arrêtent pas, ce qui est la partie que les planificateurs sous-estiment : une panne numérique dans le transport maritime ne suspend pas le flux physique, elle supprime votre capacité à savoir ce que contient ce flux.
Deux leçons survivent à la relecture. La capacité de récupération a décidé de l'issue plus que la prévention, et la récupération dépendait d'un accident plutôt que d'une conception. Lorsque j'examine les plans de continuité maintenant, ma première question n'est plus de savoir si des sauvegardes existent. C'est de savoir si quelqu'un a reconstruit un service d'annuaire à partir de ces sauvegardes dans une fenêtre de test, et combien de temps cela a pris.
Hershey 1999 et Lidl 2018 : la même erreur à vingt ans d'intervalle
Hershey a remplacé ses systèmes essentiels par une mise en production simultanée et a abordé la saison de pointe de l'industrie de la confiserie avec un processus de commande à livraison que personne n'avait encore exécuté à grande échelle. Environ 150 millions de dollars de commandes n'ont pas pu être expédiées, et le bénéfice du trimestre a chuté de manière spectaculaire.
Lidl a passé environ 7 ans sur un programme d'inventaire et de merchandising avant de l'abandonner et de passer en pertes près de 500 millions d'euros. Le point de blocage technique rapporté était banal : Lidl évaluait le stock au prix d'achat, les logiciels standards supposaient le prix de détail, et plutôt que de modifier la pratique commerciale, le projet a modifié le logiciel. La personnalisation au cœur de l'évaluation s'est ensuite propagée en aval. La décision d'arrêter était commerciale plutôt que technique, prise une fois que le bénéfice restant ne justifiait plus les dépenses que le programme nécessitait encore.
Les deux cas plaident pour la même discipline. Séquencez la transition loin des périodes de pointe, et considérez chaque demande de personnalisation d'un calcul central comme une décision qui survivra aux personnes qui la prennent.
Toyota 2011 : visibilité au niveau que vous ne pouvez pas voir
Après le tremblement de terre de mars 2011, Toyota a découvert que son exposition était bien en deçà de celle de ses fournisseurs directs, dans les produits chimiques et composants spécialisés où une seule usine desservait une grande partie de l'industrie. La réponse a été une base de données de la chaîne d'approvisionnement cartographiant les pièces et les fournisseurs sur plusieurs niveaux, ce qui a permis à l'entreprise de répondre à une question que la plupart des fabricants ne peuvent toujours pas : si cette ville est inondée, quels de mes véhicules s'arrêtent.
La raison pour laquelle je continue d'utiliser ce cas est qu'il contredit la manière dont la plupart des projets de visibilité sont définis. Les équipes achètent des outils qui montrent les positions des conteneurs, ce qui constitue des données logistiques de premier niveau, tandis que le risque qui arrête une ligne de production se situe quatre niveaux en amont, dans une usine dont le nom n'apparaît dans aucun de leurs systèmes.
TradeLens : un échec qui n'était pas technique
TradeLens était une plateforme blockchain pour la documentation maritime, lancée par Maersk avec IBM en 2018 et arrêtée en 2022. La technologie fonctionnait, et le réseau n'était pas vide non plus : plus de 175 organisations l'ont rejoint, dont cinq des six plus grands transporteurs de conteneurs. Il a néanmoins fermé. L'inscription et l'engagement se sont avérés être des décisions différentes, et les transporteurs concurrents n'ont jamais acheminé suffisamment de données commerciales via une plateforme appartenant à leur plus grand concurrent pour que les volumes soient rentables.
C'est le cas à considérer avant toute initiative de partage de données à l'échelle de l'industrie. Le problème majeur de la visibilité partagée est la gouvernance et la propriété, pas la cryptographie, et la neutralité doit être structurelle plutôt que promise. Le contraste est l'Normes DCSA de suivi et de traçabilité, que les transporteurs ont adopté car aucun concurrent unique ne les possédait.
Comment lire une étude de cas sans se faire vendre quelque chose
La plupart des études de cas publiées sont du matériel marketing produit avec la coopération du fournisseur, ce qui ne les rend pas sans valeur mais change la façon dont vous devriez les lire. Ma checklist :
- Trouvez la référence. Une affirmation de trente pour cent d'amélioration ne signifie rien sans le chiffre de départ et la fenêtre de mesure.
- Vérifiez qui l'a publié. Si c'est le fournisseur du logiciel qui l'a écrit, les modes de défaillance seront absents. Les dépôts réglementaires, les documents judiciaires et les rapports post-incident contiennent les détails que les communiqués de presse omettent.
- Cherchez le contre-factuel. Les volumes, les prix et la demande ont tous évolué pendant la période. Demandez ce qui se serait passé de toute façon.
- **Privilégiez les cas avec des dates et des chiffres en dollars.** Tout ce qui ne peut être rattaché à un trimestre et à un montant est une anecdote en costume.
- **Lisez d'abord les échecs.** Les projets réussis sont divers et difficiles à copier. Les échecs se répètent, ce qui les rend plus prédictifs de ce qui arrivera au vôtre.
- Vérifiez le niveau. Demandez quel niveau de la chaîne le cas concerne réellement, car la plupart revendiquent une portée de bout en bout et livrent une portée de niveau un.
Utiliser ces cas dans une étude de cas
Une étude de cas mérite sa place dans une proposition interne lorsqu'elle établit un chiffre que vous devriez autrement deviner. Maersk 2017 donne un ordre de grandeur défendable pour une panne système totale chez un grand opérateur logistique. Hershey et Lidl donnent un prix au risque de mise en service. Ford en 2021 montre ce qu'il peut en coûter d'annuler des engagements fournisseurs pendant un ralentissement lorsque la demande revient plus vite que la capacité.
Ce qu'aucun d'entre eux ne fera, c'est prouver qu'un outil spécifique convient à votre opération. Le schéma que j'ai vu fonctionner est plus étroit : choisissez les deux cas dont le mode de défaillance ressemble le plus à votre propre point faible, quantifiez ce que cette défaillance coûterait dans vos volumes, et laissez la comparaison fixer le budget. Cet argument résiste à l'examen d'un directeur financier, ce qui est plus que ce que la plupart des présentations de benchmarks ne parviennent à faire.