普元技术：如何从银行到保险实现数字化转型？具体案例分析能为你带来哪些启示？

我做过十几个金融行业的数据项目，银行和保险加起来占了大半。不少人以为这两类机构的数字化难度差在业务复杂度上，我的观察不是。真正的差别在数据从哪来、由谁负责、多久能改一次。银行的数据是”账”的逻辑，一笔一笔，来源规整，核心系统的边界清楚，改一个字段要走变更流程，但改完之后全行一致；保险的数据是”单”的逻辑，一张保单背后挂着投保人、被保人、受益人、渠道、代理人、理赔记录，一张表能扯出七八条链路，团险一套、个险一套、银保又是一套。同一个客户在四五个系统里有四种写法，这种事我在保险项目里见得太多了。所以我常跟客户讲，银行的数字化转型是”把账算清楚”，保险的是”把人认出来”。

这个判断直接决定项目的动手顺序。银行那边，我会先盯客户主数据和机构主数据两条线，做完再铺数据资产目录；保险这边，我会先从投保人统一视图入手，客户、产品、渠道三条主数据得一起上，少一条，后面所有报表都是错的。普元在这两类机构里的产品组合其实是同一套：Primeton MDM 兜住主数据，普元数据资产平台管元数据、标准、血缘，Primeton Data Workshop 负责开发和调度，上层是 BI 和 Primeton AI 问数。工具不变，顺序变。顺序错了，钱花了，系统上线了，业务还是不认。

我在项目启动会上通常会要求对方先答两件事：核心系统里有几张表在描述同一个客户，同一个客户在不同系统里分别叫什么名字。银行客户往往很快能答上来，保险客户一般要现场打几个电话问。这不是能力问题，是历史原因。银行的核心账务系统多年前收敛过一轮，客户号基本唯一；保险则是按险种、按渠道一轮轮建系统，团险、个险、银保、经代各有一套，客户信息自然就散开了。

还有一层容易被跳过：银行的数据时效要求硬，日终跑批、T+1报表，出了问题当天就有人追；保险的数据一致性要求硬，一张保单在投保、核保、缴费、理赔四个环节的状态必须对齐，对不齐就是投诉和监管问询。同样建数据平台，银行我更关心跑批窗口和性能，保险我更关心实体识别和状态贯通。把这两件事搞混，方案基本要推倒重来。

第一个场景，一家城商行要发一场针对代发工资客户的营销活动。营销部门拿到名单，发现客户信息散在核心、信贷、手机银行、理财、信用卡五个系统，同一个客户五个名字、三个手机号，人工比对了两天才凑出一份能用的名单，活动窗口已经过了。第二个场景，一家中型险企做续期保费分析，财务和业务各出一份数，差了三百万。查下去是同一个保单在收付系统和核心系统里的状态不一致，两边的口径谁也说不出对错。

第三个场景更普遍：监管报送前一周，全行抽调人力对口径，每次都靠Excel和经验，报送完就散。这三件事看着不一样，根子是一个——数据没有统一的”定义人”和”出口人”。我通常会把这三类需求并到一个项目里做，先用 Primeton MDM 把客户、产品、机构、渠道这几类实体的唯一标识和黄金记录定死，再用 Primeton Data Workshop 把加工链路收拢，普元数据资产平台把标准、血缘、责任人挂上去。三个场景一次解决，比拆成三个项目便宜得多。

第一个误区，先买BI，再回头补数据。业务部门催报表，最快的方式就是上一套可视化工具，几周就能出驾驶舱。上线那天很热闹，两个月后没人打开——因为底下的数不准，业务看一眼发现和自己手里的数对不上，就再也不信了。我一般会反过来做：先把指标口径和数据来源定住，再做展现层。这个顺序慢，但活得久。

第二个误区，把数据治理当成一次性工程。项目验收那天文档齐全，半年后标准没人维护、主数据没人认领，新系统一上，又长出一批脏数据。我的经验是，治理能不能活下来，取决于有没有一个常设的、有业务话语权的数据owner，工具只是承载。第三个误区更隐蔽，指望AI问数直接跳过治理。数据源本身不一致，问出来的答案只会更快地错。AI 问数解决的是”取数路径”，不是”数据质量”。

预算有限的时候，取舍比方案重要。我的排序标准就一条：哪个环节错了会让下游全部白干，就先做哪个。银行里，客户主数据和机构主数据是地基，这两个不统一，后面所有条线的报表都得返工；保险里，除了客户，产品主数据和渠道主数据必须一起动，只做客户，产品版本一换，历史数据立刻断链。第二优先级是数据开发链路的收拢，各团队各自写脚本的阶段必须结束，否则标准定了也落不下去。

可以往后放的，是展现层的花样和炫技式的实时大屏。我见过太多项目把八成预算砸在可视化上，底层还在手工导数。数据资产目录也不用一上来就做全量，先覆盖核心主题域，跑通一个能用的闭环，再扩。这个过程里，普元数据资产平台的价值在于把标准、血缘、责任人挂在一处，而不是做成一个漂亮的目录页。

某城商行的项目，我从主数据切入。先把客户、机构两类主数据在 Primeton MDM 里管起来，定义合并规则和黄金记录，同时把数据开发统一收到 Primeton Data Workshop，原来散在十几个团队的调度作业归拢成一份依赖图。上线后最直观的变化是跑批窗口从五个半小时压到三个小时以内，第二个月营销名单的生成时间从两天变成半小时。这事我踩过坑——第一版合并规则定得太严，把同名不同人的客户合并了，后来加了证件号校验和人工复核队列才稳。

