SAP 工作说明书：必须包含哪些内容

SAP 工作说明书（SOW）是一份合同文件，说明合作伙伴将交付什么、投入多少工作量、由谁来做，以及如何变更。它必须涵盖范围、详细的假设条件和排除项、按阶段和角色划分的工作量、带验收标准的交付物、具名资源以及变更控制。

大多数工作说明书对范围写得还算充分。客户常常遗漏的是详细的假设条件和排除项，而正是这一部分决定了您最终要付多少钱。

本文是我的如何选择 SAP 实施合作伙伴指南的一部分。工作说明书是这一流程的最后一步，排在 SAP 合作伙伴需求建议书和述标之后。如需一个签约前审查工作说明书的实例，请阅读我关于 ERP 合同谈判的案例研究。

一份好的 SAP 工作说明书读起来就像项目的操作手册。您这边的任何人打开它，都应该能回答三个问题：我们会得到什么，它取决于什么，以及发生变化时会怎样。

下面是它需要的各个部分，以及缺少某一部分时会出什么问题：

部分	应该写什么	写得单薄会怎样
范围	范围内的流程、模块、公司代码、工厂、国家和用户	每一次研讨会都会重新讨论到底包含了什么
假设条件	报价所依赖的条件，每一条都写明不成立时的后果	合作伙伴提出您无法质疑的变更申请
排除项	合作伙伴不做什么，以及改由谁来做	工作落在您和合作伙伴之间，没有人负责
方法和阶段	方法、阶段计划和质量关口	没有商定的阶段完成节点
工作量	按阶段和角色估算的工作量	您无法判断消耗速度是否符合计划
交付物和验收	具名的文档和产出、验收标准、签字确认期限	为不完整的工作支付发票
资源	具名的关键人员、角色、投入比例和替换规则	您在述标时见到的团队，不是到现场的团队
客户职责	您的人员必须提供什么，以及何时提供	您这边造成的延误变成了合作伙伴的变更申请
变更控制	变更如何提出、评估、定价和批准	变更申请变成了第二条收入线
治理	指导委员会、报告、升级机制	问题暴露得太晚，那时代价已经很高

在询价之前自己写好范围，让合作伙伴按您的范围报价，而不是按他们自己的范围。

这是客户经常遗漏的部分。没有它，报价就建立在您这边没有人读过、也没有人同意过的条件之上。

假设条件是合作伙伴报价时所依据的条件。排除项是合作伙伴根本没有报价的工作。两者都需要写得足够具体，让第三方能够核查它们是否成立。

需要写下的假设条件类型

每一条假设都需要一个后果。“如果这一条不成立，变更将通过变更控制并附影响评估”，这句话把假设从装饰变成了控制手段。

SAP 工作说明书应该涵盖以下类别：

1. 组织范围。 报价所覆盖的公司代码、工厂、销售组织、国家和法人实体的数量。
2. 流程范围。 列明范围内的业务流程，以及合作伙伴预期您会采用的 SAP 标准流程。
3. WRICEF 数量。 按复杂度划分的工作流、报表、接口、数据转换、增强和表单的数量。随着这份清单在 Explore 阶段不断增加，预算会被突破，所以基线数量应该写进合同。
4. 数据。 需要迁移的数据对象、历史数据量、模拟加载次数，以及由谁清洗数据。
5. 集成。 列明每一个接口、另一端的系统，以及由谁修改那个系统。
6. 测试。 测试轮次、由谁编写脚本、由谁执行，以及由谁修复缺陷。
7. 客户可用性。 需要您的哪些人员、投入多少时间，以及决策必须多快做出。
8. 系统环境和许可。 由谁提供系统、工具和访问权限，以及何时提供。
9. 地点和语言。 团队在哪里工作、在岸与离岸的比例、差旅，以及文档和培训使用的语言。
10. 培训和上线后支持。 培训模式、培训的讲师人数，以及上线后支持（hypercare）的时长和退出标准。

