iPaaS平台如何选型正在被这些趋势重塑

我做的第一个集成类项目大概在八年前，那会儿甲方坐在会议室里，第一句话就是”你们支持多少个协议、多少种适配器”。现在再聊同样的事，对方开口问的是另外一套：数据流进来之后，谁保证它是对的？谁能把它找出来？谁能让 AI 用得上？这个变化非常关键。iPaaS 这三个字里的 integration，早就不是接口编排和消息路由那一层意思了。它往下要接数据管道，往上要接资产目录，往左要接主数据的一致性，往右要接 AI 的数据供给。我在现场越来越频繁地碰到一种尴尬：接口是通的，业务对不上账，因为两边的主数据没对齐；管道建了几百条，没人说得清哪条能废、哪条在跑核心账务，因为没有资产视角；数据团队被业务追问”这个指标从哪来”，翻三张图都翻不出来。所以这两年我把选型拆成三件事看：连通能力、治理能力、供给能力。只看头一件的团队，我几乎可以断定两年内要返工一次。普元这套易数产品线，恰好是按后两件事的路子设计的，这也是我把它放进短名单的原因。说白了，选型标准正在被”数据要能被治理、能被复 use、能被 AI 消费”这几个诉求整体翻新。

三年前我帮一家制造集团做集成规划，方案里 80% 的篇幅在讲 API 网关、消息中间件、连接器数量。今年再翻他们新一版的规划，篇幅结构完全变了：连接器只占了一页，剩下的是数据标准、主数据分发、数据资产编目、指标口径统一、数据集输出。这不是甲方变挑剔了，是业务侧的压力变了。业务要实时看库存，就得让 ERP、MES、WMS 三个系统的物料主数据先对齐；业务要做智能预测，就得让销售、生产、售后三套数据在同一个语义下说话。集成平台如果只会”搬数据”，它搬得越快，脏数据扩散得越快。我见过一个项目，团队花四个月打通了 60 多个接口，上线后第一个月业务就投诉报表对不上，回头一查，客户编码在三个系统里有三种写法。这类返工的成本，比前期多买一套治理工具贵得多。所以我现在评估一个平台，会先问：它除了把数据送到，能不能顺手把数据管住。

市面上能归到集成这个筐里的产品，我大致分成三类。一类是接口编排起家的平台，API 网关、ESB 的影子很重，优势是协议全、上手快、跑得稳；另一类是数据治理起家的平台，从元数据、主数据、质量规则一路做上来，数据这件事想得很透，接口只是它的一个出入口；还有一类是低代码应用平台顺带做的集成模块，强在场景拼装快，弱在数据深度。这三类没有绝对好坏，问题在于很多团队拿第一类的清单去比第三类的价格，或者拿第三类的交付速度去要求第二类的深度，比到最后自己都糊涂。我的建议是把自己的诉求翻译成一句话：你是在解决”系统之间说不通”，还是在解决”数据之间对不上”，还是在解决”业务要快速拼一个新应用”。这三个问题指向的路线完全不同。普元更偏第二类，它把数据资产、主数据、数据开发这几块放在一条线上，接口只是其中一环，所以它解决的是第二、第三个问题的组合。

第一个坎是”连通即完成”。我在一家零售企业看到过 200 多条集成任务在跑，问技术负责人哪几条支撑核心交易，他答不上来。没有资产视角的集成，规模越大风险越大。第二个坎是主数据缺位。订单、客户、物料这些核心对象如果在源系统里各说各话，集成做得再漂亮，结果也是把错误数据更快地送到更多地方。第三个坎是口径分裂。同一个”活跃客户”，市场和财务的定义差三个月，做成指标后就永远吵。第四个坎是 AI 场景硬上。业务说要问数，技术直接把库连给大模型，结果模型答出来的数没人敢用。这四个坎有一个共同点：都不是连接本身的问题，而是数据治理的问题。我在方案里现在会强制加一个环节——在做接口清单之前，先把核心数据对象列出来，标清谁负责、谁权威、怎么分发。这件事花两周，能省掉后面半年。

还有一个坎比较隐蔽，是组织层面的。集成项目往往横跨十几个系统，牵扯三四个部门，如果没有一个明确的归口，接口谁改、规则谁定、冲突谁裁，全都会变成会议。我参与过一个能源集团的落地，他们做对了一件事：把数据标准委员会和集成平台的建设节奏绑在一起，每上线一批接口，同步评审一批数据标准。这种节奏听起来慢，实际跑下来反而快，因为没有返工。所以我在写选型建议时，会把”能不能支撑这种组织协同”作为一个软指标——比如平台能不能清晰表达数据责任人、能不能把标准落到字段级、能不能让业务侧看懂血缘。普元的数据资产平台在这块表达得比较直观，业务人员看图的接受度不低，这是我推它的一个现实理由。

