SAP 实施模板：按阶段划分的 SAP Activate 模板集

SAP Activate 模板是 SAP 为 S/4HANA 项目每个阶段发布的实施模板和加速器，从 Prepare 阶段的范围界定文档到 Deploy 阶段的切换计划。您可以在 SAP Activate Roadmap Viewer 中找到它们，云项目还可以在 SAP Cloud ALM 中找到。

简短的回答：您不需要全部模板。您需要的是十来份，每份都有具体负责人和签批时点，并且应保留 SAP 标准结构的约 80%。下表是我在亲自主导或挽救的 21 个 SAP 项目中坚持要求的一套模板。

找到模板很容易。难的是知道哪些要认真对待。

这是我要求完成签批的一套 SAP 实施模板，列出了负责人和每份模板必须通过的时点。

阶段	模板	负责人	签批时限
Prepare	项目范围界定文档	项目经理（发起人批准）	Explore 开始前
Prepare	业务论证	CFO 或业务负责人	资金下拨前
Prepare	干系人矩阵	项目经理	Explore 研讨会排期前
Explore	需求与差异分析表	设计委员会（业务和 IT）	Realize 开始前
Realize	配置日志	各模块功能负责人	每个传输请求进入 QA 前
Realize	定制开发登记表	开发负责人	任何对象开始开发前
Realize	测试策略	测试经理	系统集成测试开始前
Realize	数据迁移计划	数据迁移负责人	第一次模拟导入前
Deploy	切换计划	切换经理	最终彩排前
Deploy	上线就绪检查清单	项目总监（发起人签字）	Go/No-Go 会议前
Deploy	Hypercare 支持模式	服务交付负责人	上线前
Run	性能监控表	Basis 负责人	上线前

SAP Activate 有六个阶段：Discover、Prepare、Explore、Realize、Deploy 和 Run。它结合了 SAP Best Practices 内容、方法论和引导式配置。Discover 是不作承诺的调研阶段，因此对大多数客户来说，它在合同签订前就结束了，下面的模板从 Prepare 开始。

1. 01Discover通常在合同签订前
2. 02Prepare范围界定文档、业务论证、干系人矩阵
3. 03Explore需求与差异分析表
4. 04Realize配置日志、开发登记表、测试策略、迁移计划
5. 05Deploy切换计划、上线就绪、Hypercare
6. 06Run性能监控

每份模板在对应关口前完成签批

在 Roadmap Viewer 中，每个路线图分为阶段、交付物和任务。模板以加速器的形式归档：操作指南、样例文档和检查清单，挂在需要它们的任务下。您可以按阶段、工作流或加速器筛选，这是提取某一阶段 SAP Activate 交付物最快的方法。

调整模板时，保留约 80% 的标准结构。只改体现您自身情况的部分：行业要求、监管内控、地区特性。全部重写，就失去了使用模板的意义。

工具上的变化

阶段结构没有变。周边的工具变了。

1. 在云项目中，模板位于 SAP Cloud ALM。 它提供给享有 SAP Enterprise Support 的客户，并随 RISE with SAP 等 SAP 云订阅一同提供。Solution Manager 7.2 的主流维护到 2027 年底，部分功能的延长维护到 2030 年。
2. Joule 已进入方法论工具。 SAP 在 2025 年把 Joule 加入了 Roadmap Viewer 和 SAP Cloud ALM，团队可以请它提供任务指导或初稿。它不能取代在差异分析上签字的人。
3. Clean Core 现在分级了。 2025 年 8 月，SAP 推出了 A 到 D 四个 Clean Core 等级：A 级只使用已发布的 API，D 级则不属于 Clean Core。您的差异分析表需要一列，标明每个差异将落在哪个等级。

跳过这些基础工作的项目，会在 Explore 和 Realize 阶段付出代价。下面三份文档，是团队为了更快进入配置而跳过的。

项目范围界定文档

它界定项目包含什么、不包含什么。三个月后有人想追加范围时（一定会有），它就是依据。

我期望看到的部分：

1. 名称、发起人和项目经理。
2. 背景：现状和变革的理由。
3. 量化目标，例如“结账周期从 14 天缩短到 5 天”。
4. 范围内：按模块和流程列出（FI/CO、MM/SD 集成、数据迁移、UAT、上线）。
5. 范围外：写得和范围内一样明确（人力资源、旧报表迁移、非 ERP 接口）。
6. 假设和约束，例如发起人能出席每月的指导委员会，以及固定的上线日期。
7. 分阶段时间表，在 Explore 开始前由发起人和 PMO 签批。

