SAP 项目计划与控制：让项目不偏离正轨

大多数 SAP 项目都有计划，真正有控制的却少得多。计划确定范围、时间表、预算和风险。控制则是每周都要做的工作：对照计划跟踪进度，管理依赖关系，尽早升级问题，并在任何变更获批之前评估其影响。本指南写给项目总监、PMO 和项目发起人，无论您的 SAP 项目正在偏离轨道，还是您想防止它偏离。内容包括控制具体是什么样子，三起公开的失败案例（它们说明了缺少控制会怎样），以及一套带有责任人、本周就能采用的每周控制节奏。

我刚入行时，参与过一个纸面上看起来非常漂亮的 SAP 项目。时间表、风险登记册、变更日志，该有的都有。但没有人照着执行。指导委员会很少开会。财务部门在等数据迁移。IT 还没有动工。没有人跟踪依赖关系。每个人都以为别人在盯着进度。

到了第六个月，项目有一半落后于计划，我们都在追着自己犯下的错误跑。最糟的是，事先没有人看出来。

这不是计划问题，而是控制问题。没有真正的资源分配，没有像样的风险缓解措施，也没有升级路径。计划只做了一次，然后就被搁在一边，用开会取而代之。

计划涵盖范围、时间表、预算、资源、风险登记册和里程碑承诺。大多数团队都能做出来。问题在于有没有人逐周使用它。

控制涵盖对照计划跟踪实际进度、尽早暴露偏差、管理依赖关系、进度落后时升级处理，以及在范围或时间表正式变更时重新确定基线。大多数团队在这方面做得很差。

1. 01跟踪进度按工作包对比实际与计划
2. 02发现偏差任何晚了三天的任务
3. 03检查依赖关系这件事一旦延误，谁会被卡住
4. 04升级处理按事先约定好的路径
5. 05评估变更首先看时间、成本和资源
6. 06重新确定基线仅在正式变更之后

每周一次，责任人明确

缺少控制时，会出现这些问题：

缺少控制时会出什么问题	原因
截止日期悄悄延误	里程碑评审之间没有人检查
假设没有得到验证	每个团队都以为另一个团队会处理这项依赖
范围非正式地扩大	变更在会议上获批，却没有影响评估
风险被一直忽视，直到成为现实	风险日志每季度才更新一次，而不是每周
成本超出预算	工作量只记在工时表里，没有对应到工作包
团队不再沟通	状态会议变成只通报情况，没有行动项

这些是公开案例，不是客户的故事。它们的根本原因，正是我在咨询工作中反复看到的那些。

Lidl：约七年、估计 5 亿欧元，然后叫停

Lidl 于 2011 年在 SAP Retail 上启动了 eLWIS 项目。它的库存计价做法与 SAP 的标准模型不同，Lidl 选择调整软件，而不是调整做法。到 2018 年，系统已在奥地利、北爱尔兰和美国上线，但董事会认为，原定目标无法在合理的成本内实现。Lidl 叫停了项目，回头继续开发自己的内部系统。行业媒体估计这笔花费约为 5 亿欧元，而分管 IT 的董事会成员已于 2017 年离任。Heise 报道了这一决定，时间是 2018 年 7 月。教训是：为了保护遗留做法而连年做定制，是控制上的失败，不是软件的失败。

Hershey：约 1 亿美元的万圣节订单未能交付

Hershey 的新 SAP、Siebel 和 Manugistics 系统原计划于 1999 年 4 月上线，那是糖果行业的淡季。结果推迟了三个月，7 月才上线，正赶上万圣节订单开始涌入。订单无法从系统传到仓库。首席执行官告诉分析师，这些问题会使 Hershey 无法为万圣节交付约 1 亿美元的产品，第三季度销售额下降了 12.4%。CIO 杂志的报道把真正的失败归因于时机。如果有一套保护旺季的进度控制，就会迫使项目选择另一个上线日期。

Revlon：一座工厂受到冲击，内部控制出现重大缺陷

Revlon 于 2018 年 2 月在其最大的生产基地，也就是北卡罗来纳州牛津（Oxford）的工厂启用了 SAP。服务中断冲击了生产，也影响了发往美国大型零售商的出货。2019 年 3 月，Revlon 披露了与这次上线相关的内部控制重大缺陷，原因是没有有效的持续风险评估，受影响的运营部门里受过培训的人员也太少。投资者提起了诉讼；TechTarget 报道了这起诉讼，诉状称约 6,400 万美元的货物未能发出。

这几个项目没有一个是因为选错了 SAP 而失败。它们败在计划和控制的基本功上，而这些基本功已经存在了几十年。

工作分解结构

