MES 项目验收标准的制定方法

为什么验收标准要提前定

很多 MES 项目的验收拖了半年甚至一年，原因是验收标准模糊：

• "系统要好用"——什么叫好用？
• "要满足我们的需求"——需求清单一直在变
• "要稳定"——多稳定算稳定？

到了验收阶段，双方对"完成"的理解不一致，就会陷入拉锯。

验收标准必须在项目启动阶段就定下来，写进合同。

四类验收指标

一、功能验收

核心原则：逐条对应，量化判定。

做法：

1. 在需求确认阶段产出一份功能清单，每条有唯一编号
2. 每条功能明确验收方式（演示 / 测试 / 文档审查）
3. 验收时逐条过，判定"通过 / 不通过 / 部分通过"
4. 部分通过的要写明差距和补救计划

功能清单要冻结。项目中途可以变更，但要走变更流程，且影响工期和成本。

判断标准要写具体，例如：

二、数据验收

这是最容易被忽略但最重要的一类。

这些指标要抽样验证，并留存记录。

验证方法：随机选 N 个样本，人工核对，记录差异数。

三、性能验收

性能测试要在模拟真实并发的条件下做。单人测试响应很快，100 人同时用可能就崩了。

四、使用率验收

这是最实际但也最常被忽略的指标。

使用率是最好的验收标准，因为它直接反映了系统是否真的被用起来了。

系统功能再全，没人用也是失败的。

验收的组织

分阶段验收

不要等到最后一次性验收。建议分三段：

1. 基础数据验收：数据导入完成后
2. 功能验收：试运行结束后
3. 终验：上线稳定运行 1-3 个月后

分阶段的好处是问题早暴露，且有中间的确认点。

验收小组

• 组长：企业方项目经理
• 成员：各业务模块负责人 + IT + 财务（涉及成本时）
• 实施方：项目经理 + 相关顾问

业务部门必须参与验收，不能只由 IT 签字。因为系统是给业务用的。

验收会议

逐条过功能清单，现场演示或抽查。有争议的当场记录，会后专门讨论。

不要开成"汇报会"。要有实际的操作演示和数据抽查。

常见争议的处理

争议一：需求变更导致的差异

原则：以变更单为准。有变更单的，按变更内容验收；没有变更单的，视为原需求。

这就是为什么变更要走流程。

争议二：性能不达标

要区分是系统问题还是环境问题。服务器配置不够、网络带宽不足，属于企业方环境问题。

建议在合同里明确：性能指标是在约定的软硬件环境下测试。

争议三：使用率不达标

使用率低往往不是系统问题，而是管理问题（没有强制要求用、没有配套制度）。

这一条要在项目启动时就明确：企业方负责推动使用，实施方负责培训和支持。

遗留问题怎么处理

验收时一定有遗留问题。建议：

• 分为影响使用和不影响使用两类
• 影响使用的必须解决后才能终验
• 不影响使用的列入遗留清单，约定解决期限
• 遗留问题不超过总量的 5%

不要把"零遗留"作为验收标准，那会导致项目无限期拖延。合理的做法是约定遗留问题的数量和严重程度上限。

验收后的工作

验收不是终点：

• 质保期支持：明确质保期时长和响应时间
• 知识转移：实施方要交付完整文档，并培训企业 IT 团队
• 运维交接：数据库备份、日志查看、常见故障处理
• 持续优化：上线后 3-6 个月通常需要一轮优化

验收标准的具体条款，需要结合项目范围协商确定。百华实施团队提供标准的验收清单模板，[待补充：验收清单模板与质保服务条款]。