时间表要按现实情况来定。根据我的经验，GROW 项目需要 6 到 9 个月，RISE 需要 9 到 18 个月，Brownfield 转换需要 12 到 18 个月，Greenfield 需要 18 到 24 个月；我的 SAP 实施时间表指南 按阶段做了拆解。

业务论证模板

它用财务团队看得懂的格式列出成本收益分析。我有客户用这个结构第一次提交就获得了项目批准，因为数字清楚，假设也写明了。

结构如下：

1. 负责人和摘要：为什么是现在，什么会变，什么不变。
2. 问题陈述：结账周期长度、手工变通做法、系统老化程度。
3. 建议方案：Greenfield、Brownfield 或选择性迁移，并附范围摘要。
4. 量化收益：缩短的结账天数、FTE 工时、差错率、审计风险。
5. 成本和资金：实施、许可或订阅、内部工时、应急预算。
6. 三大风险，及其概率和影响。
7. 建议：推进、有条件推进或推迟。

我坚持一条原则：负责交付的系统集成商不应编写这份文档。他们的动机是开工。您的动机是完工。我的 SAP 业务论证模板 对收益模型讲得更深入。

干系人矩阵

它列出受实施影响的每个人、他们的影响力以及您如何与他们沟通。它告诉您谁需要每周更新，谁需要在上线前提前打招呼。

为每个群体记录角色、关注点、影响力和沟通方式。典型的组合是：作为发起人的 CFO（每月指导委员会）、作为技术负责人的 IT 总监、作为关键流程负责人的财务总监、作为受影响用户的工厂经理和应付/应收用户，以及在质量关口参与的内部审计。

用同一份矩阵规划 Prepare 阶段收集高层需求的研讨会。现在就按 Explore 阶段将使用的格式编号（REQ-001 等），这样才能一直追溯到最初的需求。

Explore 阶段通过对照 SAP Best Practices 的 Fit-to-Standard 研讨会确定设计。这也是 SAP 预算超支的地方，因为 WRICEF 数量（工作流、报表、接口、转换、增强和表单）在这里增长。

不要让阶段顺序走样。2023 年在欧洲的一个零售项目中，客户试图跳过 Explore，结果在不完整的需求上开发了三个月。我的 SAP 实施成本拆解 说明了这类返工如何变成预算。

需求与差异分析表

需求映射把每项业务需求追溯到一个系统组件和一个测试用例。差异分析再显示标准 SAP 在哪里满足需求，在哪里不满足。

我把两者放在一张表里，并设一列写解决路径。在 S/4HANA 上，每个差异都需要明确的答案：标准配置、关键用户扩展、系统内的开发者扩展，或基于 SAP BTP 的并行扩展。

需求 ID	需求	SAP 组件	匹配 / 差异	解决路径	测试编号
REQ-001	月结分录自动化	FI-GL 期末结账	匹配	循环凭证配置	TC-001
REQ-002	移动端采购订单审批	MM 采购、Fiori 审批应用	S/4HANA 中匹配	标准应用和工作流配置	TC-003
REQ-003	公司间开票自动化	SD 开票、FI 集成	匹配	公司间开票配置	TC-010
REQ-004	满足隐私规则的数据归档	Information Lifecycle Management	差异	ILM 策略配置	TC-025
REQ-005	实时成本中心报表	CO、嵌入式分析或 SAC	差异	嵌入式分析或 SAC 实时连接	TC-030
REQ-006	供应商自助门户	SAP Ariba 或供应商门户	差异	Ariba 集成	TC-020

省钱就省在这里。2023 年欧洲一家制造企业从 ECC 迁移到 S/4HANA，差异分析研讨会使计划中的增强减少了 35%，节省金额达到六位数。

让这张表发挥作用有两条规则。供应商不能掌控范围，因为他们标记为开发的每个差异，都是他们可以计费的工作。由业务和 IT 组成的设计委员会负责 Clean Core 决策，对 SAP 代码的修改需要有具名的审批人；我的 SAP Clean Core 策略 解释了各个等级。

这是构建阶段。这些模板是每项配置决策、每项开发和每个测试结果的审计轨迹。

配置日志

它记录每一项系统变更：谁改的、为什么改、放在哪个传输请求里。日后出了问题，您可以在几分钟而不是几天内追查原因。

每条记录需要：

