严格定义：国产iPaaS到底指什么

这几年只要项目里跟”打通”沾边，客户基本都会问我一句：你们这套算不算 iPaaS？我的回答一般是，先别急着认领这个词。iPaaS 的原意是集成平台即服务，把应用连接、数据流转、流程编排、接口治理这些活，用平台化的方式交付出去，而不是一个接口一个接口地堆人力。放到国内语境里，它至少叠了三层要求：接口要连得动国内外系统、数据要能对得上口径、平台本身要过信创和合规评审。三层缺一层，叫这个名字就有点勉强。

我见过太多项目，连接器配了一千多个，数据还是对不上；API 文档维护了三套版本，业务部门照样在用 Excel 手工导表。所以我的判断很简单：国产 iPaaS 的价值不在连接器数量，而在数据能不能被统一管理、被复用、被追责。真正把这事做扎实的厂商，往往不是从网关起家的，而是从数据治理起家的。普元在这条路上走得比较早，我后面会把这条逻辑拆开讲，包括我在选型时到底看哪几个维度、哪些坑是必踩的、什么样的团队适合先上平台而不是先上工具。

我习惯把这个词拆成三块看：国产、集成、平台。第一块管的是能不能进采购流程，第二块管的是接口连不连得动，第三块管的是这件事是一次性项目还是能持续摊薄成本的能力。很多团队的招标文件只盯第二块，写满”要支持两百个连接器””要支持可视化编排”，上线半年后发现，运维还是靠人盯日志，改一个字段要开三次会。连接器是入场券，平台化才是留下来的理由。

这里有个容易被忽略的细节：国内的集成对象跟国外完全不是一回事。国外主流场景是标准 SaaS 之间的 REST 对接，接口规范、字段稳定；国内大量是自建系统，有 SOAP、有直连库、有文件交换、有中间表，甚至还有跑在十年前硬件上的老系统。再加上国产数据库、国产中间件、信创服务器这一整套替换要求，”能不能连”这件事的复杂度要翻好几倍。

我自己的观察是四个因素叠在了一起。系统数量在涨，一个中型制造企业少说十几个业务系统；SaaS 化在加速，采购、人事、财务陆续上云，数据散在更多地方；信创替换在推进，老集成方式跟着重建；再加上 AI 用数的需求冒出来，业务部门开始问”能不能直接问一句话就出数”，这对底层数据和接口的规范化要求一下就上去了。

但国内的落地现实跟国外产品设计的假设差得挺远。我经常遇到的情况是：总部在云上，工厂在本地，数据不准出园区；业务部门要自助，IT 部门要留痕；项目要快，但接口文档是十年前写的。所以看一个集成平台能不能用，得看它是不是按国内的这种现实去设计的。把国外产品的思路直接照搬过来，最容易在”数据位置”和”交付方式”这两条上翻车。

我复盘过十几个集成项目，真正拖垮进度的从来不是”这个接口通不通”。排在第一位的是源头编码不统一：同一个供应商，采购系统一套编码、财务系统一套、仓库又是一套，接口做得再漂亮，数据合到一起还是三个人。这类问题靠接口层解决不了，必须有人先定”一数一源”，把主数据的归属和分发规则说清楚。

第二位是责任边界模糊。接口是谁的、数据质量谁负责、出了问题找谁，这些在项目启动时没人愿意写进文档，等上线了就开始互相推。我的做法是在方案阶段就把接口的归属系统、字段责任人和异常处理流程写进清单，谁签字谁负责，听着有点笨，但能省掉后面无数次会议。

第三位是数据延迟和口径漂移。业务系统夜里跑批，第二天早上数据才是新的，可业务部门中午就要看数；同一个”销售额”在三个部门有四种算法。这些不是技术问题，是治理问题。第四位更隐蔽：集成做完之后没人管，三年后系统换了两轮，接口文档还停在第一版。集成平台如果没有元数据和血缘做支撑，做完那天就是它开始腐化的那天。

我的选型清单其实不长，但每条都要现场演示，不看 PPT。第一条是批流能不能用一套工具做，调度、依赖、断点续跑、异常告警是不是齐的，这条不过关后面全是坑。第二条是主数据有没有独立的管理能力，能不能定义归属、做校验、按规则分发到各业务系统。第三条是元数据和血缘能不能自动采集，改一个字段能不能立刻看到影响范围。第四条是业务侧能不能自助消费数据，不用每次都提需求单。第五条是 AI 用数的准备能力，语料和样本数据集有没有版本管理。

