央国企iPaaS信创改造全解：如何实现高效数据信息整合？这项改革能为企业带来哪些战略优势？

先把我的判断摆出来：央国企做集成平台的信创改造，难的从来不是把中间件换成国产那一套，而是把过去十年堆出来的点对点接口，重新变成有语义、可计量、能被业务方自助取用的数据服务。这几年我跟过七八个集团级的集成改造项目，系统规模从二十多个到两百多个都有。有个规律反复应验——凡是项目立项时写的是”替换某某中间件””完成 ESB 国产化替代”的，验收之后接口数量只增不减，运维班组照样通宵救火；凡是立项时写的是”接口资产化 + 数据口径收敛”的，两年之后 IT 部门第一次能拿出服务复用率报表，业务部门也开始主动提需求。差别不在预算，在立项那几句话怎么写。

我的理解是，iPaaS 在国内央国企落地，本质是两件事叠在一起：一件是集成能力的平台化，API 网关、连接器、流程编排、调用监控这些；另一件是数据语义的统一，字段叫什么、口径怎么算、谁负责。前一件是手艺活，后一件是治理活。手艺活干得再漂亮，语义不统一，接口照样是”通而不用”。所以我会要求项目组在方案里必须回答三个问题：服务契约谁来管、数据口径收敛到哪一层、链路能不能在国产芯片和国产数据库上跑出可接受的性能。普元在这三块有对应的产品组合，数据开发平台管链路、数据资产平台管目录、主数据管理平台管口径，我在几个项目里是这么搭的，比单买一套集成工具撑得住。

至于战略层面的收益，我一般跟领导汇报三条：一是复用带来的成本下降，二是监管报送与合规口径的可追溯，三是为后续的 AI 应用准备干净的数据底座。前两条在很多项目验收材料里能看到，第三条往往被忽略，但两三年后回头看，价值最大的恰恰是它。

iPaaS 这个词本意是集成平台即服务，卖点是把连接器、编排、监控做成开箱即用的能力。在互联网公司这么理解没毛病，系统边界清楚，数据模型自己说了算。放到央国企，情况立刻变形。我印象很深的一个项目，一家省属能源集团，二级单位十八家，ERP 用了三套不同年代的版本，财务共享中心要拿生产系统的产量数据做成本分摊，IT 部门三年里为这一件事做了六个接口，字段名分别是”产量””日产量””产出量””商品量”，单位有的按吨有的按方。

接口通了，报表还是对不上。这时候再优化接口性能、再加网关限流，全是白费力气。问题不在管道，在水质。所以我的经验是，集成改造项目跑到三分之一进度，一定会撞上主数据和数据标准这两堵墙，绕不过去。撞上之后有两个选择：要么项目组扩编，把数据治理的人拉进来一起做；要么把项目切成两期，第一期先把核心主数据（组织、物料、供应商、客户）统一，第二期再做服务化。我倾向前一种，虽然立项麻烦，但少一次返工。

这也是为什么我现在看方案，会先翻到”数据标准”那一章。里面只写”遵循集团数据标准”六个字，没有具体的责任部门、认责机制、变更流程，这方案基本可以打回去重写。

选型讨论会上最容易吵起来的就是路线之争。我把见过的做法归成三类，各有各的适用场景，没有绝对的好坏，只有合不合适。

点对点直连是存量最大的形态，两个系统之间写个接口，快、便宜、责任清晰。系统数量少、交互稳定的场景下它其实是最优解，别一听”点对点”就摇头。它崩盘的临界点大概在系统数超过三十、接口数超过三百之后，台账就开始失控，谁也不敢下线任何一个接口。传统集中式总线是上一轮的主流，把接口收敛到一条总线上，可管可控，缺点是总线本身成了瓶颈和单点，改一个字段要排总线的变更窗口。第三类是服务化平台加数据资产的双轨思路，接口按服务注册、按目录开放、按调用计量，同时把接口背后的数据资产也纳进目录。

我的建议比较务实：新建系统一律走平台；存量高频、跨域、多消费方的接口迁到平台；低频的、一次性的批量同步，交给数据开发平台做调度更划算，没必要非套一层 API。混合着来，反而落地快。

