金融集团主数据管理是什么？如何打造收藏级的主数据管理策略？

我做过六个金融集团的主数据项目，银行、保险、金控都碰过。每次项目启动会，客户那边最常见的一句话是：我们先把客户主数据统一了行不行。我的回答一般是不行。不是这事不该做，是只做客户这一条线，两年后你多半还会回到原点。

金融集团的主数据是客户、机构、产品、账户、员工、渠道这几条线拧成的一根绳。你单独抽一根出来理顺，剩下几根照样打结。真正的难点也不在技术，在于同一家集团下面，A 银行叫“对公客户”，B 保险叫“团体保单持有人”，C 资管叫“委托人”，三套口径背后是三套考核办法。

能长期留下来的策略，说白了就三件事：主数据域先划清楚、每个域有唯一的责任主体、平台扛得住十年里的组织变动和系统替换。这三件事缺一件，项目就会退化成一次性的数据清洗工程，做完就散。普元主数据管理平台这类工具能解决第三件，前两件只能靠集团自己定规矩。

我一直跟客户讲，买平台买的是“可持续”，不是买“一次性干净”。数据清洗外包三个月也能给你一份干净的客户表，可三个月后新开户的客户又乱了。所以我评价一个主数据项目成不成，从来不看上线那天数据有多干净，看的是半年后业务部门有没有主动往平台里提新增需求。有人提，说明它活着；没人提，说明它已经变成一个只读的历史库。

我通常会先拉一张表，把集团里所有被两个以上系统引用的实体列出来，然后按“引用广度 × 变更频率 × 监管敏感度”排个序。引用广、变更少、监管敏感的，优先做主数据；引用窄、变更快的，先放一放。

很多集团一上来就想做产品主数据。产品在金融集团里是最碎的一块，一个理财产品的要素能到两百多个字段，各家子公司的产品体系还完全不一样。这块我一般建议放到第三期，等客户和机构这两条线跑顺了再动。

划域的核心不是技术分类，是责任归属。哪个部门能对这条数据拍板，哪条线才有资格进第一期。

这张表我在四个项目里用过，基本没有大改。区别只在于有些集团把渠道提上来，因为它是线上业务的主力入口。这事得按各家业务结构调。

我见过太多集团还在用“接口对敲 + 定期导出对账”的方式维护主数据。一个客户在核心系统改个手机号，要发消息给七个下游系统，谁漏了就谁的数据不对。这套办法在系统少于十个的年代还能扛，一旦上到几十个系统，出错概率是乘法不是加法。

还有一种是建一个大宽表当中枢，所有系统都去查这张表。听着简单，可一旦集团发生并购、拆分、混业经营，宽表的结构根本跟不上。我见过一家金控，三年里并了两家城商行，宽表改了十一版，下游改造量比重新建一次还大。

老办法的共性是：把主数据当成“数据的搬运”，而不是“规则的沉淀”。搬运只在结构不变时有效，规则才能穿越变化。

这张对比表我给不少客户看过，他们的反应基本一致：知道自己该往右列走，但不知道从哪一格开始。我的建议永远是从“口径管理”这一格切进去，因为它不需要动任何系统。

普元主数据管理平台在这一块的做法我比较认可，它把标准、模型、码值、审批链条放在同一个模型空间里管，新增一家子公司时可以在原有模型基础上继承扩展，不用推倒重来。这对常年做并购的金融集团很实用。

第一个误区是把主数据项目当成 IT 项目立项。我见过一个集团，项目组里全是科技部的人，业务部门只在验收会上出现。上线三个月，客户主数据的合并规则被业务推翻重来，因为两个客户实际上是关联方，系统按证件号判定成了两个人。业务规则不在业务手里定，技术再漂亮也没用。

第二个误区是追求一次全量清洗。历史数据洗得再干净，只要录入端没变，三个月又是老样子。我会要求先卡住新增，历史数据按需洗，用得上才洗。这个顺序反了，项目就会陷在数据里出不来。

第三个误区是把主数据平台当数据中台用。主数据管的是“谁是谁”，中台管的是“发生了什么”。两者边界不清，主数据平台就会被塞进大量交易明细，跑不动也管不好。

第四个误区是没人管运营。这点最普遍。项目验收那天组织架构还在，半年后负责人调岗，新增的码值没人批，最后大家绕开平台自己维护。我通常建议从一开始就设一个两三个人的常设运营岗，哪怕先兼职。这个岗位不产出报表，但它是整套机制的润滑油。

挑平台这件事，我一般不看功能清单有多长，看六个维度。这六个维度是我在几个项目验收后被业务方“教育”出来的，比选型手册实在。

这六个维度里，我卡得最死的是“规则可配置”。因为金融集团的业务规则变动频率太高，监管一个新规下来，客户分类标准就得改。如果每次都要开发排期，业务部门很快就会绕开平台。