工作分解结构（WBS）把整个范围拆成一个个交付物，并明确负责人。没有它，工作在延误之前是看不见的。对 SAP 项目来说，它涵盖流程设计、配置、数据迁移、集成、测试、培训和切换，每一项都拆解到任务，并有负责人和到期日。

价值不在那份文档本身。它迫使大家讨论：需要做什么、由谁来做、又依赖什么。依赖关系才是项目的杀手。数据迁移的延误会卡住集成测试，集成测试又卡住用户验收测试（UAT），进而压缩切换窗口。WBS 让这条链条看得见。

进度管理

时间表失败的原因都在意料之中。人被抽调走，估算有误，决策比计划花的时间更长。从第一天起就留出应急余量，把它作为明确的缓冲，放在最可能需要它的任务旁边，而不是在每个任务里都悄悄多加一点。

每周跟踪进度。第 4 周出现一周的延误，只是一次对话。第 16 周出现四周的延误，就是一场危机。同样的问题，修复的代价却天差地别。

把上线时机当作一项独立的决策。永远不要在业务高峰期上线。Hershey 的教训适用于每一家公司。

预算控制

预算失控有三个原因：范围变更无人管理，数据迁移被低估，上线后支持（hypercare）的成本高于早期估算。从第一周起就按计划跟踪实际支出。等偏差报到指导委员会时，通常已经来不及在不造成干扰的情况下纠正了。

变更控制是预算的主要保护。每一项范围变更在获批前，都要就时间、成本和资源做影响评估。如果评估在批准之后才做，这项变更就绕过了预算。我关于如何避免 SAP 实施中的范围蔓延的指南，对变更委员会讲得更深入。

风险管理

每季度才维护一次的风险登记册是走过场。风险需要每周评审，有明确的责任人和应对计划。每个 SAP 项目都要列出这些风险：数据质量问题发现得太晚、集成延误、资源可用性缺口、切换窗口被压缩，以及用户采纳情况不佳。

有一家客户损失了三个月，因为它的数据迁移供应商一次又一次错过交付期限。我们一直听到“再给两周就好”，等到再换供应商就必然超出预算时，已经太晚了。如果有一项风险带着责任人和触发日期，几个月前就会逼着大家做出这个决定。我的 SAP 风险评估矩阵提供了为这些风险打分、明确责任人的模板。

沟通与升级

高管需要的是要点。交付团队需要的是细节。项目经理需要的是偏差数据。给所有人发同一份通报，对谁都没有帮助。

要在危机出现之前，就把升级路径写下来并演练。在一个 SAP 实施项目上，IT 以为财务在审核配置，财务又以为是 IT 在审核。直到离上线只剩三个月、关键审批缺失时才有人提出来；补救办法是临时抢工、额外成本和推迟的推广。另一家公司做对了：汇报有结构，并与行动挂钩，所以出了问题，每个人都知道谁负责、影响是什么、将如何解决。

范围是升级机制真正发挥作用的地方。我合作过一家航空公司，起初只是一次简单的订票升级。六个月后，它又加进了常旅客计划的改动、机组排班和财务模块。没有一项是紧急的。没有人说不。时间表翻了一倍，成本上涨了 70%。

本地部署时代的做法，在 RISE with SAP 下不能原封不动地沿用。有三点不同。

RISE 改变了您要向谁升级问题

在 RISE with SAP 下，SAP 负责基础设施和技术运维，并提供一支跟踪采用情况的客户成功团队。您的控制结构必须把他们包括进来。对于平台问题（系统性能、超大规模云厂商的区域、SAP 的服务级别），项目群经理需要一条有文档记录、通往 SAP 的升级路径，而且不经过实施合作伙伴。要在需要之前就写下来。

Clean Core 为范围控制提供了技术上的后盾

现在每一个差距都需要一个决定：通过配置解决，通过已发布的 API 来扩展（在 ABAP Cloud 上以内嵌方式，即 on-stack，或在 SAP BTP 上以并行方式，即 side-by-side），还是直接拒绝。在 S/4HANA Cloud Public Edition 上，修改核心不是一个选项。在私有版和本地部署上是可以做的，但 SAP 的 Clean Core 指南把它当作最后的手段，因为每一处修改都会增加升级工作。

这对范围控制有帮助。一个“只是微调一下标准订单到收款流程”的请求，不再是一次随意的配置闲聊，而是一项需要设计、开发和测试工作量的扩展。在指导委员会之下设一个小型的扩展评审小组，由一位有权批准或否决的架构师负责。没有它，每一场关于定制的争论最后都会闹到指导委员会。

AI 起草报告，由人做决定