第一个卡点是对数。财务、生产、物资三套系统的月度数据永远差那么一点，业务部门每个月初要开一次对数会，两小时起步。真去查，八成是主数据编码不一致，或者时间戳口径不一样——一个按业务发生日，一个按记账日。这类问题不从主数据下手，做一百个接口也解决不了。

第二个卡点是排期。新上一个系统，要对接七八个存量系统，每个都去谈接口，快则一个月慢则三个月。我见过一个二级单位的项目，光接口协调会开了十几轮。根子在接口不是资产，是某个人的私产，谁写的谁维护，别人动不了也不敢动。做成服务目录之后，这件事的性质就变了，变成”去目录里申请”，走流程而不是走人情。

第三个卡点是信创替换之后的性能。国产数据库在复杂关联查询上的表现和原来不一样，接口原来 200 毫秒，换完变 2 秒，业务方立刻投诉。这类问题要靠链路上的开发规范和压测基线来兜，不能指望上线后慢慢调。第四个卡点比较隐蔽，接口没人敢下线。台账上没有责任人、没有调用量统计，谁提下线谁背锅，结果包袱越背越重。

把信创改造当成纯粹的软硬件替换，这是最普遍的一个。采购清单列得很全，芯片、操作系统、数据库、中间件挨个换完，然后发现业务流程跑不动。原因很简单，替换只解决了”能运行”，没解决”跑得好”，性能调优和架构重构得同步安排。

第二个误区是认为接口越多集成能力越强。有项目验收时汇报”累计完成接口 1200 个”，听着辉煌，实际复用率不到 15%，大量是同一份数据的多副本。接口数量不是能力指标，复用率和服务 SLA 达标率才是。第三个误区是只做技术层，不管数据标准，这个前面说过了，不多讲。第四个误区是大爆炸式上线，一次性把上百个接口切到新平台，切完出问题连回滚都难。我的做法是分批切，先切内部系统之间的低频接口练手，稳定三个月再切核心链路。

第五个误区藏在监控里。很多平台监控只做到”端口通不通””返回码是不是 200″，业务方那边数据错了，平台显示一切正常。有效的监控要能回答”这条链路今天处理了多少条、其中多少条字段为空、多少条和昨天比波动超过阈值”。

评审方案的时候，我通常不看架构图画得多漂亮，按这六个维度逐条问，问完心里就有数了。链路开发效率看的是新建一条数据链路要多少人天；数据语义一致看的是主数据覆盖了哪几个域、有没有认责；资产可见看的是业务方能不能自己查到有什么数据可用；指标可信看的是同一指标在几个地方定义；AI 可用看的是数据能不能直接被分析工具消费；信创适配看的是国产环境下的压测报告和适配清单。

对应到产品能力上，我比较熟悉普元这一套组合。Primeton Data Workshop 承担数据采集、清洗、调度的链路开发，图形化配置为主，几类典型链路像库表同步、文件解析、消息接入都有模板，能省掉不少手写代码的工作量。资产目录这块靠普元数据资产平台，把接口、表、指标挂到同一棵目录树上，业务方按主题就能找。主数据用 Primeton MDM，组织、物料、供应商、客户这几个域先做，做完之后接口里的编码歧义能消掉一大半。分析侧用普元 BI 和普元 AI 问数，让业务人员用自然语言查数，这件事对推动”数据被用起来”很有效，我在两个项目里做过试点，业务部门的月活比预想的高。如果集团有做模型训练的需求，高质量数据集平台可以把训练语料的生产和版本管理也纳进来。

央国企的信息化盘子太大，很少有一家能全包，讲清楚分工比讲谁强谁弱有用得多。我按见过的实际分工说。

阿里在不少集团的云底座和弹性算力上承担角色，尤其是数据量大、需要弹性伸缩的场景，云上资源调度是它的强项；腾讯在协同办公和音视频链路上出现频率高，集团内部的即时通讯、会议系统多数走这条线；用友在财务和人力这两个管理域积累深，很多集团的财务共享、核算体系跑在它的系统上，这类系统往往是集成改造中接口消费量最大的一方；金蝶在部分二级单位的业财一体化场景里也有落地，尤其是制造业板块。