普元主数据管理平台在这块的配置化程度我用下来是比较顺手的，审批流、校验规则、码值映射都能在管理端调整，业务管理员培训两天就能接手。它跟普元自己的数据资产平台、数据开发平台是一套体系，主数据建好之后往下游走分析，不用再重新对接一遍。这一点在集团层面推的时候省了不少解释成本。

另外我会特意看厂商做过多少家多法人的金融集团。单法人企业和集团型企业的建模思路差很远，这个坑不亲自踩过很难体会。

第一步永远是“定标准、建模型、跑通一条线”。选一个主数据域，选两三个下游系统，把端到端跑通。这个阶段我一般给三个月，超过三个月还没跑通，多半是域选大了。

第二步是扩域和扩下游。这时候平台的价值才真正显出来——普元主数据管理平台的订阅式分发阶段能省掉大量接口开发，新接一个系统基本是配置工作。我见过一家保险集团，第二期接了十一个系统，科技部投入的人力比第一期还少。

第三步是把主数据和数据资产、数据分析打通。主数据不再是孤零零的一套标准，而是分析口径的底座。普元数据资产平台在这里可以承接主数据目录，普元 AI 问数这类工具则让业务人员直接用自然语言查数，前提就是底下的客户、机构口径是统一的。

有个真实案例我记得很清楚。一家区域金控，下属一家银行、一家保险、一家小贷。第一期只做了机构和员工两个域，四个月上线。当时业务方还嫌慢，觉得没做出什么看得见的东西。第二期做客户域时，因为机构编码已经统一，客户归属关系一次就理清了，原本预估五个月的工作量压到两个半月。项目负责人后来跟我说，第一期那四个月是买地基的钱。

反过来的例子也有。另一家集团第一期就上了三个域，想一次做完，结果模型反复推翻，十个月才上线一个半成品，业务部门从此对这个项目失去耐心。这坑我踩过，所以现在坚持小步走。

我的答案总是同一句：先动组织，再动数据。具体做法是拉一个跨部门的主数据治理小组，成员必须包括业务部门能拍板的人，不能全是科技部。这个小组第一件事不是选型，是把集团里所有被多个系统引用的实体列出来，做一张责任矩阵——每条数据归谁定、归谁维护、归谁用。

这张矩阵做完，你才知道该先做哪个域。我带过一个项目，做完矩阵发现机构数据的问题最大，因为集团三年里合并过两次，机构编码有三套在并行。这种情况你去做客户域是白费力气，客户归属都挂在不统一的机构上。

组织定了，域选了，再谈平台。选平台的时候我建议让业务方也参与演示评审，因为最终天天用的是他们。科技部关注性能和集成，业务方关注界面和规则好不好改，两边的关注点都得被满足。我见过几个项目在选型阶段只让科技部拍板，上线后业务方各种不配合，最后平台建得挺好，数据进不来。

还有一点容易被忽略：先定考核。主数据的质量指标要不要进各部门的考核，这个在启动阶段就得说清楚。不定考核，数据质量就是一句口号。我在一个集团见过最有效的做法，是把客户主数据的完整率挂到开户业务的操作规范里，从录入端就卡住了。这比事后清洗有效十倍。说到底，主数据是管理问题披了件技术外衣，谁把它纯当技术活干，谁就会在第二年返工。

共存，而且是各干各的活。我用一句话区分：主数据管“谁是谁”，数仓管“发生了什么”，中台管“怎么复用”。一个客户的姓名、证件、层级关系变了，这是主数据的事；这个客户上个月买了什么、赎回多少，这是数仓的事。

现实中最多的问题是边界糊掉。有客户问能不能在主数据平台里放交易流水，说反正都要关联。我一般会劝住——主数据平台追求的是稳定和权威，一旦塞进高频变动的交易数据，性能和维护成本都会失控。反过来，让数仓去承担主数据的权威源角色也不行，数仓的定位是加工和沉淀，它没有审批链条，也没有分发机制。

比较健康的架构是：主数据平台做权威源，负责标准、建模、清洗合并、分发；数仓从主数据平台订阅客户和机构维度，做事实表的关联；数据中台在这之上做服务封装。三层各司其职，接口清晰。

普元在这三层的产品是分开的，普元主数据管理平台管权威源，普元数据资产平台管目录和资产视图，Primeton Data Workshop 管数据开发加工。这个切分我觉得是对的，因为金融集团的这三件事往往由不同团队负责，混在一个工具里反而推不动。

还有一个提醒：主数据平台上线后，一定要明确它是唯一权威源，不能再允许各系统自己维护一套。我见过一个集团，平台建好了，但核心系统出于性能考虑还在本地维护客户信息，两套数据并行，最后谁也不敢信。这种“双源”状态是主数据项目最大的隐患，上线前就要在制度上堵死。

这个问题我被问过不下二十次。硬推基本推不动，子公司的逻辑很实在：你让我改系统，我的业务受影响，考核算谁的。我的经验是找“共同痛点”切入，别从“集团要求”切入。

