如何避免SAP实施中的范围蔓延

要避免SAP实施中的范围蔓延，办法是让每一项变更都看得见，也让它批准起来代价不菲。把范围之外的内容，和范围之内的内容一样仔细地写下来。每一项请求都要走变更控制，并对时间、成本和质量做影响评估。每增加一项，就要求做一次取舍。在高管背书下设定范围冻结日期，并把同样的纪律写进与系统集成商（SI）的合同。这篇指南写给S/4HANA项目的项目总监、发起人和PMO。请在您下一次指导委员会的材料里，用上下面的变更成本表和合同条款。

多数SAP项目都会超预算、过工期，而范围蔓延是最常见的原因。我合作过几十家企业，它们的SAP项目都曾失控，而在超支出现在指导委员会报告之前，会先出现三个信号。小的变更不经影响评估就堆积起来。变更控制靠的是私人关系，而不是书面确定的权限。发起人在咖啡桌上批准的事情，项目团队一周之后才听说。

一家制药客户起初有一份清晰的18个月时间表。三年后，它仍在实施，成本翻了一番。一家制造企业的CIO告诉我，他的团队废弃了花几个月配置好的整个模块，因为需求一直在变。范围膨胀得太厉害，已经没有人认得出最初的计划了。

这些不是个别情况。这是SAP项目失败最常见的方式。

它开始得很无辜。一位业务负责人提出“就改一个小地方”。接着又有一个。“既然都动到这儿了，顺手……”这句话毁掉的SAP实施，比任何技术难题都多。

我合作过一家零售客户，起步很干净：核心财务和基础的物料管理。六个月后，首席营销官（CMO）想要客户分析。然后COO又需要高级仓库功能。原定九个月的时间表受到了威胁。我顶了回去，两个请求都拒绝了。这种纪律，正是这份工作的本分。

并非每一项变更都是范围蔓延。有时您会发现设计中没人预料到的关键缺口。有时法规在项目中途发生变化。这些是正当的，它们走的是有流程的路径，时间表和预算会随之调整。范围蔓延则是凭空冒出来的，通常出自走廊里的一次闲聊。

一家制造客户起初有10个自定义报表，最后变成了47个，每一个都增加了设计、构建和测试的时间。仅报表这条工作线，预算就超支了200%。

200%

自定义报表从10个增加到47个，范围漂移之后报表工作线的预算超支

来源: 制造客户项目

预警信号

下面是我会留意的信号，以及对每一种的应对：

预警信号	根本原因	应对
“再加一件事”成了日常用语	范围边界不清	与业务负责人重新确定基线；执行正式的变更控制
业务负责人非正式地增加功能	不了解下游的影响	每一项请求都经过影响评估；把成本摆出来
时间表延长，却没有正式重排计划	范围在悄悄扩大	设置范围检查点；经变更委员会签字后重新规划
文档与已构建的内容不再一致	范围处理不正式，没有版本控制	每次批准变更，都更新规格和计划
预算消耗快于进度	未记录的变更带来了隐性工作量	按工作包跟踪工作量；调查偏差
团队夜里和周末加班赶进度	范围超出了产能	上报变更委员会；逼着做出范围决策
业务、IT和合作伙伴互相指责	范围早已蔓延到失控	冻结范围，做根因复盘，重置基线

一切都相互关联

SAP把一切都串在一起。财务影响供应链。人力资源牵涉薪资。销售连着库存。一个变更可能弄坏十个东西。

有一位客户在采购订单流程里加了一个字段。看上去微不足道。结果它弄坏了三个接口，还要求各部门的报表重写。另一位客户要求对定价过程做一个“小小的改动”，结果需要把整个定价结构重新配置：三周的工作量，4万美元的咨询费，只为一个小小的改动。

十年一遇的压力

多数企业每10到15年才实施一次SAP。每个部门都知道，十年内不会再有第二次机会。没人愿意听到“第二期”，因为在大多数组织里，这就意味着不会有。于是所有东西都被塞进当前的项目，范围清单变成了愿望清单。

Clean Core带来了什么变化

Clean Core对定制化加上了一道技术上的刹车。在S/4HANA Cloud公有云版上，不可能修改核心：扩展要通过已发布的API，用栈上（on-stack）或SAP BTP上的并行（side-by-side）方式。在私有云版和本地部署上，仍然可以修改，但SAP的指引把它当作最后的手段，因为每一处修改都会增加升级的工作。

它有一个有用的副作用，就是带来范围纪律。一个“就在标准的订单到收款里加这个审批步骤”的请求，不再是一次随意的配置闲聊，而变成了一个有自己设计、构建和测试成本的扩展。在指导委员会之下设一个扩展评审论坛，由一位能批准或否决的架构师把关，许多这样的请求在进入基线之前就停下了。没有这个论坛的本地部署项目，又会回到老路上去。我写的Clean Core指南讲了如何建立这样一个论坛。

