4. 迁移数据质量验收框架

核心银行迁移项目里，数据质量验收不是“跑完脚本看结果”这么简单。它是一套需要提前定义、贯穿迁移全过程的治理框架。框架缺失时，最常见的后果是：验收会上争论“什么算合格”，迁移团队与业务团队各执一词，最终要么无限延期，要么带着隐患上线。本节围绕四个支柱展开：验收目标、验收范围、验收标准、验收组织与角色职责。

一、核心原理：验收框架是“契约”，不是“检查表”

数据质量验收框架的本质，是迁移方与业务方之间的一份可执行契约。它回答四个问题：为什么验（目标）、验什么（范围）、验到什么程度算通过（标准）、谁来验和谁签字（组织与职责）。这四个问题必须在迁移执行前冻结，而不是在验收当天讨论。

从原理上看，验收框架建立在三个假设之上：第一，数据质量是分维度可度量的，如完整性、准确性、一致性、唯一性、及时性、有效性；第二，不同数据对象的容忍度不同，总账余额与客户地址的容错空间天差地别；第三，验收结论必须可追溯，每一条不通过记录都要能定位到具体表、字段、批次和责任人。

二、验收目标：三层目标对齐

验收目标需要分层表达，避免“保证数据质量”这类无法验证的口号。

• 业务目标：迁移后核心业务可连续运行，客户账务、利息、额度、交易流水与旧系统保持一致，监管报送不受影响。
• 数据目标：关键数据对象的完整性、准确性、一致性达到约定阈值，差异可解释、可修复、可追溯。
• 工程目标：迁移过程可重复、可回滚，验收证据完整留存，为后续投产和审计提供依据。

三层目标之间存在约束关系：业务目标决定数据目标的优先级，数据目标决定工程目标的验证手段。若只谈业务目标而不落到数据指标，验收就会变成主观判断。

三、验收范围：按数据对象与迁移阶段双维度界定

范围界定不清是验收争议的高发区。建议从两个维度同时界定：数据对象维度和迁移阶段维度。

维度	分类	典型对象	验收关注点
数据对象	核心账务	存款账户、贷款账户、总账、利息	余额、积数、状态、币种
	客户信息	客户主档、证件、联系方式	唯一性、完整性、合规字段
	交易与辅助	历史流水、参数、限额	连续性、关联一致性
迁移阶段	抽取	源系统取数	记录数、抽取时间点
	转换	映射与清洗	映射规则命中率、异常记录
	加载	目标系统入库	入库成功率、约束冲突

范围文档中应明确“不验什么”，例如明确排除已销户超过一定年限且无余额的账户，避免范围蔓延。

四、验收标准：可量化、可分级、可追溯

标准必须写成可执行的判定条件。推荐采用“指标 + 阈值 + 判定方式 + 证据来源”的四元组结构。

示例：存款账户余额一致性校验
指标：目标系统余额 - 源系统余额
阈值：核心账户差异 = 0；辅助账户差异绝对值 <= 0.01
判定方式：全量比对 + 差异清单人工复核
证据来源：migration_check_balance_20240615.log

标准分级建议：

1. 阻断级：不通过则禁止投产，如总账不平、账户余额差异、客户唯一性冲突。
2. 整改级：限期修复后可投产，如地址格式不规范、非关键字段缺失。
3. 观察级：记录并纳入投产后跟踪，如历史流水备注字段截断。

五、验收组织与角色职责

验收组织应独立于迁移实施团队，确保结论客观。典型结构包括决策层、管理层和执行层。

• 验收决策组：由项目发起人、业务负责人、科技负责人组成，负责批准验收标准、裁定阻断级问题、签署验收结论。
• 验收管理组：由数据治理负责人牵头，负责制定验收计划、协调资源、汇总报告、跟踪整改。
• 业务验收人：熟悉业务规则，负责确认业务口径、复核差异、判断业务影响。
• 技术验收人：负责执行校验脚本、分析日志、定位技术缺陷、提供修复证据。
• 独立复核人：可由内审或第三方担任，抽查验收过程与证据，防止“自验自过”。

六、场景复盘：一次余额差异引发的验收争议

某银行迁移项目中，验收当天发现存款账户余额存在差异。迁移团队认为差异源于源系统历史脏数据，属于“可接受”；业务方认为任何余额差异都不可接受。争议持续三天，根因是验收标准中未定义“源系统脏数据”的处理规则，也未明确差异裁定权归属。

复盘结论有三点：第一，验收标准必须提前约定源端脏数据的识别规则与豁免流程；第二，阻断级问题的裁定权应明确归属决策组，而非执行层争论；第三，差异清单必须附带业务影响分析，帮助业务方快速判断。此后该项目补充了“差异分类与裁定矩阵”，类似争议再未发生。

框架落地时，建议把上述四支柱写入《数据迁移验收方案》并完成三方签字。验收标准冻结后，任何变更都需走决策组审批。只有框架先行，验收才能从“扯皮会”变成“签字会”。