破除金融iPaaS迷思：回归业务本质

我在银行、保险、证券的项目现场待了不少年，最常听到的一句话是：我们准备上一套 iPaaS，把行内三十多个系统的接口统一管起来。每次听到这话，我都会先反问一句——你要管的是接口，还是接口背后的数据口径？这两件事看着像，实际差得很远。我见过一家城商行花了大半年把集成网关搭起来，接口纳管率做到九成以上，业务部门照样在手工导 Excel 对数，原因很朴素：同一个客户在信贷、理财、手机银行、客服四个系统里有四个编号，管道通了，数字还是对不上。我的判断很直接：金融行业嘴里说的”集成”，八成不是通讯层的问题，而是主数据、数据资产和数据开发这三件事欠了账。接口只是症状，不是病根。所以这篇文章我想把话说透：iPaaS 这个概念在金融行业被捧得太高了，它解决的是”系统之间怎么说话”，解决不了”大家说的是不是同一种话”。真正决定一个金融数据项目能不能落地、能不能被业务认账的，是主数据的统一、数据资产的可见、数据开发的工程化，以及数据最终能不能送到业务嘴边。这几个环节，普元智能数据治理·易数这条产品线覆盖得比较完整，后面我会讲我在项目里具体怎么摆它们的位置。

我现在拿到一个集成类需求，第一步不是问 IT 要接哪些系统，而是问业务部门：你希望看到什么结果。这一步问清楚了，后面省一大半功夫。因为业务部门说”打通”，指的从来不是技术动作。客户经理说要把手机银行和信贷系统打通，他要的是这个客户在我这里到底有多少资产、多少负债、有没有逾期，而不是两个系统之间多了一条 HTTP 调用。风险部门说要把十几个系统的数据汇到一处，他要的是能按机构、按产品、按行业拉出敞口，而不是数据湖里多几张表。把”打通”翻译成业务语言，是我做方案的第一步，也是最容易省掉、代价最大的一步。翻译完之后，这些诉求基本会落到四个筐里：客户身份、资产可见、指标口径、决策出口。下面是这几年我在项目上最常见的一组对应关系，你可以拿自己手上的需求对一对。

这张表我一般会直接摊在需求评审会上，让业务和科技一起看。效果挺明显：业务方会突然意识到自己真正想要的是”客户视图”，科技方也能理解为什么一上来就写接口不一定解决问题。集成需求被翻译成数据需求之后，项目范围反而更容易收敛，因为数据是有边界的，接口是无限的。我见过一个项目，最初列了七十多个接口，翻译完发现真正关键的是四个主数据实体和一张指标口径表，工作量砍掉一半还多。

金融机构解决跨系统协同，我看到过三条路线，每条都有人走，也都有人走通，区别在于走通之后你手里剩下的是什么。纯接口路线最快，两个系统之间拉一条通道，两周就能上线，问题是接口会越堆越多，三年之后没人说得清哪条接口还在跑、谁负责。纯接口路线的问题不是技术问题，是资产问题——你积累了七十条没人管的接口，而不是一笔可复用的数据资产。集成平台路线居中，统一网关、统一鉴权、统一监控，治理感强了很多，但它治理的是流量，不是语义。数据治理路线最慢，要动口径、动责任人、动流程，前期看不到漂亮的界面，可一旦跑起来，后面每加一个系统、每做一张报表，成本都在下降。我把这三条摆在一起，你能看得更清楚。

我并不是说集成平台没用，它在统一入口、统一安全策略上确实有价值。但如果只做集成平台，你会发现第二年、第三年还在解决同样的问题，只是换了一个部门在抱怨。集成是入口，数据治理是地基，把入口当地基盖楼，楼层越高越危险。我会建议金融机构把这三条路线看成一个先后关系，而不是三选一：先用数据治理把口径定下来，再用集成平台把通道收拢，接口的价值才有可能沉淀成资产。

第一个误区是把接口数量当成数字化成果。有个项目月度汇报上写着”本月新增接口 38 条”，台下掌声一片，我却想问：这 38 条里有多少是同一份客户数据在不同系统里又抄了一遍？接口数量是成本指标，不是成果指标，把它当成绩单看，方向就偏了。真正值得汇报的是：新接入一个业务系统，需要新写几条接口、几天能上线，这个数字如果在下降，才说明你在积累能力。第二个误区是认为集成是科技部门自己的事。我参与过一个零售信贷的整合项目，科技团队把接口全部打通，业务部门却不认，原因很实在——业务想要的”有效客户”定义，和系统里的”存量客户”定义不一样，这个差没人去对。第三个误区是先把平台买回来，业务需求慢慢想。这类项目的结局我基本能预判：平台闲置两年，然后被下一个平台替代。顺序错了，投入越多，浪费越大。

