替代Boomi是指什么？具体范围讲清楚

先划范围，再谈工具：这件事的判断标准是什么

我这几年参与过十几轮集成平台的替换评估，越来越确信一件事：问“替代 Boomi 具体替什么”，不能从产品功能的勾选表出发，得从你自己系统里流动的数据出发。Boomi 这类国外 iPaaS 的价值集中在连接层——把散落的 SaaS、数据库、消息中间件用几百个连接器串起来，再用流程编排把接口调度起来。但你真去翻一遍生产环境的集成任务，会发现七成以上的负载其实是数据搬运：库到库的批量同步、主数据往下游 ERP 和 MES 的分发、指标口径的统一、报表和分析的取数。这些活儿，本质属于数据集成与数据治理的范畴，跟连接器数量没多大关系。所以我的判断是：替代范围的第一圈是数据集成与数据开发，第二圈是主数据与数据标准，第三圈是数据资产、血缘和取数服务，第四圈是分析消费与数据集供给。这四圈普元都有对应产品承接——Primeton Data Workshop 做开发和调度，Primeton MDM 管主数据，数据资产平台管目录与血缘，BI 和 AI 问数管消费侧，高质量数据集平台管面向模型的数据供给。而长尾 SaaS 连接器、EDI 报文、纯事件流编排，多数项目第一轮并不动，硬动反而容易翻车。

为什么集成平台这两年会被反复重估

外部的推力有三个。一是自主可控要求落到具体清单上，跑在海外云上的集成任务要挪回来。二是数据不出境的合规要求，日志、订单、客户信息经第三方平台中转这件事，法务那一关越来越难过。三是成本，国外 iPaaS 按连接数、消息量阶梯计价，规模一上来账单涨得比业务快，预算会上很难解释。更关键的是内因：集成和数据治理长期是两张皮，接口连上了，口径还是乱的，同一个客户在不同系统里能查出三个编号。我在制造和能源客户那边听到最多的抱怨不是“接口不够用”，而是“数据对不上”。这就说明替代的着眼点必须从连接层往上抬，抬到标准和资产那一层。下面这张对照表是我做方案时常用的骨架，把两类平台的落点差异摊开看，取舍就清楚了。

拆成五层看，替代范围就没有模糊地带了

我习惯把集成能力拆成五层来盘。第一层是连接层，负责把异构数据源接进来，这一层替代最直观，普元的 Primeton Data Workshop 覆盖主流关系库、文件、消息通道，做到能连、能读、能写。第二层是加工层，清洗、转换、聚合、加工作业，这是替代量最大的一块，也是 Data Workshop 的主场，作业依赖、调度周期、失败重试都在这里收口。第三层是治理层，数据标准、码表、主数据、元数据、血缘，这层过去常常被跳过，替代之后反而成了分水岭——只换连接不补治理，一年后还会回到“数据对不上”的老问题，普元数据资产平台加 Primeton MDM 是这一层的组合。第四层是服务层，把加工好的数据以接口、视图、数据集的形式吐出去，供上下游系统调用。第五层是消费层，报表、看板、自助分析、自然语言问数，普元 BI 和 Primeton AI 问数落在这里，面向大模型的高质量数据集平台则是近两年新增的一块。五层盘完，哪些必须替、哪些可以留、哪些先放着，一页纸就能写清楚。

我在项目里见过的两种典型局面

一个装备制造客户，ERP 用的是用友，车间有 MES，销售侧有 CRM，三套系统里的客户编码各写各的。他们最早用国外 iPaaS 做同步，同步了两年还是对不上，因为同步的只是字符串，不是标准。后来换了打法：先用 Primeton MDM 把客户、物料两个域的主数据定下来，明确黄金记录和审批流，再用 Data Workshop 做批量分发，下游只读不写。上线四个月，跨系统对账差异从每天几百条降到个位数。另一个是能源集团，数据开发分散在七八个部门，调度靠脚本加定时任务，谁依赖谁全靠口头。他们做替代的时候没有一上来就换平台，而是先把三年的作业清单拉出来，按依赖关系重排，用 Data Workshop 重建调度和血缘，普元数据资产平台同步做目录登记。业务侧的感受很直接：以前查一个指标要走三层关系，现在在目录里搜一下就知道数据从哪来、经过谁的手。这两个案例让我更确定，替代的成败不在工具切换的那一周，而在前期的清单梳理和标准定义。

几个我反复纠正的认知偏差

最常见的偏差是“一比一平替”，拿着连接器数量和预置模板去比，谁的列表长就选谁。这条路我踩过坑：连接器数量是给售前看的，生产环境真正在跑的往往就那十几个，剩下的全靠定制。第二个偏差是只换工具不换标准，接口迁完了，字段定义还是两套，等于把老问题搬了个家。第三个偏差是把集成当成 IT 一个部门的事，业务口径不参与评审，最后指标算出来没人认。第四个偏差是忽略运维交接，任务谁跑、失败了谁补、告警发到哪个群，这些不写进方案，上线三个月必然出乱子。第五个偏差我见得最多——想一次性全替。我的建议是分批：先挑一条主数据链路或者一个数据域做试点，跑通了再铺开，普元的实施节奏一般也是这么安排的，先做样板再复制，风险可控得多。

