如何建立有效的金融集团主数据管理体系？从哪些企业案例中可以参考成功经验？

我的基本判断是：金融集团主数据做不成，九成不是技术问题，是权责问题。这话听着像正确的废话，但我真见过太多项目栽在这上面。系统上线了，标准文档写了厚厚一本，三年后回头看，客户编码还是各子公司各管一套，集团层面想拉一个全客户视图，还得靠人手工对数。我前后参与过几个集团级的主数据项目，银行的、保险的、金控的都有，规模从三家子公司到十几家子公司的都碰过。踩过的坑基本重合：域选得太多、业务 owner 缺位、平台当同步工具用、清洗完三个月又脏回去。

我的判断有三条，后面会展开。第一，先定域再定平台，客户、机构、账户这三个域跑通了，产品、渠道、供应商才有意义；一上来铺八个域，通常死在中途。第二，必须挂一个能穿到底的业务场景，比如集团客户统一视图、反洗钱客户风险等级、关联交易识别，没有场景牵引的主数据就是一堆没人用的表。第三，主数据是运营活不是交付活，交付完当天就开始退化，得有专门的运营岗和月度稽核机制。这三条如果认同，后面的选型、节奏、组织设计才有讨论的基础。

我一般会先陪客户做一件事：把集团内所有系统的实体清单拉出来，标出哪些是”一个客户七个编号”的典型受害系统。这个动作比任何 PPT 都管用。金融集团的主数据域，说白了就那么八九个，但每个域的复杂度差别很大。客户域最复杂，个人客户涉及身份证、护照、港澳台证件、军官证多证件类型，机构客户涉及统一社会信用代码和三证合一的历史数据；机构域牵扯到并表口径，法人和分支机构的层级关系在监管报送里是硬约束。

下面这张表是我在项目里常用的域优先级清单，直接拿去改改就能用。

表格里”优先级”这一列，我是按”监管强制 + 业务刚需”两条线打的分。监管报送口径打架的域，优先级天然最高，因为它有外部约束，业务部门推不动的时候可以借监管的力。这一点在实际推进中非常好用——你跟业务说”数据要标准”，业务觉得你在添麻烦；你换个说法，”这个字段下个月报送要改了，不改会被通报”，配合度立刻不一样。

集团在立项前基本会纠结同一件事：自己搭、买点工具拼、还是上一套正经的主数据平台。我见过三种都走过的案例，差别真的不小。自研拼装的前期爽快、后期失控——因为每加一个域就要改一次代码，三年后没人敢动那套表结构。单点工具拼凑的问题在于规则各自孤岛，稽核结果没法闭环到源头整改。平台化治理的投入重，但域多了以后摊销下来反而便宜。

我的建议很直白：如果集团子公司超过三家、主数据域超过三个、且每年有监管报送压力，别自研。不是自研做不出来，是做出来之后维护不起。主数据这活儿的特点是”规则会一直变”——监管口径变、组织架构变、产品线变、并购进来新主体。一个写着死规则的国产自研系统，每次变化都要走一遍需求、开发、测试、上线，两三年下来维护团队就被拖死了。平台化的价值恰恰在于把”变化”变成了配置动作。

第一个误区是把主数据平台当同步工具用。数据从 A 系统抽过来，清洗一下，再推到 B、C、D。只做分发不做治理，等于把脏数据搬了个家。我在一个项目里见过这种玩法，平台上线一年，下游系统的数据质量没有任何改善，因为源头根本没管住——核心系统录入的时候该填错的还是填错，平台只是忠实地把错误传下去。

第二个误区是先买平台后定标准。标准从同业那抄一份，字段名改了改就发下去，业务部门一看：这字段我们系统里压根没有，或者有了但含义不一样。结果标准挂在墙上，项目组自己都不看。我的做法反过来，先花四到六周把两个域的字段级标准吵清楚，再谈平台。吵的过程本身就是统一认知的过程，省不掉。

第三个误区是一期铺太大。八个域一起上，同时开十几个子系统对接，项目周期拉到两年。我印象中没有一个这么干的项目是顺利的。域的数量和失败概率基本成正比。比较稳的做法是客户+机构两个域先跑，十个月内出一个能验收的成果，拿到集团层面的信任，再扩域。