WRICEF 基线对预算最为重要。SAP 自己的课程材料把 Explore 阶段描述为适配标准（fit-to-standard）分析，在这一阶段，经批准的差异需求会被加入 Realize 阶段的产品待办清单（SAP Learning）。每一项经批准的差异都可能变成新的 WRICEF 工作量，所以您需要初始数量来衡量增长。

需要写下的排除项类型

排除项应写明改由谁来做这项工作。只写“排除”而没有负责人，就是一个等着在切换期间被发现的缺口。

以下是常见的类别：

1. 历史系统中的数据清洗和数据补充，通常是客户的任务。
2. 接口另一端第三方系统和历史系统的修改。
3. 软件许可和订阅，它们属于您与 SAP 的合同，而不在工作说明书中。
4. 基础设施和托管，除非明确由合作伙伴运营。
5. 最终用户培训的实施，合作伙伴只负责培训您的讲师。
6. 组织变革管理，超出所列内容的部分。
7. 安全、角色和权限设计，如果由另一方负责。
8. 性能测试、渗透测试和回归测试，在列明的测试轮次之外的部分。
9. 不在组织范围内的国家、实体或本地化。
10. 上线后支持期结束后的应用支持，这是另一份合同。

与您的项目总监一起把这两份清单对照着读。凡是两份清单中都没有出现的内容，就是变更申请将要冒出来的地方。

我为 SAP 实施推荐的商务模式是人天计价（T&M），并量化工作量。也就是说，把按阶段和角色估算的工作量写进合同，这样您每个月都可以把实际工作量与之对比。

固定总价在董事会看来更安全。实际上，只有在每一项假设都成立时价格才是固定的，而一个 SAP 项目到 Explore 阶段结束时，大多数假设都已经受过检验。我关于 SAP 实施成本的笔记介绍了固定总价的阶段在什么情况下仍然有意义。

下面是两种模式在工作说明书中的对比：

对比点	固定总价	量化工作量的人天计价
合同固定了什么	价格，在假设成立期间	费率，以及按阶段和角色估算的工作量
风险在哪里	合作伙伴把它作为风险准备金计入报价	在您这边，但每个月都看得见
范围变化时	每一次变更都变成一次谈判	工作量变化，您可以对照估算看到
您能跟踪什么	里程碑和变更申请	按阶段和角色划分的实际工作量与计划的对比
什么在保护您	严密的假设条件和排除项	严密的假设条件、排除项和工作量报告

量化的工作量把人天计价从一张空白支票变成了一笔受控的预算。要求对方以阶段对角色的表格形式、以人天为单位提供估算，并把每月对照该表格报告列为合同义务。

不要让费率藏在工作量里。用我的 SAP 项目资源分配规划指南，把角色构成与市场费率进行对比。

前期资深人天多、后期初级人天多的计划很常见。反过来则需要一个解释。

交付物是一个有完成定义的具名产出。“设计支持”不是交付物。一份经过签字、按商定标准审查过的记录到报告（record to report）解决方案设计文档才是。

把验收与质量关口挂钩

SAP Activate 分为六个阶段：Discover、Prepare、Explore、Realize、Deploy 和 Run。SAP 描述了每个阶段之后的正式质量关口，用于在项目推进之前检查该阶段的交付物是否完整（SAP Learning）。

在工作说明书中使用这些关口。列出每个关口应交付的交付物、验收标准，以及您有多少天时间审查。把付款与已验收的交付物挂钩，而不是与日历挂钩。

您这边必须有人能够评判这些文档。这是我建议引入独立顾问的三个节点之一：签约期间、设计阶段以及评估合作伙伴的交付物。我关于 SAP 合作伙伴与独立顾问的文章解释了这两种角色如何协同工作。

写明人员，并核查他们

拟派人员素质不高，是让我放弃一份投标的两件事之一。另一件是合作伙伴讲不清楚架构和计划。

