SAP项目范围模板：该定义什么，该排除什么

SAP项目范围模板定义了项目将要交付什么、有意不交付什么、每个部分由谁负责，以及范围可以如何变更。下面的九个部分涵盖了这些内容。其中最重要的两个，恰恰是团队常常跳过的：明确的排除项，以及数据迁移范围。在配置开始之前填好模板，并由发起人和流程负责人签字。

有时候，团队填完范围模板就往前走了。这一步感觉很轻松。几周之后，在设计或构建期间，有人指出某个流程是“默认在范围内”的。谈话变得不愉快。没有人把它写下来。也没有人有意把它漏掉。这样的事，我见得太多了。开头几个没有核对的假设，会悄悄把项目推离轨道好几周。

范围文档的作用，不是记录人们在会议室里说过什么。它的作用，是在配置把那些难以逆转的假设固定下来之前，逼着大家把事情说清楚。

下面是九个部分，以及每一部分必须回答什么。

1. 目标

为什么要做这项工作，完成之后业务会看到什么？把每个目标与可衡量的结果挂钩：月结缩短三天、去掉三个实体之间的手工对账、所有工厂统一的库存视图。含糊的目标会带来含糊的成功标准，分歧会在用户验收测试（UAT）中浮现出来。

2. 范围定义

模块、法律实体、工厂、国家、语言、集成和部署模式。要具体。“财务”不是范围。“财务会计与管理会计（FI/CO），涵盖S/4HANA Cloud私有版上阿联酋法律实体的应付账款、应收账款、总账和成本中心会计”才是范围。

3. 排除项

大多数范围模板就是在这里失败的。如果某件事没有写明被排除，就会有人认为它被包含在内。要逐一写明的排除项：

1. 推迟到后续阶段的国家或实体。
2. 暂时保持原样的旧系统集成。
3. 某个设定的截止日期之前的历史数据。
4. 移到上线后增强清单中的报表。
5. 因等待法律确认而推迟的监管要求。

为每一项排除，写明它被移到哪个阶段（如果有的话）。一份签了字的排除项，能把一场两周的争论变成一次简短的谈话。

4. 数据迁移范围

这是一个一贯的盲区。要以书面形式回答三个问题：

1. 迁移什么：只迁移未结项目，还是包含历史数据？所有客户和供应商，还是只迁移活跃的？每个工厂的物料，还是只迁移首批上线的实体？
2. 截止规则是什么：未结采购订单、销售订单和工单的截止日期，以及切换时处于进行中的项目如何处理。
3. 哪些改为归档：历史数据的法定保留规定，以及旧系统保持可读的时长。

这里没有记录下来的假设，会在构建期间变成争议。我写的SAP数据迁移为什么失败一文，深入讲了这方面的规划。

5. 非功能范围

这些内容在规划中被丢掉，又在测试后期变成拦路虎浮出水面。要把它们纳入范围：

1. 可用性和维护窗口。在RISE下，引用您合同里的可用性条款。
2. 高峰负载下的性能，例如月末结账。
3. 审计日志：哪些事务，日志保留多长时间。
4. 按角色划分的安全与访问控制。
5. 报表延迟：实时、准实时，还是每日。

它们不是功能。它们是系统必须满足的约束。如果它们不在范围内，就没有人会为它们做设计。

6. 角色与职责

每个工作流都需要一位顾问负责人，以及一位有决策权的业务对口人，两者都要写明姓名。我见得最多的缺口是UAT的归属：谁可以签字确认某个流程已经测试并验收？要在构建开始之前就定下来，而不是在上线前两周。

7. 变更控制

不是“变更需要正式批准”这句话。而是一套具体的流程：什么会触发变更请求、谁评估对时间和预算的影响、谁批准，以及记录什么。没有它，“我们能加上这个吗？”就会变成“我们以为那是包含在内的”，然后是一次没有人计划过的三周延期。

8. 扩展规则

自定义开发将如何批准。SAP现在把扩展分为从A级（仅限已发布的API）到D级（修改核心）的几个级别（SAP News，2025年8月）。在GROW下的公有版上，系统只允许使用已发布的接口。在RISE下的私有版以及本地部署上，核心仍然可以修改，所以范围里应当写明目标级别，以及由谁批准例外。我的Clean Core指南解释了这些级别。

9. 假设与约束

列出范围背后的假设，让有人必须去核对。然后是约束：确定上线日期的监管截止期限、预算上限、只能兼职的人员，以及旧系统的退役日期。

定制是最晚才显现出来的那种范围蔓延。一份获批的自定义报表，会变成五份。一个工作流的例外，会成为此后每一个请求的先例。

在批准任何事情之前，先给每个请求分类：