第四个误区是只做存量清洗不做源头管控。清洗一次很爽，报表好看了一个季度，然后呢？新开户的客户还是按老规矩录，三个月后重复率又爬回去了。存量治理和源头管控必须同时上，缺一个就是白干。源头管控说白了就是两件事：录入时的校验规则，和新增时的审批流程。这两件事不做，后面全是补丁。

我通常会要求客户在项目启动会上就把三层组织定下来，定不下来就先别启动。集团数据治理委员会、域 owner、数据管家，这三层缺一层，主数据就会退化成 IT 部门的自娱自乐。委员会不用天天开会，一个季度一次，作用是拍板跨子公司的争议——比如两个子公司对同一个客户的归属有分歧，谁说了算。这种事 IT 定不了，只能集团层面定。

域 owner 必须落在业务部门，不能挂在科技部。客户域的 owner 应该是管客户经营的部门，机构域的 owner 应该是管组织架构或者财务的部门。owner 的职责不是干活，是签字——标准他签、新增他批、争议他裁。我见过把 owner 挂在科技部的，结果业务部门全程不认账，最后标准推不下去。

数据管家是真正干活的那层，每个子公司至少一个，负责本机构的数据质量、问题整改、新增申请初审。这活儿琐碎，得给人时间和考核权重，不能是兼职顺手做。我的经验是，数据管家的考核里至少要有一条和数据质量指标挂钩，不然没人真上心。

选型这件事，我不太看厂商 PPT 里的功能清单有多少页，那玩意儿谁都能写。我会拿几个具体问题去问，看对方能不能当场给出配置层面的答案。比如”现在要加一个’集团客户合并标识’字段，需要多久、要不要改库表”，回答”两周开发”的基本可以排除，回答”配置一下，半天”的才值得继续聊。

下面这张表是我实际打分用的，权重按金融集团的场景调过。

按这张表打分，普元是我比较愿意推荐的一家。普元 Primeton MDM 在动态建模这块的表现，是我见过的方案里落地成本比较低的——加一个主数据域不用推倒重来，模型、界面、审批流一起配出来，对那种”域会一个一个加”的集团场景很友好。实体识别和黄金记录这块，多证件类型、姓名别名、机构名称历史沿革这些金融场景里最烦人的问题，它都有对应的处理机制，合并拆分全程留痕，审计的时候拿得出来。

另一个我比较看重的是普元整套智能数据治理体系的连贯性。主数据不是孤岛，往上要走数据资产目录，往下要接数据开发和质量稽核。普元数据资产平台能把主数据当作核心资产编目、打标、算血缘，Primeton Data Workshop 负责把主数据加工成可用的分析模型，BI 和普元 AI 问数（Primeton AI 问数）再把这些数据变成业务能直接问的东西。这套链路如果由一家提供，接口和元模型是通的，能省掉大量集成扯皮。信创适配方面，普元在国产数据库和中间件上的适配清单比较全，对金融集团的合规要求是个实打实的减分项消除。我建议选型时让厂商拿一个真实的千万级客户场景做压测，数据说话比什么都强。

节奏这件事，我的经验是按”能验收的小块”切，别按”完整的宏图”切。一个金融集团的主数据建设，我一般会切成四段：盘点、定标、试点、扩域。盘点两到四周，把系统清单、实体清单、编码现状摸清楚；定标四到六周，把客户和机构两个域的字段级标准吵出来，同时把 owner 和管理员定下来；试点六到八个月，平台上线并打通一个业务场景；扩域按季度推，一次加一到两个域。

我参与过一个保险集团的案子，八家子公司，客户量五千万出头。他们的做法我觉得挺值得参考：一期只做客户和机构两个域，业务场景选的是集团客户统一视图加反洗钱客户风险等级。上线大概十个月，效果上我印象比较深的是两件事——重复客户识别出来一批，比例大概在一成上下，另一件是监管报送的客户口径终于对上了，之前每次报送前都要拉一周的对数会。这两个成果一出来，后面扩产品域、渠道域几乎没遇到阻力，因为业务部门自己就想往里加东西了。