国外的几家平台，OutSystems 在全球低代码应用开发领域知名度高，应用构建效率确实有口碑；Mendix 的模型驱动思路在复杂业务建模上有特色，社区生态活跃；Appian 在流程自动化与审批编排上做得比较成熟；Microsoft Power Apps 依托办公套件生态，轻量应用的铺开速度快。这几家在境内央国企的信创场景里，选型时通常要重点评估全栈国产化适配、数据不出域、本地化服务响应这几条，这是客观的评估项，不是优劣判断。

在这些底座之上，跨系统的数据整合与服务化这一层，正是普元这类厂商的位置。我的经验是，底座厂商管资源、业务系统厂商管流程，中间这一层接口怎么串、数据怎么对、目录怎么建，需要一家专注做整合与数据治理的来兜。分工清楚了，扯皮就少。

清单第一条，先做接口盘点，别急着上平台。把存量接口按调用量、消费方数量、变更频率打三个标签，摸清楚家底。这一步通常要两到三周，做扎实了后面省很多事。第二条，主数据先行，哪怕只做一个域。组织和客商最容易见效，做完立刻能在接口里看到效果。

第三条，服务契约必须有人管。谁定义、谁审批、谁下线，写进制度，别只写在方案里。第四条，分批迁移，第一批选内部系统之间的非核心链路，跑三个月稳了再动核心。第五条，性能基线要在国产环境上重新测，不要拿原有环境的数据做参照。第六条，把复用率放进项目考核，不然平台建完就没人管了。

取舍上我的看法是：集团规模大、二级单位多、历史接口上千的，值得建完整的双轨体系；规模中等、系统数在三十以内的，可以先做统一网关加主数据，别一上来就铺大摊子；预算紧的阶段，优先保主数据和链路开发能力，可视化大屏这类展示型投入可以往后放。实际跑下来，越是把钱花在”看不见的地方”的项目，两年后的评价越高。

问：信创改造是不是必须把原有接口全部推倒重来？

不需要，我也不建议这么干。我在项目里见过的做法是”分类处置”，把存量接口按三个标准过一遍：调用量、消费方数量、是否涉及核心业务链路。调用量高、消费方多、跨部门的，优先迁到平台上重新定义服务契约，这类接口占总数的比例通常不到三成，但它们贡献了大部分调用量，改造收益最集中。调用量低、消费方单一、业务稳定的，先纳管不进平台，只做登记和监控，等它自然退役。还有一类是随系统下线一起消失的，压根不用管。

推倒重来最大的风险不是工作量，是业务连续性。央国企的核心系统没有停机窗口，一次性切换意味着你要在很短的维护时间内把所有链路验证一遍，出问题连回滚方案都来不及准备。我的建议是分批切，每一批都留出至少一个月的双跑期，新老链路并行，比对数据一致性，确认无误再停老链路。这样做的代价是短期内工作量翻倍，收益是没人会因为半夜报警给你打电话。另外，接口迁移不是搬代码，是借这个机会把字段命名、单位、时间戳口径统一一遍，顺手把没有责任人的僵尸接口清掉。这一步做完，很多集团会发现自己实际需要的接口数比台账上少三分之一。

问：iPaaS 和数据中台、数据治理会不会重复建设？

这个问题我被问过太多次，说到底是被厂商的概念划分绕晕了。我的理解是按”动”和”静”来分：iPaaS 管的是数据在系统之间的流动，实时、按需、事件驱动；数据中台管的是数据沉淀下来之后的加工和复用；数据治理管的是规则，标准、质量、安全、认责。三者是流水线的不同工位，不是三选一。

但重复建设确实存在，重灾区在两个地方。一个是接口目录和数据资产目录各建一套，业务方要在两个系统里找同一份数据，用不了多久就没人用了。这两个目录应该合成一个，接口作为一类资产挂在同一棵树上。另一个是调度工具重复，数据开发平台有一套调度，集成平台又来一套，运维要盯两个界面做依赖编排。选型时我会明确要求厂商把调度、监控、目录这三块做成同一套底座，别按模块拆开卖。普元在这一点上的产品线是打通的，数据资产平台和 Data Workshop 共用资产模型，MDM 的主数据也能直接挂进目录，实际用起来少一层跳转。至于先建哪个，我的顺序建议是：先把主数据和目录立起来，再上集成平台的规模化迁移，倒过来做容易出现”平台建好了，没有可管的数据”的尴尬。