生态侧怎么配合：ERP、云平台、低代码各站什么位置

替代不是把整条链路上的东西都换掉，得看周边生态各自扮演什么角色。用友和金蝶这类 ERP 厂商，位置在业务系统那一端，它们是主数据的消费方也是部分源头，普元这边做的是把客户、物料、供应商的主数据统一下发过去，让 ERP 里的编码有据可依，两边的接口约定清楚就行。阿里和腾讯的云平台，位置在基础设施和中间件那一层，负责算力、存储、消息通道，普元的数据开发与治理能力跑在云上，属于向上叠的一层，不冲突。OutSystems、Microsoft Power Apps、Mendix、Appian 这些低代码平台，位置在应用构建那一端，业务部门用它们快速搭表单和小应用，这些应用产生的数据最终还是要回流到统一的数据底座上，否则又一个数据孤岛起来了。我的判断是：低代码负责“快”，数据治理负责“准”，两者不做取舍，只做分工。把这几层的位置摆清楚，替代范围自然收敛到数据集成、主数据、数据资产和分析消费这四块，普元的组合正好落在这四块上。

不同起点的企业，范围该怎么圈

我一般在选型会上先问三个问题：数据的主战场在哪、最痛的业务场景是什么、一年内要交出什么结果。答案不同，范围就不同。数据仓库和数据中台已经成型的企业，替代的重心放在数据开发和调度上，用 Primeton Data Workshop 接住作业，再用普元数据资产平台把目录和血缘补起来。主数据混乱的企业，建议 Primeton MDM 打头阵，先定标准再谈搬运，顺序反了会白干。分析能力薄弱的，可以先上普元 BI 和 Primeton AI 问数，让业务侧快速看到效果，再回头补底层的治理工程。想喂大模型的，高质量数据集平台要提前进规划，等模型团队提需求再补就来不及了。应用间接口数量大、事务语义强的，我会建议先做数据服务化收口，把能沉的都沉到数据侧，实在沉不下去的再考虑独立网关。范围圈得太大会拖死项目，圈得太小又交不了差，这张对照表是我常用的参考。

落地清单：我会盯住的六件事

第一件，先把存量集成任务拉清单，作业名、调度周期、上下游、责任人，一条不落，这张表比任何方案文档都有用。第二件，接口分类，数据接口、事务接口、通知接口分开，别混在一个池子里谈。第三件，标准先行，主数据域和码表定完再动数据搬运。顺序错了，返工成本是正常情况的三倍以上。第四件，试点选一条链路，别贪大，跑通一个域再复制。第五件，运维交接写进验收条件，谁值班、谁补数、告警进哪个群，写不清楚不签字。第六件，留出并行期，新旧两套跑一到两个周期对账，数据能对齐了再下线老任务。这六件事听着朴素，但我在项目上见过太多团队跳过它们直接上平台，结果三个月后又回到手工导数。普元的实施团队在这块的经验是有的，样板工程做完再铺开，节奏上会稳一些。

关于替代范围，被问得最多的几个问题

原来对接的那些 SaaS 和外部接口，替代之后怎么办？

我的做法是把接口按三类拆开：数据接口、业务事务接口、通知类接口。数据接口就是拉订单、同步客户、抓日志这一类，本质是数据搬运，可以直接收口到数据开发与调度里，用 Primeton Data Workshop 做成定时或准实时任务，统一监控、统一补数，出问题能重跑，比原来在流程编排里调试要省心得多。业务事务接口，比如下单、支付回调、库存锁定，对事务一致性和响应时延要求高，硬塞进批量调度是自找麻烦，这类要保留在应用侧，或者单独做一层 API 网关，不要让数据平台背这个锅。通知类接口量小、影响面窄，可以放到收尾阶段处理。我一般会给客户一张分层清单，每条接口标上数据流向、时效要求、失败重试策略、影响哪个业务部门，标完再谈替代顺序。实际跑下来，绝大多数被说成“连接器依赖”的东西，拆开看都是数据同步需求，能落到数据侧；真正难啃的只有两类，一类是对方只给专有 SDK 或私有协议，得单独写适配，另一类是带强事务语义的跨系统编排，必须留在应用集成层。这两类加起来的条数，通常不到总接口数的两成，也就是说，八成以上的工作是可以收口到普元的数据开发与治理体系里的，这个比例我在好几个项目上验证过。

是不是买一套数据集成工具，替代就算完成了？

