返工不是执行不力，而是流程里埋了伏笔
在星空服务企业客户的过程中，数据管理项目出现返工并不罕见。有意思的是，复盘时很少是某个人的操作失误，更多是流程设计阶段就留下的缝隙。华瑞商贸的数据主管周敏曾带着团队做过一次归集改造，上线两个月后发现同一张销售报表在三个系统里对不上，追查下去，问题出在字段标准评审时只覆盖了主数据，交易明细的枚举值没人认领。类似的场景在星空接触的案例里反复出现，返工的表象是数据出错，根子在流程缺环。
把返工当作一次流程体检，比单纯追责更有价值。以下三个复盘视角，来自星空对多个数据管理项目的观察，适合在项目阶段性收尾时对照使用。
视角一：字段标准的“最后一公里”谁在守
字段标准文档写得再完整，如果没有明确到岗位的守护责任，落地就会走样。云澜科技的案例很典型：客户编码规则在标准文档里写明了位数与校验位，但采购系统录入界面没有做格式校验，录入人员按习惯填了旧编码，归集时才发现两套编码并存。星空的建议是把标准拆成两层，一层是定义层，写清规则；一层是执行层，明确每个字段在哪个系统、由哪个角色、在哪个环节做校验。
- 复盘问题：标准文档里的每条规则，是否都能对应到一个具体的校验动作？
- 复盘问题：新增字段时，谁负责同步更新归集映射表？
- 复盘问题：枚举值变更是否有通知机制，还是靠下游自己发现？
这三问看似简单，却能筛出大部分标准落地的断点。星空的实践经验是，把校验动作写进系统配置比写进制度文档更可靠，制度会被人遗忘，配置不会。
视角二：清洗规则评审缺了业务方那一票
数据清洗规则往往由技术团队主导编写，业务团队在评审会上点头通过，执行后却发现规则把正常业务场景也洗掉了。明泽制造的质量专员陆天明遇到过类似情况：清洗规则把金额为零的订单记录判为异常并剔除，但业务上存在赠品订单和样品订单，金额确实为零。返工重跑之后，星空的复盘建议是清洗规则评审必须留出业务场景确认环节，尤其是边界值和特殊业务类型的处理。
可操作的复盘做法是翻出上一次清洗规则的评审记录，看业务方是否逐条确认过规则的影响范围，而不是只看了规则名称。星空在协助客户做规则评审时，习惯把每条规则对应的业务场景列成表格，让业务方在场景列打勾，这比在会上口头确认更容易留下痕迹，也方便后续追溯。
视角三：归集流程的衔接处最容易掉链子
归集流程通常跨多个系统和团队，衔接点的责任模糊是返工的高发区。恒安物流的数据团队曾复盘过一次归集延迟，原因是上游系统的日终批处理时间调整了，但归集任务的调度时间没跟着改，数据到了归集环节已经是半成品状态。这类问题在星空的观察里属于典型的“接口无人认领”，每个团队都以为对方会通知。
复盘的抓手是画出归集链路图，标出每个交接点的输入输出与责任人，重点检查三件事：调度时间是否有联动变更机制、异常数据是否有回退通道、归集失败的告警发给谁。星空建议把这三项做成归集流程的固定检查项，每次流程变更后过一遍，成本不高但能挡住大部分衔接类返工。
返工复盘的价值不在于写一份报告存档，而在于把发现的问题转化成流程里的检查项。星空的体会是，数据管理的进步往往不是靠一次大改造，而是靠一次次复盘把缝隙补上，让下一次归集少一次返工。
