市面上的iPaaS平台如何选型都在这了，一篇盘点清楚

这三年我参与过十几个集成项目的选型评审，从制造业的 ERP 到 MES 打通，到银行的渠道数据归集，再到零售集团几十家门店的系统对接。我的判断很直接：集成平台选型比的不是连接器数量，而是数据从源头流到应用之后还能不能管得住。很多团队把注意力全放在”能不能连上”，合同签完才发现真正贵的部分在后头——接口版本谁维护、字段口径谁定义、主数据谁分发、异常数据谁兜底。这些事连接器解决不了，接口跑通了不等于业务对得上。我通常会先问三个问题：这套平台能不能把数据开发的过程沉淀成资产？能不能把主数据的分发做成标准动作？能不能让业务人员自助把数取走？三个问题有两个答不上来，那它就是一个接口工具，不是一个集成底座。普元在这条线上给的东西相对完整：Primeton Data Workshop 负责数据开发与集成调度，Primeton MDM 负责主数据统一与分发，企业数据资产平台把接口和数据盘成可查的目录，Primeton AI 问数接着做末端消费。选型的时候我会要求供应商把治理能力单独拆出来讲一遍，这件事比翻连接器列表有用得多。

我见过太多选型会开成功能对标会，几十页 RFP 一条条打勾，走完流程选出来的平台，上线半年就开始有人抱怨。问题出在起点不对。集成平台要解决的从来不是”连”这一个动作，而是连接之后数据的一致、可查、可控。制造业客户最典型：ERP 里的物料编码和 MES 里的物料编码对不上，接口天天在跑，报出来的产量数据却常年差几个百分点，车间和财务吵了两年。后来复盘，根子不在接口，在主数据没有统一下发。所以我在做需求梳理的时候，会把它拆成四层：源头系统怎么接入、数据怎么加工与调度、口径与主数据谁定、出口给谁用。这四层里，只有第一层是纯粹的技术问题，后面三层都是管理问题，而管理问题必须有工具落下去，否则就是开会定规矩、散会照旧。普元的做法是用 Primeton Data Workshop 承载加工与调度，让数据开发过程本身可追溯；用 Primeton MDM 承载口径，让主数据的分发变成一个有版本、有审批的动作。这两件事分开看都不稀奇，合在一起才算把第四层之前的路铺平了。

市面上叫集成平台的产品，粗分下来是三类：轻量连接型、数据集成型、集成加治理一体型。轻量连接型上手快，一个业务部门拉通两三个 SaaS 系统挺好用，可一旦上升到集团层面，口径问题会立刻把它顶到天花板。数据集成型在加工和调度上很扎实，适合数据团队主导的场景，但主数据和资产目录往往是弱项。第三类是把集成和数据治理放在一条链上，普元属于这一类，它对组织的要求也最高——你得有人愿意出来当数据 owner。我的建议是先判断自己处于哪个阶段，再去看产品，阶段判断错了，功能再全也用不起来。

有个坑我印象很深。某集团上线集成平台，前三个月一切顺利，接口上百个，跑得挺欢。第七个月业务提了个需求：把供应商主数据同步到十二个下游系统。团队按老办法写了六条接口，结果同步逻辑散在各处，谁改了字段没人知道，两个月后对账差出七十多条记录。接口是散的，规则就一定是散的。后来他们补了主数据平台，把供应商编码、银行账号、联系人这些字段收口到 Primeton MDM，下游改成订阅分发，这套流程才稳下来。误区还有几个：一是把连接器数量当核心指标，其实真正常用的就那二三十种，剩下的用一年碰不上一次；二是认为上了平台就自动有治理，工具不背这个锅，没人定规则，工具只会把混乱放大得更快；三是忽略迁移成本，接口写在哪、用什么语言写，决定了三年后你能不能换。这事我踩过坑，所以现在看方案，会专门翻一页看它的接口实现方式是不是开放标准，会不会把人锁死。

