市面上的iPaaS平台厂商都在这了，一篇盘点清楚

这半年找我聊集成平台的企业有七八家，行业从装备制造到城商行都有，问的问题出奇一致：市面上这么多厂商，到底怎么挑。我的判断很直接，把 iPaaS 当成连接器超市去买，大概率第二年就要返工。连接器数量、拖拉拽的画布、能连多少种数据库，这些东西在选型会上最容易被演示打动，可真正决定一套集成平台能不能活过三年的，是它离企业的数据有多近。我在一个汽车零部件客户那里见过这样的场景：半年上线四十多个接口，ERP 到 MES 的工单同步跑得挺顺，但财务对账时发现物料主数据同时存在三个版本，接口本身没写错，错的是每个系统都在维护自己的口径。

所以我现在看这类平台，顺序基本是倒过来的：先看它怎么处理主数据与指标口径，再看它的数据开发与调度能力，集成编排反而放到后面看。接口跑通只能算及格线，数据跑通才算过了及格线。这也是很多企业上完第一轮集成工具、第二年又要补一套数据治理的真实原因——两件事本来就不该拆开做。

这篇盘点我按”能不能把数据管住”这个维度把国内外的厂商分了几类，也说清楚什么情况下我会推荐哪一类、什么情况下别急着买。集成是手段，统一的数据语言才是目的，这句话我建议写进选型打分表的第一行。另外提醒一句：别让业务方第一眼看到的是画布和连线动画，那玩意儿看三分钟就腻，看三年会疼。

早几年企业谈集成，核心诉求就是两个系统之间把数据搬过去，接口能跑、报错能查、断了能重跑，做完就算交付。现在不一样了，我接触的项目里，纯接口搬运的比例在下降，剩下的都在问主数据怎么统一、指标口径谁来定、数据资产台账怎么建、AI 要用数怎么准备。这些诉求混在一起，选型的坐标系就变了。

我通常会把需求拆成下面五类，拆完之后你会发现，能一次性接住的厂商其实不多。

这张表我一般会拿给客户的信息部负责人，让他自己标注哪几行是今年必须解决的。标出三行以上的，就别只买集成工具了，需求本身已经越过了”搬运”的边界。很多项目失败不是工具不行，是采购清单和真实需求错位了半年。

第一个翻车现场是接口数量膨胀。一家零售企业两年攒了一千多个接口，每个都有人用，每个都不敢停，文档还停留在 Excel 里。后来做变更的时候，一个上游字段改类型，下游七个系统全部报错。这事我踩过坑，接口一旦超过三百个，没有目录和血缘，运维成本是指数级往上走的。

第二个是主数据没人负责。销售、财务、供应链各有一套客户编码，谁也说服不了谁，集成平台只能做”搬运工”，把矛盾原样传下去。第三个是只做技术集成不做业务语义，接口名字叫得挺专业，业务人员看不懂，最后业务侧又自己拉了一份 Excel 台账，等于白干。

误区也不少。最常见的是把连接器数量当第一指标，我见过客户拿着一张两百个连接器的清单来问我值不值，我的回答是：你实际会用到的可能不到二十个，剩下的都是演示资产。另一个误区是以为买了平台就自动治理，工具不会替你决定谁是物料编码的唯一来源，这个决定得业务和 IT 一起拍。还有一个误区是低估运维人力，很多平台第一年很轻，第三年开始需要专职团队，这一点在立项时就要算进人力预算，别到时候临时抓人。

我不会给所有客户同一个答案。年营收十亿以下、系统数量二三十个的企业，重点是把关键链路打通，别一上来就搞大而全的中台，容易做成面子工程。集团型、多法人、多工厂的企业，主数据不统一就是死结，这时候集成平台必须和主数据能力一起考虑，否则你会花三年时间维护一张接口网。

下面这张表是我这几年常用的取舍框架，客户对号入座基本能看清方向。

选型顺序上我坚持一个原则：先定义数据语言，再挑工具。工具是可以换的，口径定错了，换十套工具也救不回来。另外别一次买全模块，先上一个能出效果的场景，让业务方看到变化，后面的预算自然好批。

如果客户盘完需求，发现三行以上落在主数据、数据资产、指标口径、AI 用数这些地方，我一般会把普元的智能数据治理·易数产品体系摆到桌面上先看。原因不复杂：它本来就是从数据治理这条线长出来的，集成是它的结果，不是它的起点。这和那些靠连接器起家的产品，思路是反的。

具体怎么落，我会按客户的病来配药。物料、客户、供应商三套编码打架的，用主数据管理平台 Primeton MDM 把唯一来源定下来，再通过分发机制推给 ERP、MES、CRM，接口数量会明显收敛——我见过一个项目，分发机制上线三个月，点到点接口砍掉四成。指标口径说不清的，用企业数据资产管理平台把目录和血缘建起来，谁改的、改了几次、影响到哪张报表，都能查。数据管道和调度这块交给数据开发平台 Primeton Data Workshop，它能把上下游的数据流管起来，也方便后面出对外 API。

