SAP 实施模板：分阶段指南

SAP Activate 为 S/4HANA 项目中几乎每一项交付物都提供了模板。您可以在 SAP Activate Roadmap Viewer 中找到它们，在云项目中则在 SAP Cloud ALM 里。找到它们很容易。难的是知道该认真对待哪些。

本指南写给正在启动实施的项目经理、PMO 负责人和发起人。它涵盖了我在每个阶段都坚持要有的模板，给出每一份的可用版式，并指出团队在哪些地方偷工减料。如果您在启动会前只有一周时间，先做范围界定文档和相关方矩阵。后面的一切都依赖这两份。

在我做过的制造、零售和金融服务行业的 ECC 和 S/4HANA 项目中，规律是一致的。遵循模板的团队更早发现问题。把它们当作可有可无的文书工作的团队，会在项目中途发现，每一项他们从未写下来的决策，都变成了范围争议。

这是我希望看到完成签批的整套模板，包括每份模板的负责人，以及它必须通过的节点。

阶段	模板	负责人	在此之前完成签批
Prepare	项目范围界定文档	项目经理（发起人批准）	Explore 开始前
Prepare	业务案例	CFO 或业务负责人	资金批出前
Prepare	相关方矩阵	项目经理	Explore 研讨会预约前
Explore	需求和 Fit-Gap 表	解决方案架构师与流程负责人	Realize 开始前
Realize	配置日志	功能负责人	每个传输请求进入 QA 前
Realize	自定义开发登记表	开发负责人	任何对象开始构建前
Realize	测试策略	测试经理	系统集成测试开始前
Realize	数据迁移计划	数据迁移负责人	第一次模拟加载前
Deploy	切换计划	切换经理	最终彩排前
Deploy	上线就绪评估	项目总监（发起人签字）	Go/No-Go 会议前
Run	Hypercare 支持模式	服务交付负责人	上线前
Run	性能监控表	Basis 负责人	上线前

Activate 有六个阶段：Discover、Prepare、Explore、Realize、Deploy 和 Run。它结合了 SAP Best Practices 内容、引导式配置和敏捷交付方法。对大多数客户来说，Discover 发生在合同签订之前，所以下面的模板从 Prepare 开始。

1. 01Discover通常在合同签订之前
2. 02Prepare范围界定文档、业务案例、相关方矩阵
3. 03Explore需求和 Fit-Gap 表
4. 04Realize配置日志、开发登记表、测试策略、迁移计划
5. 05Deploy切换计划、上线就绪评估
6. 06RunHypercare 模式、性能监控

每份模板都在其关口之前完成签批

阶段顺序不是可选的。我合作过一家零售商，它试图跳过其中一部分，最终把三个月的工作重做了一遍。每一道质量关口的存在都有其理由。

调整模板时，保留大约 80% 的标准结构。只改动反映您自身情况的部分：行业要求、监管控制、地区特殊性。把一切都重写，就违背了初衷。

2026 年工具方面有什么变化

Activate 的结构和以前一样。围绕它的工具发生了变化。

1. 在云项目中，SAP Cloud ALM 承载这些模板。 它是 SAP 对 Solution Manager 的继任者，随 SAP Enterprise Support 以及 RISE with SAP 等云订阅一并提供。范围界定、需求、测试计划和切换任务都可以放在那里，彼此之间可追溯。Solution Manager 7.2 的主流维护在 2027 年底结束，部分功能的扩展维护延续到 2030 年，所以现有的本地部署环境还有几年时间，而不是十年。
2. Joule 现在已进入方法论工具。 SAP 在 2025 年让 Joule 在 Activate Roadmap Viewer 和 SAP Cloud ALM 中可用，团队可以据此请求任务指引，或者从路线图起草内容。它加快初稿。它不能取代签署 Fit-Gap 的那个人。
3. Clean Core 现在是带等级的设计规则。 2025 年 8 月，SAP 用四个 Clean Core 等级取代了原来的三层扩展模型，从 A 到 D。A 级只使用已发布的 API，无论是在 SAP BTP 上还是通过 ABAP Cloud 在系统内。D 级则完全不干净。Fit-Gap 模板需要增加一列，说明每个差距最终落在哪里。
4. Public Edition 缩小了 Fit-Gap 的范围。 SAP 现在把 S/4HANA Cloud Public Edition 作为 SAP Cloud ERP 来推广，以 SAP GROW 的名义卖给中型公司。同样的六个阶段适用，只是交付物更轻，而且只允许使用已发布 API 的扩展，所以“差距”一列可能的答案更少。