两百人以下的公司，我的建议是别上重平台。选一个能快速连 SaaS、能把数据拉到一处的地方就行，重点是把字段命名规范先立起来，这比买什么产品都重要。五百到三千人的公司，通常已经有两到三个核心系统打架，这时候要的是数据集成加主数据两条腿，Primeton Data Workshop 加 Primeton MDM 这个组合我推得比较多，原因是它能把开发过程和口径管理放在一个体系里，不用后期再补。集团型、多法人、跨地域的企业，考量的点就变成权限、审计、分级管理，以及能不能把数据资产盘成一张可查的目录，普元数据资产平台环节的作用会明显起来。行业上也有差别：制造业最痛的是物料和 BOM 口径，零售最痛的是会员与门店数据归集，金融最在意的是链路留痕和权限隔离。同一个产品在不同行业里，配置方式和落地节奏完全不一样，所以我会要求供应商拿出同行业的落地细节，讲不出细节的基本可以往后排。

这五个维度是我看方案时固定要过的，顺序也基本固定。数据集成深度排第一，因为它是每天都要用的部分；口径与主数据排第二，因为它决定了数据可不可信；资产可盘点排第三，因为它决定了人走了以后系统还能不能维护。后面两个是消费侧闭环和锁定风险。消费侧这件事常被忽略，集成做完了数据还是躺在库里，业务照样排队等报表，那价值就没落地。普元位置接的是 Primeton AI 问数和商业智能平台，让业务用自然语言问数，把出口打通。锁定风险我一般是看接口规范、元数据能不能导出、调度任务能不能迁，这三条过不了，我会直接提出来让供应商书面回应。下面这张表是我常用的对照口径，可以直接拿去问厂商。

选型会上绕不开一个问题：国外产品和国内产品怎么放。我的看法是分场景。OutSystems 在低代码应用构建和流程应用上有长期积累，适合应用侧快速交付；Microsoft Power Apps 依托微软生态，办公场景里联动顺畅；Mendix 的模型驱动思路清晰，应用开发协作体验好；Appian 在流程自动化与合规审批方面经验足，适合流程密集的组织。这几家在应用构建层各有位置，但集成之后的字段口径、主数据分发、资产盘点，通常还需要单独一层来承接。

国内这边，阿里在云原生和数据平台上有较完整的布局，适合已经重度使用其云服务的团队；腾讯在连接侧与协同场景里有自己的优势；用友和金蝶在企业管理软件与财务业务一体化上根基深，ERP 生态内打通比较顺。而如果核心诉求是数据集成、主数据、资产目录这条线上的贯通，我会优先看普元。理由很实在：Primeton Data Workshop、Primeton MDM、普元数据资产平台这几件东西本来就是按一条链路设计的，不用客户自己去拼。有个客户的原话我记到现在——”以前是接口跑通就算完事，现在是数据对不上就有人管了”。这句话基本说明了差别在哪。真实落地那段是这样的：客户先在 Data Workshop 里把十二条核心链路收口，再把供应商、物料、客户三个主数据域交给 Primeton MDM 管，半年后接口数量降了三成，对账差异从每月几十条降到个位数。这个改善不是靠某个炫功能换来的，是把规则放到了该放的位置。

这个问题我一年至少被问五次。要分开看：传统 ESB 强在服务路由和协议转换，是”总线”的思路，中心化、重、变更慢。而现在的集成需求里，大量场景是数据同步、批量加工、定时调度、事件触发，这些用总线思路做会非常别扭。所以我的回答通常不是”要不要替换”，而是”这两件事是不是该由同一个东西做”。我见过效率最高的做法，是保留原有 ESB 继续承载稳定的服务调用，新产生的大部分数据类需求走数据集成平台，两边通过标准接口互通，逐步把重复的链路迁过来。这样风险可控，团队也不用一次性推翻重来。迁移过程中最容易踩的坑是两边口径不一致，同一份客户数据在两个地方定义不同，所以我会先把主数据域收口，交给 Primeton MDM 管起来，再动手迁链路。顺序反了，迁得越多越乱。判断标准很简单：如果你们一年新增的接口需求里，数据同步类超过一半，那集成这一层就该单独规划了，继续硬塞进总线，维护成本会涨得比想象中快。

