SAP 项目挽救：让偏离轨道的项目重回正轨

SAP 项目挽救，意味着叫停一个偏离轨道的迁移或实施项目，弄清它的真实状况，并以这些事实为基础重新制定计划。第一周决定成败：评估项目状态，审查设计，并评估系统中实际部署了什么。

简短的回答：如果这三项检查彼此一致，并且与计划一致，项目需要的是推一把，而不是挽救。如果它们不一致，在现有计划上投入再多的努力也无济于事，您需要一次正式的挽救，并设定新的基线。

本文讲的是这种诊断以及之后的工作。它是我的 ECC 到 S/4HANA 迁移指南的一篇分支文章，那篇指南讲的是路径、时间线和截止日期。这里的问题更具体：您的项目陷入了困境，现在该怎么办？

大多数延误的项目并不需要挽救。它们需要更快地做出决策、腾出一位关键用户，或者让供应商按期交付。这就是推一把。

挽救则不同。迹象来自我在第一周进行的同样三项检查，信号很简单：状态、设计和已部署的内容彼此不一致，或者与计划不一致。

我会把以下几种情况视为需要挽救的信号：

1. 状态是绿色的，系统却不是。 报告说大部分构建已经完成，但测试系统连一个基本的订单到收款流程都跑不通。
2. 设计已经签字，构建却无视它。 配置是根据研讨会笔记做的，而不是根据批准的设计。
3. 计划上有上线日期，却没有人能解释如何到达那一天。 测试、数据加载和切换演练都没有现实可行的时间安排。
4. 范围只增不减。 在 Explore 阶段结束很久之后，WRICEF 清单（报表、接口、转换、增强、表单和工作流）仍在增长。

其中任何一项，都可以靠推一把来解决。两项或更多同时出现，通常就不行了。

第一周是用来弄清真相的。不是用来修复，不是用来追责，也不是用来写新计划。我按以下顺序评估三件事：状态、设计和实际部署的内容。

下表是每项检查涵盖的内容，以及不一致时说明了什么：

检查	我看什么	它回答的问题	如果与其他检查不一致
项目状态	计划、状态报告、RAID 日志、未结的变更请求、实际支出与预算对比	项目对自己的认识是什么？	报告过于乐观，或者与交付脱节
设计	业务流程设计、Fit-to-Standard 产出、WRICEF 清单、悬而未决的设计决策	向业务承诺了什么？	构建已经偏离了约定的内容，或者设计从未完成
实际部署的内容	开发和测试系统、配置、传输请求、自定义代码、目前为止的数据加载	今天实际存在的是什么？	汇报的进展所对应的工作并不在系统里

第三项检查是大多数评审都会跳过的。它意味着坐在系统前面实际运行流程，而不是阅读关于系统的文档。

状态报告和设计文档是声明。系统才是证据。

应该由谁来进行检查

写状态报告的人，不应该是核实这些报告的人。这不是指责。这和审计师不审计自己工作的道理是一样的。

我会让一位独立于实施合作伙伴的人负责第一周的工作，给予他对系统的完全访问权限，并允许他与项目中的任何人交谈。如果做不到，至少要让合作伙伴现场向您展示已部署的系统，而不是用幻灯片展示。

2018 年，我参与了一个航空项目的挽救工作。各个模块都已经部署，但没有任何配置是根据业务需求完成的。

第一周的三项检查，正是为了揭示这种情况而存在的。已部署的模块并不等于一个能用的设计，只有深入系统内部才能看出其中的差别。

航空公司把维护、采购和财务紧密关联在一起，所以一个领域的缺口会蔓延开来。我在 SAP 航空行业页面中讲解了 SAP 如何适配这个行业。

在我主导或挽救过的 21 个 SAP 项目中，我见过的最大错误是在实施开始时没有好好做计划。一次挽救，往往就是在压力之下、迟来地补做当初缺失的计划。

另外两个原因反复出现：

1. 供应商掌控范围。 当系统集成商编写范围时，它描述的是集成商计划交付的内容。缺口会在之后以变更请求的形式出现，而报价的也是同一家供应商。
2. 自定义代码超期。 根据我的经验，自定义代码是迁移中最常超期的阶段，也是最常被遗忘的隐性成本。

预算方面的问题，包括为什么成本会在 Explore 阶段跳升，我在SAP 项目为何超出预算一文中做了讲解。这里不再重复。

控制薄弱是另一个常见的共同点。如果项目从未建立每周跟踪、升级和变更控制的节奏，挽救工作就必须把它建立起来。我的 SAP 项目计划与控制指南列出了这种节奏以及对应的负责人。

一旦您知道了真相，挽救就有一个清晰的顺序。跳过任何一步，通常意味着要把挽救再做一遍。

SAP 项目挽救顺序

1. 01

   诊断

   状态、设计和已部署的内容，相互对照检查。

2. 02

   收回范围

   由客户掌控的范围，冻结，每一项变更都要报价。

3. 03

   重设基线

   基于证据制定一份新计划，应急储备由您这一方掌握。

4. 04

   阶段把关

   在剩余每个阶段的末尾设置质量关卡。

5. 05

   演练并切换

   在确认上线日期之前进行完整的演练。

1. 收回范围的所有权

在任何人重新制定计划之前，先决定由谁掌控范围。如果答案仍然是供应商，新计划会以与旧计划同样的方式失败。

在客户一方编写范围，把它与已部署的内容进行对比，然后冻结。从那时起，每一项变更都是一个有负责人、已经报价的决策。

2. 基于证据只重新设定一次基线