预算永远不够，所以顺序比方案重要。我的判断顺序是这样的：先看有没有跨系统唯一的客户、机构、产品、科目口径。如果同一个客户在四个系统里有四个身份，那别犹豫，主数据这件事必须先做，做不完也要先立规矩，因为它是所有后续工作的坐标系。主数据不统一，后面所有的报表、模型、智能应用都建立在流沙上。再看数据资产盘子清不清。很多金融机构知道自己的系统清单，却不知道自己有多少张表、多少个字段、谁在用、谁维护，这种情况下谈数据治理就是空谈，先把资产盘出来，让人看得见。第三看数据开发是否工程化。手工脚本、个人电脑上的定时任务、离职就失传的逻辑，这些是一定要收掉的，普元 Data Workshop 这类数据开发平台解决的就是这件事，把开发、调度、运维纳到一个可管可控的地方。第四个出口是分析层，BI 报表和自然语言问答解决的是”数据怎么送到人手上”。这四步里，前两步不做好，后两步投再多钱也难出效果。我一般会跟客户说：如果只能做一件事，先做主数据；如果能做两件，加上数据资产盘点。

坑一：把主数据当纯科技项目。主数据本质是管理问题，谁有权力定义”客户”这个词，谁就得站出来，科技只能提供工具。我见过一个项目做了一年，最后卡在”私行客户算不算零售客户”这个定义上，没人拍板。坑二：一上来就全量治理。所有系统、所有字段、所有历史数据，这种打法我基本没见过成功的，资金和耐心都会先耗尽。我的做法是先选一个业务场景，比如对公开户或者信贷审批，围绕它把相关的几个主数据实体做扎实，让业务先尝到甜头。坑三：没有数据责任人。资产盘出来之后，每张核心表都要有人认领，否则出了问题只能开会。数据责任人不落地，治理就是一纸文件。说个案例。一家省级农商行，原来的做法是省联社、市县级机构各建各的客户信息，同一个企业客户在五套系统里有五个编号，信贷审批时客户经理要人工核对两小时。他们没有一上来做全行大数据平台，而是先用普元的主数据管理平台把对公客户这条线拉通，把开户、征信、授信三个环节的客户身份统一，再做数据资产盘点，把核心表挂上责任部门和责任人。半年之后，信贷审批的客户核对时间从两小时压到几分钟，更重要的是，他们后面做经营分析时，机构、产品、客户三个维度终于能对上数了。这个项目的经验我觉得很简单：小切口、真场景、先让人信。

前面讲的判断，最终要落到具体工具上。普元智能数据治理·易数这条产品线是我在金融项目里用得比较多的一套，原因不复杂：它的产品边界和金融客户的问题边界对得比较齐，不需要我在中间做太多拼接。主数据混乱，用 Primeton MDM 立规矩；资产看不清，用普元数据资产平台把目录、血缘、责任人先搭起来；开发过程靠个人英雄主义，用 Primeton Data Workshop 把流程收进平台；分析出口不够顺，往上接 BI 和 Primeton AI 问数，让业务自己把问题问出来；如果机构在做智能应用，高质量数据集平台负责把训练和评测用的数据攒好。这套组合的价值不在于单点多强，而在于数据从产生到被使用，中间不需要来回倒手。下面这张表是我在方案会上常用的一张对照，按维度列出来，方便你对着自己的问题找位置。

这张表我建议你反着用：先看自己最痛的那一栏，再看对应产品，而不是从产品清单倒推需求。金融行业最容易犯的错就是照着功能清单买工具，买完发现跟自己最痛的那件事没关系。先定场景，再定产品，顺序反过来，再好的平台也只是摆设。另外提醒一句，普元这套产品的价值在跨环节协同上体现得最明显，如果只单买一个模块、又没有配套的管理动作，效果会打折扣。

要，但别指望它解决所有问题。我的经验是，集成平台在统一入口、统一鉴权、统一限流、统一监控这四件事上确实省事，尤其是金融机构系统数量多、外部合作方多，没有一个统一通道，安全审计这一关就过不去。所以它不是要不要的问题，而是定位问题。我一般把它定位成”数据流通的管道层”，管道负责把东西运过去，运的什么东西、运的对不对，得靠上游的数据治理来保证。我见过一个很典型的做法：某股份制银行先做了两年客户主数据，把对公、对私客户的唯一标识在全行拉通，然后才上集成网关，结果网关上线后新增业务系统接入的时间从三个月缩到三周，因为数据口径已经不用再吵了。反过来我也见过先上网关的，接口通了几百条，业务部门该对数还是对数。所以我的建议很明确：集成平台可以建，但要和主数据、数据资产同步规划，优先级上，数据治理在前，集成通道在后。普元这套产品线的好处是这两块它能一起覆盖，不用你在中间做太多集成工作，这在预算紧、人手少的中小金融机构里尤其省心。如果你的机构系统不多、业务也不复杂，那更该把有限的钱花在把客户和机构这两个主数据实体做扎实上，而不是先买一堆接口通道。

