上线第一周：war room 该准备什么

我见过最惨的一次 WMS 上线：go-live 当天中午，拣选员的 RF 枪扫不出任务单，仓库 40 多个人站在货架前面干瞪眼。老板在办公室拍桌子，IT 在会议室里互相甩锅——因为从头到尾，没人规定这种时候该谁说话、该听谁的。

那次之后我学乖了：系统上线第一周，仓库里必须有一个 war room。它不是会议室，是战时指挥部。谁在里面、带什么工具、按什么节奏打仗，上线前就要定死。下面这套，是我这几年带上线项目总结出来的，拿去就能用。

我见过的三次翻车，都是栽在"没人说了算"

先讲三个真实教训，你就知道 war room 为什么不能省。

第一次：面单纸。 上线第二天上午，打印机集体罢工——不是系统 bug，是面单纸用完了。行政按老系统的用量备的货，新系统打印格式变了，耗材消耗翻倍。仓库 30 个人等了一上午，等快递把纸送来。war room 清单里从此多了一条：耗材按 3 天用量备。

第二次：接口半夜挂了。 ERP 订单接口凌晨 2 点断了，WMS 收不到订单。值班的是个新来的 IT，不知道接口重启权限在谁手里，在群里 @所有人，等了 40 分钟才找到人。那 40 分钟里，早班 6 点开工的波次计划全乱了。从此值班表精确到人、到电话，贴在 war room 墙上。

第三次：老板亲自下场指挥。 上线第三天出了个 S2 问题，IT 说要 4 小时修，运营说等不了。老板冲进仓库，绕过 war room 直接指挥现场改流程，结果改完和系统逻辑冲突，当天多出 200 单异常。这件事之后我立了条铁规：上线第一周，现场只听 war room 指挥一个声音，老板有意见进 war room 说。

三次翻车，三种死法，但病根都是一个：关键时刻没人能拍板，或者拍板的人不对。

war room 里必须坐的 5 种人

人不对，war room 就是个吵架的地方。这 5 个角色缺一不可：

现场指挥（1 人说了算）。 必须是懂业务的运营负责人，不是 IT。他有且只有一个权力：出问题时 5 分钟内拍板"继续"还是"停"。上线第一周最忌讳开会讨论，所有人等一个结论。

WMS 实施方驻场。 出了系统 bug，只有他们能当场改配置、重启服务。合同里必须写明 go-live 当周驻场支持，远程支持的上线我见过翻车的。

IT / 接口负责人。 WMS 从来不是孤岛：ERP 订单接口、快递面单接口、财务结算接口，任何一个挂了，仓库就停摆。这个人手里要有所有接口的监控和重启权限。

一线班组长。 拣选、收货、复核各出一名。他们是系统的"人肉传感器"——界面卡了、流程别扭了，他们第一个知道。别让他们只当传话的，给他们直接报问题的通道。

记录员兼升级经理。 所有问题建单、定级、跟踪闭环。这个人决定问题是"记下来明天修"还是"现在立刻升级"，war room 的秩序就靠他。

一句话：war room 里坐满了，现场就不乱。

上线前 48 小时的清单

war room 是上线前两天搭起来的，不是上线当天现找的。清单如下，打勾一项是一项：

• 数据冻结：老系统停止录入的时间点，全公司同步。冻结前做一次完整数据校验：SKU 主数据、库位、库存余额，三项对不上不许上线。
• 打印耗材备足：面单纸、标签纸、碳带按 3 天用量备。别笑，我真见过上线第二天面单纸用完、全仓等快递送纸的。
• 回滚预案演练：回滚不是"实在不行就回老系统"一句话。要写清楚：触发条件是什么、谁下令、数据怎么导回、老系统需要几小时恢复。上线前至少桌面推演一遍。
• 值班表：第一周每天两班、每班 12 小时（早晚班接力覆盖全天），写到人、写到电话。凌晨 3 点出问题，你得知道打给谁，而不是在群里 @所有人。
• 账号权限提前开通：所有 war room 成员的系统账号、接口监控后台、服务器重启权限，上线前一天全部开通并实测登录。我见过上线当天才发现实施方 VPN 账号过期，干等两小时的。
• 一线培训留痕：拣选、收货、复核三个环节的标准操作，每人实操一遍并签字确认。别信"都会了"，上线第一周所有"我以为会了"都会变成异常单。
• war room 物理布置：大屏实时显示订单履约率、积压单量、接口状态；白板写当日 Top3 风险；零食和水备足——第一周没人有空好好吃饭。

第一周的节奏：三会 + 分级

每天三会，雷打不动。 早会（开工前 30 分钟）：确认昨日遗留问题、今日波次计划；午盘点（中午）：看上午的积压和异常，决定下午是否加人手；晚复盘（收工后）：当日问题清单过一遍，定级、派单、定 deadline。每会不超过 30 分钟，站着开。会议纪要当天发出，责任到人、时间到天，没闭环的问题第二天早会第一个过。war room 大屏的数据每小时截屏存档，出了纠纷有据可查。

问题分级与升级矩阵，贴墙上：

什么时候喊停：回滚的红线

最难的决定不是修 bug，是承认"今天上不了"。红线要提前写好，写进上线方案，老板签字：

• 订单履约率跌破 80% 且 2 小时内无改善趋势；
• 积压订单超过单日产能的 1.5 倍，且还在涨；
• 核心接口（ERP 订单 / 面单）中断超过 4 小时无恢复方案；
• 账实差异大面积出现，盘点无法收敛。

触发任意一条，现场指挥有权直接喊停、启动回滚。记住：回滚不是失败，是止损。 硬撑三天把客户得罪光了，才是真正的失败。我经手的上线里，果断回滚的那次，两周后二上一次过；硬撑的那次，折腾了一个月。

回滚之后别急着定二上日期。先开复盘会，把触发回滚的根因一个个钉死：是数据问题、接口问题，还是流程设计问题。根因不清就二上，等于同一个坑跳两次。我的标准：根因全部关闭、回归测试通过、war room 原班人马确认 ready，才定二上时间。

war room 什么时候撤

撤也有标准，不是"感觉差不多了"：连续 3 天无 S1/S2 问题，订单履约率回到上线前基线，积压清零。达到之后再开最后一次复盘会：问题清单归档、 backlog 移交日常运维、值班表降级为 on-call。然后，白板擦掉，war room 解散。

上线第一周拼的不是技术，是组织。系统再稳，也架不住 40 个人不知道听谁的。把 war room 搭好，把规矩立好，第一周就能平稳落地——这句话，是我用好几个通宵换来的。

最后补一句：war room 的经验别浪费。第一周结束，把值班表、升级矩阵、回滚红线这三张纸存档，下次上线直接复用。我现在的客户里，有一家已经把这套东西做成了标准模板，新仓上线直接套，war room 搭起来只要半天。