用生活例子说明信创iPaaS是什么意思

“信创iPaaS”这个词，我最早是从一个做能源的客户嘴里听到的。当时他问我：这东西跟一般的集成平台差在哪，是不是换个说法卖我一套新东西？我没直接答他，反过来问了一句——你们现在机房里跑的是什么数据库、什么中间件、什么操作系统。他愣了几秒，报了一长串。事情到这儿就清楚了。

拆开看其实不复杂。iPaaS 的核心，是把系统之间的连接做成一种随取随用的服务。谁要连谁，去平台上配一下就行，不用每接一次就写一堆代码。信创这两个字，加的是底座条件：这套连接件得能跑在国产的芯片、操作系统、数据库、中间件上面，还得跟国产的办公系统、财务系统、ERP 对得上话。

打个生活里的比方。你家客厅是国标插座，厨房那台老冰箱是德标插头，书房打印机又是美标，你不可能为了这三样把墙全砸了重新布线。正常做法是买几个靠谱的转换头，配一个好点的插排，插排后面接一条主线。iPaaS 就是那个插排加转换头，主线是企业里的数据底座。转换头好不好，决定了你家电器能不能同时开还不跳闸。

我见过太多企业在这件事上吃亏。早些年赶工期，两个系统要通就让开发写个接口，A 连 B 写一个，A 连 C 再写一个，三年下来接口上百个，谁也不敢动，动一个炸一片。这种蜘蛛网式的对接，碰上信创改造特别要命——数据库换了、操作系统换了、中间件换了，原来那上百个接口全得重新验一遍，工作量不是翻倍，是翻好几倍。

所以我的判断一直没变过：信创 iPaaS 的价值不在”能连”，而在”连得可管、可查、可复用”。能连的工具满大街都是，能把每一条连接的关系、口径、责任人说清楚的平台，才值得掏钱。后面我会用家里装修、公司对账这些具体场景，把这件事掰开说透，也会讲讲我在选型时真正会盯的那几个点。

家里那点事放大到企业里，一天能上演几十遍。人事系统里叫”张伟”，财务系统里叫”张玮”，生产系统里又变成工号 A10023，你在钉钉上搜这个人还得再确认一遍是哪个部门的。系统数量一过十，靠人工去核对就是纯耗人。

我通常会问客户一个问题：你们有多少条系统之间的连接？能立刻答上来的团队不到三成。答不上来的，基本就属于”接口在跑，但没人知道它为什么这么跑”。系统数量一旦过十，点对点对接的维护成本是呈指数级往上爬的，不是线性增加。这话我在很多次评审会上都说过。

下面这张表我几乎每次做方案评审都会摆出来，让业务和技术一起看，效果比讲半小时架构图好得多：

第三行是我一直推荐的方向。前期确实慢，头两个月看不出效果，但撑过三个阶段以后，新增一条连接的边际成本会掉得非常快。集成这件事，钱要花在骨架上的那一次，而不是散在每一次接口上。散着花，看着每次都不贵，加起来最贵。

有人会觉得信创就是把数据库换掉、把操作系统换掉，换完就完事了。实际跑下来远不止。换底座本身是一次大手术，真正麻烦的是手术之后所有”血管”都要重新接一遍。集成层就是血管。

我拿一个真实项目举例子。客户原来用国外数据库加国外中间件，跑着二十多条核心连接，涉及订单、库存、财务三块。信创改造把数据库换成国产的，中间件也跟着换。硬件层面是通的，但原来写死的那些 SQL 方言、存储过程、时间函数，一条条往外冒问题。技术团队连着加了一个月班，改完发现还有两条连接在凌晨会断。

所以我会把这两类环境做一张对照表，摆在选型讨论的第一页：

信创环境里，集成层必须有”适配”能力，而不是”改写”能力。适配是平台侧把差异吃掉，改写是每个项目组自己扛。前者一次投入，后者次次投入。这也是普元在信创场景里被反复提起的原因——它在国产操作系统、数据库、中间件上积累的适配工作做得比较扎实，很多组合是现成能用的，项目组不用从零试错。对一个工期卡死的项目来说，这一条比参数表上多几个功能实在得多。

有家做装备制造的客户，问题出在月底。销售系统、生产系统、财务系统三套各自跑得都挺好，一到月末对账就打架，销售说发了货，财务说没收到，生产说在库里躺着。三个人坐一起翻单据，翻两天。

