FDE落地

平台上线那天，会议室里气氛通常不错。报表能看了，规则配上了，元数据也采进来了。半年后再回头看，标准文档没人翻，元数据停在补录那一版，质量告警堆在群里没人认领，业务该导 Excel 还是导 Excel。 问题往往不出在建设阶段——那一段多数团队做得不差。真正卡住的地方，是上线之后。 ## 一、上线即终点：四个断点 上线之后跑不起来，通常不是单点故障，而是几个断点同时存在： - **治理不前置。** 建表、改字段、上报表都做完了，才想起来补治理动作。事后补登记，补的是记录，不是约束。 - **无 Owner。** 规则有人配，没人负责。出了问题所有人都能看到，没有人动手。 - **无机制。** 变更靠口头沟通，今天说一句「这个字段改一下」，明天就改了。没有提报、评审、上线、验证这条链路，治理只能靠人的记性和自觉。 - **无自动化。** 校验、采集、告警全靠人工触发，人一忙就停。 这四个断点里，只要占了两条以上，平台基本就只剩一个「登记处」的功能。 ## 二、六步推进顺序 下面这套顺序，是一种在多数团队里比较可行的做法，不是唯一标准。团队规模、数据体量、监管要求不同，顺序可以调整。 1. **定范围。** 先划清楚这一轮治理覆盖哪些域、哪些系统。范围不收口，后面每一步都会被稀释。 2. **建标准。** 把命名、编码、取值这些约定先定下来，作为后续校验的依据。 3. **盘元数据。** 把技术、业务、管理三层元数据盘一遍，尤其是业务元数据。 4. **配规则。** 按数据质量规则库配置校验规则，分层分级，别一上来就全量 P0。 5. **跑一轮完整的处理流程。** 让问题从发现、派单、整改走到复核，走通一遍。 6. **固成果。** 把上面跑通的机制固化下来，纳入日常流程和考核。 顺序上后一步依赖前一步。跳过第二步直接配规则，规则会因为缺少标准依据而互相打架；跳过第五步直接谈固化，固化下来的是一堆没人用的表单。 ## 三、数据质量：规则库六类规则与误报来源 数据质量规则库通常按六类来组织： | 规则类别 | 检查内容 | 常见误报来源 | |---------|---------|-------------| | 完整性 | 必填字段是否为空 | 上游系统允许空值，未同步口径 | | 唯一性 | 主键、业务键是否重复 | 历史数据未清洗，重复记录未标记 | | 有效性 | 取值是否在允许范围内 | 枚举值新增未同步到规则 | | 一致性 | 跨系统同一字段是否一致 | 统计时点不同，T+1 与实时混用 | | 准确性 | 数值是否与实际业务吻合 | 业务口径变更未通知治理侧 | | 及时性 | 数据是否在约定时间内到达 | 上游调度延迟被误判为缺失 | 误报是规则落地时最容易被低估的问题。误报一多，业务方就不看了；业务方不看，规则就白配了。所以规则上线初期要盯误报率，而不是盯命中量。 规则还要分层分级。**P0** 是影响对外报送、监管口径、核心经营指标的，必须拦；**P1** 影响内部经营分析，需要限期整改；**P2** 是参考类，记录即可，不必告警。分级不清，所有规则都当 P0 处理，最后就是所有告警都被忽略。 ## 四、元数据：三层结构，业务元数据最常缺失 元数据一般分三层： - **技术元数据**：表名、字段、类型、长度、分区、血缘。这类通常靠采集工具就能拿到。 - **业务元数据**：这个字段在业务上叫什么、怎么算、谁在用、口径是什么。这类最常缺失。 - **管理元数据**：Owner、密级、生命周期、访问权限。这类决定数据能不能被放心使用。 三层里最容易缺的是业务元数据。技术元数据采集工具跑一遍就有了，管理元数据填一次也能填上，但业务元数据要靠业务方配合确认，没人推就没人填。 后果很直接：数据目录建起来了，业务方搜不到自己想要的字段，搜到了也看不懂，于是目录建而不用。目录一旦没人用，元数据的更新也就失去了动力，很快回到补录那一版。 ## 五、主数据与数据标准：不做系统级约束，业务就会回到 Excel 主数据和数据标准这两件事，光有文档是不够的。 **编码规则要定死。** 客户、供应商、物料、组织这些主数据的编码规则，必须唯一、可扩展、不含业务含义。规则含糊，各地就会各自编一套，最后对不上。 **校验要放在系统层。** 能做成下拉的别让人手填，能建字典映射的别靠文档约定，能用规则校验的别靠评审会提醒。人靠不住不是人的问题，是设计的问题。 **认责和考核要跟上。** 主数据的维护责任要落到具体的人，并且和考核挂钩。没有考核，主数据的更新优先级永远排在业务需求后面。 这三条缺一条，业务就会绕过平台。系统里填不进去，或者填进去了对不上，业务就会自己拉一份 Excel 维护。Excel 一旦在业务侧生根，再想收回来，成本比一开始做约束高得多。 ## 六、平台落地：把治理关卡嵌进开发流程 平台要真正跑起来，得让治理动作长在开发流程里，而不是挂在流程外面。 **治理关卡嵌入开发流程。** 建表、改字段、上报表，这些动作在流程里就要过治理这一关，而不是事后补登记。 **变更影响分析。** 改一个字段之前，先看血缘，看这个字段被哪些报表、哪些下游任务引用。这一步做在前面，能省掉后面大量的排查工作。 **上线治理验收。** 需求上线时，除了功能验收，加一道治理验收：标准是否符合、元数据是否更新、Owner 是否明确。验收清单里没有这几项，治理就永远排在最后。 ## 七、成果巩固与验收口径 治理成果能不能留下来，取决于验收看什么。 从「交付物验收」转向「运行机制验收」，问几个问题就够了： - 有没有常设组织，而不是临时项目组？ - 有没有 Owner 分配表，每个名字都对得上人？ - 有没有工单从头走到尾，从提出一路走到复核？ - 有没有考核挂钩，做不做在绩效上看得出来？ - 有没有保鲜责任人，元数据和标准谁负责更新？ 指标口径也要跟着换。比起「完成了多少条」，「运行得怎么样」更值得看：规则命中趋势是收敛了还是持平，工单四个环节的量和停留时间，元数据的更新活跃度，标准校验在系统层拦下了多少不合规的建表和取值，变更前有多少次做了影响分析。 这些问题的答案不理想，交付物再齐全，也只是把风险往后推了一段。 ## 八、结语 平台上线不是终点。真正决定治理成不成的，是上线之后那些琐碎、重复、不显眼的日常动作：标准有没有被引用，元数据有没有被查询，主数据有没有被调用，质量问题有没有从发现走到整改完成。 开通数据治理围绕数据质量、元数据、主数据、数据标准、数据治理平台落地五个方向，提供平台能力与方法支撑，服务地域为中国大陆。治理这件事没有一次性交付的终点，把机制嵌进日常流程，比多上一套功能更值得投入。