类别	判断标准	怎么做
必要	没有它，流程在法律上或运营上无法运转	批准，采用成本最低且升级安全的扩展方式
重要但非关键	能提高效率，但不是致命阻碍	只有在有明确的成本效益论证时才批准
不必要	一种偏好，或者是对旧系统运作方式的照搬	质疑它，然后拒绝或推迟

大多数不必要的定制之所以存在，是因为有人不想改变自己的工作方式，而不是因为SAP无法支持这个流程。而且，构建成本只是开始。每一个自定义对象，只要它存在一天，就会增加测试、培训、文档和升级的工作。

设定变更冻结期：选定一个日期，通常在上线前四到六周，此后本次发布不再接受新的请求。之后的一切，都进入上线后的待办清单。冻结期需要有指导委员会的签字作为支撑。只由项目经理宣布的日期，一旦有部门负责人施压，就会被推翻。

1. 01提出请求事先界定什么算变更
2. 02分类必要、重要或不必要
3. 03评估影响对时间和预算的影响，由指定的评估人负责
4. 04决策由指定的批准人批准、拒绝或推迟
5. 05范围版本化新的版本号，以及变更内容的清单

变更冻结之后，新的请求进入上线后的待办清单

分析是范围谈话最容易变得激烈的地方。人人都想要报表，却没有人说要几份。

在设计阶段，商定一份固定的报表清单。问人们需要什么，而不是他们可能想要什么。把每份报表标明是SAP标准输出还是自定义开发，并让这份清单与其余范围一起签字。标准报表的成本，只是自定义报表的一小部分。同时识别每份报表的数据来源；从三个系统取数的报表，就是一项集成需求。如果仪表板和计划也在范围之内，我写的SAP Analytics Cloud指南讲了该先敲定什么。

错误	造成什么	如何避免
目标不可衡量	UAT中围绕“能用”是什么意思发生争议	在一开始就设定可衡量的结果
排除项没有写下来	工作未经批准就被吸收进来	逐一列出不在范围内的事项
数据迁移范围含糊	数据量不对、切换延误、返工	界定迁移什么、截止规则和归档
缺少非功能需求	上线时出现审计和性能问题	把可用性、性能、日志和安全纳入范围
没有指定UAT负责人	测试拖沓，没有人能签字	指定有授权的具体个人
没有变更控制	非正式的追加、被压缩的测试	把变更流程写进范围
没有签字确认	日后范围受到质疑，却无人负责	由发起人和流程负责人签字
分析留到以后	上线前两周才冒出报表需求	在设计阶段商定报表清单
部署模式或扩展规则悬而未决	争论一直拖进构建阶段	在范围签字之前，两者都要定下来

在每个SAP Activate阶段关口，以及每次获批的变更之后，都要复查范围，并带上版本号和变更内容的清单。范围应当通过引用，写入项目章程，让两份文档讲的是同一个故事。

SAP项目范围模板应该包含什么？

九个部分：带有可衡量结果的目标、范围定义（模块、实体、国家、集成、部署模式）、明确的排除项、数据迁移范围、非功能需求、指定的角色、变更控制、扩展规则，以及假设与约束。排除项是最常缺失的部分。

如何防止SAP项目中的范围蔓延？

明确写下排除项，让每一项变更都走正式请求流程，附上影响评估和指定的批准人；在批准之前，先给定制分类；并在上线前四到六周，设定一个经过签字的变更冻结期。目的不是拒绝所有变更。而是让变更看得见、被评估、有授权。

SAP项目中的数据迁移范围是什么？

它界定哪些数据迁入SAP，以及依据什么规则：哪些对象（客户、供应商、物料、未结订单、历史数据）、截止日期，以及哪些改为归档而不是迁移。它决定工作量和时间线，也决定旧系统必须保持可访问多久。

SAP项目中的非功能范围是什么？

系统必须满足的约束，相对于系统所支持的流程而言：可用性、高峰负载下的性能、审计日志、安全与访问控制，以及报表延迟。它们常常被排除在范围之外，然后在测试中才被发现。在受监管的行业里，审计日志是一项法律义务。

范围中应该如何处理定制？

把每个请求分为必要、重要或不必要。对每一项获批的定制，记录需求、标准SAP为何满足不了、工作量、对测试的影响、维护成本以及扩展方式。在私有版和本地部署上，写明目标Clean Core级别，以及由谁批准例外。

SAP项目范围应该在什么时候复查？

在每个SAP Activate阶段关口，每次获批的变更请求之后，以及预算、资源或时间线发生变化的任何时候。保留每个版本，附上日期、版本号和变更内容的摘要。日后范围受到质疑时，这份历史记录会保护团队。