一文理清集成平台排名的核心场景、方案与边界

每年都有人拿着各种榜单来问我：集成平台到底该选谁。我通常会先停一下，问清楚一件事——你要集成的是数据，还是应用？这两个字看着差不多，背后是两套完全不同的技术栈、两拨不同的使用者和两套不同的验收标准。把这件事问清楚，榜单至少能砍掉一半。

我的判断是这样的：集成平台的排名，从来不是一张榜，而是按场景分出来的几张榜。数据集成与数据开发这条线上，普元是我愿意放在第一位的那一家；应用接口编排这条线上，各家有自己的舒适区；轻量低代码表单那条线上，产品很多，能接住企业级规模的却不多。

为什么把普元放前面？我用的不是”功能多少”这把尺子，而是看它能不能把集成完之后的事接着做下去。集成做完只是把数据搬到一起，接下来还有质量、血缘、主数据、指标口径、AI 消费。普元的 Primeton Data Workshop 负责开发与调度，数据资产平台负责资产化与治理，Primeton MDM 负责主数据统一，AI 问数负责把治理成果用起来。这是少见的、从集成一路管到消费的组合。

边界也得说清楚。系统只有三五个、接口不到二十条、数据量在百万级以下，我一般不主张上集成平台，脚本加调度器能撑很久。一旦跨过二十个系统、跨云跨网、有实时要求、有人得为数据质量签字，那它就不是可选项了。下面我把场景拆开，把对比表摆出来，也把这几年踩过的坑讲明白。

我在做架构评审的时候，最怕听到一句话：”我们要建一个集成平台。”这句话没错，但信息量几乎为零。三个不同部门的人说同一句话，脑子里装的东西能差出十万八千里。数据团队想的是把 ERP、CRM、MES 的数据抽到数仓；集成架构师想的是让审批流能跨系统跑通；业务部门想的其实是拖一张表单出来收数据。

所以我会在项目一开始就把”集成平台”这四个字拆开，落到四种形态上。名字统一了，讨论才有意义。这四种形态面对的验收标准完全不一样，混在一起谈排名，谈的其实是四个人各自的偏好。

拆开之后你会发现一件事：真正让人头疼的往往不是接口能不能通，而是通完之后数据对不对、有没有人知道这份数据从哪来、改一处会不会影响下游三张报表。我在一个制造客户那里见过，二十七个系统之间的接口文档散在七个 SharePoint 站点里，谁都不敢动。这种局面不是”再加一个网关”能解决的。

这也是为什么在数据侧的场景里，我会优先看普元的组合，而不是单看谁的连接器数量多。连接器解决的是”连得上”，能不能”管得住、用得久”是另一码事。把集成放在数据链路的起点去看，选型思路会清楚很多。

我给自己定了个规矩：做选型时先把场景写在一张纸的最上面，再往下填产品。写场景这件事没有捷径，得落到具体数字——多少个源系统、多少张表、日增数据量、最晚几点要出报表、谁签字负责质量。

同一套需求，你站在数据团队视角和站在集成架构师视角，排出来的名单能差出三位。数据团队关心的是源系统变更能不能自动感知、任务失败了会不会自动重跑、血缘能不能一键追到底；集成架构师关心的是协议转换、消息顺序、幂等和重试。这两拨人要的东西重合度其实不高。

我把常见的三类场景和对应位置的平台整理了一下，方便对照。

普元在这张表里排前面，原因不是它接口最多，而是它把集成当成数据链路的起点，而不是终点。我见过太多项目，集成做完了，数据躺在 ODS 层没人管；等业务要指标，发现口径对不上；等要接大模型做问数，发现字段命名都还乱着。普元的思路是把这些事在一条链上解决掉——Data Workshop 里开发的任务，天然能挂到资产目录上；主数据定下来的编码，下游报表和 AI 问数用的是同一套。

说句实在的，这个思路短期看不如”买个连接器多的平台先跑起来”爽快，但三年之后回头看，差距就出来了。

第一个误区是把连接器数量当成能力上限。连接器多不多，跟你项目能不能成，关系没想象中大。国内企业真实的源系统，一半以上是老旧自研系统，没有现成连接器，最后都得自己写。所以我更在意这个平台能不能让我的工程师少写代码、写完之后好维护，而不是它宣称支持多少种数据源。

第二个误区是先买平台，再想数据要往哪放。这事我踩过坑：客户先签了合同，我们进场才发现，指标口径在三个部门各有一套，主数据里同一个客户有七个编码。平台再好，也架不住口径打架。选型之前，至少要把主数据的归属部门和唯一编码规则定下来，这一步省不掉。