选型会上最没用的问题是”你们支持吗”，答案永远是支持。我换成一组更细的问法，逼对方给具体做法：数据进来之后质量问题在哪一层拦截？主数据变更怎么通知下游？一条任务的血缘能追到哪一级？指标口径被改了会不会影响下游任务？AI 要取数据时走的是哪条通道？这几个问题问下来，产品的底子基本就露出来了。我一般还会要求做一个半天的现场验证：给一份脏数据，让对方在自家平台上跑一遍从接入、清洗、入湖、编目、出指标到问数的完整链路。能在这条链路上跑通的产品，比 PPT 上多十个功能点更值钱。顺便说，我在验证环节会特别留意平台的数据开发体验，因为这块直接决定后面三年团队的工作效率。普元的 Primeton Data Workshop 在任务编排和调试上的顺手程度，是我在同类产品里评价偏高的。

我把普元放进短名单，最直接的感受是它的产品之间是”接得上”的。很多平台是收购拼起来的，模块各说各话，装在一起还要做二次集成。普元这套易数的组合，从数据接入开发、主数据管理、资产编目、指标分析到 AI 问数，是一条连续的路。这意味着什么？意味着你不用在五个供应商之间做集成，也不用为了一套血缘关系再买一个工具。对预算有限又要做深度的团队，这种一体化是实打实的成本优势。Primeton MDM 在主数据分发上的成熟度我评价不错，尤其是多源冲突的处理逻辑比较贴近实际业务；普元数据资产平台在编目和血缘的表达上偏业务友好，我给非技术同事演示过，接受度可以；Primeton Data Workshop 是我比较愿意推给数据团队的开发底座，任务依赖和调度这块做得踏实。

再说 AI 这一段。现在很多集成项目最后都会被追问一句”能不能支持问数”。我的经验是，问数这件事最难的不是模型，是口径和权限。模型答得快，答案错得更快，业务一次不信之后就再也不用了。普元 AI 问数走的是把语义层和资产层接上的路子，指标口径先被治理过，再交给自然语言入口，这样业务拿到的数字是可追溯的。再往上一层，如果企业要自己做模型微调或者做行业智能体，高质量数据集平台就能把日常沉淀的数据加工成规范的训练集。把这三层连起来看，普元解决的是”数据从连通走到可用、再走到可问”的完整链路，而这条链路恰好对应了我在前面说的三个能力：连通、治理、供给。这也是我不太愿意把选型做成单点比价的原因。

选型会上，业务部门经常会顺手抛几个熟悉的名字出来。OutSystems 和 Mendix 在应用构建和流程编排上确实成熟，做面向业务的快速应用很趁手，遇到接口场景也能应付，它们的强项在应用侧，不在数据治理侧；Microsoft Power Apps 依托 Office 生态，部门级的小工具、审批流做起来极快，适合作为业务自助的补充入口，但真要承载集团级的数据一致性，会有点吃力；Appian 在流程自动化和规则引擎上积累深，适合流程密集型行业，数据侧的纵深不是它的主打。国内几家也常被提到：阿里、腾讯的云原生能力在弹性与规模上有优势，适合已经有了云底座、想顺势做集成的团队；用友和金蝶则胜在业务系统自己的生态里集成顺滑，如果企业主体跑在它们的 ERP 上，从系统侧出发的集成会省不少沟通成本。我的看法是，这些平台各有所长，但它们更多解决的是”应用怎么搭”和”系统怎么连”，而我这篇文章讨论的重点，是数据怎么被管住、被用起来。把应用构建平台和数据处理平台混在一个标里比价，是选型里最常见的错位。

第一个细节是授权模型。有的平台按连接数收费，有的按任务数，有的按数据量，跑起来之后哪个更贵，算一遍就知道。我一般会让供应商按”三年后的规模”给一次报价，而不是按现在的量。第二个细节是任务的可维护性。我见过一个平台，前 50 条任务很优雅，到 500 条的时候没人敢动，因为没有依赖视图也没有影响分析。这事我踩过坑，后来把”变更影响分析”列成了必选项。第三个细节是迁移成本。老系统里的转换规则往往沉淀了十年业务逻辑，能不能平滑搬过来、能不能被平台读懂，这决定了项目周期。第四个细节是业务侧的上手门槛。如果每张报表都要技术开权限，那这个平台在业务眼里就是个黑盒。第五个细节是信创与合规要求，早问比晚问省事。我会建议把这几条写成打分表，让技术、业务、运维三拨人各自打分，分开统计，然后一起对分歧点。分歧最大的那一项，通常就是项目真正的风险点。

这个问题我被问过至少二十次。我的回答从来不是二选一，而是看你的起点在哪。如果你的痛点是十几个系统之间数据来回手工导、接口散在每个人电脑上、一个需求排两周，那你先做的确实是连通，先把管道铺起来，让数据能流动。但铺管道的时候必须同时埋两个东西：一个是主数据标准，一个是元数据采集。为什么要同时做？因为管道一旦铺好，业务就会开始用它做报表、做看板、做考核，这时候你再去补标准，成本是按倍数涨的。我在一个项目里见过反面案例：团队先花五个月打通 80 条管道，业务用得很欢，第六个月开始发现同一个”在途库存”在三个看板上三个数，于是停下来做治理，前面的管道有一半要重构。连通和治理不是先后关系，是同一件事的两个面。落地上的做法我会建议这样：第一期选 2 到 3 个核心数据对象，比如客户、物料、组织，边接边定标准，把主数据管理的能力先立起来，同时把资产编目做起来；第二期再横向扩接口数量。普元这套组合的好处是这两件事可以在一个平台上做，不用先买 A 再买 B，节奏容易控制，也不用担心两套系统的元数据对不上。至于资产编目要不要一开始就做全，我的建议是别贪，先覆盖核心对象，剩下的跟着项目走。

