2011年春天，西雅图的一位亚马逊采购经理坐在电脑前，盯着面前长长的Excel数据发呆。
他需要为1200多个商品决定何时订货、订多少、分配到哪些仓库，还要把滞销的商品调拨到畅销的仓库去。但一天只有24小时。即使工作12小时，平均每个SKU只有35秒。
所以他做了每个理性人都会做的事：放弃尾部，聚焦头部。把80%时间花在200多个畅销品上，剩下1,000多个产品只能靠简单规则进行批量化操作："库存低于安全线就补货，补多少？补到考核的库存周转要求吧"。
这么简单粗暴的决策，不是能力问题，而是复杂度超越人类认知极限的结构性问题。
当杰夫·贝索斯2011年批准启动"Hands off the Wheel"项目时，他看到的正是这个临界点。如果一个人管理1,000个SKU就已经捉襟见肘，当产品目录增长到1,000万时怎么办？招聘1万个采销人员？管理成本会指数级爆炸。
"Hands off the Wheel（HOTW）"项目的目标从一开始就不是"辅助人类"，而是让机器接管决策。
这听起来可能有些极端，但理由很简单：当决策的复杂度超越人类认知极限时，人类的参与不是帮助，而是瓶颈。如果你保留一个"人工审核"环节，那么系统的速度就被限制在人类的处理速度；如果你允许人工"调整"算法的建议，那么系统的一致性就被破坏了，全局优化也就不复存在。
这个转变有多难？它不仅需要技术突破，更需要组织勇气、文化转型和心理革命。这正是接下来十年间，亚马逊将要经历的三次深刻跃迁的起点。
第一次跃迁：
从Excel到算法的权力转移
HOTW项目的Phase I（2011-2013）面临的最大障碍不是技术，而是信任。
在此之前，供应链决策主要依赖人工判断和Excel表格。采购经理会查看历史销售数据，考虑即将到来的促销活动，评估供应商的交货时间，然后在Excel里计算一个"感觉合适"的订货量。这个过程可能需要几个小时，但采购经理对结果有掌控感: 他们知道每个数字从哪里来，为什么是这个值。
现在，算法给出了一个完全不同的建议。它考虑了需求分布的不确定性、提前期的波动性、缺货的长期影响、残值处理的成本。最终的数字可能比人工判断高30%，或者低40%。
而算法不会解释为什么，至少在早期版本中不会。
这制造了一个心理障碍：采购经理看着这个数字，本能地想要"调整"它，因为它"感觉不对"。但SCOT团队（SCOT介绍）坚持的原则是：要么完全信任算法，要么不要使用它。因为一旦允许人工干预，你就永远无法通过对比实验证明算法是否真的更优。
这场信任危机的解决方案不是更多的技术文档，而是让数据说话。
团队设计了严格的A/B测试：一部分产品使用算法决策，另一部分保持人工决策，然后在数周后比较结果。对比的指标不是"订货量是否接近人工判断"，而是最终的客户结果：缺货率、库存周转天数、总体成本、客户满意度。
结果是令人信服的。算法管理的产品类别在降低缺货率的同时，库存持有成本也更低。这看似矛盾，更少的缺货意味着更多的安全库存，怎么可能成本更低？答案在于优化目标的不同。
人工决策优化的是"安全感"，采购经理倾向于保守，宁可多备货也不愿承担缺货的责任。算法优化的是"长期客户价值减去总成本"，它精确计算了缺货造成的客户流失成本和库存积压的持有成本，找到了真正的平衡点。
但即便有了数据证明，完全放手仍然需要组织勇气。Phase I最大的成就不是开发出了预测模型和采购算法，而是成功移除了人工干预环节。到2013年底，绝大多数采购决策已经由算法自动执行，人类只在异常情况下介入。
第二次跃迁：
当工程师变成业务负责人
如果说Phase I是技术的胜利，那么Phase II（2014-2016）则是一场组织革命。
当系统达到高度自动化后，一个新问题浮现了：谁对结果负责？
在传统的组织架构中，界限是清晰的：工程团队负责构建系统，业务团队负责运营业务。工程师的KPI是系统的稳定性、响应速度、准确性；业务经理的KPI是销售额、成本、客户满意度。
但当系统开始做所有决策时，这个界限变得模糊了。
如果某个产品类别出现了缺货问题，这是算法的bug，还是市场环境的变化？如果库存周转率下降了，是模型需要调整，还是业务策略需要改变？
SCOT团队的领导层意识到，当你把决策权交给了系统，你就必须对业务结果负责。不能再说"我的系统运行正常"，而是要问"业务表现如何"。
这促成了一个深刻的角色转变。SCOT不再是一个技术支持团队，而是业务的实际运营者。这意味着：
工程师需要像业务经理一样思考。他们不仅要懂算法，还要理解市场动态、竞争格局、客户行为。当算法建议减少某个产品的库存时，工程师需要判断：这是因为需求真的在下降，还是因为竞争对手降价导致的短期波动？如果是后者，正确的反应可能不是减少库存，而是调整定价策略。
这种判断需要的不是更好的模型，而是商业洞察力。这正是Phase II要培养的核心能力。
团队内部开始建立一套新的工作机制。每周的例会不再聚焦技术指标（如模型准确率、系统延迟），而是聚焦业务指标（如各品类的销售趋势、库存健康度、客户体验得分）。工程师被要求对业务数据异常提出解释，并主动提出改进建议。
更重要的是，团队培养了一种"有观点"的文化。不是被动地响应业务部门的需求，而是主动地对未来趋势形成判断，并提前调整系统。例如，如果数据显示某个新品类开始流行，SCOT不会等到销售部门提出增加库存的请求，而是主动预测需求的增长曲线，调整采购和配置策略。
但这种主动性也带来了新的挑战：如何在保持自动化的同时，又不失去对业务变化的敏感性？
Phase II的另一个关键机制是持续的系统审计。不是年度审计，而是每天、每周的深度检查。团队会随机抽取一些"看起来奇怪"的决策，追溯其原因。有时候答案是合理的，系统捕捉到了人类忽略的信号；有时候答案揭示了模型的盲点，需要改进。
这种审计不是为了推翻算法的决策，而是为了理解系统的思维方式。久而久之，团队对系统的行为模式有了直觉，能够更快地识别真正的异常。
到2016年，SCOT已经实现了一个重要的转变：团队不再是"管理自动化系统的工程师"，而是"通过自动化系统运营业务的管理者"。
第三次跃迁：
在高速公路上换引擎
2017年，亚马逊的供应链网络已经高度自动化，每天处理数千万订单。就在这时，业务提出了一个近乎不可能的要求：我们需要支持Prime One-Day（一日达），以及Prime Now（两小时达）。
这不是简单的"加快速度"，而是对整个供应链逻辑的颠覆。
传统的供应链是为"全国性需求"优化的：把热门商品分散到各个区域仓库，然后通过标准化的两日达或三日达服务覆盖全国。但两小时达意味着超本地化：每个城市需要一个专门的小型仓库，库存必须精确匹配该城市的独特需求结构。
问题是，你不能关闭现有系统去重新设计。就像一个飞行员不能在飞行途中更换引擎一样，亚马逊不能停止服务数千万客户去重构供应链系统。
这就是Phase III（2017至今）的核心挑战：颠覆性创新必须在运营的系统上进行。
团队面临的第一个问题是：如何在已经全局优化的网络中，插入一个全新的"本地化"层级？
"这一次，我们连可以参考的教科书都没有了。"当时的团队负责人道出了Phase III创新的本质：你不是在优化一个已知问题，而是在定义一个新问题。
团队的解决方案是开发一套全新的多层级库存优化系统。这个系统要同时考虑：
国际供应商通过海运到达的长周期库存（几周到几个月）
国内供应商的短周期补货（几天到几周）
区域性的大型FC存储（服务全国或大区域）
本地化的SSD仓库（服务单个城市）
以及FBA卖家的数千万件商品（完全不受控制）
所有这些层级必须协同优化，因为它们共享容量、共享运输网络、面对相互影响的需求。
当系统达到高度复杂时，优化不再是纯粹的数学问题，而是需要人类判断力的艺术。你无法通过A/B测试证明一个需要数月才能稳定的新系统是否更优；你无法用历史数据预测一个全新业务模式的表现。这时候，经验、直觉、对业务的深刻理解变得至关重要。
这似乎与"完全自动化"的理念相矛盾，如果最终还是需要人类判断，那自动化的意义何在？
答案在于决策的层次。Phase III的团队不再做"订多少货、从哪发货"这样的执行层决策。这些仍然由算法完成。他们做的是系统设计和战略调整的决策：我们应该优化什么目标？如何权衡全局效率和本地响应性？在资源有限的情况下，哪些市场应该优先获得两小时达服务？
这是一种更高层次的控制。人类从执行者变成了架构师，从操作员变成了指挥家。
Amazon不是在"自动化现有的人工流程"，而是在创造一种新的决策范式。一种只有在算法时代才可能存在的决策方式。
尾声
十多年前，亚马逊SCOT团队面对一个看似简单的问题：明天该订多少货？
今天，他们运营着全球最复杂的自动化供应链网络，每天为数千万客户做出数亿个决策。
这个故事给所有企业的启示不是"你应该复制Amazon的系统"，你无法也不应该复制。而是：
你愿意放手吗？ 愿意把决策权交给算法，相信数据而非直觉？
你愿意挑战自己的成功吗？ 在系统运行良好时仍主动寻找下一个突破点？
你愿意重新定义人的角色吗？ 从控制者变为设计者，从执行者变为创新者？
如果答案是肯定的，那么你的自动化的旅程即将开始。
而这个旅程的终点，永远在明天。
It's still Day 1.
END
e-works
近期活动预告长按下方二维码
即可快速在线报名↓
