我所知道的最具启发性的供应链案例研究并非一个成功的案例。2017年6月，NotPetya恶意软件袭击了马士基公司，该公司在大约十天内重建了约4,000台服务器和45,000台个人电脑，估计成本为2.5亿至3亿美元。此次恢复部分成功的原因是，在攻击发生时，加纳的一台域控制器处于离线状态，而该域控制器幸存的目录副本使得重建成为可能。我们另外单独报道了马士基袭击事件全文。
大多数案例研究集都跳过了这类细节。它们描述了一家公司采用了一个系统并改进了一项指标，这样的阅读令人愉快但对规划毫无用处。下面的案例是我实际引用的，之所以选择它们是因为每个案例都有公开的数字和可供争论的根本原因。
十个带有编号的供应链案例
| 案例 | 年份 | 已发布的影响 | 值得研究的根本原因 |
|---|---|---|---|
| 马士基和NotPetya | 2017 | 2.5亿至3亿美元，4000台服务器重建 | 扁平化网络，单个共享目录，按设计无离线恢复副本 |
| 耐克和 i2 需求计划 | 2000 | 约一亿美元的销售损失 | 预测结果比能够看到实际需求的商店经理更值得信赖 |
| 赫尔希企业资源规划系统上线 | 1999 | 约有 1.5 亿美元的订单未交付 | 大爆炸式上线计划在万圣节高峰期进行 |
| Lidl 和 SAP | 2018 | 约七年后，约五亿欧元被注销 | 核心库存估值逻辑已定制，而非采纳 |
| 目标加拿大 | 2013年至2015年 | 两年后退出市场，亏损约20亿美元 | 维度中的主数据错误和条形码导致配送中心瘫痪 |
| 长赐号在 苏伊士运河 | 2021 | 搁浅 6 天，约 400 艘船只排队等候，预计保险损失超过 20 亿美元 | 关键线路上的单点故障，由强风下的引航操作导致 |
| 丰田在东日本大地震之后 | 2011 | 覆盖数十万个零件的多层数据库 | 一级可见性从来不是限制，四级可见性才是。 |
| TradeLens | 2018年至2022年 | 四年后关闭，尽管有175人或更多参与者 | 技术可行，运营商也加入了，但他们不愿意将数据提交给竞争对手的平台。 |
| 福特汽车的半导体短缺 | 2021 | 公司预计将产生约25亿美元的影响 | 2020年取消的芯片订单不能随意恢复 |
| 亚马逊网络区域化 | 2023 | 美国网络重组为区域集群 | 减少行程比增加运力更好 |
马士基 2017：改变我提问方式的案例
NotPetya 通过对乌克兰税务软件的受损更新进入，并横向传播，加密机器的速度之快，以至于没有人能够做出反应。马士基丢失了预订系统，其网络大部分地区的码头运营转为手动。船只仍在抵达，因为船只不会停下，这是规划者低估的部分：航运业的数字中断不会暂停物理流动，而是会剥夺你了解这些流动内容的能力。
只有两个教训得以保留。恢复能力比预防能力更能决定结果，而恢复又依赖于意外而不是设计。现在我审查连续性计划时，我的第一个问题不再是是否有备份。而是任何人是否能在测试窗口内从这些备份中重建目录服务，以及花费了多长时间。
好时1999年与利德尔2018年：二十年间犯了同样的错误
好时公司在一次性切换中替换了核心系统，并在糖果行业的旺季推出了一个此前无人批量运行过的订单交付流程。大约有 1.5 亿美元的订单未能发货，该季度的利润急剧下降。
Lidl 在一项库存和商品化项目上投入了大约 7 年时间，之后放弃了该项目，并进行了约 5 亿欧元的注销。据报道，技术上的症结很普通：Lidl 以采购价为库存估值，而标准软件则以零售价为准，与其改变业务实践，不如改变软件。然后，估值核心的定制化向下游传播。停止的决定是商业性的而非技术性的，一旦剩余的收益不再能证明该项目仍需要的支出是合理的，就做出了这一决定。
两种情况都主张同样的原则。将上线时间安排在非高峰期，并将每一次定制核心计算的请求视为一项将超越决策者本身的决定。
丰田 2011：您看不到的档位可见性
2011年3月地震后，丰田发现其暴露程度远低于其直接供应商，在专门的化学品和零部件领域，一个工厂服务于整个行业。对此，丰田建立了一个供应链数据库，绘制了多层级的零部件和供应商，使公司能够回答大多数制造商仍然无法回答的问题：如果这个城镇被洪水淹没，我的哪些车辆会停产。
我一直使用这个案例是因为它与大多数可视化项目的范围界定方式相反。团队购买能够显示集装箱位置的工具，这是第一层级的物流数据，而导致生产线停产的风险却存在于工厂上游四个层级，而这家工厂的名字却不在任何他们的系统中。
TradeLens：一场非技术性的失败
TradeLens 是一个用于海运单证的区块链平台，由马士基与 IBM 于 2018 年推出，并于 2022 年停用。该技术是可行的，网络也不乏参与者：超过 175 家组织加入了该平台，其中包括六大集装箱航运公司中的五家。但它最终还是失败了。注册和承诺是不同的决定，竞争对手的航运公司从未通过他们最大竞争对手拥有的平台路由足够多的商业数据来达到规模效益。
这是任何行业范围的数据共享计划之前都应阅读的案例。共享可见性中的难题在于治理和所有权，而不是密码学，并且中立性必须是结构性的，而不是承诺的。与之形成对比的是 DCSA 追踪和追踪标准，运营商之所以采用它，是因为没有哪个单一的竞争对手拥有它。
如何阅读案例研究而不被“推销”
大多数已发表的案例研究都是在供应商的合作下制作的营销材料，这并非使其毫无价值，而是改变了您阅读它们的方式。我的清单：
- 找出基准。 如果没有起始数据和测量窗口，百分之三十的改进就毫无意义。
- 检查谁发布的。如果软件供应商写的，就会缺少故障模式。监管申报、法庭文件和事后报告会保留新闻稿所省略的细节。
- **寻找反事实。** 销量、价格和需求都在这段时期内发生了变化。问问原本会发生什么。
- 优先选择包含日期和金额的案例。 任何无法确定到季度和具体数字的内容，都只能算是经过包装的轶事。
- 先阅读失败的案例。成功的项目多种多样，难以复制。失败的项目却会反复出现，这使得它们更能预测你的项目将会发生什么。
- 检查层级。 询问案件实际处理的是链条的哪个层级，因为大多数声称是端到端的范围，但实际只实现了第一层级的范围。
在商业案例中使用这些案例
案例研究在内部提案中占有一席之地，当它能够提供一个否则需要猜测的数字时。马士基 2017 年的案例为大型物流运营商发生全面系统故障提供了可信的数量级估计。好时和利德尔的案例为上线风险定价。福特公司 2021 年的案例表明，在经济低迷时期取消供应商承诺，在需求比产能恢复得更快时会付出多大的代价。
他们都不会做的是证明某个特定工具适合你的业务。我观察到有效的模式更为狭窄：选择两种失败模式最接近你自身薄弱环节的案例，量化在你的业务量下这种失败的成本，然后让比较结果来确定预算。这种论证能够经受住财务总监的审查，而这比大多数基准报告所能做到的要多。