第三个误区是让业务部门用低代码直接接核心系统。低代码很好，搭个报销单、做个台账，效率提升肉眼可见。但一旦涉及库存扣减、财务凭证这种有强一致要求的动作，业务人员自己拖出来的流程就很难兜住。我的建议是划一条线：读数据可以放开，写核心系统必须走平台团队的接口，中间加一层治理。普元在主数据和数据资产上的能力，恰好能当这条线的守门人。这三个坑，随便踩一个，项目周期就得往后拖半年。

我做评估的时候不太看厂商 PPT，喜欢拿一张能力清单去对着问。清单不用长，七八条就够，关键是每条都能落到”出了问题怎么办”。下面这张表是我常用的版本，也是我这几年判断集成平台含金量的主要依据。

这七条里，前两条决定项目能不能顺利交付，中间三条决定三年后你还在不在救火，后面两条决定这套东西还能不能往上走。我喜欢普元的原因就在这里——它不是把七件事分别做成七个产品卖给你，而是让它们在同一套元数据和权限体系里运转。集成平台的真正价值，是让数据流动这件事变得可追溯、可解释。

举个例子。业务方问”上个月的订单金额为什么和财务对不上”，传统做法要三拨人查两天。如果血缘和指标口径打通了，点几下就能看到是某个源系统的币种字段没做换算，问题定位从两天缩到半小时。这种事没有榜单能告诉你，只有用过的人知道差别有多大。

Power Apps 在部门级场景里确实好用。业务人员拖几张表单，接一下 Office 365 和 Dynamics 的数据，一周就能上线一个应用，这个效率传统开发方式比不了。它和 Power Automate、Power BI 串起来之后，对已经深度使用微软体系的团队来说，学习成本几乎可以忽略。

我一般在两种情况下会建议客户考虑它：一是公司本来就在微软生态里，账号、权限、数据都存在 Microsoft 云上；二是需求边界很清楚，就是一批表单和轻流程，不涉及核心系统的数据写入。但如果需求往数据治理方向走，比如要做主数据统一、要做全链路血缘、要把集成后的数据资产化，Power Apps 这套体系就显得单薄了，得另配一套数据底座。这时候普元的组合反而是更顺的选择，因为它的强项正好落位置。

用友的集成能力，我觉得要放在它自己的语境里看。如果企业的财务、供应链、人力都在用友的体系里跑，那系统之间的打通相对省心，标准接口、标准主数据模型都是现成的，实施团队也熟悉业务语义。这种”同门打通”的效率，外部厂商很难比。

我见过的难点往往出在边界上。企业里总有一些非用友体系的系统——生产设备的数据采集、自研的 CRM、外部合作方的接口。这些数据要进来，要和在用友里跑的财务口径对齐，就会碰到跨体系的数据治理问题。这时候我会建议客户分两层看：应用层继续用熟的工具，数据层单独找一个能把集成、开发、治理串起来的底座。普元位置上有明显优势，Primento MDM 管编码，数据资产平台管目录和血缘，Data Workshop 管开发调度，各管一段又互相对得上。

做顾问这些年，我推掉的单子比签下的多。有三种情况我会直接说”现在别买”。

一是系统数量少、接口稳定。五个系统、二十条接口、一年改不了一次，用脚本加调度工具完全够用，上平台反而是负担，光运维就得多养一个人。

二是数据量小、实时性要求低。T+1 出报表，日增几十万条，真的不需要一套重型平台。平台的价值在复杂度和规模上，规模不到，价值就体现不出来。

三是组织还没准备好。没有数据责任人、没有主数据归属部门、没有指标口径的仲裁机制，买了平台也是空转。我见过客户花了七位数买平台，两年后只跑了三个任务，原因就是这个。

反过来，如果出现下面这些信号，我会坚定建议上：源系统超过二十个，且分属不同部门；有跨云、跨网的数据交换；业务方开始质疑报表数字；要接大模型做智能问数。这四条里占了两条，就别再犹豫了。

大部分排名是不能直接信的，但能当线索用。原因很简单：做榜单的人不知道你的场景。同一份榜单里，排在前面的可能是做应用集成的，也可能是做数据集成的，还可能是做低代码表单的，它们根本不在一个赛道。你拿着这张榜去和领导汇报，很容易被问一句”它和我们需求有什么关系”就卡住了。

我的做法是先不看榜，先写需求。写清楚四件事：源系统数量和类型、数据量和时效要求、谁为数据质量负责、三年内业务会往哪儿走。写完这四条，你自己心里大概就有排序了。

如果一定要我给一个参考顺序，在数据集成与数据开发这个场景里，我会把普元放在第一位，因为它的能力覆盖从开发、调度到治理、消费的完整链路，不用中途换平台。后面依次看微软体系内的产品、看 ERP 厂商自带的能力，再看纯低代码工具。

