如果你做过 SAP 本地部署项目，习惯的路径大概是：调研需求 → 写蓝图 → 业务要什么就配什么。在 SAP Cloud ERP（S/4HANA Cloud 公有云版）里，这个习惯会让你踩坑。
SAP Activate 是 SAP 为云 ERP 设计的实施方法论。本文讲清楚：每个阶段在公有云项目里到底做什么、要交付什么，以及新人最常犯的错误。
一句话版本： 公有云项目不是从一张白纸开始设计系统，而是从 SAP 预配置好的最佳实践出发，演示给业务看，只有真正不适用的部分才算差异（Gap）。
1. Activate 背后的三个理念
| 理念 | 实际含义 |
|---|---|
| 从可运行的流程开始 | 系统自带 SAP 最佳实践：数百个预配置的业务流程（Scope Item），每个都有流程图、测试脚本和配置内容。顾问是"选择和调整"，而不是从零搭建。 |
| Fit-to-Standard，而不是写蓝图 | 不问"你们现在怎么做？"，而是先演示标准流程，再问"你们的业务能不能按这个方式跑？" |
| 敏捷、迭代 | 配置和测试以短冲刺（Sprint）进行，业务全程参与，而不是先闷头开发、最后一次性测试。 |
在这三点之上还有一条铁律：保持核心干净（Clean Core）。公有云不能修改 SAP 标准代码，所有扩展都必须走官方认可、可平滑升级的方式（见第 4 节）。
2. 六个阶段
Discover → Prepare → Explore → Realize → Deploy → Run
发现 准备 探索 实现 部署 运行
▲Q ▲Q ▲Q ▲Q ▲Q
（每次进入下一阶段前都有质量门 Quality Gate）
Discover 发现 ——"这家公司适合上 Cloud ERP 吗？"
- 了解业务、流程范围以及现有 IT 和集成架构。
- 确认产品能力：Scope Item、相关国家的本地化（Localization）、是否需要额外许可。
- 坦诚说明云模式：标准流程、客户无法跳过的版本升级、每次升级都要回归测试、以及变革管理。
- 交付： 确认实施范围、时间计划和目标方案模型。
Prepare 准备 ——"搭项目、开系统"
- 项目启动会、团队角色、计划和管理机制。
- 开通系统环境。典型的公有云项目先使用 Starter System（预配置好的演示系统，用于 Fit-to-Standard），之后是三系统架构：开发、测试、生产。
- 准备实施工具，通常是 SAP Cloud ALM，用来管理任务、需求、流程文档和测试。
- 在 Central Business Configuration（CBC） 中开始基础配置：选择范围、搭建组织架构。
- 交付： 项目计划、可用的系统环境、确认的 Scope Item。
Explore 探索 ——"Fit-to-Standard 工作坊"
这是公有云项目的核心阶段，项目的价值（或隐患）大多在这里产生。
- 按流程领域，在 Starter System 中用贴近实际的数据演示标准 Scope Item。
- 与关键用户一步一步走完流程。
- 把每个差异归为两类：
- 配置值（如公司代码、工厂、付款条件）——正常、必然存在；
- 差异需求（Delta Requirement）——真正的 Gap，必须说明理由、排优先级、给出解决思路。
- 对每个 Gap 追问：这是真实的业务需要，还是旧系统留下的习惯？
- 交付： 确认的流程、配置值清单，以及差异需求清单（同时识别集成、数据迁移、输出单据、角色权限和扩展开发）。
Realize 实现 ——"按冲刺配置和测试"
- 在 CBC 和开发系统中配置；开发已批准的扩展和接口。
- 使用标准迁移工具（Migrate Your Data）及其模板，反复向测试系统导入数据。
- 与关键用户按冲刺测试：单元测试 → 串联测试 → 集成测试 → 用户验收测试（UAT）。尽量使用测试自动化——每次版本升级都会再用到这些脚本。
- 准备角色权限、培训和切换（Cutover）计划。
- 交付： 测试通过的方案、完成的迁移演练、培训好的关键用户。
Deploy 部署 ——"上线"
- 最后一次迁移演练、执行切换计划、生产数据导入。
- 最终用户培训、Go/No-Go 决策、正式上线。
- 交付： 正常运行的生产系统。
Run 运行 ——"上线支持与持续改进"
- 上线后的 Hypercare 支持。
- 之后是云上永远不会结束的节奏：每个版本发布时，评估新功能、做回归测试、决定采用哪些新能力。
- 交付： 稳定的系统，以及采用新功能的计划。
质量门（Quality Gate）
每次进入下一阶段前，项目都要通过一次质量门：与客户、合作伙伴一起过一张检查清单（范围确认了吗？Gap 有应对方案吗？集成列清楚了吗？资源到位了吗？签字确认了吗？）。把质量门当成帮手——它能在问题还便宜的时候发现期望不一致。
3. 与本地部署项目的区别
| 本地部署的习惯 | Cloud ERP 的现实 |
|---|---|
| 写长篇的现状 / 未来蓝图 | 在预配置的真实系统上做 Fit-to-Standard 工作坊 |
| 在 IMG（SPRO）里想配什么就配什么 | 只能在已激活的范围内，通过 CBC 和配置应用（SSCUI）配置 |
| 业务坚持就改标准代码 | 做不到——只能用可平滑升级的方式扩展 |
| 公司决定何时升级 | 版本按 SAP 的节奏到来，你要回归测试并适应 |
| 大量自定义报表 | 先找标准 Fiori 应用和分析功能，确实需要再建自定义 CDS 视图 |
| 用自开发程序（LSMW 等）导数据 | 使用标准迁移模板和 Migrate Your Data 应用 |
4. 处理 Gap：扩展的"阶梯"
确认一个差异需求后，从上往下依次尝试：
- 改流程——业务能否接受标准做法？（最便宜，最不怕升级。）
- 配置——换一个设置或另一个 Scope Item，可能已经能解决。
- 关键用户扩展（Key-user Extensibility）——自定义字段、自定义逻辑、自定义 CDS 视图、自定义业务对象、表单——在应用里完成，不需要开发人员。
- 开发者扩展（Developer Extensibility）——基于已发布 API 的 ABAP Cloud 开发。
- BTP 旁路扩展（Side-by-side）——在 SAP BTP 上做独立应用或集成。
每往下走一级，开发成本和每次升级后的维护成本都会增加。
5. 新人常犯的错误
- 把 Fit-to-Standard 做成需求访谈。 一上来问"你们需要什么"，得到的就是旧系统。先演示，再讨论。
- 照单全收所有 Gap。 每个 Gap 都是永久成本。多问一句："如果不做，会怎样？"
- 到 Realize 才想起集成。 集成（总部系统、银行、MES、电子发票、税务平台）往往决定项目工期。在 Explore 阶段就要列清楚。
- 低估数据迁移。 数据清洗是业务的工作，从 Explore 就要开始，而不是上线前两周。
- 忘记版本周期。 测试脚本要能重复使用，每年至少要跑两次。
- 拿路线图（Roadmap）上的功能做承诺。 分清"已经发布"和"计划中"。
6. 延伸学习（官方、免费）
- SAP Activate Roadmap Viewer——每个阶段的完整任务清单和加速器（模板）。
- SAP Signavio Process Navigator——所有 Scope Item 的流程图和测试脚本。
- SAP Learning——SAP Cloud ERP 免费入门课程。
- SAP Help Portal——S/4HANA Cloud 公有云版产品文档。