夜雨聆风
在不少企业，主数据平台上线几年以后，最不能停的不是平台，而是一张 Excel。
该建的都建了：统一客户号、申请流程、编码映射。但业务部门仍维护着一张表，记着哪些公司实际属于同一集团，哪些客户号看似重复却不能合并，哪些停用编码仍被旧系统识别。
真正说得清这张表的，往往只有一两个老员工。
每次有人提下线，业务都会说同一句话："先别动，这张表删了，很多业务就对不上了。"
这张 Excel，就是业务给自己留的侧门。
主数据平台是正门。编码统一、流程审批、规则校验，什么都有。但业务还是绕着正门走。
不是业务不懂治理，而是正门太贵、太慢，也装不下他们的真实业务。
问题不是业务不愿意走正门。问题是正门还不如侧门好用。
统一错了，比不统一更贵
主数据管理最容易犯的第一个错误，不是统一得不够，而是统一错了。
销售眼里的客户是一个集团，合同必须落到法人，财务区分开票和付款主体，客服关注实际服务对象，风控关心授信主体。这些都叫"客户"，却不是同一个东西。
主数据项目追求"全公司一条客户记录"，中央平台看起来更整齐了，一线场景却无处安放。于是业务重新维护本地表，把集团、法人、付款主体和服务对象再拆开。
这种 Excel 不是在抵抗治理。它只是在补回统一模型压掉的业务语义。
但另一些差异正好相反。同一个法人，在 CRM、财务和子公司系统里各有一套编号，没有层级和角色之分，只是各系统分别创建。主数据平台上线后，又加了一个企业级编码。企业没有从四套答案变成一套，而是从四套变成了五套。
该统一的没统一，不该压掉的被压掉了。
主数据追求的不是全公司只能有一种看法，而是每个场景都知道该采用哪个权威答案。
可一旦真正要落地，每个判断都会碰硬：付款主体到底是独立对象还是客户的一项属性？某套本地客户号是合法视图还是该退出的平行编码？
每一个答案背后，都跟着改流程、停建码、退本地表。这不是专业分析的问题，是权力背书的问题。
那张 Excel 之所以还在，第一个原因是：统一模型把不该压掉的东西压掉了。合法的业务差异被当成了数据不一致，业务只好在平台之外重新维护自己的视图。
质量最好的那份数据，不一定是主数据
就算分类做对了，数据也做准了，主数据仍然可能没有权威。
真正决定一条数据是不是 Master 的，不是它放在哪个平台、完整率多高，而是它有没有进入开户、准入、签约、下单、结算和授信这些流程。
主数据平台认定客户号是 A，销售系统仍接受 B，财务继续创建 C，业务还在 Excel 里维护 D。四套答案都能让业务继续做下去。A 就不是权威，只是一份质量较高的参考数据。
主数据并不是质量最好的一份数据。而是企业有权要求关键流程默认采用的那份数据。
光管业务"用什么"还不够，还必须管住答案"从哪里产生"。
很多项目花大量精力清理存量，但 CRM 还能本地新建客户，子公司仍可自行编码物料，紧急业务仍可先建临时码、事后再补——而这个"事后"，往往永远不会来。
只清历史、不关入口，就像一边排水，一边水龙头没关。
所以判断治理是否生效，不能只看历史重复率降了多少，更要看本地编码的新增量是不是真的在下降。只要旧系统还在生产新的平行编号，黄金记录做得再漂亮，也只是在下游追赶上游。
平台建成了，却没有卡在任何一条业务流程的必经之路上。业务创建客户、录入供应商、编码物料，仍然走原来的入口。
那张 Excel 里维护的那些编码映射关系，就是业务绕开统一流程后，自己铺出来的临时台阶。
正门走不通，侧门关不掉
旧入口为什么难关？最简单的答案是：业务不配合。
但站到业务的位置上，保留侧门往往是一种理性选择。
Excel 对业务有一个很现实的作用：它是一条退路。中央平台出错时，它能让流程继续运行；统一模型漏掉特殊场景时，它可以补充关系；切换失败时，它至少能保证业务不停下来。
业务守着的不只是一张表，而是一条中央规则出错以后，仍然能把事情做下去的救命通道。
为什么要这样做？
因为统一主数据的收益属于全公司：报表更一致，客户视图更完整，系统协同更顺畅。但退出旧答案的成本，却落在具体部门头上。
数据治理团队说：本地编码必须退出。
业务说：行，那系统改造谁出钱？切换期效率下降谁承担？中央平台判断出错，谁到现场收拾？
数据治理团队说：这些我们会协调。
业务说：那等协调完了再说吧。这张表我先留着。
这不是不配合。这是"协调"两个字背后，成本和责任从来没有真正落地。
更扎心的是，成本和收益往往不在同一批人身上。
销售、采购、仓库和生产负责源头录入，财务、风控和管理部门希望从数据中获得更多信息。下游需求被汇总成一张越来越长的主数据表，再变成一线的必填字段。
对管理部门，这叫源头治理。对一线，这是替所有下游完成额外的任务。
如果一个字段主要让下游获益，采集成本却全部留给上游，企业实际上是在用一线效率补贴全局。
谁会真的干？
项目组看到数据质量不好，常见反应是继续加控制：必填更多、审批更长、规则更严。
可车间要领料，销售要签合同，采购要下单。正门排队排不起，业务就借旧码、建临时码，或者转到线下。
绕行越多，管控越严。管控越严，侧门就越有吸引力。
关不掉旧入口的 Owner，只是审批联系人
企业会建各种委员会，指定数据 Owner，希望由 Owner 来解决冲突。但很多 Owner 拥有的是一个责任名称，不是让规则生效的权力。
他可以审批、开会，却未必能关闭本地建码入口、推动历史系统改造，或者要求各部门执行同一个对象模型。
编码规则之争是典型。表面上讨论的是有含义还是无含义，背后却是谁改系统、谁承担历史转换成本。谁的定义进入标准，谁以后少付成本；谁的规则没被采用，谁就要改流程和系统。
所以很多标准会最终变成谈判会。委员会可以形成原则共识，却未必能改变关键流程和系统录入的默认行为。
而且，要求各部门放弃本地定义的一方，不能只拿走定义权。系统改造要有人承担预算，服务时效要有人承诺，中央判断出错要有人快速修正并承担后果。否则，本地部门失去调整权，却要承担全部现场风险。
这样的集中化，业务当然不会真正接受。
不能让裁决结果进入生产流程的 Owner，不是 Owner，只是审批联系人。
那张 Excel 能维持这么久，是因为真正说了算的不是平台上的 Owner，而是每天用这张表做业务的那个老员工。口径打架时，所有人最后还是等他回来。
只不过没有人给他这个头衔，也没有人替他承担这个责任。
平台验收了，主数据管理还没开始
诡异的是，即使这些问题都没解决，主数据项目仍然可以顺利通过验收。
因为项目验收看的通常是平台有没有建成：接入多少系统，汇聚多少记录，制定多少标准，匹配率和完整率是否达标。
这些指标证明不了旧入口是否关闭，也证明不了关键流程是否默认采用统一身份。如果数据指标很好，业务行为却没有变化，验收的就只是一个数据平台，不是主数据管理。
更大的问题是，项目总会结束，主数据却不会停止变化。客户会更名、重组和注销，供应商会更换账户和资质，产品和物料持续升级、拆分和替代。
项目期可以集中清理、集中协调、集中决策。项目验收以后，实施人员撤场，专项组织解散，新的例外和冲突每天都在发生。
而主数据运营做得好的样子，恰恰是"没有发生什么"：没有重复付款，没有发错货，没有对不上账，也没有因为身份错误触发审计整改。
组织更容易为一次事故立项，却不容易为持续不出事配置稳定资源。而主数据要的，恰恰就是这种看不见成果的长期投入。
平台可以项目化建设，主数据管理不能项目化生存。
这就是为什么企业隔几年就要重新治理一次。不是上一次清洗不够认真，而是错误答案今天仍然可以被合法地创建、使用，并把业务继续做下去。
正门修了一半就验收了，侧门却从来没关过。几年之后再回头看，正门落了灰，侧门踩出了路。
先把正门修好，再谈关掉侧门
所以下一次复盘主数据项目，先别急着换平台，也别一上来重新清理全部数据。先问一个问题：正门为什么不如侧门好用？
首先，正门得认识业务。
先选一条真正受影响的业务流程，比如客户开户到签约、供应商准入到付款。只有放进具体流程，才能判断哪个对象必须唯一，哪些关系必须保留，哪个答案应该成为权威。
真正值得强统一的，是跨系统反复使用、错误后果高、能够形成稳定规则的核心事实。只在局部使用、变化频繁、统一成本很高的属性，不必都塞进企业级主数据。
主数据管理不是统一得越多越成熟。
其次，正门得让人走得动。
权威可以集中，录入不必集中。业务仍可以在 CRM、采购或生产系统中操作，但新对象无论从哪里发起，都必须经过统一的查重、编码、规则校验和主数据服务。
一线不应该替所有下游部门填写数据。交易必需、错误后果高的字段在源头校验；系统能取得的自动带出；主要服务于分析、风控和管理的属性，由实际使用部门负责补充。
最后，正门出错得有人修。
拿走本地定义权，就要接过改造成本、服务时效和错误责任。处理时限要能兑现，紧急业务要有正式例外通道，判断出错要能快速修正和回滚。系统改造和过渡成本，不能全部留给业务部门消化。
集中化不能只集中定义权，却把时效压力、现场风险和错误后果继续留在业务。
先把正门修得比侧门便宜，再来谈关掉侧门。
这里的"便宜"，不是少花几块钱，而是少录入、少等待、少解释、少重复维护，也少承担不确定性。
正门修好以后，才能逐步关侧门：旧系统的创建入口转为只读，临时绕行必须留痕并设置到期时间，新增本地编码必须能够被发现。
然后让统一结果成为业务默认——不是平台"可以提供"统一客户号，而是合同、采购、付款和授信流程必须调用；绕开统一规则，就不能长期照常完成交易。
最后才是清理历史存量，建立常态运营。顺序倒过来，今天清完，明天还会重新长出来。
那张 Excel，到底装着什么
回到开头那张删不掉的 Excel。
现在可以看得更清楚了：它同时装着三种东西——主数据模型没有覆盖的合法业务视图，尚未退出的历史编码，以及只有那个老员工才说得清的裁决规则。
第一种应该被正式建模为场景关系，第二种应该停止继续生产，第三种应该从个人经验变成组织规则。
判断一个主数据项目有没有真正做成，可以只问三个问题：
新对象无论从哪里发起，是不是都必须经过统一规则和主数据服务，而且比绕行更省事？ 关键流程是不是默认采用统一身份，同时没有把所有下游需求都变成一线必填？ 没有独立业务含义的本地编码，新增量是不是真的在下降？
只要这三个问题答不上来，平台可能已经验收，主数据管理却还没有真正开始。
那张 Excel 未必应该马上删。但如果企业一直说不清自己为什么离不开它，那正门大概率还没修好。
那个一直维护这张表的老员工，才是整家公司最应该被看见的人。
真正该被替换掉的，不是他，而是只有他知道答案、也只能由他兜底的运行方式。
但这个人，不该长期替一套没有完成的制度兜底。
