3. 验收标准与合同依据
在S/4HANA项目验收中，最常出现的争议不是“系统能不能跑”，而是“合同里到底承诺了什么”。合同、SOW（工作说明书）、验收条款、KPI与SLA共同构成验收的商务依据，但它们的语言通常是法律化、概括化的，而验收动作需要的是可测量、可复现的技术指标。本节的核心任务，就是完成从“商务约定”到“技术验收指标”的翻译。
一、四类依据文件的分工与优先级
先要厘清四类文件各自回答什么问题。合同主协议回答“双方权利义务与总体交付范围”；SOW回答“具体做什么、不做什么、交付什么”；验收条款回答“以什么程序、什么条件确认交付完成”；KPI与SLA回答“上线后运行质量维持在什么水平”。它们不是并列关系，而是层层细化：合同是骨架，SOW是肌肉，验收条款是关节，KPI/SLA是上线后的体检标准。
当文件之间出现冲突时，必须建立明确的优先级。通常建议的顺序是：合同主协议中的特别约定 > SOW > 验收条款 > 附件中的KPI/SLA。但这一顺序必须在项目启动会上书面确认，否则验收时双方各引一份文件，技术团队将陷入被动。实践中，最稳妥的做法是在SOW中增加“术语与指标定义”章节，把关键指标的计算口径提前锁定。
二、把模糊表述翻译成可验证指标
商务语言与技术语言的最大差异在于“可验证性”。例如SOW中写“报表查询响应迅速”，这是无法验收的；必须翻译为“在标准测试数据集下，FI模块资产负债表查询的P95响应时间不超过3秒，测试并发用户数为50”。翻译过程遵循一个固定结构：对象 + 动作 + 条件 + 阈值 + 测量方法。
以下是一组示例翻译，参数为教学假设，实际项目需以合同约定和基线测试为准：
| 商务原文（示例） | 可验证技术指标（示例） | 测量方法 |
|---|---|---|
| 系统应支持月末结账高效运行 | FI月结关账批处理在4小时内完成，数据量为过去12个月凭证 | ST03N记录批处理作业运行时长 |
| 接口应稳定可靠 | MM-PI-PO接口日成功率≥99.5%，单条消息端到端延迟≤30秒 | SXMB_MONI监控 + 消息日志抽样 |
| 用户操作应流畅 | 核心事务码VA01在50并发下平均响应≤1.5秒，P95≤3秒 | STAD/SM50统计 + 压测工具 |
| 数据迁移应准确 | 期初余额迁移差异为0，未清项条目数差异≤0.1% | 迁移对账报表 + 抽样核对 |
翻译时还要注意“谁提供测试数据、谁执行测量、谁签字确认”。如果SOW只写指标不写测量责任，验收会上就会出现“你说达标、我说没达标”的僵局。建议在验收条款中明确：由乙方执行测量并提交证据，甲方在5个工作日内复核，逾期视为认可。
三、KPI与SLA：上线后的持续验收
KPI与SLA容易被混为一谈。KPI是衡量系统运行效果的指标集合，SLA是这些指标对应的服务承诺等级及违约后果。例如“系统可用率”是KPI，“月度可用率≥99.5%，每低0.1%扣减当月服务费2%”才是SLA。验收阶段要做的，是把SLA中的每个指标落到可采集的数据源上。
以可用率为例，必须定义清楚：统计周期是自然月还是滚动30天；计划内停机是否计入；分母是7×24小时还是工作时间；采集工具是SAP Solution Manager还是第三方监控。这些定义不写清楚，99.5%这个数字就没有意义。同样，性能类SLA要明确采样时段、并发模型和排除条件（如批量作业窗口）。
四、从条款到验收用例的落地路径
完成翻译后，需要把指标组织成可执行的验收用例。每个用例至少包含：用例编号、对应合同/SOW条款、前置条件、测试步骤、预期结果、实际结果、判定结论、证据附件。这样做的价值在于，验收会上可以直接按用例逐条过，而不是凭印象争论。
下面给出一个验收用例的示例结构，供实际项目参考：
用例编号：ACC-FI-007
对应条款：SOW 4.2.3 / 验收条款 5.1
验收对象：FI月结关账批处理
前置条件：已迁移12个月历史凭证，后台作业已配置
测试步骤：
1. 以关账用户执行F.19并触发批处理
2. 记录作业开始与结束时间
3. 检查过账结果与余额一致性
预期结果：批处理≤4小时完成，余额差异为0
实际结果：3小时42分完成，余额差异为0
判定结论：通过
证据附件：ST03N截图、余额对账报表需要强调的是，验收用例不是测试脚本的替代品。功能测试验证“系统做得对不对”，验收用例验证“合同承诺有没有兑现”。两者可以复用部分场景，但判定依据不同：前者看业务正确性，后者看条款符合性。
五、常见风险与应对
第一类风险是“指标孤岛”：SOW写了性能指标，但验收条款没有对应的测量程序，导致指标无法执行。应对方法是在SOW定稿前做一次“可验收性评审”，逐条检查每个承诺是否有对应的测量方法、数据源和责任人。
第二类风险是“基线漂移”：验收时使用的数据量、并发数、硬件配置与合同签订时的假设不一致。应对方法是在SOW中写明基线假设，并约定基线变化时的指标调整机制。
第三类风险是“SLA不可采集”：承诺了指标，但监控工具没有部署或数据保留期不足。应对方法是在上线准备阶段完成监控埋点验证，确保每个SLA指标都有连续、可追溯的数据来源。
把上述内容落到项目动作上，建议在验收准备阶段完成三件事：第一，建立“条款—指标—用例—证据”四列映射表，逐条销项；第二，对每个指标确认数据源可用、保留期足够、采集责任明确；第三，在预验收会上用真实数据跑一遍关键指标，提前暴露偏差。做到这三点，正式验收时技术团队才能把讨论聚焦在“是否达标”，而不是“当初说的是什么意思”。