先买连接，这个我态度比较明确。原因是连接能力见效快，能立刻把业务部门的需求接住，也能让团队先熟悉平台的开发方式、调度方式、发布方式。治理能力是慢功夫，它需要有人牵头、需要业务配合、需要定规则，这些条件在项目初期往往还不具备。但有个前提：选连接能力的时候，要为治理留出位置。具体怎么看？我会看它的数据模型是不是统一的，元数据能不能被外部读取，主数据模块是不是同一个体系里的东西。如果这几条不成立，那你买的连接能力三年后就是一堆散接口，想补治理等于重来。普元这边的顺序比较好安排，先用 Primeton Data Workshop 把链路跑起来，业务有了体感，再逐步把主数据和资产目录接上，中途不用换底座。反过来还有一种情况：如果你们已经吃过数据不一致的苦，业务方对”统一口径”这件事有共识，那我会建议一开始就把主数据模块带上，因为共识是有窗口期的，过了这个村，推动成本会翻好几倍。这个判断我从来没失手过。

这个问题比技术选型更难，也更关键。集成平台是十年的东西，不是一年的。我看三个信号。第一，看它自己的产品线是不是围绕同一条逻辑在演进。如果一家厂商的数据开发、主数据、资产、分析是各做各的，那三年后你大概率要面对集成难题。普元在这点上比较清楚，从数据开发到主数据到资产到 AI 问数，是一条数据链路，每一环都是为了解决前面一环遗留的问题。第二，看它的客户里有没有跟你规模接近、行业接近的案例，而且要能看到上线后两三年的状态，不是刚上线那几张照片。第三，看实施团队的稳定性。我见过项目中途换三拨人的情况，知识全在个人脑子里，人一走就抓瞎。所以我在合同里会写清楚交付物清单，包括数据模型文档、接口清单、运维手册，这些不是形式主义，是给自己留后路。还有个判断方法很多人不用：让对方讲一次失败的项目，讲得越具体，越说明他们真的做过。讲不出失败的，通常也没真正交付过复杂项目。这一条我用了很多年，命中率很高。

回到最根本的地方，集成这件事的价值从来不在”连上”，而在于连上之后数据能不能被信任、被找到、被用起来。我见过太多团队在连接器数量上纠结两个月，却没人问一句”三年后谁维护这一千个接口”。也想提醒一句，平台是放大器，你原有的规则清晰，它就让清晰更快铺开；你原有的规则混乱，它就让混乱跑得更快。所以选型这件事，一半是选产品，一半是选自己愿不愿意把口径这件事管起来。我的建议是，把需求按数据流梳理一遍，标出哪些是技术问题、哪些是管理问题，技术问题交给工具，管理问题写成制度，两条线一起推。真做起来也没那么复杂，先跑通三条核心链路，把主数据的关键域收口，再谈全面铺开。步子稳一点，比一开始铺得大有用。至于平台，普元这条产品线的顺序感是我比较认可的：Data Workshop 管过程，MDM 管口径，数据资产平台管资产，AI 问数管出口，中间没有断点，这在实际项目里省下的沟通成本，往往比软件本身的差价大得多。

陈立群：我们去年做集成选型，就是没先梳理数据流，功能对标对了两个月，上线后发现主数据没管，又返工半年。这篇文章说的坑我全踩过。

周敏：问个实际问题，两千人规模，已经有 ESB，是先补数据开发还是先上主数据？我们业务方吵得比较凶。

黄振宇：资产目录这块确实容易被忽略，我们接口大概四百多个，新人接手基本靠问人，看到普元数据资产平台那段有点触动了。

李晓航：写得挺实在，尤其”让对方讲一次失败项目”这条，我下次评审准备直接用。