工作说明书应该写明解决方案架构师、项目经理以及每一位功能和技术负责人。写进他们的投入比例、您面试替换人员的权利，以及每一次人员替换都需要您批准。关于 ERP 合同谈判的案例研究展示了具名资源条款的实际运用。

核查认证，而不是轻信简历。SAP 通过 Credly 颁发认证徽章，支持实时核验（SAP Learning）。根据 SAP 的认证保持流程，如果持有人错过了强制评估，认证就会失效（SAP Learning）。

这项条款比看上去更重要。我曾在项目进行中更换过合作伙伴，起因是那家合作伙伴提供不了高素质的资源。我的项目中途更换 SAP 合作伙伴指南介绍了在走到那一步之前必须先保全的东西。

单薄的工作说明书，正是在变更控制上变得昂贵。如果假设条件含糊，几乎任何事情都可以被说成是变更。

一个可行的变更控制部分需要以下要素：

1. 触发条件。 只有当某项假设不成立、某个排除项被纳入范围或者您提出新的要求时，才构成变更。
2. 影响评估。 在开工之前，以书面形式说明范围、按角色划分的工作量、时间和成本。
3. 费率表。 变更按合同费率定价，除非另有约定，不因紧急而加价。
4. 审批权限。 您这边谁可以批准多大金额以内的变更，超过设定门槛则由 CFO 批准。
5. 日志。 每一项变更，无论批准还是否决，都连同累计总额一起报告给指导委员会。
6. 与基线挂钩。 新增的 WRICEF 对象对照假设条件中的数量来衡量。

合作伙伴会提出合理的变更。SAP 项目总会发现一些签约时没人知道的事情。目标是让每一项变更在任何人花钱之前，都是可见的、已定价的、已批准的。

在我主导或挽救过的 21 个 SAP 项目中，我看到的最大错误就是在一开始没有做好规划。工作说明书是这项规划变得具有约束力的地方，与有争议的变更申请相比，花在它上面的时间很便宜。

具体的下一步：拿出您手头的工作说明书，把每一条假设条件和排除项列在一页纸上。在每一条旁边，写下它一旦出错会怎样，以及由谁付钱。如果您填不出这一栏，这份工作说明书就还不能签。

如果您希望在签约前对 SAP 工作说明书获得独立的审阅意见，我会在签约阶段为客户提供这方面的帮助。您可以在这里联系我。

SAP 工作说明书应该包含什么？

范围、详细的假设条件、排除项、方法和阶段、按阶段和角色估算的工作量、带验收标准的交付物、具名资源、客户职责、变更控制和治理。最常写得单薄的是假设条件和排除项，而正是这一部分决定了最终成本。

SAP 工作说明书中的假设条件和排除项有什么区别？

假设条件是合作伙伴报价时所依据的条件，例如公司代码或 WRICEF 对象的数量。排除项是合作伙伴根本没有报价的工作，例如历史数据清洗。每一条假设都应写明不成立时会怎样，每一个排除项都应写明改由谁来做。

SAP 实施采用固定总价还是人天计价更好？

我推荐量化工作量的人天计价：把按阶段和角色估算的工作量写进合同，并每月跟踪。固定总价只有在每一项假设都成立时才站得住，而一个 SAP 项目在 Explore 阶段就会检验大多数假设。

如何为 SAP 交付物制定验收标准？

写明每一项交付物，描述完成是什么样子，并为您的团队设定审查期限。把它们与每个阶段结束时的 SAP Activate 质量关口挂钩，只有在交付物通过验收后才付款。

SAP 工作说明书应该写明顾问的名字吗？

应该，至少对关键角色：解决方案架构师、项目经理以及功能和技术负责人。加上他们的投入比例、您面试替换人员的权利，以及任何人员替换都需要您批准。通过 Credly 上的 SAP 徽章核验认证，而不是依赖简历。

SAP 工作说明书应该由谁来写？

由合作伙伴起草，但范围和假设条件应该来自您。在询价之前写好您的范围，并在签约前请一位独立于合作伙伴的人审查假设条件、排除项和交付物。