AI 现在能帮着处理控制工作中的文书。SAP Cloud ALM（SAP 的应用生命周期管理工具）保存项目任务、需求和测试状态，并能根据研讨会的转录文字生成需求草稿。Microsoft Copilot 根据仪表板和状态报告，为指导委员会的材料起草偏差摘要。Power BI 或 SAP Analytics Cloud 中的异常检测，会标出偏离常态的 KPI。这对资源使用、变更请求数量和支持工单很有用，对本来就会自然波动的指标则用处较小。

AI 做不到的是采取行动。仪表板可以连续六周用红色显示进度落后。如果指导委员会什么都不做，落后就会继续。

这是处于积极交付阶段的项目所需的最低节奏。如果缺少哪一行，先把它补上，再做别的。

控制项	最低做法	责任人	频率
工作分解结构	每项任务都有负责人、到期日及其依赖关系	PMO 负责人	每周更新
进度评审	标出任何晚于计划超过三天的任务；检查关键路径	项目群经理	每周
预算跟踪	按工作包对比实际与计划	项目财务负责人	每周，按月汇报
风险评审	每项活跃风险都有责任人、触发条件和应对措施	工作组负责人	每周
变更控制	获批前先就时间、成本和资源做影响评估	变更委员会主席	每周，或在请求到达时
扩展评审（RISE 和 GROW）	对每个差距做出配置、扩展或拒绝的决定	解决方案架构师	每两周
指导委员会	做决策，而不是通报状态；材料提前发出	高管发起人	每两周；切换和上线后支持期间每周

大多数计划与控制的失败，并不是因为方法不对，而是因为到第四个月，纪律就松懈了。让这套节奏保持足够精简，这样团队到第十四个月仍然愿意执行。关于指导委员会本身，请参阅我的指南：如何建立有效的 SAP 项目指导委员会。

项目计划和项目控制有什么区别？

计划产出路线图：范围、时间表、预算、资源和风险。它在开始时确定方向。

控制是持续进行的工作：对照计划跟踪进度，暴露偏差，管理依赖关系，并在正式变更发生时重新确定基线。它在项目的整个生命周期里每周都要做。

大多数 SAP 项目在计划上投入很多，在控制上投入太少。等偏差在指导委员会上显现时，已经积累了数周乃至数月的挽救成本。

为什么 SAP 项目有项目计划，还是会失败？

因为没有人照着计划去做。依赖关系没有被跟踪，所以一个工作组的延误会悄悄卡住另一个。风险日志每季度才更新一次。范围变更被非正式地批准。指导委员会每月开一次会，看到的是里程碑摘要，而这些摘要掩盖了一线实际发生的情况。

Lidl、Hershey 和 Revlon 都有计划。它们缺少的是主动控制：如实跟踪、尽早升级，以及在警示信号出现时做出真正的响应。

如何管理长周期 SAP 项目中的范围蔓延？

每一项范围变更，在获批前都要有书面的影响评估：时间、成本和资源。没有它，批准变更就等于批准一个未知数。

最有效的规则是：任何新增内容都必须挤掉别的内容。仅这一条约束，就能让业务负责人老老实实地排优先级。

高管必须撑腰。当 CFO 或 COO 公开支持变更控制时，非正式的请求会迅速减少。在 RISE 和 GROW 项目上，对每个差距做出的扩展决定，又在此之上增加了一层技术把关。

什么是工作分解结构，它对 SAP 为什么重要？

WBS 把整个范围拆成交付物，每个交付物都有负责人和到期日。在 SAP 项目上，这意味着流程设计、配置、数据迁移、集成、测试、培训和切换，全部拆解到任务。

它的实际价值在于依赖关系映射。数据迁移支撑集成测试，集成测试支撑 UAT，UAT 支撑切换。当其中一环延误，下游的影响立刻就看得见。

RISE with SAP 如何改变项目计划与控制？

SAP 成为交付的参与方。它负责基础设施和技术运维，其客户成功团队有自己围绕采用和价值的节奏。

由此带来三个变化。第一，您需要一条有文档记录、通往 SAP 的升级路径，用于处理平台问题，且不经过合作伙伴。第二，您需要在指导委员会之下设一个扩展评审小组，决定在 Clean Core 下如何处理每个差距。第三，您应当把 SAP 客户成功团队的节奏纳入自己的治理，而不是与之平行运行。

SAP 项目的指导委员会应该做什么？

做决策。它的职责是解决项目团队解决不了的事：资源冲突、范围争议、预算变更，以及任何需要跨职能权限的事项。一场没有做出决策的指导委员会会议，只是一次状态通报。

大型项目上每月一次的指导委员会，会让问题最多等上四周。积极交付阶段，每两周一次是最低要求，切换和上线后支持期间则每周一次。进展报告提前发送，会议用来处理这些报告引出的决策。