一次挽救只设定一个新基线，而不是一连串的小幅延期。以系统所显示的内容为基础来构建它，而不是以旧计划所期望的内容为基础。

首先重新估算自定义代码，因为超期最常出现在那里。然后是数据，因为数据迁移占工作量的 30% 至 40%，在陷入困境的项目中通常也是落后的。

在您这一方保留 10% 至 20% 的应急储备，只针对具体的风险动用。我的姊妹篇 S/4HANA 迁移成本解释了推动这些数字的因素。

3. 在每个阶段的末尾设置质量关卡

陷入困境的项目，通常是按日期而不是按证据从一个阶段进入下一个阶段的。要纠正这一点。

在 SAP Activate 中，Explore 阶段进行 Fit-to-Standard 研讨会，批准的差异需求进入 Realize 阶段的产品待办清单。如果项目在设计尚未完成时就离开了 Explore，就回去把它完成。SAP Cloud ALM 支持把质量关卡作为带检查清单的检查点，并显示在项目概览上，所以关卡不必放在电子表格里。

4. 在确定日期之前先演练

在棕地转换中，我会在切换前安排三次模拟转换。陷入困境的项目常常为了节省时间而削减演练，这就把风险转移到了上线周末。

我见过的切换停机时间从一个周末到一周不等。一个被挽救的项目，应该通过演练而不是估算来知道自己的数字。

5. 核实您真正面对的截止日期

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束，可选的延长维护到 2030 年底，需额外支付两个百分点（SAP News）。如果一次挽救把 ECC 迁移推迟到 2027 年之后，就应该公开地为延长维护做预算。

不要让 2027 年这个日期逼出一个演练结果并不支持的上线。晚一些上线，花的是维护费。上线失败，代价要大得多。

挽救常常会引出一个问题：是否要保留当前的系统集成商。有时更换合作伙伴是对的。但更多时候，更大的问题在于项目当初的搭建方式，而新的合作伙伴会把它继承下来。

以下是我在做决定之前会提出的问题：

1. 您能否现场展示已部署的系统，并与签字确认的设计相对照？ 不是演示环境，也不是幻灯片。
2. 哪些 WRICEF 对象已经构建、测试并传输，哪些只是被汇报为已完成？
3. 您完成项目的概要设计是什么，有哪些您挽救过与我们类似项目的参考客户可以让我们打电话核实？ 参考案例和概要设计，是我在签约前向任何合作伙伴索要的两样东西。
4. 您需要我们提供什么，而目前没有得到？ 缺失的决策和兼职的关键用户，往往占了问题的一半。
5. 对于 RISE with SAP 客户：哪些问题归 SAP 而不是合作伙伴负责，由谁来升级处理？

危险信号和我在选型时放弃一家合作伙伴的那个信号一样：笼统的回答。如果挽救计划可以适用于任何公司，那它就不是为您的公司写的。我的如何选择 S/4HANA 迁移合作伙伴指南讲解了选型方面的内容。

如果项目从未对源系统进行过像样的评估，现在就做一次。SAP Readiness Check 会分析您现有的系统，SAP 建议在生产系统中运行它，以准确反映真实的使用情况。我关于 SAP Readiness Check 与迁移评估的文章解释了它遗漏了什么，首先就是自定义对象。

与您的项目总监和 SAP 负责人约半天时间，请他们把三样东西并排展示给您看：最新的状态报告、签字确认的设计，以及运行一个完整业务流程的测试系统。如果这三样东西讲的是同一个故事，就推一把。如果不是，就在下一次指导委员会会议之前启动正式的挽救。

如果您希望对一个偏离轨道的项目有一个独立的视角，我帮助企业做的正是这种诊断。您可以与我预约通话。

什么是 SAP 项目挽救？

SAP 项目挽救，是让一个偏离轨道的 SAP 实施或迁移项目重新受控的工作。它从诊断项目状态、设计和实际部署的内容开始，然后收回范围的所有权，设定一个新基线，并在剩余阶段加入质量关卡。

如何判断我的 SAP 项目是否需要挽救？

对比三样东西：状态报告怎么说，签字确认的设计怎么说，以及系统中实际部署了什么。如果它们彼此一致，并且与计划一致，项目需要的是推一把。如果不一致，在现有计划上投入更多努力也解决不了问题，您需要一次正式的挽救。

SAP 实施项目挽救的第一周应该做什么？

只做诊断。评估项目状态，审查设计，并评估实际部署的内容，最好由一位独立于实施合作伙伴的人来主导。在这三项检查完成之前，不要写新计划。

挽救期间应该更换 SAP 实施合作伙伴吗？

不是必然的。请合作伙伴对照签字确认的设计展示已部署的系统，并给出完成项目的概要设计，以及类似挽救项目的参考案例。

如果回答很笼统，那就是应该更换的强烈信号。如果真正的问题在于范围的所有权，或者您这一方缺失的决策，新的合作伙伴也会把它继承下来。

SAP S/4HANA 迁移为什么会偏离轨道？

我见过的最常见的根本原因，是在实施开始时没有好好做计划。让供应商掌控范围是另一个原因，而自定义代码是最常超期的阶段。占工作量 30% 至 40% 的数据迁移，通常也是落后的。

挽救会让我们的 ECC 迁移错过 2027 年的截止日期吗？

有可能。增强包 6 至 8 上的 SAP ERP 6.0 主流维护于 2027 年 12 月 31 日结束，可选的延长维护到 2030 年底，需额外支付两个百分点。要为延长维护做预算，而不是强行推动一个演练结果并不支持的上线。