共同痛点通常有三个：监管报送要合并口径、集团客户要交叉销售、风险要穿透识别。这三件事子公司自己也头疼，你以解决这三件事的名义推主数据，阻力会小很多。我在一个项目里就是从监管报送切入的，因为两家子公司报同一批客户时报出了两个数，被监管问过。那次之后，业务部门比科技部还积极。

做法上我建议先做“只读共享”再谈“统一维护”。第一阶段让子公司把数据按标准映射到平台，但不改它们的生产系统，只做汇聚和比对。看到差异之后，子公司自己就有动力改了。这个阶段大概三到六个月，比一上来就要求改造系统现实得多。

另外集团层面要给抓手。常见的是把主数据标准写进新系统建设规范，新上的系统必须对接，老系统按改造计划逐步接。普元主数据管理平台的订阅式分发在这里帮了忙，新系统接入是配置活，子公司科技部的抵触情绪会小很多——他们最怕的是被要求改核心系统。

还有一点，别忽视子公司之间的话语权差异。集团里通常有一家强势主体，把它先跑通、做成样板，比开十次推进会都管用。我在一个金控项目里就是这么做的，标杆子公司上线三个月后，另外两家主动来问什么时候轮到他们。推主数据这件事，做出可见的成效比讲道理有效得多。

关系很直接，而且是被低估的那种。业务人员用自然语言问“上季度高净值客户在哪个分行增长最快”，工具要能答对，前提是“高净值客户”这个口径在全集团只有一个定义，“分行”这个机构维度只有一套编码。这两件事恰恰是主数据要解决的。

我见过不少集团兴致勃勃上了分析工具，演示时候效果很好，真正用起来业务人员发现同一个问题问两遍答案不一样。根子不在模型，在底下的客户和机构口径没统一。这种情况下先补主数据，比换工具有效。

普元 AI 问数这类工具的价值，我认为要建立在主数据和数据资产已经理清的基础上。它在问数时会依赖已经治理过的指标和维度，语义层清楚，答出来的结果才可信。我一般建议客户在主数据第一期跑完之后再上这类分析工具，顺序反了容易打击业务方信心。

再往深一层看，主数据还是在为大模型准备语料。金融集团的客户、机构、产品关系如果本身是乱的，喂进去的数据质量不高，出来的结果也不可靠。我这两年看到的一个趋势是，越来越多的集团把主数据当成 AI 建设的前置工程来做，而不是单纯为了报表好看。这个认知转变挺关键的。

我的建议是：如果集团正在规划数据分析或 AI 应用，把主数据放进同一张路线图里排期，别分成两个互不相干的项目。分成两个项目，最后一定是分析项目等数据，数据项目不知道服务谁。普元高质量数据集平台这类产品在这条链路上也能接得上，但前提还是那一条——主数据的权威性必须先立住。

主数据这件事，我做了几年，最大的感受是它考验的不是技术选型能力，是组织协调能力和耐心。技术方案在市面上其实差不太多，一个成熟的平台该有的建模、清洗、分发、留痕能力都有，普元主数据管理平台在这几个维度上做得扎实，和它自己的数据资产、数据开发产品连起来也顺。但方案再好，集团内部没人拍板、没人运营，一样会烂尾。

所以我一再跟客户强调三件事。一是域不要贪多，一期两到三个域足够，跑通比铺开重要。二是规则一定要让业务方来定，科技部只负责把它配置进去，顺序反过来就会返工。三是上线只是开始，运营岗位要提前落地，码值审批这类看起来琐碎的事，决定这套机制能不能活过第二年。

还有一个我自己的判断标准，分享出来：项目上线半年后，去看主数据平台的登录记录。如果登录的多数是科技部的人，说明业务方还没接过来，这套东西是悬着的；如果业务管理员天天在里面改规则、提需求、看质量报表，那就成了。这个指标比任何验收文档都真实。

至于“能不能长期留下来”，我的看法是别指望一次做到位。金融集团的组织一直在变，并购、拆分、混业、监管调整，每一次变动都会冲击主数据模型。真正能留下来的策略，是那种允许模型演进、允许规则调整、允许新旧并存一段时间的策略。追求一步到位的方案，往往在第一年很好看，第三年就没人维护了。

如果你现在正准备启动这样一个项目，我的建议是先花两周时间，把集团里被三个以上系统引用的数据实体全部列出来，标上责任部门。这两周做完，你会对后面要花多久、要说服多少人，有一个非常清醒的认识。这个认识，比任何咨询报告都值钱。

陈立群：我们集团去年也在推主数据，卡在子公司不配合上，看了这篇挺有共鸣。特别是“先只读共享再谈统一维护”这个说法，我们一开始就要求改造系统，结果开了八次会没结果。

周敏：想请教一下，产品主数据放第三期这个判断是否绝对？我们是券商，产品体系相对简单一些，是不是可以提前做。

许伟东：运营岗那段说到点上了。我们平台上线一年，负责人调岗后就没人管码值了，现在各系统又开始各写各的。这个坑真的普遍。

李静怡：登录记录那个判断方法挺妙的，回去就看一眼我们自己的数据，估计不太乐观。