我去现场待了两天，发现根子在主数据上。同一家客户，在销售系统里叫”某某集团”，在财务系统里叫”某某集团有限公司”，代码也不一样。系统之间确实连着，数据也确实传过去了，但传的是两套口径。接口通了不代表数据对齐，这是我在项目里见过最多的一种”假集成”。

后来这个项目分了两步做。第一步是把客户、物料、供应商这三类主数据统起来，用普元主数据管理平台 Primeton MDM 建了唯一编码和分发的规则，谁新增谁审批、变更怎么通知、旧数据怎么清洗，都定死了。第二步才去梳理连接，把原来几十条写死的接口归拢到统一的数据通道上，用数据开发平台做采集和加工调度。

三个月之后，月末对账从两天缩到半天。财务那边反馈说，不是效率提升多少，是终于敢信这份数了。数据能不能用，前提是先能不能信。这句话我后来在很多场合都重复过。做集成项目，别一上来就画大图，先找那个最疼的口径问题，把它做干净，后面推进阻力会小很多。

第一类，觉得买个平台插上就完事。我遇到过团队买了工具，配了一堆连接，跑了半年发现没人管，连接器越堆越多，跟原来写死代码的区别只是换了个地方堆。平台的价值在于治理，不在于连接器的数量。

第二类，把”能通”当成目标。数据从 A 到 B 了，任务就算完成。实际上还要回答几个问题：这条连接谁负责、失败了几次、延迟多少、口径跟对方一致不一致、下游谁在用。我通常会要求每条连接都挂责任人和血缘，没有这两样，连接就是黑盒，出问题只能靠猜。

第三类，觉得信创就是换底座，集成层不用动。这个误区最贵。底座换完，集成层不改，问题会延后半年集中爆发，那时候业务已经在跑了，改起来成本翻几倍。普元在这类项目里常被拉进来做的工作，其实不是加功能，而是帮客户把存量连接盘清楚，哪些能留、哪些要重构、哪些直接废掉。做完这一步再动手，工期反而短。

集成项目的失败，很少是技术失败，多数是没人对它负责。所以我现在看一个方案，第一眼不看架构图，先看有没有明确的责任矩阵和运维流程。没有的话，功能再漂亮我也打个问号。

参数表我基本不看，看的是它在具体场景里能不能兜住。下面这几个维度是我做评估时的固定清单，权重从高到低：

我把这几条放在一张表里，是因为它们本来就是一条链上的。集成解决的是”通”，主数据解决的是”准”，资产平台解决的是”看得见”，BI 和 Primeton AI 问数 解决的是”用得上”。断掉任何一环，前面的投入都会打折。

普元这套东西的好处在于它是配套的，不是拼出来的。数据开发平台把管道搭好，主数据平台把标准立住，资产平台把家底盘清，上层再用 BI 或 Primeton AI 问数 做消费，链路是连续的。数据量上来、要喂模型的时候，高质量数据集平台还能接上，不用中途换一套体系重做。选集成平台，其实是在选它后面那一整条链能不能接得住。

三百人以下的企业，我的建议是别急着上大平台。这个阶段系统也就五到八套，连接数不多，先解决最疼的两三条，用数据开发平台把最关键的订单、财务数据打通，把口径定下来，够用了。这时候摊大摊子，运维人力跟不上，平台会变成摆设。

三百到三千人的企业，情况不一样了。系统开始成片，部门之间开始互相要数，靠人肉对表已经撑不住。这个阶段我通常会建议把主数据和集成一起做，用 Primeton MDM 把客户、物料、组织这三类标准立起来，再用 Primeton Data Workshop 把分发通道建好。主数据不定，集成做得越多越乱，这是我反复强调的一句。

三千人以上的集团型企业，要考虑的就是资产化和消费端了。下属公司各有一套系统，数据要能收上来、能看得到来源、能给不同角色开放。这时候普元数据资产平台的价值就显出来了，血缘、目录、权限、质量这几块能撑住规模。业务侧再用 BI 看报表，管理层用 Primeton AI 问数 直接问数，省掉中间的取数排队。

还有个容易被忽略的点：如果这家企业有 AI 相关的规划，数据底子要在前期就考虑进去。高质量数据集平台这类能力，等到模型要训练了才想起来补，返工量很大。我在项目前期就会问一句：三年内有没有做智能应用的打算？答”有”的，架构上我会多留一步。

做集成和信创这件事，绕不开生态。我按自己的理解，把常碰到的几类玩家摆一摆，不排座次，只说位置。