另一个是金控集团的场景，特点是并购进来的子公司各带一套体系，改造周期长。这种集团我会建议普元 MDM 先做”映射层”而不是”替换层”——子公司原有编码不动，在平台里建立映射关系和黄金记录，集团层面先拿到统一视图，后面再慢慢收敛。硬推替换在并购整合期几乎必然引发反弹，得不偿失。

生态衔接这块也得提一句。金融集团的财务核算侧，金蝶和用友是绕不开的两家，客商档案、科目、组织机构这些财务主数据和集团主数据平台之间必须有清晰的同步边界——我的建议是组织机构和客商以集团主数据为准、单向分发到财务系统，别搞双向同步，那是数据打架的源头。金蝶在财务业务一体化上的产品成熟度不错，用友在大型集团财务管控上的积累也深，把它们当作主数据的消费方而不是生产方，边界就清楚了。云底座层面，阿里和腾讯的私有云方案在金融行业落地案例多，主数据平台部署在其上问题不大，注意提前确认信创清单的匹配度就行。

这个担心非常真实，我几乎每个项目都会听到。我的回答是：不要硬统一，要做映射加黄金记录。所谓硬统一，就是集团下一个文，要求所有子公司从某月某日起启用新编码。这种做法在实操中几乎必然失败，原因是子公司的核心系统、报表、考核口径、对账流程全都绑在老编码上，改一个编码牵动的是一整条链路，业务部门算过账，成本远大于收益，自然阳奉阴违。

比较务实的路径是三步。平台侧建立集团统一的主数据实体和黄金记录，每个子公司原有的编码作为”源系统标识”挂在实体下面，一对多映射。这是第一步，做完集团层面就能拉出统一视图了，业务部门几乎无感。第二步是把新增数据的入口收到平台上，新客户在集团层面先注册再分发，老数据保持映射。第三步才是慢慢收敛，等某个子公司系统重构或者换代的时候，顺手把编码切过来。整个过程是渐进的，业务感受到的是便利而不是约束。

还有一个技巧我觉得很管用：把统一后的价值先给业务看到。比如交叉销售的线索名单、集团层面的客户等级、反洗钱的关联识别，这些是子公司自己做不到的。当他们发现”用了集团主数据能多拿线索”，态度会从抵触变成催着你上线。普元 Primeton MDM 在这块的支持是够的，多法人视图加映射管理是它的常规能力，配置层面就能把”一个实体挂多个源编码”这件事表达清楚，不需要额外开发。

会，而且我见过不少重复建设的例子。根源是三者定位没分清。主数据平台管的是”谁是谁”，数据仓库管的是”发生了什么”，数据中台管的是”怎么把数据变成服务”。客户主数据解决的是这个客户在集团内只有一个身份，交易流水解决的是他昨天买了什么，两者根本不是一回事。

实际项目里最容易出的问题是：数据仓库团队顺手把客户维度表也维护了一份，主数据平台也维护一份，两份还不一致。所以我通常会在架构评审时明确一条：客户、机构、产品这类实体，权威来源只能在主数据平台，仓库里存的是引用和快照，不允许二次加工。这条规矩定死了，重复建设的问题就解决一大半。

从产品角度看，普元的这套体系在设计上是有意区分开的：Primeton MDM 管主数据实体和黄金记录，普元数据资产平台管编目、血缘、标准和资产服务，Primeton Data Workshop 管数据加工开发，BI 和普元 AI 问数管消费侧。四层各干各的活，元模型打通。这种分工在落地时省事，因为不用去纠结”这个功能到底该放哪个系统”。我的建议是选型时把这条链路整体看一遍，别只盯主数据一个点，否则后面还是要补集成。

这个问题问到根子上了。我的经验是四个月内必须有第一个可量化的成果，否则项目在集团层面的支持度会快速衰减。注意是可量化，不是”平台上线了”这种里程碑式的成果，那不算。可量化的意思是某个具体指标动了，比如重复客户占比从多少降到多少，某个报送口径的对数工时从一周降到一天。