跳过这项基础工作的项目，要在 Explore 和 Realize 阶段付出代价。

项目范围界定模板

界定项目包含什么、不包含什么。当有人在三个月后想增加范围时（一定会有），这份文档就是参照点。SAP 项目章程位于它之上，承载治理方面的细节。

章节	详情
标题、发起人、项目经理	SAP S/4HANA 财务实施；CFO；指定的资深项目经理
背景	现状和变革的驱动因素
目标	把月结周期从 14 天缩短到 5 天；消除手工对账
范围内	FI/CO、MM/SD 集成、数据迁移、UAT、上线
范围外	HR 模块、遗留报表迁移、ERP 之外的第三方集成
假设	执行发起人能参加每月的指导委员会（SteerCo）；测试数据在第 6 周前商定
约束	固定的上线日期；配置只使用内部资源
交付物	已配置的系统、测试计划、切换计划、培训材料
时间线	Prepare：第 1-4 周；Explore：第 5-10 周；Realize：第 11-26 周
批准	Explore 开始前，需要项目发起人和 PMO 签批

业务案例模板

以财务团队能读懂的格式，逐步走完成本效益分析。我有客户用这个结构一次提交就拿到了项目批准，因为数字清楚、假设都写了下来。

我坚持一条规则：将来负责交付工作的系统集成商，不应该来写这份文档。他们的激励是开始。您的激励是完成。我的 SAP 业务案例模板更深入地讲了收益模型。

章节	详情
负责人和摘要	CFO 或项目总监；为什么是现在，什么会改变，什么保持不变
问题陈述	具体的运营问题（月结周期长度、手工权宜做法、系统年龄）
建议方案	Greenfield / Brownfield / 选择性迁移，附范围摘要
收益	量化：缩短的月结天数、节省的 FTE、错误率下降、审计风险降低
成本和资金	实施、许可或订阅、内部资源时间、应急储备；预算来源
风险	前三项，附概率和影响
建议	推进 / 有条件推进 / 推迟，并说明理由

相关方识别矩阵

梳理受实施影响的所有人及其影响力水平。让您一眼就能看出谁需要每周更新，谁只需要在上线前打个招呼。

相关方	角色	关注点	影响力	参与方式
集团 CFO	执行发起人	项目投资回报、月结改进	高	每月 SteerCo，每周书面更新
IT 总监	技术负责人	系统稳定性、集成、安全	高	每周项目委员会，Realize 期间每天
财务总监	关键流程负责人	FI/CO 设计、月结流程	高	Explore 阶段的研讨会，UAT 签批
工厂经理	受影响的用户	MM/PP 流程变化	中	每月变革沟通，参与 UAT
终端用户（AP/AR）	操作人员	交易层面的变化	低	培训，Hypercare 支持
内部审计	治理	可追溯性、控制、合规	中	在质量关口审阅交付物

用同一张矩阵来规划 Prepare 阶段的研讨会，按部门收集高层级需求。给这些需求编号时，采用您在 Explore 阶段将要使用的格式（REQ-001 等等），这样以后就不会有任何重新编号，追溯到最初诉求的线索也得以保留。

Explore 是实施成形的阶段。这些模板会暴露 SAP 开箱即用的能力与业务所需之间的差距。

需求映射和 Fit-Gap 模板