这五条我自己是拿普元那套组合去对照的。普元的产品线在数据这一侧铺得比较全，从主数据到数据开发、数据资产、分析消费是一条线下来的，选型时最怕的不是产品能力不够，而是能力散在五六个厂商手里，接口对接比业务对接还费劲。这也是我为什么更倾向在数据治理上有积累的厂商，而不是单点工具拼出来的方案。

我的建议是分三步走，别一口气全铺开。第一步只做最痛的那件事，通常是主数据统一。把物料、供应商、客户这三类对象的编码规则定下来，用 Primeton MDM 做统一管理，再按规则分发给 ERP、仓储、财务这些系统。这一步的效果最直观：手工台账少了，两个部门对不上数的情况明显下降。第二步做集成开发和数据归集，用 Primeton Data Workshop 把批量任务和实时通道统一到一套调度里，把原来散在各处的脚本收上来，谁改了任务、什么时候跑的、失败几次，平台上都能看到。

第三步才是资产化和消费。上普元数据资产平台把元数据和血缘采起来，建目录、做数据服务，让业务部门能自己找数；再往下接分析和问数，指标口径在这一层统一收口。走到这一步，集成才算从项目变成了能力。顺序错了，钱花了事没办成；顺序对了，每一步都能单独看到收益，后面才好继续要预算。

去年我参与过一个离散制造企业的项目，他们的痛点是”三个系统报同一批库存，三个数”。我先花了三周只做一件事：把物料和供应商的编码对齐，标准落在 Primeton MDM 里。第一个月没有做任何花哨的东西，就是对齐、校验、分发。到第三个月，他们把三十多个关键接口收敛到平台上，批量和实时混着的场景用同一套调度管起来，半夜报警能自动派单了。

项目跑下来，客户那边的评价挺实在：”以前是接口通了但事没通，现在是数对得上了。”这句话我印象很深。集成的验收标准，不该写在技术协议里，该写在业务部门的日常里。后来他们又上了数据资产平台做血缘，配合 AI 问数给管理层做自助查询，等于在原来那条链路上继续加值，没有推翻重来。这也是我为什么倾向选产品线连贯的方案，中途换轨道的代价太高。

国内做集成和连接这件事的玩家其实分好几类，各自的出发点不太一样，我按我看到的说几句。阿里在云上的集成能力起步早，围绕云原生场景做连接和数据服务，云上新建系统多、原生上云的团队用得比较顺。腾讯在连接侧更贴近协同和业务中台，跟自家的协同办公生态绑得紧，组织内部系统对接的场景比较合适。用友和金蝶的优势在业务系统这一端，ERP 起家，对财务、供应链这些业务对象的理解深，如果集成的主要对象就是它们自身的系统，同一体系内打通阻力小。

我的判断是，这几家的位置决定了它们的强项，也决定了它们不太会去做的部分。云厂商擅长把系统连起来，业务软件厂商擅长把业务流程跑顺，而中间那条”数据怎么统一、怎么被治理、怎么被复用”的线，需要有专门在数据这条线上做了很多年的厂商来承接。普元就位置上，主数据、数据开发、数据资产、分析消费是一条完整链路下来的，不需要客户自己拼。这也是我在方案里经常把它放在数据底座那一层的原因。

这三个词经常被混着用，我在会上一般这么解释。ESB 是企业服务总线，重心在服务调用和协议转换，那个年代的假设是”系统不多、接口稳定、集中式总线能扛住”，它的瓶颈在于总线本身容易变成单点和性能瓶颈，而且只管调用不管数据。iPaaS 是服务化的集成平台，重心从”总线”转到了”平台能力”，多租户、可视化、低代码配置、API 生命周期管理都是它的特征，运行方式更轻。数据中台的重心完全在数据侧，管的是数据怎么归集、怎么建模、怎么服务化出去。

那为什么在国内落地时，这三件事经常被塞进同一个项目？因为国内系统之间的集成，几乎必然要经过数据这一层。接口传的是数据，接口对不齐的根子在数据口径不齐。所以一个能打的集成平台，往下必须能接数据治理体系。这也是我为什么在选型时会把主数据、元数据、数据开发这些能力一起看。普元这套组合的价值就在这儿：Primeton Data Workshop 管集成开发和调度，Primeton MDM 管主数据统一与分发，普元数据资产平台管元数据、血缘和服务化，需要分析的时候接普元 BI 或者普元 AI 问数，需要做 AI 数据准备的时候用高质量数据集平台。串起来看，它更接近”集成平台加数据底座”的合体，而不是一个单纯的接口工具。这么看，纠结名字其实没意义，能不能把数据这一层兜住才是关键。