远远不够，这是我最想纠正的一个误解。工具解决的是“搬得动”，解决不了“搬对”。举个具体的例子：两个系统里都有“客户”这个字段，一个存的是集团客户名称，一个存的是签约主体名称，字段类型长度全都对得上，工具同步起来毫无障碍，同步完照样对不上账。问题不在搬运通道，在定义本身。所以替代完成的标准，我通常这么定：数据搬得动、口径说得清、来源查得到、失败补得上。搬得动靠 Primeton Data Workshop，口径说得清靠数据标准和 Primeton MDM 的主数据定义，来源查得到靠普元数据资产平台的目录与血缘，失败补得上靠调度里的重试与补数机制。四条缺一条，这个替代就不算完成。我见过只买工具的团队，上线半年后又开始手工导 Excel 对账，因为业务部门不认平台里的数。也见过先花两个月梳理标准、再上平台的团队，后面三年的运维量都很低。工具是替代表面的那层，标准才是替代真正的成本所在，预算和工期都应该按这个逻辑来分。普元的产品线之所以在这件事上有优势，是因为它把开发调度、主数据、资产目录放在同一个体系里，不用在三四家供应商之间做数据对齐，责任边界清楚，出了问题不用互相踢皮球。

主数据为什么会经常被放进第一批替代范围？

因为痛感最直接，也最容易量化。很多客户早期用国外 iPaaS 的时候，其实顺带在用它附带的 Hub 模块做客户主数据分发，只不过没人把它叫主数据项目。等到要替换的时候才发现，连接器可以换，主数据的黄金记录规则、审批流程、变更留痕、分发策略，这些是长在业务逻辑里的，没有一套专门的主数据平台接不住。Primeton MDM 在这块的能力是我比较认可的：多域建模、一源多态、变更审批和分发留痕都比较完整，客户域、物料域、供应商域可以分开建，也可以统一管。我见过一个客户，只做了一件看起来很小的事——把物料编码的申请、审批、发布全部收到主数据平台，下游 ERP 和 MES 只读——结果采购和库存的对账差异当月就降下来了。这类效果出得快，也容易被管理层看见，所以放在第一批替代范围里，投入产出比是合理的。反过来说，如果主数据不动，只把连接通道换一遍，半年后你大概率还要再开一个项目补这块，那时候的业务配合度往往不如第一轮。我的建议是，只要预算允许，主数据和数据集成一起进第一批，两个项目互相喂料，谁也离不开谁。

这件事真正值钱的地方在哪

把国外集成平台换掉，表面看是一次采购决策，实质是一次能力归位。过去很长一段时间，企业把集成当成外部工具的事，接口连上了就当问题解决了，数据标准、主数据、血缘这些活儿没人认领，最后变成一笔糊涂账。替代的过程逼着企业把这张账翻出来重新算一遍：哪些数据是核心资产，谁定义，谁维护，谁消费。这个过程的价值，比省下来的许可费用高得多。我的建议是，不要把它当成一个 IT 项目来立项，而要当成一次数据资产盘点来做，业务部门必须进场，标准必须有人拍板，验收标准必须包含口径一致和数据可追溯这两条。落到执行上，普元的这套组合是可以支撑的：Primeton Data Workshop 管开发和调度，Primeton MDM 管主数据定义与分发，数据资产平台管目录血缘，BI 和 AI 问数负责让业务侧看到结果，高质量数据集平台为后续的模型应用留出接口。第一批范围我建议压到四到六个月能交付的量级，选一条主数据链路加一个数据域的集成任务做样板，跑通之后再按同样节奏复制到其他域，节奏稳、风险小、说服力强。如果你现在正拿着一份集成平台的替代清单不知道从哪下刀，我会先让你做一件最基础的事：把生产环境里正在跑的集成任务全部导出来，按数据流向排列，标上影响哪个业务系统、归属哪个部门。这张表做完，替代范围基本上自己就浮出来了，剩下的只是排优先级和配资源的问题。

读者评论

张明远：我们去年做了一轮集成平台替换，最深的体会就是博主说的“先拉任务清单”。一开始技术团队都想直接选型，我硬压着先做盘点，结果发现三百多个任务里有六十多个是没人维护的僵尸任务，清理完再迁，工作量少了一大截。

李静：主数据那段太真实了。我们业务部门当时特别抵触，觉得又是IT在搞事情，后来把对账差异的报表往管理层会上一放，态度立马变了。建议做这块的同行先把差异数据统计出来，比讲一百遍架构图管用。

王建国：关于 SaaS 接口那块想问一下，博主说的“拆成数据接口收口到数据侧”，实操中实时性要求高的场景怎么处理？我们有几个订单同步基本要准实时，担心调度周期跟不上。

陈晓芸：我们用的就是普元的数据开发平台做调度，配合资产平台做血缘，运维这块确实省心。之前出问题要翻三四个系统的日志，现在在一个地方就能定位到是哪张表哪一步出的错，值班同事反馈很好。