需求映射按部门记录业务需求，并把每一项追溯到系统组件和测试用例。我见过有的公司跳过它，最终得到了没人使用的系统，因为构建所依据的是顾问的假设，而不是业务说过的话。

Fit-Gap 分析随后显示，标准 SAP 在哪里满足了每项需求，在哪里没有。对我的大多数客户来说，这真是一次大开眼界。我喜欢看到一个团队意识到自己可以使用标准功能、而不是昂贵的自定义代码的那一刻。

我把两者放在同一张表里，并加一列解决路径。在 S/4HANA 上，每个差距都需要一个明确的答案：标准配置、关键用户扩展、系统内的开发者扩展，或者 SAP BTP 上的并行扩展。对 SAP 代码的传统修改是代价最高的答案，应该由指定的批准人来批准。

需求编号	需求	SAP 组件	Fit / Gap	解决路径	测试引用
REQ-001	自动化月末结账凭证	FI-GL，期末结账	Fit	配置循环凭证模板	TC-001
REQ-002	通过 Fiori 审批采购订单	MM 采购，Fiori 审批应用	Gap（ECC 中没有）	标准 S/4HANA 应用和工作流配置	TC-003
REQ-003	公司间开票自动化	SD 开票，FI 集成	Gap	公司间开票配置	TC-010
REQ-004	批处理作业监控	Application Jobs 应用	Fit	标准应用	TC-015
REQ-005	供应商自助门户	SAP Ariba 或供应商门户	Gap	Ariba 集成	TC-020
REQ-006	符合 GDPR 的数据归档	ILM，数据归档	Gap	ILM 策略配置	TC-025
REQ-007	实时成本中心报表	CO，嵌入式分析或 SAC	Gap	嵌入式分析或 SAC 实时连接	TC-030
REQ-008	支持 500 个并发用户	HANA 容量规划	Gap（已测试 300）	容量规划复核和基础设施升级	TC-035

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

配置跟踪模板

记录每一项系统变更：谁做的、为什么做、放进了哪个传输请求。日后出了问题，您几分钟就能追溯到问题，而不是几天。

1. 配置 ID 和模块：[例如 MM-CONF-001，MM]
2. IMG 路径和配置对象：[例如表 T161，采购订单凭证类型]
3. 目的和受影响的业务流程
4. 配置人和日期
5. 传输请求号：[例如 DEVK900123]
6. 关键值：变更前和变更后
7. 关联的测试用例
8. 验证和批准状态

自定义开发登记表

每个自定义对象在任何人写代码之前，都要先占一行。我的一位客户把自定义代码削减了 30%，因为登记表显示了标准 SAP 在哪里完全够用。

开发编号	对象	描述	开发人员	工作量（小时）	状态	扩展类型
CD-001	Fiori 磁贴：成本中心概览	面向财务的实时 CO 报表磁贴	Fiori 开发人员	12	已完成	开发者扩展
CD-002	公司间开票报表	用于公司间对账的报表	ABAP 开发人员	20	进行中	开发者扩展
CD-004	供应商付款状态应用	用于 AP 付款查询的 Fiori 应用	BTP 开发人员	10	待 QA	BTP 上的并行扩展
CD-005	收货通知	收货过账时触发的邮件	集成开发人员	24	已计划	基于事件，在 BTP 上

测试策略模板

把所有测试计划放在一处：谁测什么、何时测、在哪个环境、按什么标准。

章节	详情
范围	对范围内的模块做功能、集成、回归、性能和 UAT 测试（渗透测试归信息安全部门）
环境	DEV、QA、UAT（预生产）、用于最终验证的 staging
工具	在 SAP Cloud ALM 或 Jira/Xray 中做测试管理；用 Tricentis Tosca 或类似工具做自动化；用 JMeter 或 LoadRunner 做性能测试
缺陷生命周期	新建、处理中、已解决、已验证、已关闭；严重程度和优先级在分流时设定
退出标准	所有严重缺陷已关闭；已收到 UAT 签批；回归通过率至少 95%；达到性能基准

