主数据平台验收三年后,那张 Excel 为什么还删不掉?

朋友公司两年前花大价钱上了主数据平台。上周系统升级，业务总监从抽屉里掏出一张 Excel，说了句让我记到现在的话："先别动这张表，删了它，全国三十个分公司的对账全乱。"

这张表，业务自己维护了六年。统一客户号、编码映射、哪些停用编码旧系统还在识别——都在里面。真正说得清的，是财务岗一个老员工。

我问他，平台不是管这些吗？他说：平台是正门，这是侧门。正门太贵、太慢，装不下我们的真实业务。

这句话，值得所有做数据治理的人贴在工位上。

一、75% 的项目没达标，问题出在"统一错了"

Gartner 有个被反复引用的判断：到 2025 年，超过 75% 的主数据管理项目将无法达到业务预期。注意，是"业务预期"，不是"平台指标"。

主数据最容易犯的错，不是统一得不够，而是统一错了。销售眼里的客户是一个集团，财务区分开票和付款主体，风控关心授信主体——这些都被叫"客户"，却不是同一个东西。平台追求"全公司一条客户记录"，一线场景却无处安放，于是业务重新维护本地表，把被压掉的关系再拆回来。

更糟的是另一头：同一个法人，在 CRM、财务、子公司系统里各有一套编号，平台上线后又加了一套企业级编码。企业没从四套答案变成一套，而是从四套变成了五套。

核心判断：主数据追求的不是全公司只能有一种看法，而是每个场景都知道该采用哪个权威答案。该统一的没统一，不该压掉的被压掉了——这才是那张 Excel 活着的第一层原因。

图1｜正门与侧门的真实对比

二、权威不在平台，在流程入口

就算分类做对了、数据也准了，主数据仍可能没有权威。

真正决定一条数据是不是 Master 的，不是它放在哪个平台、完整率多高，而是它有没有进入开户、准入、签约、下单、结算和授信这些流程。平台认定客户号是 A，销售系统仍接受 B，财务继续创建 C，业务还在 Excel 里维护 D。四套答案都能让业务做下去，A 就不是权威，只是一份质量较高的参考数据。

一句话：主数据不是质量最好的一份数据，而是企业有权要求关键流程默认采用的那份数据。

很多项目花大力气清存量，但 CRM 还能本地新建客户，子公司仍可自行编码物料，紧急业务先建临时码、事后补——而这个"事后"往往永远不会来。只清历史、不关入口，就像一边排水，一边水龙头没关。

所以判断治理是否生效，不能只看历史重复率降了多少，更要看本地编码的新增量是不是真在下降。在 DAMA 体系里，主数据管理是 11 个知识领域之一；在国标 DCMM（GB/T 36073-2018，2025 版已扩展为九大能力域）里，它归口"数据标准"能力域。但"能力域达标"和"业务入口默认采用统一身份"，是两件事。

图2｜权威来自流程入口，而非平台存放

三、成本和收益，从来不在同一批人身上

旧入口为什么难关？最简单的答案是"业务不配合"。但站到业务的位置，保留侧门往往是理性选择。

Excel 对业务是一条退路：中央平台出错时它能让流程继续，统一模型漏掉特殊场景时它能补关系，切换失败时至少保证业务不停。

更深一层：统一的收益属于全公司，退出旧答案的成本，却落在具体部门头上。数据治理团队说"本地编码必须退出"，业务问："系统改造谁出钱？切换期效率下降谁承担？中央平台判断出错谁到现场？"——"协调"两个字背后，成本和责任从没真正落地。

很多项目组看到质量不好，反应是继续加控制：必填更多、审批更长、规则更严。可车间要领料、销售要签合同。正门排队排不起，业务就借旧码、建临时码、转线下。绕行越多，管控越严；管控越严，侧门越有吸引力。这本质是用一线的效率，补贴全局的数据整齐。

图3｜谁获益、谁买单，从来不是同一批人

四、Owner 不掌权，就只是审批联系人

企业建了委员会、指定了数据 Owner，希望由 Owner 解决冲突。但很多 Owner 拥有的，是一个责任名称，不是让规则生效的权力。

他可以审批、开会，却未必能关闭本地建码入口、推动历史系统改造、要求各部门执行同一个对象模型。编码规则之争，表面讨论有含义还是无含义，背后是谁改系统、谁承担转换成本。

不能让裁决进入生产流程的 Owner，不是 Owner，只是审批联系人。那张 Excel 能维持这么久，因为真正说了算的，不是平台上的 Owner，而是每天用这张表做业务的老员工。口径打架时，所有人最后等他回来。只不过没人给他头衔，也没人替他承担这个责任。

五、平台验收了，主数据管理还没开始

诡异的是，就算这些问题都没解决，主数据项目仍可能顺利通过验收。因为验收看的通常是平台有没有建成：接入多少系统、汇聚多少记录、匹配率完整率达不达标。这些指标证明不了旧入口是否关闭，也证明不了关键流程是否默认采用统一身份。

更大的问题是，项目总会结束，主数据不会停止变化。客户更名、重组、注销，供应商换账户换资质，每天都在发生。项目期能集中清理，验收后实施人员撤场，新冲突每天都在长。

主数据运营做得好的样子，恰恰是"没有发生什么"：没有重复付款、没有发错货、没有对不上账、没有因身份错误触发审计整改。平台可以项目化建设，主数据管理不能项目化生存。

图4｜用三句话替代一张验收报告

六、先把正门修好，再谈关侧门

下次复盘主数据项目，别急着换平台，先问一句：正门为什么不如侧门好用？

第一，正门得认识业务。选一条真正受影响的流程（客户开户到签约、供应商准入到付款），放进具体流程才能判断哪个对象必须唯一、哪些关系必须保留。只在局部使用、变化频繁、统一成本高的属性，不必都塞进企业级主数据。主数据管理不是统一得越多越成熟。

第二，正门得让人走得动。权威可以集中，录入不必集中。新对象无论从哪里发起，都必须经过统一查重、编码、校验和主数据服务。一线不该替所有下游填数据；交易必需、错误后果高的字段在源头校验，主要服务分析的属性由使用部门负责补充。

第三，正门出错得有人修。拿走本地定义权，就要接过改造成本、服务时效和错误责任。处理时限要能兑现，紧急业务要有例外通道，判断出错要能快速回滚。

这里的"便宜"，不是少花几块钱，而是少录入、少等待、少解释、少重复维护，也少承担不确定性。正门修得比侧门便宜，侧门才有理由关。

最后，那张 Excel 未必该马上删。它装着三种东西：主数据模型没覆盖的合法业务视图、尚未退出的历史编码、只有老员工说得清的裁决规则。第一种该建模成场景关系，第二种该停止生产，第三种该从个人经验变成组织规则。

判断一个主数据项目有没有真正做成，只问三句话：新对象是否必须过统一规则且比绕行更省事？关键流程是否默认采用统一身份且不把所有下游变必填？无业务含义的本地编码新增量是否在下降？答不上来，平台可能已经验收，主数据管理却还没真正开始。

那个维护 Excel 的老员工，才是整家公司最该被看见的人。真正该被替换的，不是他，而是只有他知道答案、也只能由他兜底的运行方式。

做数据治理这些年，我越来越确信一件事：主数据管理从来不是建平台，而是修一条所有人都愿意走的正门。门修好了，侧门自然就关了。