1. 配置 ID 和模块（例如 MM-CONF-001）。
2. 配置路径和变更对象。
3. 受影响的业务流程和变更原因。
4. 配置人和时间。
5. 传输请求编号。
6. 关键值的变更前和变更后。
7. 关联的测试用例和审批状态。

定制开发登记表

每个定制对象在任何人写代码之前都要先登记一行：ID、描述、开发角色、工作量、状态和扩展类型。Clean Core 就是靠扩展类型这一列来落实的。

2024 年在欧洲一家零售企业的 S/4HANA 实施中，这份登记表使计划中的定制代码减少了 30%。它显示出标准 SAP 完全够用的地方。

测试策略

它把所有测试集中在一处：谁测什么、何时测、在哪个环境测、按什么标准测。

1. 范围：覆盖范围内模块的功能、集成、回归、性能测试和 UAT。
2. 环境：开发、QA、UAT 和预生产。
3. 工具：在 SAP Cloud ALM 或现有工具中进行测试管理，并写明自动化和性能测试工具。
4. 缺陷生命周期，严重度和优先级在分诊时确定。
5. 退出标准：所有严重缺陷关闭，UAT 签批，回归通过率达到事先约定的水平。

SAP Activate 的 Realize 阶段以集成测试和用户验收测试收尾。退出标准要在测试开始前写好，而不是等结果出来再定。

数据迁移计划

数据迁移是最容易让您吃亏的工作流。计划涵盖范围（业务伙伴、物料、未清项、余额）、源系统、映射规则、工具（SAP S/4HANA 迁移驾驶舱）、模拟导入、验证和回滚。

验证是团队最常低估的部分：在第一次模拟导入前，就记录数、抽样和余额核对达成一致。

在 SAP Activate 中，Deploy 涵盖生产环境搭建、切换、上线和 Hypercare。这些模板把一个混乱的周末变成一次受控的行动。

SAP 切换计划模板

切换计划把停机窗口按小时排定。每项任务都有负责人、开始时间和依赖关系。凌晨 2 点不应有人站在那里不知道下一步做什么。

写任务清单之前，先就四件事达成一致：窗口（例如周五 22:00 到周六 06:00）、回滚触发条件、旧系统能多快重新启用，以及证明新系统可用的冒烟测试。然后是顺序：

步骤	任务	负责人	开始	状态
1	冻结旧系统（停止过账）	Basis	22:00	待执行
2	最终数据抽取和核对	数据迁移负责人	22:30	待执行
3	生产迁移导入	数据迁移负责人	23:00	待执行
4	导入剩余传输请求	Basis	00:30	待执行
5	切换接口和网络路由	集成负责人	01:30	待执行
6	冒烟测试：FI 过账、收货、销售订单	QA 负责人	02:00	待执行
7	业务确认和 Go/No-Go	项目总监	03:00	待执行
8	向业务用户开放系统	Basis	06:00	待执行

上线就绪检查清单

它决定您是否真的可以切换。每一项都用是或否回答，并附证据。

1. 功能：关键流程和跨模块场景已测试，未关闭的 P1 和 P2 缺陷已列出，关键用户确认就绪。
2. 数据：主数据和交易数据已导入并核对，核对报告已批准，旧系统冻结已确认。
3. 财务：每个公司代码和实体的期末结账配置均已测试。
4. 技术：切换计划已批准，传输请求已进入生产，批处理作业已排程，监控已配置。
5. 人员：培训覆盖情况，访问角色已验证，Hypercare 团队已到位。
6. 决策：重大风险和缓解措施，Go / No-Go / 有条件上线，按姓名、角色和日期审批。

财务这一项有它的道理。2024 年在 GCC 的一个零售项目中，上线评审在上线前两天发现了全部 25 个实体的财务结账配置问题；如果没发现，会引发六位数的补救成本。

我曾用这项评估在两个项目上建议推迟两周。这正是它的用途。

Hypercare 支持模式

它安排上线后如何处理问题。没有它，每个问题都会变成 P1。

1. Hypercare 周期和覆盖范围，例如四周，延长工作时间。
2. 支持渠道：事件队列、聊天频道和用于 P1 的电话会议桥。
3. 支持层级：服务台、功能顾问，然后是 Basis 和开发。
4. 按严重度划分的响应和解决时间。
5. 退出标准：没有未关闭的 P1 或 P2 问题，并已签署移交给运维支持组织的文件。