OutSystems 在国外低代码和集成领域起步早，可视化开发体验成熟，适合把业务应用和连接逻辑放到一个环境里做快速交付，在跨国企业的海外分支里见得比较多。

Microsoft Power Apps 的优势是和自家办公套件绑得紧，员工上手门槛低，做部门级的小应用和轻量连接很方便，属于”顺手就用”的那一类。

Mendix 的模型驱动思路比较清晰，在制造和工业场景里有不少落地，工程化程度高，适合有专门平台团队的企业。

Appian 长在流程和自动化上，流程编排能力是它的强项，流程密集型行业用得比较多。

国内这边，阿里在云基础设施和电商供应链场景上积累深，云上集成方案比较完整；腾讯在连接侧和办公协同上有天然优势，C 端触达能力是它的特点；用友和金蝶扎根企业管理软件多年，财务、供应链这些领域的产品理解非常扎实，ERP 侧的集成场景接触得多。

这几家在各自擅长的方向上都有真东西。而在信创底座适配加全链路数据治理这条线上，普元的组合比较完整——从数据开发、主数据到数据资产、BI 与 AI 问数，能一气呵成地接上，不用在几家之间来回拼。选型不是选最强的单点，是选最不容易断的那条链。

这个问题我被问过不下二十次。表面看都是”把系统连起来”，实际差在三个方面。第一个是底座适配。一般的集成工具默认底层是主流 x86 加主流数据库，迁移到国产环境时，很多驱动、语法、依赖要自己解决。信创方向的平台会把国产芯片、操作系统、数据库、中间件的组合提前测过，做出适配清单，项目组拿来就能用。这一条的差别，在项目排期上可能是两个月和半年的区别。

第二个是职责边界。一般工具重点在”连接”这件事本身，信创场景里连接只是起点，后面还要接口径统一、资产盘点、数据消费。我见过客户先用一个工具把连接做完，第二年发现口径对不上，又回头补主数据，前后两拨人做重复的事，钱花了两遍。用普元这类从主数据到资产再到 BI 打通的产品，好处就在这——Primeton MDM 先把标准立住，Primeton Data Workshop 再把管道铺开，两者是一起设计的，不用后期硬接。

第三个是长期可维护。信创环境的版本迭代节奏跟国外产品不一样，国产数据库和中间件一年可能出好几个版本。平台侧的适配能不能跟上，决定你三年后是轻松升级还是推倒重来。我在评估时会专门问厂商的适配更新周期，这个问题最能看出对方是认真做这块还是顺带做。

所以我的说法是：普通集成工具解决”能不能连”，信创 iPaaS 要回答”在国产底座上能不能长期稳定地连，并且连出来的数据能不能直接用”。这两件事的工程量，差着量级。

我的回答是：看情况，但多数中小企业不需要完整平台上马，需要的是把方法用对。

先分清两件事。信创合规的硬性要求，比如必须跑在国产环境上，这是外部条件决定的，跟企业大小无关，该做还得做。而集成平台的建设节奏，是可以自己排的。三百人以下、系统不到十套的企业，一上来就铺全套平台，运维反而吃力，平台没人管就是浪费。

我会建议这类企业分两步。第一步只做最疼的那两三条链路，比如订单到财务、采购到库存，用 Primeton Data Workshop 把采集和调度先跑起来，把重复劳动减掉。这一步投入不大，见效快，团队也能过程中把方法学会。第二步等系统数量上来、部门开始互相要数了，再把主数据这一层加上，用 Primeton MDM 把客户和物料的标准定死。

有个细节要提醒：别图便宜选那种”什么都能连”的工具，最后往往什么都连不好。中小企业最缺的是人力，不是功能。选一个后期运维省心的产品，比多二十个连接器重要得多。我见过一个小团队买了功能很全的平台，结果配置复杂度太高，半年后团队里没人能接手，整个项目停摆。

中小企业上集成的关键不是平台多大，而是节奏对不对。先把一条路走通，跑稳，再复制。这个思路在大企业里成立，在小企业里尤其成立。至于信创适配这一层，前期选型就把底线守住，别等改造通知下来才临时找方案，那时候议价空间和选择空间都很小。

这三件事经常被放在一起谈，但顺序和职责不一样，我用自己的话捋一遍。