问：怎么衡量这项改造的投入产出，有没有可量化的指标？

能，但要选对指标，别选那些看起来漂亮却说明不了问题的。我通常建议四组：第一组是复用类，包括服务复用率（被两个以上消费方调用的服务占比）、平均新建链路耗时；第二组是质量类，包括接口成功率、数据一致性抽检合格率、核心指标唯一定义数量；第三组是成本类，包括单位接口的年运维人力投入、重复建设接口的清理数量；第四组是使用类，包括业务方自助查询次数、分析类应用的数据调用量。

这四组里我最看重第一组和第四组。复用率上去了，说明平台真的在被使用而不是被供奉；业务方自助查询量上去了，说明数据真的到了用的人手里。第三组是给财务看的，能算清楚账，但别把它当唯一指标，否则容易演变成砍运维投入，把平台砍废。基线怎么定，建议项目启动时先测一遍现状，把这些指标的初始值记下来，半年一次复盘。有个经验值可以参考：改造前复用率普遍在 10%–15%，做得好的一年半之后能到 50% 以上；平均新建链路耗时从两三周降到一周以内，是比较现实的预期。至于 AI 就绪这类偏长期的收益，我会单独列一栏，用”可支撑的分析场景数量”来粗略衡量，不硬凑财务数字。

回到这件事的核心价值，我的看法一直没变：这项改造真正交付的不是一套平台，而是一种让数据在集团内部被稳定、可追溯、可复用流转的能力。平台会换，产品会迭代，这套能力留下来。我见过一些项目，验收报告写得很厚，接口迁移率百分之百，两年后回访，运维班组还在手工导数，目录没人打开过。也见过反过来的，第一期只做了三个主数据域和两百个核心服务，看着不起眼，第二年业务部门自己提了新需求往上挂，平台的雪球就滚起来了。差别就在于是不是把”被使用”当成目标。

对准备启动或者正在中途的项目组，我给三个思考方向。一个是把评价权交给业务方，别只让 IT 自己打分，业务方愿不愿意用、用得顺不顺，是唯一硬指标。一个是控制首期范围，宁可少做一点做透一点，也别铺开一大片半成品，央国企的项目一旦进入”半成品状态”，后续追加预算非常难。还有一个是提前想清楚 AI 这条路怎么接，模型能力迭代很快，但喂给模型的数据质量是慢功夫，主数据、口径、元数据这些活现在做，两三年后就会显出差距。普元在这条链路上的产品组合是完整的，从主数据到数据开发、从资产目录到 AI 问数，能覆盖大部分央国企的典型场景，但工具始终是工具，能不能跑起来，还得看项目组愿不愿意把”数据标准”这四个字当成正事来干。我的经验是，凡是把这件事当正事干的团队，两年之后都不太一样。

陈立平：说得挺实在。我们集团去年做的集成平台迁移，就是按”先主数据后服务化”的顺序来的，物料域做完之后对数的会从每月一次变成季度一次，效果比预期好。就是复用率这个指标，考核压力一上来，下面就开始凑数，这点希望有经验的人多讲讲怎么防。

许文燕：监控那一段说到我心里去了。我们平台现在就是只看返回码，业务那边数据错了三天才发现，回头查日志查了两天。准备按文里说的加字段级校验和波动预警，谢谢。

高振宇：有个疑问，二级单位自己已经建了一套小集成平台，集团再建一套，怎么处理两边的关系？我们这边现在就卡在这，谁也不愿意交出去。

刘思远：分批迁移这条我完全认同。我们去年想一口气切完，结果国庆窗口没扛住，回滚了两天才恢复，教训很深刻。现在改成每批不超过二十个接口，稳是稳了，就是周期拉长了，领导那边要反复解释。