Run 是对上线系统的支持和管理。大多数团队过早放下的模板，是监控性能的那一份。

性能监控表

它每天跟踪系统健康状况，让您在用户抱怨之前发现变慢。2024 年在欧洲一个金融服务项目中，它在 Hypercare 第 3 周发现了一个数据库问题，否则系统会在月结期间崩溃。

我跟踪的指标，每项都设目标、告警阈值和负责人：

1. 对话响应时间（第 95 百分位）：目标低于 1 秒，2 秒告警，Basis。
2. 后台作业：100% 按计划完成，任何失败即告警，运维负责人。
3. 数据库查询时间：目标低于 200 ms，500 ms 告警，数据库管理员。
4. 接口错误率：低于 1%，2% 告警，集成负责人。
5. 月结作业运行时间：在约定窗口内，超出基线 30% 告警，财务运营。

SAP Activate 在各阶段路线图中内置了质量关口，每个阶段都有检查点。我的 SAP 质量关口 指南讲了如何设置；这里说说为什么关口必须有约束力。

在每个关口设定通过和不通过的标准。“95% 的回归测试通过。”“所有 FI 集成场景都是绿色。”有了这样的标准，当业务方不顾质量也要按日期上线时，您才能守住底线。

2024 年在欧洲的一个制造项目中，集成测试通过率只有 74% 时，质量关口让我们停了下来。我们守住了，修复了问题，两周后上线。上线后第一个月的支持工单只有同类项目通常水平的一半。

高管签批也不应走过场；上面提到的 GCC 零售财务结账问题，恰恰是在那次评审中发现的。发起人一个电话就能推翻的关口，算不上关口。在需要之前，就写明谁有权豁免它。

围绕这些模板的完整流程，请参阅我的 SAP 实施分步指南。

本指南是我的SAP 实施指南的一部分，该指南汇总了从业务论证到上线的所有主题。

在哪里可以下载 SAP Activate 模板？

在 me.sap.com/roadmapviewer 的 SAP Activate Roadmap Viewer 中。打开与您的部署方式对应的路线图，再按阶段或加速器筛选，即可看到每项任务的模板、指南和检查清单。

在云项目中，同样的内容也可以在 SAP Cloud ALM 中使用，任务和交付物可以按项目进行跟踪。

SAP Activate 每个阶段的交付物是什么？

Prepare 交付范围、计划、治理和业务论证。Explore 交付 Fit-to-Standard 结果、需求和差异待办清单以及解决方案设计。Realize 交付配置完毕并经过测试的系统，包括集成测试和用户验收测试。

Deploy 交付切换、上线和 Hypercare。Run 涵盖对上线系统的支持和改进。

SAP Activate 哪个阶段的模板最重要？

Prepare。范围界定文档、业务论证和干系人矩阵决定了之后的每一个决策，而它们也正是团队为了更快进入配置而跳过的。

Explore 紧随其后，因为差异分析表决定 WRICEF 数量，而预算正是在那里超支的。

可以定制 SAP Activate 模板吗？

可以。保留约 80% 的标准结构，只改您特有的部分：制药行业的验证规则、公共部门采购、SOX 内控。这些修改要在 Prepare 开始时完成，而不是在 Deploy。

不要通过定制去掉阶段顺序、质量关口或上线就绪评估。

SAP 切换计划模板应该包括什么？

一份针对停机窗口、带时间安排的任务清单，每项任务都有负责人、开始时间和依赖关系。在任务清单之前，先就窗口、回滚触发条件、重新启用旧系统所需时间和冒烟测试达成一致。

在切换开始前，约定由谁在什么时间点之前做回滚决定。凌晨 4 点在没有约定标准的情况下做出的回滚决定，正是上线后问题的开端。

SAP 上线就绪检查清单包括哪些内容？

功能、数据、财务、技术和人员的就绪情况，每项都用是或否回答并附证据，再加上一份记录了姓名和日期的 Go / No-Go 决定。

上线前测试每个实体的期末结账配置。这是最有可能让您免于六位数补救成本的检查。

SAP Activate 模板适用于 Greenfield 和 Brownfield 吗？

适用。差别主要在 Explore。Brownfield 转换会沿用现有配置，因此差异分析聚焦于必须改变的内容，以及哪些定制代码现在可以由标准 S/4HANA 取代；Greenfield 项目则从 SAP Best Practices 起步。

切换计划也不同，因为系统转换遵循的技术顺序与 Greenfield 的数据导入不同。