1. 在定义范围时明确写出排除项。 把范围之外的内容，和范围之内的内容一样仔细地记录下来，并让双方都签字确认。模棱两可的地方，就是争吵的起点。
2. 执行有后果的正式变更控制。 每一项变更都需要对成本、时间和质量做影响评估，并让批准人看得见。
3. 每次指导委员会都沟通范围边界。 用简单的红、黄、绿视图展示范围状态。许多漂移其实是误解。
4. 编写范围管理计划。 写明变更如何评估、批准、升级和跟踪，让每一条工作线都用同样的方式处理。我写的SAP项目范围模板给出了一个起步结构。
5. 用MoSCoW排优先级。 必须有（Must have）、应该有（Should have）、可以有（Could have）、这次不做（Won't have）。要使劲把“必须有”保持得短。
6. 对每一项决定做版本控制。 每一项获批的变更都要更新基线。每一项被否决的变更都要连同理由记录下来。
7. 要求取舍。 新需求进来，就得有别的东西出去。“必须有”一旦要付出代价，很快就变成了“可选”。

我用过的三个方法，能让这些策略真正落地。

签字纪律。 让业务负责人在获批的需求上签字。有一个项目里，一位业务负责人发誓说他从没批准过某个流程。我们拿出了有他签名的文件，争论就结束了。签字不是官僚作风。它能避免同样的争论在六个月后重新开始。

把连锁反应摆出来。 我给一位客户做了一个演示，展示改动销售订单上的一个字段，会影响14个方面，从报表到接口，再到安全角色。行为随之改变。讲解要花几个小时。不理解连锁反应，则要花几个月。

把变更的成本摆出来。 在设计阶段做一个变更，可能花5000美元。同样的变更放到测试阶段，可能要花5万美元。把这样一张简单的图表摆在大家面前，随口提出的请求就会慢下来。

下面是美国市场S/4HANA项目的示意性变更成本区间。它们因复杂度和合作伙伴而异。请把它们当作参照，而不是报价。

阶段	小型变更的典型成本	中型变更的典型成本
探索（设计）	2000至1万美元	1万至3万美元
实现早期	5000至2万美元	2万至8万美元
实现中期（构建）	1.5万至5万美元	5万至20万美元
实现后期（测试）	3万至10万美元	10万至40万美元
部署与切换	8万至30万美元	30万至100万美元以上
上线后重点保障（Hypercare）	15万至50万美元	50万至200万美元以上

这个规律，与几十年来的研究结论一致。一项NASA关于错误成本递增的研究发现，在集成与测试阶段才发现的需求错误，修复成本是在需求阶段发现的21至78倍，而系统投入运行之后还要高得多。范围治理的存在，就是为了让变更留在这条曲线便宜的那一侧。

重要的合同条款

含糊的合同会制造昂贵的问题。我见过一位客户签的合同里只写了“实施S/4HANA”。合作伙伴后来声称，某些特定流程属于附加项，要另收费用，客户最后付了双倍。下面这些条款可以防止这种事：

条款	目的
带明确排除项的范围	限定固定价格涵盖的内容，消除附加项上的歧义
对常见变更预先约定费率	在压力到来之前，锁定报表、接口和配置变更的价格
顾问的连续性	避免新来的顾问重新翻出已经定下的决定，扩大范围
双方的批准权限	避免初级顾问承诺无人授权的功能
按里程碑计费	把付款与签字确认的交付物挂钩，而不是与流逝的时间挂钩
每项交付物的验收标准	在有人争论之前，先定义什么叫“完成”
Clean Core扩展条款	要求扩展使用已发布的API或SAP BTP；在第一次大版本升级时免去返工

我写的ERP合同谈判笔记，讲了如何让这些条款谈成。

变更委员会

变更委员会只有配对了合适的人才管用。我组建的委员会有三个角色：一位关心功能的业务决策者，一位关心进度的项目经理，一位关心预算的财务负责人。这种平衡，避免任何一种优先级一家独大。

1. 01提出请求书面提出，而不是在咖啡桌上
2. 02影响评估在任何人批准之前，先评估时间、成本和质量
3. 03明确取舍腾出空间，就得有别的东西出局
4. 04变更委员会决定业务、项目和财务三方同桌
5. 05更新基线被否决的变更连同理由一并记录

范围只通过变更委员会变动

变更委员会需要有真正的权力。在一个项目里，没有它的批准，任何范围变更都不会发生。一个都没有。走廊里的口头约定停止了。当销售副总裁想悄悄塞进新需求时，团队手里有一份成文的审批矩阵可以出示。