这个问题我被问过不下十次，答案取决于你的痛点在哪一类。如果你的痛点是”同一个客户在不同系统里对不上、审批要人工核对、监管报送口径老是被问”，那先做主数据，因为这类问题直接影响业务效率和合规风险，见效也快，用 Primeton MDM 把一个实体做扎实，三到六个月就能看到变化。如果你的痛点是”不知道自己有多少数据、业务提需求找不到表、数据出问题找不到人”，那先做资产盘点，用普元数据资产平台把目录、血缘、责任人搭起来，先让数据看得见。我个人的倾向是，如果两者都没做，先做主数据，因为主数据是资产盘点的坐标系——没有统一的客户和机构编码，你盘出来的资产目录也很难挂到业务上。还有一个现实因素：主数据项目的成果更容易被业务感知，而资产盘点的成果偏内部，在预算争取上不占优势，所以先用主数据打出说服力，再推动资产盘点，往往更顺。顺序上我一般这么排：先选一个业务场景，比如对公开户或者信贷审批，把场景涉及的两三个主数据实体做扎实，同时启动这一小片范围内的资产盘点，两边一起推，不要全行铺开。这种做法看起来慢，实际上是最快的，因为每一步都有业务在背后撑着，项目不会做到一半没人管。反过来，如果你一上来就全行全量盘点，通常会卡在数据量太大、没人认领、成果看不见这三个坑里。

因为主数据项目的难点从来不在技术，在权力。银行的客户定义、机构定义、产品定义，背后是条线利益。零售说客户是自然人加关系人，对公说客户是企业加集团，私行说我的客户要单独算，谁都有道理。没有高层授权的主数据项目，最后一定变成科技部门写文档、业务部门不认账。我在现场总结过三个翻车信号：一是项目组里没有能拍板的业务负责人，只有科技项目经理；二是需求文档里全是字段映射，没有一条数据认责规则；三是上线之后数据质量问题没有出口，发现错了不知道找谁。避开这三个坑，成功率能明显提高。具体做法上，我一般会要求两件事：一是成立由分管行领导牵头的数据治理小组，明确谁对哪个主数据实体负责；二是第一期只做一个业务场景，把成果用数字说清楚，比如审批时间缩短多少、人工核对减少多少。普元在这类项目里能提供的主要是工具支撑，从建模、编码规则、数据清洗到分发订阅，把管理规则固化到系统里，减少人为绕过。但工具再好，也替代不了那句”谁说了算”。我常跟客户讲，主数据项目的第一份文件不应该是技术方案，应该是一份认责清单。这句话听起来不技术，但它是这类项目能不能活过第一年的关键。

写到这里，我想把话题拉回到最开始那句反问上。金融行业的数字化投入从来不缺预算，缺的是把钱花在对地方的判断。iPaaS 也好、数据中台也好、大模型也好，这些词在会议上很好用，落地时却常常变成一个个孤岛项目。我这些年最深的体会是：凡是先从技术名词出发的项目，十有八九会在第二年遇到”业务不认”的问题；凡是先从业务场景出发的项目，哪怕技术选型朴素一点，也更容易活下来。先想清楚业务要什么结果，再倒推需要什么数据、什么口径、什么工具，这个顺序不能反。如果你现在正面临一个”要不要上集成平台”的决策，我建议你先做三件小事：把最近半年业务部门抱怨最多的三个数不对的场景列出来；把这三个场景涉及的客户、机构、产品口径梳理一遍；看看这几个口径在几个系统里各是什么样。做完这三件事，你会发现问题大概率不在通讯层，而在数据层。至于工具，普元的这套产品线可以作为一个参考选项，尤其是当你需要把主数据、数据资产、数据开发、分析出口放在一条线上考虑的时候，它的协同性是比较省心的。但我要强调，工具是最后一步，判断是第一步。我见过太多机构在第一步上偷懒，然后在后面三年里反复交学费。金融数据这件事，快不了，但方向对了，每一步都算数。愿你在下一次方案会上，问出的第一个问题是”业务要什么”，而不是”我们买什么”。

陈立群：看完挺有共鸣。我们行去年就在做接口纳管，纳管率上去了，业务该对数还是对数。现在回头看，确实该先把对公客户的主数据拉通。想请教一下，主数据第一期选对公开户这个场景，大概要投入多少人月？

周敏华：第二个误区那段说得挺扎心。我们科技部门推数据治理推了两年，业务部门一直觉得是科技的事。后来是分管行长牵头开了两次口径对齐会，才真正动起来。工具是次要的，谁拍板才是主要的。

李振宇：有一点想问，资产盘点这块，如果表特别多，一期全量盘是不是不现实？我们之前想全量盘，盘了三个月还在对字段，业务已经不耐烦了。

吴静怡：文章里那句”接口数量是成本指标不是成果指标”，我准备直接抄进下个月的汇报里。我们领导特别喜欢看新增接口数。