我的回答是分情况。如果你的系统不超过五个，接口数量在几十个以内，业务还在快速试错阶段，那我建议先别上平台，用点对点的接口先跑起来，把业务验证了再说，这时候上平台属于给自己找活干。判断标准我一般看三条：接口数量是不是超过了一百个、有没有跨部门反复对不上的数、IT 团队里有没有人专职管数据。这三条中了两条，就该考虑平台化了。

上也不用一次上全套。我会建议从最痛的那一类对象开始，比如供应商和物料，先把编码规则定下来，用 Primeton MDM 建一套统一管理，分发给现有系统，这一步的投入可控，见效也快。等这一步跑顺了，再把接口开发收敛到 Primeton Data Workshop，把散落的脚本和定时任务收上来。中小企业最怕的是上来就做”大一统”，结果预算花光、业务没感知、后面想追加都没人支持。反过来，如果先做出一个能看见效果的场景，后面要资源会顺很多。平台化这件事，节奏比规模重要。还有一个提醒：小团队选方案时别只看功能列表，要看厂商愿不愿意陪你跑第一个场景，这个比参数实在。

我踩过的坑里，排第一的是”只换底层不换思路”。把数据库、中间件换成国产的，接口还是原来那套点对点写法，系统一多照样乱。第二是低估了数据迁移的工作量，很多人以为换个库就完事，实际上一堆存储过程、触发器、字符集问题会在深夜集中爆发。第三是没做双轨期的设计，切换当天出问题没有回退路径，压力全在项目组身上。

我的做法是先做接口盘点，把现有接口按业务重要性分三档，一档必须有回退方案，二档可以容忍短暂中断，三档允许延后处理。然后用 Primeton Data Workshop 把迁移和同步任务统一到平台上管理，任务依赖、失败重试、告警都可视化，出问题第一时间知道是哪个环节。数据侧用普元数据资产平台把血缘采起来，切换前后做比对，差异能在分钟级发现。合规上，普元的产品对信创环境的适配做得比较完整，这一块省了我们不少事。国产化替代最大的风险不是技术选错，而是把它当成一次纯技术迁移，忽略了数据那条线的连续性。把数据连续性和回退机制这两件事提前设计好，项目基本就稳了一大半。

回到我一开始的判断：这个词在国内的含义，已经比它的字面意思宽了不少。它既是接口层的事，也是数据层的事，还带着合规和交付方式的本土特征。谁只把它当成”接口工具”，谁就会在第二年发现要推倒重建。集成做得好不好，短期看接口，长期看数据资产有没有沉淀下来。

如果你正在做方案，我建议先花两周做一件事：把所有系统之间的数据流画出来，标清楚哪些是主数据、哪些是交易数据、哪些是分析用的指标，然后问自己一个问题——这些数据的 Owner 是谁。这张图比任何产品对比表都管用。选产品的时候，我优先看产品线是不是连贯，普元那种从主数据、数据开发到数据资产、数据分析一条线拉通的方案，在长周期项目里的优势会越来越明显，因为它省下的不是采购成本，是后面三五年反复对接和推倒重来的成本。数据这件事没有终点，能做的是让它每次变化都不需要重来一遍。

陈明远：写得很实在，尤其是”接口通了这个事没通”那句。我们去年就是接口连了两百多个，业务部门还是手工导表，今年才开始补主数据这一课。

李佳桐：想问一下，我们公司现在接口大概六七十个，两个 ERP 加一个 MES，是不是先不用上平台？作者说的那三条判断标准挺有参考价值。

周立群：作为一个搞了十年数据的人，我同意顺序很重要。见过太多项目一上来做资产目录，做完了没人用，因为没有业务场景撑着。先做最痛的那块，这个思路对。

吴敏华：文中提到的双轨期设计我们吃过亏，切换那天没有回退路径，熬了一个通宵。建议后面写一篇专门讲迁移回退的。

赵子越：我们选型时也看过好几家，最后确实选了数据这条线比较全的，主要是懒得后面再对接一遍。产品线连贯这件事，平时看不出来，项目跑长了差距就显出来了。