项目上线时，功能清单可以逐项打钩；过了一段时间，一线人员仍在用表格补录，审批也没有变快。这时再追问项目价值，往往会发现：没有留下改造前的记录，也没有人约定上线后由谁继续观察。
验收安排要从立项时开始。上线资格、交付完成和业务见效分别需要什么证据，应提前写清。若涉及采购，内部的价值评估还要与双方约定的合同验收条款分开管理，不能临近交付才单方面增加要求。
先写一张验收卡
每个项目用一页写清主要问题、验收对象和判断方法。指标不必多，但每项都应包含以下内容：
- 对象与口径：测量哪些业务，哪些情况不计入；开始和结束时间以什么事件为准。
- 基线与来源：改造前的水平如何得出，数据来自哪个系统，谁负责核查。
- 目标与护栏：希望改善到什么程度，同时不能损害哪些质量或风险指标。
- 观察期与责任：何时有足够样本，谁提供证据，谁有权确认结论。
- 未达标动作：整改、延长观察、缩小范围或停止推广，分别由谁决定。
情境示例：一个合同审批项目，可以关注完整申请提交至最终审批的时长，同时保留退回率和审批差错的检查。补材料所花的时间应单独记录，不能为了让数字好看而全部从统计中消失。具体目标要根据基线和业务可承受程度协商，不能直接套用别人的改善比例。
没有可靠基线时，先安排有限范围的测量。无法补齐的数据应如实标记，避免事后凭印象声称效率提升。
四类证据，分别回答不同问题
功能证据：约定的场景能否完成
从真实业务场景生成验收用例，包括主流程、角色权限、边界输入和异常处理。除了“正常审批通过”，还要验证撤回、拒绝、重复提交、人员离岗和接口失败等适用场景。
性能、稳定性、安全和恢复要求，应根据业务风险设定。关键权限错误、数据损坏或核心流程中断，不能用其他功能完成率抵消。交付方提供测试记录，业务人员用实际操作方式复核，两者承担不同责任。
流程证据：工作方式发生了什么变化
观察一次业务从开始到结束的全过程。系统内少了一次点击，却增加了线下确认，未必节省了总时间。
可以抽查处理时长、交接等待、重复录入和返工。除了平均值，也看看耗时较长的个案，区分正常情况和复杂情况。新旧样本的业务复杂度不同，直接比较平均数可能产生误导。
数据证据：记录是否足以支持使用
针对关键字段核对完整性、准确性、及时性和跨系统一致性。完整率高，只说明有值；随机填入默认值，同样可能通过完整性检查。
迁移验收应结合数量核对、汇总校验和明细抽查。金额、状态或业务关联等关键数据，要有相应的校验规则。抽样范围与方法应事先说明，发现差异后还要能追溯和修正，不能仅留下一个“数据已导入”的结论。
结果证据：预期收益是否出现
流程效率、客户体验、成本和收入，观察难度各不相同。把“按规定完成关键流程的业务占比”与简单登录人数区分开，才能看见系统是否进入日常工作。
经营指标还可能受季节、业务结构、活动和人员变化影响。能做小范围对照时，尽量比较条件相近的组；条件不足时，记录这些变化，把结论写成有局限的判断。上线前后出现差异，不能自动归因于系统。
验收分三次作出决定
上线前，决定是否具备试运行条件。 核心场景、权限、数据迁移、监控和恢复预案需要达到约定门槛。问题分级后，明确哪些必须修复，哪些可以带着责任人和期限进入有限试运行。
试运行中，决定是否扩大使用。 查看用户能否独立完成业务、线下绕行是否有合理原因、异常是否有人处理。培训签到和使用次数只能提供线索，最好结合现场观察与具体任务完成情况。
经过合适观察期，决定是否兑现了预期价值。 高频流程可以较早复盘，低频或长周期业务则要等待足够样本。三十、六十、九十天可以作为提醒节点，但不能代替对业务周期的判断。安全和严重质量问题也不能等到固定复盘日才处理。
每次决定都留下证据、结论、遗留事项及负责人。上线后必须有人接管日常运营，否则建设团队退出后，价值验证就容易失去执行者。
未达标时，避免只有“通过”或“失败”
先定位问题在哪一层：功能缺陷需要修复；流程没人采用，要查操作负担和管理安排；数据不可用，要查采集和责任；流程改善但经营指标未变化，则需要重新检查收益假设及观察条件。
根据证据形成四种可执行结论：通过并推广；限范围运行、限期整改；因样本不足继续观察；停止新增投入并安排退出。附条件通过要写明条件和期限，不能长期挂着“后续优化”。
验收记录的最后一行，最好能回答一个具体问题：下一阶段准备投入什么，依据是什么，达到什么条件才继续。这样，项目的下一笔投入就有了可以追问的依据。