数据治理越集中，业务手里的第二套答案反而越多。
主数据统一了客户号，业务仍保留一张 Excel；指标平台统一了口径，部门仍有自己的算法；数据共享进了正式平台，紧急需求还是会走临时通道。
集团有一套正式答案，业务手里还有一套真正干活的答案。
这通常被解释成业务不配合、部门本位主义，或者数据 Owner 不敢管。
但如果统一答案真的足够可靠，谁愿意额外维护另一套？
真正值得追问的，不是业务为什么不服从，而是：
数据治理已经集中起来了，业务为什么仍然不敢把自己的退路交出来？
过去，客户关系有问题，业务可以直接改表；
物料编码来不及申请，可以先建临时码；
指标口径有争议，也能先按本部门的算法把会开下去。
这些做法未必规范，但能让眼前的业务继续前行。
集中化以后，客户由谁认定、供应商采用哪个主体、合同和付款使用哪套编码，都要服从企业级规则。
业务不能再自行修改，只能等待统一认定、统一编码和统一修正。
集中化收走的，不只是一张表的维护权。
它收走的，是统一规则出错、流程卡住或者特殊情况出现时，业务自己把事情继续做下去的机会。
业务不再只是使用一个平台，而是在把合同、付款、生产和经营分析，托付给一套统一答案。
问题是，这套答案真的准备好了吗？
统一答案最容易犯的错，不是不够统一，而是把本来不同的东西硬压成一样。
销售说的客户，可能是一个集团；合同必须落到具体法人；财务关心开票和付款主体；风控盯的是授信主体。
这些都叫“客户”，业务上却根本不是同一个对象。
企业级平台为了得到“全公司唯一客户”，很容易把这些差异塞进一条记录。平台看起来整齐了，真实的业务关系却被压没了。
于是，业务只能再建一张表，把集团、法人、付款主体之间的关系重新补回来。
可另一类差异，又确实应该消失。
同一个法人，在 CRM、财务和子公司系统里各有一套编号，如果这些编号没有独立的业务含义，就不是场景差异，只是几套同时存在的平行答案。
指标也是一样。
销售按签约金额看收入，财务按确认条件看收入，可以是不同场景下的合法口径；但同一个正式财务指标，因为加工规则不同而出现多个结果，就不能继续被解释成“业务特色”。
集中化真正难的，不是把不同变成一样，而是分清：
到底哪些必须一样，哪些根本不能一样。
集团希望全公司只认一套答案，业务面对的却是具体合同、具体付款，以及每天都可能出现的例外。
标准太粗，装不下现场；标准太细，又复杂到无法维护。
很多项目因此陷入一种尴尬：
该统一的没有真正统一，不该压掉的却被统一掉了。
业务保留本地表，大多不是在抵制治理，而是在补回企业级模型没有装下的那部分现实。
可就算统一答案真的说对了，业务也未必愿意只用它。
客户、供应商和指标统一以后，管理层得到一致报表，风控得到完整视图，跨系统协同也更加顺畅。
这些收益属于全公司。
但退出旧答案的成本，却落在具体部门：
历史系统谁来改，接口改造谁出钱，切换期间效率下降谁承担，旧数据对不上由谁处理。
以“源头治理”为例。
下游部门希望获得更多信息，最后往往变成销售、采购、仓库和生产人员填写更多字段。
对管理部门，这叫完善数据；
对一线，这意味着多录入、多等待、多解释。
如果一个字段主要让下游获益，采集成本却全部留给上游，企业实际上是在用一线效率补贴全局。
集中化最难推动的地方就在这里：
受益的人不用改，真正要改的人未必直接受益。
在这种成本结构下，本地 Excel、本地编码和线下流程，不只是坏习惯，也是更便宜的工作方式。
于是，会上同意统一，现场继续绕行。
业务保留第二套答案，不只是为了省事。
更重要的是，它不能把出错的后果押在一个还不可信的平台上。
企业级平台不可能永远正确。
客户会重组，供应商会更换主体，看似重复的编码可能不能合并，紧急业务也可能等不及正常流程。
过去业务有本地调整权，问题可以在现场解决。
集中化以后，本地调整权被收走，但错误造成的后果仍然发生在现场：合同签不了，付款停住了，生产领不了料，客户业务无法受理。
面对投诉、考核和经营压力的，仍然是业务部门。
所以业务一定会问：
统一判断错了，谁来改？多久能改完？紧急业务能否先继续？平台不可用时有没有备用通道？
很多企业有统一标准和审批流程，却没有可兑现的服务时限、紧急例外、快速纠错和问题升级机制。
数据 Owner 也经常只是一个责任名称。
他可以审批标准、参加会议，却未必有权关闭本地入口、推动系统改造，或者要求平台团队限时处理现场问题。
不能让裁决结果进入生产流程的 Owner，不是 Owner，只是审批联系人。
谁拥有最终定义权，谁就应当承担与之匹配的规则质量、服务时效和纠错责任。
只把定义权收上去，却把响应压力、现场风险和错误后果留在下面，本质上是把风险转给了业务。
换谁坐在业务的位置，都会先给自己留一条退路。
所以，那张 Excel 不是集中治理失败以后剩下的垃圾。
它是业务面对一套还不能完全信任的统一答案，自己买下的保险。
平台没有覆盖特殊场景时，它补关系；
正式流程太慢时，它抢时间；
统一判断出错时，它让业务还能继续运行。
当然，并不是每张本地表都有保留价值。
有些只是历史惯性，有些是在维护部门自己的解释权，还有些早已失去业务意义。
判断标准不是数据放在平台里还是 Excel 里，而是它有没有独立业务含义，以及正式平台是否已经能够替代它。
真正麻烦的是，只要替代没有完成，第二套答案就会继续存在。
正式平台里有一套，真正干活时还有一套；
系统里使用统一编码，现场仍维护历史映射；
平时走正式流程，紧急时转到线下。
而双轨一旦形成，就会自我强化。
业务绕行，数据继续分叉；
数据越分叉，治理团队越要增加规则和审批；
流程越重，业务越需要继续绕行。
最后会出现一个反常识结果：
数据治理越加强，第二套答案反而越顽固。
这也是为什么很多企业隔几年就必需重新治理一次。
不是上一轮清洗得不认真，而是第二套答案从未停止生产，新的分叉仍然可以被合法创建和使用。
因为企业验收的通常是“集团建成了什么”，而不是“业务退出了什么”。
平台有没有上线，接入多少系统，制定多少标准，完整率提高多少，这些都能写进验收材料。
但本地编码新增量有没有下降，旧入口有没有关闭，关键流程是否默认采用统一答案，本地 Excel 是否持续减少，往往没人真正检查。
建设成果容易被看见，退出行为却很难写进项目成绩。
于是，企业很容易得到一个漂亮结论：
平台完成了，组织建立了，标准发布了，集中化成功了。
项目组随后撤场，新的客户、供应商、物料和业务例外却仍在持续出现。
统一答案逐渐过期，本地答案继续生长，几年以后，企业又启动新一轮治理。
这种循环没有在验收时被认定为失败，是因为验收了企业级平台建成，却没有验收实际的数据权威是否已经归一。
很多企业完成的是平台验收，并没有完成集中化验收。
回到开头那张不能删的 Excel。
下一次复盘数据治理项目，不妨先找出业务仍在维护的那张表、那套口径，或者那条临时通道。
别急着问为什么还不删。
先问它到底在替正式平台补什么：是平台没有表达的业务关系，是正式流程满足不了的时效，还是统一答案出错后的兜底？
这些问题没有被接住以前，强行删掉第二套答案，只会让它换一个更隐蔽的地方继续存在。
只要业务还必须依赖第二套答案，企业的数据权威就永远是双轨。
真正的集中化，不是平台里只剩一套答案，而是业务不再需要另一套答案兜底。
在那之前，先别急着责怪那张表。
它未必正确，却往往把集中化尚未完成的地方，暴露得最诚实。
（部分内容来源网络，如有侵权请联系删除）