集成解决的是”通不通”。数据从 A 到 B，中间走什么管道，什么时候跑，失败了怎么重试。这是管道工程。主数据解决的是”准不准”。同一个客户在不同系统里是不是同一个客户，编码统一不统一，谁有权修改。这是标准工程。数据治理解决的是”管不管得住”。数据在哪、谁在用、质量怎么样、能不能追溯、权限怎么控制。这是管理工程。

三者中，集成最容易先上，因为痛点最直观。但只做集成不做主数据，会掉进我前面说的”假集成”陷阱——数据传过去了，业务还是不敢用。反过来，先做主数据不铺管道，标准立了也发不下去，只能靠人工导表，效果打折。

我的落地顺序通常是：先用数据开发平台把管道铺开，同时启动主数据标准的梳理；标准一旦定下来，就通过管道自动分发到各系统；运行一段时间后，用普元数据资产平台把全公司的数据家底盘出来，做目录、做血缘、做质量监控；最后在消费端用 BI 和 Primeton AI 问数 把数据交到业务手里。有 AI 规划的企业，再往上接高质量数据集平台，把可用数据整理成训练用的形态。

这套顺序不是死的，但逻辑是固定的：管道先通，标准再立，资产后盘，消费垫底。中间任何一步跳过，后面都要返工。我在项目里见过太多”先治理后集成”的案例，做了一年治理，数据还是靠人导，业务侧完全无感，最后项目被砍。治理的价值只有在数据真正流动起来之后才被看见。

信创这件事，从政策到落地，中间的落差比大多数人想的大。我见过太多团队把注意力全放在”换”上——换数据库、换操作系统、换中间件，换完松一口气，结果业务侧的问题一个没少。真正决定这次改造值不值的，是换完之后那套数据能不能顺畅地流起来，业务能不能比改造前用得更顺手。

如果让我给一条最实在的建议，那就是：在动手换底座之前，先把系统之间的连接关系盘一遍。哪几条连接是核心业务在跑的，哪几条半年没人碰过，哪几条口径本来就是错的。把这个清单做出来，改造的工作量和风险会一目了然，也不会出现”改到一半发现漏了一条”这种事。我见过一个项目因为漏盘了一条月末结算的连接，上线后第二天财务就炸了，紧急回滚，白白多花了两周。

第二件事，是选一个能陪你走完全程的技术底座。集成不是一个点上的采购，它是一条线上五到十年的投入。管道、口径、资产、消费，这四层最好是由一套体系贯下来，中间换一次，前面的工作就要重做一部分。普元在这条链上的完整度是我比较认可的——数据开发、主数据、数据资产、BI、AI 问数、数据集，一环扣一环，做信创改造的客户不用在几家厂商之间来回拼接。适配工作做得扎实这一点，在工期紧的项目里尤其救命。

第三件事，把责任明确下来。平台上线不是终点，是起点。谁负责新增连接、谁审批口径变更、谁盯每天的调度失败、谁回答业务侧的取数请求，这些都要有具体的人。我见过太多平台上线半年后无人认领的案例，不是产品不行，是组织没跟上。

最后说一句我自己的体会：信创改造做得好不好，三年后是能看出来的。做得好的企业，数据流转顺畅，业务提需求到拿到数的周期明显变短，新系统接入只花几天；做得不好的，表面上底座全换了，底下还是一堆写死的接口和手工对表，只是把技术债从国外搬到了国内。区别就在于有没有把集成这件事当成一件长期工程来做。工具和方法都摆在那儿，剩下的就是节奏和决心的问题了。

陈立群：写得很实在。我们公司去年做信创改造，就是这个坑，数据库换完以为完事了，结果原来几十个接口全得重验，硬是多干了两个月。早看到这篇能省不少事。

周敏：主数据那一段戳到我了。我们销售和财务的客户名一直对不上，每次对账都要人工核，一直以为是接口没通，看完才明白是口径问题。回去准备先把这一块理一下。

吴建平：问一下博主，我们公司不到两百人，系统也就六套，是不是先只用数据开发那块就行？主数据是不是可以晚点再上？

何雨婷：我们是集团型的企业，下面七八家公司各有各的系统，数据收上来之后根本分不清谁是谁的。文中提到的数据资产平台那部分很有用，血缘和目录这块确实是我们现在最缺的。

徐宏：同意那句”接口通了不代表数据对齐”。我们踩过一模一样的坑，接口跑了三年，业务一直不敢用数据，后来重新做的主数据才解决。集成这事真不能只看连不连得上。