数据迁移规划模板

数据迁移是最容易伤到您的工作流。这份模板把它拆成若干步骤，让数据质量问题在切换之前、而不是切换期间暴露出来。数据迁移失败模式一文讲了跳过它会出什么问题。

章节	详情
范围	客户主数据、供应商主数据、未清项、物料主数据、库存余额、成本中心层级
源系统	ECC 6.0 EHP 7（主要）；遗留 HR 系统（员工成本中心分配）
目标系统	S/4HANA（当前版本）
映射和规则	客户和供应商迁移到业务伙伴；成本中心迁移到新层级；删除无效的银行信息；合并重复项
迁移工具	SAP S/4HANA Migration Cockpit（主要）；用于自定义对象的 Migration Object Modeler；用于预处理的脚本
加载策略	在 QA 上做模拟加载；增量迁移和对账；生产切换
验证方法	源到目标的记录数核对；10% 随机抽样；余额对账报表
回退计划	切换前备份；遗留系统待命 48 小时

Deploy 阶段就是您上线的时候。这些模板把一个混乱的周末变成一场受管理的事件。

切换规划模板

按小时规划整个停机窗口。每项任务、每个负责人、每个开始时间。您的团队永远不应该在凌晨 2 点站在那里，不知道下一步该做什么。

在写任务清单之前，先商定四件事：窗口（例如周五 22:00 到周六 06:00）、回退触发条件、遗留系统能多快重新启用，以及证明新系统可以运行的冒烟测试。然后是任务顺序：

步骤	描述	负责人	开始时间	状态
1	冻结 ECC 系统（不再过账）	Basis	22:00	待处理
2	最终数据抽取和对账	数据迁移负责人	22:30	待处理
3	运行生产迁移加载	DBA	23:00	待处理
4	把剩余传输请求导入生产	Basis	00:30	待处理
5	DNS 和负载均衡器切换到 S/4HANA	网络	01:30	待处理
6	冒烟测试：FI 过账、收货、销售订单	QA 负责人	02:00	待处理
7	业务确认和 Go/No-Go 决定	项目总监	03:00	待处理
8	向业务用户开放系统	Basis	06:00	待处理

上线就绪评估

决定您是否真的准备好切换。我有客户根据这份评估推迟了上线，他们事后感谢了我。

领域	检查项（每项回答是或否，并附证据）
功能	关键流程已测试；跨模块场景已完成；未关闭的 P1/P2 缺陷已列出；关键用户确认就绪
数据	主数据加载完成；交易数据已验证；对账报表已批准；遗留系统冻结已确认
技术	切换计划已批准；传输请求已进入生产；批处理作业已排程；监控已配置
人员	培训覆盖率（%）；访问角色已验证；Hypercare 团队已配备；支持计划已沟通
决策	已列出重大风险和缓解措施；Go / No-Go / 有条件通过；由具名人员、角色和日期批准

上线之后，工作的形态变了。这些模板带着系统和团队走过 Hypercare，进入稳态。

上线后支持模板

组织您在上线后如何处理问题。没有它，每个问题都会变成 P1。

章节	详情
Hypercare 窗口	上线后第 1-4 周：全天候（24/7）覆盖
支持渠道	ServiceNow 事件队列（主要）；专用聊天频道；P1 问题的电话会议桥
支持层级	1：服务台（密码、导航、已知问题）；2：功能顾问（流程咨询、小幅配置）；3：Basis 和开发（系统错误、性能、接口）
SLA（响应 / 解决）	严重 15 分钟 / 2 小时；高 30 分钟 / 4 小时；中 4 小时 / 1 天；低 1 天 / 3 天
监控	SAP Cloud ALM 或 Solution Manager；每日审查错误日志
退出标准	没有未关闭的 P1/P2 问题；所有事件都已记录；最终交接签批

性能监控模板