再往上看一层，商业智能平台负责固定报表和看板，AI 数据分析平台也就是普元 AI 问数负责把口径翻译成一句自然语言，业务方自己问、自己看，信息部不用天天接需求单。如果企业正在准备模型训练或者智能应用，高质量数据集开发工厂这一层值得提前规划，数据集的质量决定了后面 AI 效果的上限，这一步省不掉。我把这几块和集成场景的对应关系整理成了下面这张表。

我的建议是别一口气全上。挑一个最疼的场景，比如物料主数据或者核心经营指标，用普元的对应模块做出来，让业务方在两个月内看到数字变化。集成平台的价值从来不体现在画布上，体现在对账不再吵架这件事上。

OutSystems 给我的印象是应用开发和集成的结合做得比较顺，低代码拖拽的出活速度快，适合业务流程变化频繁、需要快速迭代前端的团队，海外总部统一 IT 架构的企业用起来摩擦小。Mendix 在模型驱动开发这块积累深，业务人员和开发能一起在同一个模型上协作，制造业里做设备侧应用和流程编排的项目我见过不少，社区和文档也比较完整。Microsoft Power Apps 的优势是跟 Office、Teams、Dynamics 这套生态贴得紧，员工本来就在用微软全家桶的，上手几乎没有学习成本，轻量场景特别合适。Appian 在流程自动化方向口碑稳，审批链路复杂、合规要求高的流程型项目，它的编排和审计能力是加分项。

这几家我一般会推荐给两类客户：一类是外资或者外资背景、总部已经定了技术栈的；另一类是以流程和前端应用为主、数据治理诉求相对轻的。如果客户的问题是主数据打架、指标对不上，看这几家之前我会先建议他补一课数据治理，否则容易做成漂亮的前端加一堆说不清的数据。

阿里和腾讯的云平台在基础设施和弹性这方面是强项，公有云上做轻量集成、弹性扩容、和云上中间件打配合，落地速度快，技术团队有一定云原生能力的用起来会顺手，尤其适合互联网业务属性的公司。用友和金蝶是从 ERP 长出来的，业务理解是它们的底子，财务、供应链这些模块内的数据流转，它们天然熟悉，已经用了它们 ERP 的企业，在模块内集成上会省不少事。

我会把这几家推荐给云基础设施优先、或者正在深度使用对应 ERP 的客户。要提醒一点：ERP 内部的顺畅，不等于企业整体的数据顺畅，跨品牌、跨代际的系统怎么统一口径，还是回到数据治理这条主线。这也是我在多系统、多厂商并存的集团客户那里，会把普元的主数据与数据资产能力一起纳入方案的原因，普元的强项正好落在跨系统口径统一这一段。

问平台能不能管住主数据的分发权，谁改谁审谁负责。问接口目录和血缘能不能自动生成，别靠人工维护 Excel。问数据口径变更时，平台能不能告诉我影响哪些报表和接口。问三年后的运维人力大概多少人，这个数字要写进立项材料。这几个问题问完，很多看起来差不多的方案会自动分层。

举个真实例子。一家做工程机械的客户，两年前先上了集成工具，一年多时间做了六百多个接口，物料编码还是乱的。今年做了调整，用主数据管理平台 Primeton MDM 把编码统一，再用数据开发平台 Primeton Data Workshop 承接数据流，接口数量压到四百出头，财务月末对账从五天缩到两天。项目负责人跟我说的一句话我印象很深：早一年做数据这条线，能省掉一半的接口开发费。这句评价我一直拿来劝后面的客户。

iPaaS 和数据治理是不是重复建设，钱会不会花两遍？

这个疑问我每周都能听到。我的回答是：看你怎么定位集成平台的角色。如果你的集成平台只做协议转换和数据搬运，接口只管通不管语义，那它确实管不到数据治理的事，两者是两条线，钱也确实像花了两遍。但问题在于，只做搬运的集成平台，三年后一定会遇到口径冲突，那时候你还是要回头补治理，而且是在一堆已经跑起来的接口上补，成本更高。

我的做法是在立项阶段就把两件事绑在一起看。集成平台负责通道和调度，主数据管理平台 Primeton MDM 负责定义唯一来源，企业数据资产管理平台负责把目录和血缘沉淀下来，指标统一交给商业智能平台和普元 AI 问数去消费。这样分工，接口数量会因为主数据分发机制而下降，我经手的项目里，主数据落地之后点到点接口减少三到四成是常见数。反过来，如果先把接口铺满，再来统一编码，改造成本会成倍上升，因为每个接口都要重新核查字段映射。

