凌晨3点，数据库迁移卡在40%，项目经理说还在计划内

凌晨3点，数据库迁移进度停在40%。DBA从周二开始就没睡过觉。项目经理——愿他安好——说出了那句开启所有上线灾难故事的话：“我们还在计划内。”

没人信。DBA不信，切换负责人不信，在作战室椅子上打盹的CIO也不信。进度表从蓝图第二周起就是虚构的——那周业务方认定他们的自定义定价引擎“太有战略意义，不能标准化”，往RICEFW清单里塞了47个增强项。一场研讨会，47个对象。倍数在那时候就已经埋进去了。

这个模式在18年里反复出现，失败不是随机的，是可预测的，而且每次开场都一样。

RICEFW的陷阱

每个SAP项目都从估算练习开始。RICEFW——报表、接口、转换、增强、表单、工作流。业务方在一间屋，顾问在另一间，有人在白板上写下40个对象，所有人点头。

到上线时，40变成180。倍数在不同项目间落在2倍到4倍之间。职业生涯里，它从没往反方向走过。这不是算术失败，是对SAP项目实际运作方式不够诚实。

规划时该用的算法：把发现研讨会的对象数乘以2.5到3倍。每次都这样。差异来自范围蔓延，不是估算误差——而范围蔓延是结构性的。

数字为什么总在涨？发现阶段，业务描述现有流程，顾问按复刻它来圈对象。项目一启动，业务发现SAP的干法不一样。他们不想改流程。于是每个差距变成一个新对象——要写、要评审、要测试、要传输。RICEFW清单是活的，而且只朝一个方向长。

模板话术与现实

标准防御是“模板方案”。模板加速一切，模板是安全网。但模板是起点，不是约束。顾问不会把这点说透，因为一个能约束范围的模板更难卖。

模板实际提供的是：预配置基线设置、已知数据模型、经过测试的集成模式。它不给项目划范围。那些把RICEFW撑大的业务决策，发生在模板部署之后。模板回答“怎么做”，它对“做多少个”一言不发。

基于模板且按时上线的项目我见过。每一个都把模板当天花板，不是地板。问题不是“能不能加这个”，而是“模板支不支持，不支持的话是第一期还是第二期”。这是另一种对话，大多数项目从没进行过。

杀死上线的范围，是研讨会第二周由一群不会出现在凌晨3点电话会上的人批准的。

治理是唯一真正的解法

每一个“就再加一个”的增强项都带着复合成本，申请时看不见。它在上线时现身——你在跑并行系统，然后意识到自定义代码没做过回归测试。每个修改还是一场未来的升级对话、一个未来的传输管理麻烦、一轮未来的测试周期。

蔓延不是纪律失败，是治理失败。谁有权说“不”？大多数项目里，这个人要么没被授权，要么不在屋里，要么不愿意吵这一架。于是这一架改在上线时打，而不是在发现阶段打。

蓝图签字即冻结范围，没有例外。不在蓝图文档里的，就是第二期。蓝图之后的任何新增，都需要正式变更请求，并且要挤掉清单上已有的某项。这不是新想法，每个有经验的SAP人都知道，每个新项目都无视它。

机制是流程，不是意志力。蓝图签核后的每个变更请求都要做正式影响评估：时间估算、成本估算、置换建议（这个进去，什么出来）。需要发起人签字，没有例外。

成本可见时，发起人说不行。置换明确时，相关方自己就降优先级了。变更控制委员会不是官僚机构，它是把“就再加一个”的真实成本摆到审批人面前的机制。多数时候，他们选择不加。

我见过项目中途装上这套机制，硬生生叫停了一场死亡行军。装得晚很痛苦，在启动时装好得多——那时候大家还是朋友。

具体动作：

• 蓝图签核即范围冻结。不做“第二期”的口头承诺。RICEFW清单基线化，就这样。
• 蓝图后的每个新增都必须置换。填变更单：哪个标准流程退役？哪个自定义对象删除？答案是“没有”，那答案就是“不行”。
• 指导委员会记名投票，不接受口头批准。投票和理由当周进项目简报。
• 切换计划里包含重试缓冲。每个迁移对象都有重试窗口。如果MARA在38%失败，你需要4小时回滚重跑。

签字前的几项检查

让没参加估算研讨会的人对RICEFW数量做压力测试——新鲜的眼睛乘出来的数不一样。蓝图要有正式签核日期，以及针对其后变更的具名控制流程。模拟上线至少安排在8周之外，是真正的切换演练，不是走流程。

真正按时交付的项目有什么共同点？不是运气，不是更快更聪明。它们只在一件事上毫不留情：说不。

我参与过的最好一次上线提前4天交付。那位PM对每个蓝图后的范围请求只有一个回答：“这个想法很好，放第二期。”说得热情，说得毫无歉意，每一次都这么说。团队说她是合作过最难搞的PM，也是最好的PM。这两件事是同一件事。

蓝图后范围对话的通用句式：“我可以把这个加进计划。为此，请告诉我这三项里哪一项拿出去：[A]、[B]还是[C]？你更倾向哪个？”对话通常到此结束。

大多数上线计划缺的是：一个把迁移重试算进去的切换时间线。多数计划只画一次迁移运行。生产迁移第一次会失败，有时第二次也失败。切换窗口至少要假设两次完整尝试，中间带决策检查点——而且业务方要在上线周末之前知道这件事，不是在上线周末之中。

错过日期的项目不是坏人做的坏项目。它们是善意项目，只是治理强度不足以扛住相关方的请求。这是结构问题，有结构解法。而且必须在前四周装上，不是最后四周。

凌晨3点的电话可以避免。只是不能在凌晨3点才去避免。