它让您逐日观察系统健康状况，并在用户抱怨之前发现变慢。我最近就这样帮一家公司发现了一个数据库问题，否则它会在月结期间让他们的系统崩溃。

指标	目标	工具	告警阈值	负责人
对话响应时间（第 95 百分位）	低于 1 秒	ST03 / SAP Cloud ALM	2 秒	Basis 团队
后台作业完成率	按计划 100%	SM37 / Application Jobs	任何失败的作业	运维负责人
数据库查询时间	低于 200 毫秒	SAP HANA cockpit	500 毫秒	DBA
系统可用性	高于 99.5%	SAP Cloud ALM	低于 99%	基础设施
接口错误率	低于 1%	SAP Integration Suite 监控	2%	中间件负责人
登录成功率	高于 98%	安全审计日志	低于 95%	安全负责人
月结作业运行时间	在约定的窗口内	作业调度器	比基线高出 30% 以上	财务运营

质量关口防止某个阶段的问题在下一阶段变成昂贵的返工。我的 SAP 质量关口指南讲了如何设置。下面说明它们为什么重要。

上线前的高管签批不应该是走过场。在我参与的一个项目中，CEO 在上线评审时发现了一个大问题，它本来会扰乱财务团队的工作。

在每个关口设定通过或不通过的标准。“95% 的回归测试必须通过。”“所有 FI 集成场景都是绿色。”这样的标准，让您在业务不顾质量、坚持要在某个日期上线时，有一个站得住脚的依据来守住底线。

在我的一个项目中，质量关口在只有 75% 的集成测试通过时拦住了我们。我们先修复了问题，而不是一味赶进度。这为客户节省了大约 10 万欧元的上线后紧急修复费用。

发起人一个电话就能推翻的关口，不是关口。在需要之前，先写下谁有权豁免它。

什么是 SAP Activate 方法论？

SAP Activate 是 SAP 面向 S/4HANA 及其他云产品的实施方法论。它分六个阶段（Discover、Prepare、Explore、Realize、Deploy、Run），结合了 SAP Best Practices 内容、引导式配置和敏捷交付。

针对每种部署场景的任务清单和交付物模板，都发布在 SAP Activate Roadmap Viewer 中。

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

Prepare。范围界定文档、业务案例和相关方矩阵为之后的每一项决策奠定基础，而它们正是团队为了更快开始配置而跳过的。这种捷径是 Realize 阶段范围争议最常见的原因。

Explore 排第二。Fit-Gap 和需求映射文档中的缺口，几个月后会以 UAT 缺陷的形式浮现，那时修复它们的成本，远高于在 Explore 第 3 周的时候。

可以定制 SAP Activate 模板吗？

可以。保留大约 80% 的标准结构，只改动您自身情况特有的部分：制药行业的验证、公共部门的采购规则、SOX 控制。在 Prepare 阶段开始时加入这些，而不是在 Deploy 阶段。

不要定制质量关口结构、阶段顺序，以及必须有的交付物（范围界定文档、业务案例、上线就绪评估）。

SAP Activate 模板对 Greenfield 和 Brownfield 都适用吗？

适用。主要区别在 Explore。Brownfield 转换会沿用现有配置，所以 Fit-Gap 关注的是哪些必须改变、标准 S/4HANA 现在可以替代哪些自定义代码，以及转换之前需要做哪些数据清理。Greenfield 项目则从 SAP Best Practices 出发，确认哪些标准流程适用。

切换计划也不同。Brownfield 的系统转换，其顺序与带完整数据迁移的 Greenfield 上线不同。

切换计划应该详细到什么程度？

至少精确到每小时，对于停机窗口还要更细。每项任务都需要有开始时间、负责人和依赖项。

在切换开始之前，先商定回退标准：什么情况会触发回到遗留系统，由谁做这个决定，以及在几点之前。凌晨 4 点在没有预先商定标准的情况下做出的回退决定，正是上线后灾难的开端。