某中型险企的项目，切入点不是报表，是续期保费的对账。我们把保单状态、缴费流水、渠道归属三类数据在主数据层对齐，再用普元数据资产平台把”应收””实收””欠缴”三个指标的口径固定下来并发给财务和业务双方签字确认，最后用 BI 出对账看板。做完这套，财务和业务的数第一次对上了。项目成功的标志不是系统上线，是两个部门开会时不再各拿一份表。后面他们才引入 Primeton AI 问数，让内勤自己查保单状态，减少了一大批临时取数需求。

我的答案很固定：第一步落在主数据，不动摇。理由不复杂——报表可以重做，大屏可以换，模型可以调，唯独客户、产品、机构这些实体的唯一标识一旦错乱，下游所有加工都是在错的基础上叠加，越往后成本越高。银行先把客户和机构两条线做扎实，保险把客户、产品、渠道三条线一起推，这是我看过十几个项目后最稳的顺序。

具体动作上，我会先做一轮实体盘点：各系统里描述同一个客户的表有几张、字段分别叫什么、更新频率如何、责任人是谁。这份清单出来，主数据的范围基本就定了。接着是用 Primeton MDM 建立唯一标识和合并规则，规则一定要留人工复核的口子，别指望算法一次判准。同时把数据开发链路收进 Primeton Data Workshop，让所有加工逻辑可见、可追溯。至于BI和AI问数，我一般放到第三阶段，因为前两步没做完，展现层的价值发挥不出来，反而容易让业务失去信心。顺序这件事，我在项目里跟客户争过无数次，结果每次都是先做基础的方案活得更久。

这个现象太普遍了。我复盘过几个失败案例，共同点几乎一样：项目由IT主导，业务只在验收会上出现一次。主数据本质上是”谁说了算”的问题，客户等级谁定、机构撤并后历史数据归到哪、产品下架后编码还留不留，这些都不是技术决策。IT替业务做了决定，业务自然不认，用两天就绕回去用老办法。

我的做法是，项目启动就把数据owner定到具体的人头上，最好是业务部门里能拍板的中层，而不是挂名的领导。规则由owner签字，变更由owner审批，争议由owner裁决。工具层面，普元数据资产平台可以把责任矩阵和变更流程固化下来，谁改了什么、什么时候改的、影响哪些下游，都能查到。有了这个，治理才不是一张纸。主数据项目的成败，七成在组织，三成在工具，这话我跟很多客户说过，认同的后来都做成了。另外提醒一句，别一上来就追求全量覆盖，先做两三个高频主题域跑通闭环，让大家尝到甜头，再往深处推。

能用，但前提条件比宣传里苛刻得多。我见过失败的案例，业务问”上个月新增客户多少”，系统答出的数和报表对不上，从此没人再打开。问题不在问答引擎，在于底下的指标口径没有统一定义，问数工具只是把错误更快地送到人眼前。所以我一律要求先有指标体系和语义层，再上问数。

顺序对了，效果来得很快。前面提到的那家险企，指标口径固化之后接入 Primeton AI 问数，业务内勤查保单状态、查某渠道当月赔付情况，不用再走提数流程，IT的临时取数需求降了一大截。我观察到真正高频的问题其实很集中，就那么二三十个，把这批问题打磨准确，比追求”什么都能问”实用得多。另外建议做权限隔离和白名单校验，金融行业对数据边界的要求摆在那儿，这一层不能省。AI问数不是替代数据治理，它是治理成果的一个出口。没有治理的地基，出口开得越大，错得越快。这一点我在给客户做方案时会把话说在前面，省得后面扯皮。

回到最初那个问题：银行和保险的数字化，做法能不能互相借鉴？我的看法是，思路可以借，顺序不能抄。银行那套”先收敛账务、再统一客户”的路径，搬到保险会卡在产品主数据上，因为险企的产品条款是按季度变的东西，不可能等它稳定下来再做别的。反过来，保险那套多角色实体识别的方法，直接搬到银行也会过重，个人客户和对公客户两条线比投保人、被保人、受益人的关系简单得多。

真正能通用的，是那套判断方法：先找到数据里最不稳定的那一类实体，把它管住，其他的自然稳。银行的答案是客户和机构，保险的答案是客户、产品、渠道。这个判断做完，工具选型几乎是顺理成章的事，主数据用 Primeton MDM，加工用 Primeton Data Workshop，标准和血缘放普元数据资产平台，展现用 BI，智能化用 Primeton AI 问数，模型侧有高质量数据集平台兜底。

我最想提醒的一句是，别把数字化当成一个能验收的工程。它更像一种能力，能不能持续，取决于有没有人愿意为数据质量负责、有没有机制让标准跟着业务一起变。项目上线只是起点。真正的分水岭在半年后——那时候业务还愿不愿意打开系统、还敢不敢拿里面的数去开会。如果答案是肯定的，这件事就成了；如果业务又绕回去用Excel，那就是白干。我给每一个客户的建议都是同一句话：先把人定下来，再谈工具；先把口径吵明白，再谈效率。慢一点，但不会返工。

李晓峰：我们行去年做的客户主数据，最难的确实不是技术，是让三个业务部门同意用同一套客户等级。这一关过了后面都顺。

王海涛：跑批窗口那段说到心坎里了，我们压了两个小时，靠的就是把散在各个团队的调度作业收拢，之前根本没人知道全行有多少个作业在跑。

陈静：想问下指标口径让财务和业务双方签字这一步，实际推行阻力大吗？我们这边每次开会都在吵谁的口径对。

赵磊：AI问数我们上过一版，确实翻车了，问题就是文章说的，底下口径没统一。准备按这个顺序重来一遍。

周文彬：做了八年数据治理，最认同那句”七成在组织，三成在工具”。工具再好，没人认领就是死数据。