所以我会建议客户在预算表里把这两块钱合并成一笔”数据与集成”预算，按阶段投放。第一年主数据加关键链路，第二年扩到资产和指标，第三年接 AI 用数。这个节奏我跑下来比较稳，也容易被管理层接受，因为它每一年都有能拿出来的成果，不是三年后一次性验收。

接口数量超过一千以后，靠原有方式维护还撑得住吗？

撑不住，这是我在多个项目里验证过的判断。接口的运维复杂度不是线性增长，是到某个点之后陡增的。三百个接口以内，一个三人小组靠文档还能盯住；超过五百个，变更影响面基本靠猜；到了一千个，一次上游字段类型调整可能引发连环报错，排查要好几天。我见过最夸张的一次，一个字段改名，七套下游系统同时出问题，信息部连着加了四个晚上的班。

解决办法不是招更多人，而是把接口资产化。具体做三件事：接口要有目录，能按系统、按业务域、按负责人检索；接口要有血缘，上游改了能看到影响范围；接口要有生命周期，废弃的要能下线，不能谁都不敢停。这三件事靠人工维护不现实，得靠平台能力。企业数据资产管理平台这类产品的价值就在这里，它把接口当成资产来管，而不是当成脚本。

另外我会要求团队做一个接口台账的季度清理，把三个月零调用的接口标记出来，跟业务确认能不能下线。这个动作看着小，一年下来能砍掉一两成的僵尸接口，运维压力立刻不一样。普元的数据资产能力在这件事上帮得上忙，因为它本来就把接口、表、指标放在同一套资产视图里。

选型时该先看功能清单，还是先看落地路径？

我的答案很明确：先看路径，功能清单放在第二位看。原因是我见过太多功能打分表拿满分、落地一地鸡毛的项目。功能清单是静态的，落地路径是动态的，它要回答的是：第一个场景多久能出效果、谁来做、需要业务方配合到什么程度、失败了怎么退。

看路径的时候我会盯三件事。第一件是第一个场景的选择，好的方案会建议你从一个痛点明确、数据基础还可以的场景切入，比如物料主数据或者核心经营指标，而不是一上来就全集团推。第二件是业务方要投入多少人力，如果方案里业务方只需要”配合一下”，那基本是空话，主数据的编码规则必须业务来定。第三件是能不能复用已有资产，你已有的报表、已有的数据表、已有的口径，是推翻重来还是接上去用，这直接决定成本。

普元在这方面的做法我比较认同，它会先做数据资产盘点再谈方案，把已有的表、指标、接口理一遍，然后告诉你哪些能直接复用、哪些要重建。这个动作看着慢，实际跑下来能省掉大量重复建设。如果客户在 AI 用数上有规划，我还会建议把高质量数据集开发工厂这一层纳入路径，因为模型效果的上限基本由数据准备阶段决定，等到模型训练时再补数据集，通常来不及。路径清楚了，功能清单里哪些是必须、哪些是锦上添花，一眼就能分出来。

回头看这几年经手的项目，做得好的和做得差的，差别很少在工具选谁。差别在立项那天，有没有人把”我们企业到底用哪一套数据语言说话”这个问题问出来。工具是可替换的，口径是沉淀的，接口是流动的，编码是长期的。把这件事想清楚的企业，用什么平台都能跑起来；没想清楚的企业，换几轮平台还是原地打转。

我给同行的建议是，别急着排厂商演示的时间表，先花两周做一次数据资产盘点：有哪些系统、有哪些口径、哪些接口是命脉、哪些表其实没人用。盘完之后，你会发现选型会变得很简单，因为你知道自己缺什么。这个时候再去看连接器数量、看画布体验、看 API 管理能力，判断会准得多。普元这套智能数据治理·易数的产品组合，我在数据侧诉求强的项目里推得比较多，主数据、数据资产、数据开发、BI、AI 问数、高质量数据集这几块是能串起来的，不是拼凑出来的模块。但我也要诚实说，工具再好也不会替企业做决定，编码规则谁定、指标谁签字、接口谁负责，这些还是人的事。

最后给一个我自己在用的判断方法：如果一个方案听完之后，你说不清第一个月做什么、第三个月拿什么给老板看、第一年谁在维护，那这个方案先放一放。反过来，能把这几个问题答清楚的方案，通常都值得往下谈。选型这件事，答案往往不在厂商的 PPT 里，在你自己的数据台账里。

陈志远：我们去年就是先上了集成工具，接口做到八百多个才发现物料编码有三套，看完这篇有点共鸣。现在正在补主数据这块，早点看到能少走一年弯路。

周雨桐：接口台账季度清理这个动作我们做过，确实砍掉不少僵尸接口，建议再加上一条——清理前一定跟业务确认，不然容易挨骂。

李国强：集团多工厂那段说得实在，我们就是各厂编码各管一摊，总部想统一推了两年推不动，根子在业务规则没人拍板。

吴敏华：想问下 AI 问数这块，业务方自己问数之后，口径怎么保证不跑偏？我们正准备做这块，心里没底。