大多数决定应该留在委员会这一层。只有真正的争议才上交发起人，这样既让发起人保持参与，又不会让他被淹没。每两周与各工作线负责人开一次范围评审，并汇报提交、批准和否决的请求数量。当人们在状态报告里看到“本月范围增长了15%”，行为就会改变。

有些变更是必要的。我有一位制药客户，在实施中途碰上了新的FDA法规。这些必须加进去。这不是范围蔓延。这是现实。

当一项正当的变更出现时，要问两个问题。能奏效的最小修复是什么？还有，要问提出请求的人：为了腾出空间，您愿意拿掉什么？当一项请求要付出代价时，紧迫感就会很快下降。

可选的办法有：延长时间表、追加预算、砍掉其他需求、增加人手，或者几种混合。不管选哪一种，都要记录下来，并同时更新所有的基线文档。过时的文档，会引出下一轮范围问题。

如今AI可以帮忙处理文书工作。Microsoft Copilot这类助手，能把很长的变更请求讨论串，汇总成供委员会决策的简报；SAP Cloud ALM则让需求、变更和测试保持关联，使变更的影响更容易追溯。AI能指出一项变更牵涉14个方面。但它没法对COO说，她的请求意味着CFO的请求就办不成了。这场对话，仍然是您的。

我合作过的一家制造企业，按时完成了SAP项目，这比它本该有的比例要罕见得多。它很早就设了范围冻结日期，此后任何变更都需要CEO亲自批准。项目收尾时预算还有剩余，上线的时候没有人在周末加班。

另一位客户用了令牌制度：每个部门在整个项目期间，获得三枚变更令牌。想要改动？就花一枚令牌。人们会认真想什么才重要，而“必须有”的东西，一旦要花有限的“货币”，也被重新考虑了。

这两种做法都不复杂。都需要纪律和领导层的支持。检验任何范围流程的，是COO带着“就一个小改动”走进项目室的那一天。请为那一天来设计它。

什么是SAP项目中的范围蔓延？

需求逐渐地、不受控制地增长，却没有相应调整时间表、预算或资源。在SAP里，它通常从小的追加开始：多一份报表、多一个字段、“就改一下流程”。每一项看上去都无伤大雅。加在一起，就是好几个月。

正当的范围变更走的是有流程的路径，并伴随时间表和预算的调整。范围蔓延则是非正式地到来，绕过了变更控制。

SAP项目中范围蔓延最常见的原因是什么？

有三个原因反复出现：最初的需求含糊，所以什么都可以争辩成在范围之内；没有正式的变更控制，所以各个层面都有变更溜进来；以及十年一遇的心态，每个部门都想在这个项目里解决多年的问题。

SAP的相互关联放大了这三点。一个变更可能弄坏十个相关联的流程，如果业务负责人看不到这些关联，影响就会在测试阶段才显现，那时代价要高出许多倍。

Clean Core如何改变范围蔓延的风险？

它加了一道技术上的刹车。在S/4HANA Cloud公有云版上，核心无法修改，所以每一个缺口都变成了一个有自己设计、构建和测试成本的扩展。在私有云版和本地部署上，修改是可以的，但会增加升级工作，所以SAP的指引不鼓励这样做。

设一个扩展评审论坛，由一位有决定权的架构师把关，就能在许多请求进入基线之前把它们拦住。没有这个论坛，本地部署项目又会滑回老习惯。

范围蔓延和镀金（gold-plating）有什么区别？

范围蔓延来自业务方：超出原先约定的请求。镀金来自交付团队：没人要求过的复杂性。

用SAP的话说，镀金就是顾问在简单路由就够用的地方，搭了一套复杂的工作流逻辑。范围蔓延则是COO在一个只定了基础MM范围的项目里，做到第六个月时要求高级仓库功能。两者都会推高成本和时间，也都需要同样的纪律。

如何搭建一套真正管用的变更控制流程？

有三个要素。每一项请求都附带对时间表、预算和资源的影响评估。批准的委员会里，要有一个人关心这三者中的每一项，而不是只有业务负责人，因为他们什么都会批。每一项追加，都要求做一次取舍：有别的东西出局。

光是最后这一条规则，就能把那些并非真正关键的请求筛掉。

能完全避免范围蔓延吗？

不能。在任何超过几个月的项目里，业务状况会变，法规会变，设计也会发现缺口。

目标是控制，而不是消除。受控的变更走的是成文的流程，经过影响评估，并更新基线。失控的变更绕过流程，在测试阶段或上线之后冒出来，成为没人规划过的成本。

在周期很长的SAP项目里，处理范围冻结的最佳方式是什么？

给它配上后果，以及明显可见的高管背书。我用过的最有效的版本是：冻结日期从第一天起就写在项目章程里，变更流程定义“冻结”在实践中意味着什么，发起人则在日期到来之前，在指导委员会上公开强调。

当冻结之后的每一项变更都要CEO亲自批准时，清单就会变得非常短。