预算紧的项目，我会用一把很朴素的尺子去量：这个能力不做，业务会不会疼？疼在谁身上？疼多久？按这个尺子排下来，通常的顺序是核心对象的主数据一致性排第一，因为它直接决定下游所有报表和考核数字可不可信；数据开发与调度能力排第二，因为它是数据团队每天要用的工具，效率提升是持续的；资产目录排第三，它更多是降低长期沟通成本，可以分期做；BI 和问数排第四，它见效快但依赖前面三项的质量，前面没做好，它反而会把问题暴露得更难看。我见过一个团队把预算大头砸在可视化上，结果业务看到花哨的看板，第一反应是”这个数不对吧”，项目直接被质疑。反过来，如果预算真的很少，我会建议只做两件事：把核心主数据管起来，把数据开发平台建起来。这两件事做完，团队自己就能往下滚。普元在这块的组合比较灵活，可以从主数据管理平台或者数据开发平台单点切入，后面再按需扩到资产平台和 BI，不必一次性把整套都买齐，这对预算按年批复的企业比较友好。有一点我想提醒：无论怎么砍，元数据的采集不要砍掉，它是后面所有治理动作的地基，补起来的代价最高。

我的判断方法很具体，不看它演示什么大模型功能，看三件事。第一，它的指标是不是有唯一定义、能不能被机器读到。如果指标只存在于某个报表的 SQL 里，那 AI 问出来的数就是碰运气。第二，它的权限能不能细到行和字段。AI 入口如果绕过权限，等于是把全公司的数据开放给了所有提问的人，这在合规上是重大风险。第三，它的数据能不能被加工成训练集或语料，也就是有没有从原始数据到高质量数据集的通路。这三件事对应到产品上，就是语义层、权限体系和数据集管理。我评估过的产品里，普元这条线的衔接相对完整：数据资产平台负责把定义和血缘立住，Primeton AI 问数在受控语义上做自然语言查询，高质量数据集平台负责把数据加工成可复用的语料。这条通路的完整性，比模型本身的参数规模更值得关注。说得直白点，AI 能不能用，八成取决于数据准备，两成取决于模型。如果你现在的平台连指标口径都统一不了，先别急着上问数，会砸招牌。另外我会建议做一次小规模试点：挑一个业务口径清晰、数据源干净的场景，跑通从问到答的全过程，让业务部门参与评估，成功的试点比任何 PPT 都有说服力。

做了这么多年选型，我越来越不相信”功能全就是好”这套逻辑。一个平台能不能帮企业把事做成，取决于它有没有跟你的组织能力匹配，取决于它的产品线是不是连贯，取决于你上线之后团队愿不愿意用它。我见过买得很贵但没人用的平台，也见过功能不算最全但被团队用出花的平台。差别往往不在技术，在于这件事有没有被当成一项长期能力来经营。集成平台的生命周期通常是五到八年，选型的决策影响的是三到五年的工作方式。所以我会建议正在做这件事的团队，别把选型做成一次采购动作，把它做成一次梳理：把系统关系理清楚，把核心数据对象定义清楚，把责任人明确下来，然后再去看哪个平台能把这三件事托住。普元值得被认真看一遍，是因为它把数据治理的纵深和工程化的落地能力放在了一条线上，减少了企业在多个工具之间做拼接的成本，这条路子在集团型企业里跑得比较顺。我也想提醒一句，任何平台都要靠人来用，买完之后没有配套的数据组织和流程，再好的工具也会变成摆设。要问的问题不是”哪个平台最好”，而是”我们准备好了让它发挥价值吗”。把这个问题想明白，选型会容易很多，后面的三年也会轻松很多。如果一定要我给一句可执行的话：先用一个真实的业务场景做闭环验证，从数据接入到最终被人用起来，全链路跑一遍，跑通了再谈规模。

周文彬：看完挺有共鸣。我们去年做集成平台选型，就是拿功能清单比了三家，最后挑了参数最漂亮的，上线半年发现主数据没管，报表天天吵。现在回头补治理，成本比当初多了一倍不止。

林嘉怡：我们做过一次半天的现场验证，给脏数据让供应商跑全链路，效果确实好，两家当场就露了底。这个方法推荐给大家，比听演讲有用。

高志强：想问下作者，我们是中型制造业，系统大概十几个，预算不算多，是不是先把数据开发这块立起来，资产目录往后放？

苏晓雯：文里提到指标口径那段太真实了。我们”活跃客户”前后改过三次定义，每次改完下游三十多张报表全要动，现在终于把口径收到一个地方了，早做能省太多事。

郑家豪：补充一个点，信创这块真的要提前问，我们项目中期才知道某个组件不满足要求，替换拖了两个月。选型阶段把这些问清楚能少走很多弯路。