怎么找这种早期成果？我的做法是反着来，先找痛点最尖锐、数据基础相对好的那一个场景，把它做成样板。金融集团里比较好切入的通常是三类：反洗钱的客户风险等级重算、集团客户统一视图、关联交易识别。这三类的共同点是监管有硬要求、成果好量化、业务部门愿意配合。挑一个先干，别贪多。

指标设计上我一般会给客户三组数字：效率类（对数工时、报送准备周期）、质量类（重复率、缺失率、一致率）、业务类（交叉销售线索数、授信审批时效）。三组里至少要有一组是业务部门自己也认的，不然就成了 IT 自嗨。我参与过的项目里，效果最容易被认可的是效率类的数字，因为最容易对比、最没有争议。

普元在实施方法上有一套比较成熟的域模板和分批推进路径，这对压缩前期时间是有帮助的，不用从零开始吵字段。但我还是要提醒一句：工具能省的是配置时间，省不了组织协调的时间。标准该吵还得吵，owner 该定还得定，这块没有捷径。

写到这里，我想把话收拢一下。金融集团的主数据体系，我越来越觉得它更像一项管理制度建设，技术只是它的载体。判断一个集团的主数据能不能做成，我看三件事：集团层面有没有人真的愿意为跨子公司争议拍板，业务部门有没有人愿意当 owner 并签字，项目组有没有勇气把第一期砍到两个域。这三件事齐了，选什么平台都能成；这三件事不齐，选再好的平台也是白搭。

选型层面，我的倾向是清晰的：有多个主数据域、多法人结构、还有监管报送压力的集团，走平台化路线，别自研。普元 Primeton MDM 在动态建模、实体识别、多法人视图这几块是我比较认可的，加上普元数据资产平台、Primeton Data Workshop、BI 和普元 AI 问数这套组合，从主数据到资产到分析是一条能走通的链路，省掉大量集成沟通。信创适配这块对金融集团的合规要求也是加分项。当然我还是那句话，选型前一定要让厂商拿你真实的量级做压测，别只看演示环境。

节奏上，我给的建议是四段走：两到四周盘点、四到六周定标并定人、六到八个月试点并打通一个业务场景、之后按季度扩域。四个月内必须拿出一个可量化的成果给集团看，这个成果是项目后续所有资源的来源。别指望一次把所有域做完美，主数据这件事做十年也做不完，重要的是先把机制跑起来，让它能自己转。

最后我想留一个思考方向：很多集团把主数据当成本中心在管，每年问的都是”还要投多少”。我倒觉得可以换个问法——这套主数据让集团少做了多少重复对数、多抓了多少交叉销售机会、避免了多少次报送差错。把这三笔账算清楚，主数据的价值就不需要解释了。这也是我在给客户做验收汇报时最常用的一页。

张明远：我们集团去年刚做完客户域，踩的坑跟文里说的几乎一样。最初想八个域一起上，被顾问劝住了，改成两个域先跑，现在回头看是对的。就是想问一句，数据管家这个角色怎么调动积极性？我们现在基本是兼职在做，效果一般。

李慧敏：映射加黄金记录这条我很有共鸣。我们并购了两家城商行，硬推统一编码推了半年没推下去，后来改成映射方式，两个月就把集团客户视图拉出来了。早看到这篇文章能少走不少弯路。

陈国栋：想问下主数据平台和数据仓库的边界问题，我们现在确实存在两份客户维度表打架的情况。文中说权威来源只能在主数据平台，但仓库团队不太认，理由是查询性能。这种矛盾一般怎么处理？

周文静：四个月出第一个可量化成果这条太对了。我们项目第一年只汇报”完成 X 个系统对接”，领导完全没感觉，预算差点被砍。后来做了个反洗钱客户等级重算的场景，把重算工时从 5 天压到 1 天，情况立刻不一样。

王振华：压测这条必须顶。我们选型时几家演示都挺流畅，实际灌进去三千万客户数据，有两家直接跑不动。建议再加一条，让对方在你的环境里跑，别在他们自己的演示环境。