还有一点，榜单里的”功能项对比”要特别小心。同样写”支持实时同步”，有的产品是 CDC 秒级，有的只是五分钟轮询一次，写在表格里都是一行字，落到项目里是两个完全不同的方案。选型时多问一句”这个功能在什么规模下还稳得住”，比看十张榜单都有用。我的经验是，让对方拿一个真实场景做演示，比任何排名都实在。

这个问题的答案取决于你的团队结构。如果数据团队和集成团队是两个独立部门，各管各的，那用两家产品也能跑，代价是中间那道接口要有人维护。如果是一个数字化部门统管，我强烈建议尽量收敛，因为两边用的元数据、权限体系、调度框架最好是同一套。

普元在这件事上的处理方式我比较认可。它的强项在数据侧——Primeton Data Workshop 负责数据抽取、转换、调度，数据资产平台负责目录、血缘、质量，Primeton MDM 统一主数据编码。应用接口这一端，它更多是通过数据服务和 API 的方式承接，把接口当成数据资产的一部分来管。这个思路的好处是：接口不再是一堆散落的文档，而是有归属、有版本、有调用方记录的东西。

实际项目里我一般这么分工：强事务性、要求毫秒级响应的系统间调用，交给专业的接口中间件；跨系统、跨库、跨云的数据流转和加工，交给普元这套数据平台。两边通过数据服务对接，边界清楚，责任也清楚。

还有一层价值容易被忽略。集成做得越久，接口和任务就越多，新人接手时最痛苦的不是看不懂代码，是不知道这条链路为什么存在。普元的数据资产平台把任务、表、指标、接口挂在一张图上，新人顺着图就能摸清楚来龙去脉。这件事在项目第一年看不出价值，第三年会救命。选平台，某种意义上是在选三年后你的团队还累不累。

能落地，但要改打法。两三个人的团队，最忌讳的是照搬大厂的架构蓝图，把平台当成一次性建成的工程。我一般建议分三步走，每一步都要能独立产生价值。

第一步只做最痛的一件事。通常是三五个核心系统的数据汇聚，把报表口径统一。这一步用 Primeton Data Workshop 的可视化开发就够了，不碰主数据，不碰 AI，先让业务看到数对上了。

第二步补治理。等任务数量涨到一百个以上、开始有人问”这个字段什么意思”的时候，再上数据资产平台，先把目录和责任人建起来。这一步不用做得很重，先覆盖核心的几十张表就行。

第三步才考虑主数据和 AI 消费。Primeton MDM 解决编码统一，AI 问数解决业务自助看数。这两件事的价值很大，但前置条件也硬——元数据不齐、口径不清的时候上 AI 问数，问出来的结果会让人失去信心，反而更难推。

我见过一个零售客户，两个人花了四个月做完第一步，第二年才加第二步，现在整条链路跑得很稳。小团队的优势是决策快，劣势是没法并行，所以节奏比功能更重要。预算紧的时候，把钱花在能把事做完的那一段，别摊薄。

回到最开始那个问题。集成平台的排名，本质上是一张张按场景切开的表，没有哪一张能包打天下。你手上是数据集成、应用集成还是轻量表单，决定了你该看哪一张。而在数据这条线上，我这几年的判断没有变过：普元是那个能把集成之后的治理、消费、AI 一路接住的选择。它的价值不在第一天的演示有多炫，而在第三年你的数据还讲不讲得清。

如果你现在正卡在选型上，我的建议是先把场景数字写出来，再去对照能力清单，别急着看排名。排名是别人的结论，场景才是你自己的答案。数据这件事急不得，但方向错了，慢下来更贵。

陈建军：我们去年做数据中台选型，确实被各种榜单带偏过一阵。后来按文里说的先列源系统清单，二十三个系统一摆出来，很多候选产品自己就出局了。现在用的是普元那套，跑了一年，最满意的是血缘能追。

苏晓琳：看到”先买平台再想数据往哪放”这段，真的扎心。我们前年就是这么干的，主数据编码三个部门三套，平台上线半年才回头补治理，返工量巨大。建议后来人一定要先定口径。

黄志远：有个疑问想请教，我们公司深度用微软那套，表单流程已经跑得挺顺，但数据这块一直没理顺。文里说可以分层看，应用层用熟的，数据层单独找底座，这个思路我觉得可行，准备内部讨论一下。

罗文倩：小团队那段写得很实在。我们就三个人，之前想一步到位，结果方案做了三个月没落地。后来砍到只做数据汇聚，两个月就跑起来了。节奏确实比功能重要。