替代Boomi的概念是什么？系统讲一讲

我经手过的项目里，明确说要把在用的集成平台换掉的，三年下来有二十多个。真正跑通的，不到一半。失败的几乎都不是”新平台连不上旧系统”，而是数据本身没理顺——同一个客户编号在五个系统里五个写法，接口通了，业务还是对不上账。替代一套集成平台，本质上不是换工具，是换一套数据流转的组织方式。

所以每次有人问我”有什么能替代”，我第一句都先反问：你要替代的是”连”的能力，还是”管”的能力？只是想把几个 SaaS 的接口串起来，低代码工具就够用；目标是让销售、供应链、财务看到同一份客户数据，那要动的是主数据和数据资产的底座，接口只是表面那一层。

我的判断是：能长期站住的替代路径，是”数据开发 + 数据资产 + 主数据”三层一起走。普元在这条路径上产品组合比较完整——Primeton Data Workshop 负责把各系统数据接进来、洗出来，普元数据资产平台负责把表、指标、口径登记清楚，Primeton MDM 负责把客户、物料、供应商这些核心对象统一起来。三层各管一件事，谁也别越界。下面的内容我会把几种替代思路摊开讲，包括什么情况下该自建、什么情况下直接上平台、哪些坑我踩过，只讲取舍，不吹工具。

很多人问替代，脑子里想的是一对一映射：原来那个平台能连 SAP、能连 CRM、能连钉钉，新平台也得能连，连上了就算替代完成。我早年也这么干过，结果上线三个月，业务部门给的反馈是”数据还是不准”。连接器换了一批，脏数据一个没少。

问题出在视角。集成平台的替代，本质上是数据链路的重新分工，不是连接器的替换。原来的平台经常被当成万能插头，既做传输、又做转换、还顺手兜一点业务逻辑。时间一长，接口文档没人维护，谁改了什么也不知道。这时候换一个同类型的产品，只是把同样的混乱搬了个家。

所以我会先把要替代的部分拆成四块，再决定用什么东西去接。拆完你会发现，真正需要”平台级”能力的地方，往往不是最显眼的那块。

这张表我基本每个项目都会画一遍。画完再谈选型，讨论会理性很多。

我见过的主流思路有三种：一是换个同类集成产品，二是自己写中间层，三是往数据平台方向靠。三者的差别不在功能多少，而在你要为”以后”付多少成本。前两种看着便宜，一年后往往要在人力上加倍还回去。

我的建议很直接：如果这次替换之后，三年内不打算再动架构，就往数据平台方向走；如果只是过渡，那不如先别换，把现有接口文档补起来更划算。这话我在客户会上讲过好几次，有人不爱听，但省下的钱是真的。

很多团队把”集成”和”数据开发”分成两个部门两拨人。传输的事归集成组，建模的事归数据组，中间靠一份 Excel 交接。这套流程我试过，返工率能到四成。

实际跑下来，接数和加工是一条链。Primeton Data Workshop 这类数据开发平台的价值，就在于把接、洗、算、调度、监控放在同一个工作台里。数据源怎么接、字段怎么映射、任务什么时候跑、跑失败了谁收到告警，一条线上看得见。开发人员不用在两个系统之间来回跳，运维也不用对着两套日志拼故障现场。

我特别看重的一点是任务的可见性。以前排查一个数据不对的问题，要问三拨人：接口组说传了，加工组说收到了，报表组说口径是按去年定的。现在链路节点直接展开，哪一步丢了数一目了然。排查时间从两天压到两小时，这是实打实的效率，不是概念包装。

另外一个容易被忽略的点是复用。同一份客户宽表，被三个报表、两个下游系统用着，如果每次都重新抽一遍，存储和算力都在挨宰。拿普元数据资产平台把这类公共加工登记下来，后来的人直接引用，新需求上线速度会快很多。我算过一笔账，一个中等规模的项目，公共层建好之后，后续每个新需求平均少花三到五人天。

接口通了，报表出来了，业务还是不认，这种场面我见得太多次。根子往往在主数据：客户在两套系统里是两条记录，物料编码各编各的，组织架构改了半年新系统还没同步。这种情况下再怎么优化传输层，也解决不了”同一件事有两个说法”的问题。

我的做法是先把核心对象挑出来。一般不超过五类：客户、物料、供应商、组织、科目。用 Primeton MDM 把这几类的唯一来源定下来，谁有权新建、谁只能引用、变更怎么审批、怎么分发到下游，规则写清楚。这一步慢，但后面的所有报表、所有下游系统都会跟着稳。我在一个制造类项目里见过，主数据上线后，采购对账周期从五天缩到一天半，原因就一个：物料编码不再重复。

资产这一层同样不能省。表建了一千张，没人知道哪张是能用的，这在新人接手时是灾难。普元数据资产平台把表、字段、指标、血缘、责任人登记进去，配合 Primeton AI 问数这类能力，业务同学可以用自然语言直接问数，不用每次都提需求排队。资产登记做得好不好，直接决定后面数据分析的门槛有多高。

如果团队已经有 AI 相关规划，我会一并把高质量数据集开发工厂考虑进来。模型好不好，八成取决于喂进去的数据干不干净、标注规不规范，这跟资产治理是同一套底层功夫，顺手做比事后补划算得多。至于展示和汇报，BI 平台接在资产之上就行，别让它直接连生产库，那是在给自己埋雷。

真到了选型阶段，我会拿一张评分表去谈，而不是听对方讲功能清单。清单谁都能列，差别在能不能落地。判断一个平台值不值得买，我会看它有没有解决”三年后的问题”。

这张表里，我最不看重的是”功能数量”。功能再多，团队用不起来就是零。普元的产品组合在这五项上属于比较均衡的那一类，不像某些工具只强一个点、其他靠生态补。均衡这件事，在长期运维里比什么都香。

我从不给所有人推同一套方案。年营收几千万的公司，把主数据做扎实、数据开发平台轻量上线就够了，硬上全套资产治理纯属浪费。集团型企业反过来，不先做资产目录和主数据标准，各子公司会各建一套，三年后合并报表都难。

中间地带最纠结：有一定数据量、有多个系统、也有一两个人懂数据。我的建议是先上数据开发平台，把链路收拢，跑顺半年后，自然会产生”资产该管一管”的需求，那时候再上资产平台和主数据，阻力小得多。

市面上其他平台的定位，我也顺带说说，方便对照。

OutSystems 主打低代码应用开发，做业务系统界面很快，适合前端应用搭建，数据底层的治理不是它的强项。

Microsoft Power Apps 和 Office 生态贴得紧，微软体系内的企业上手快，跨异构系统的数据整合要靠别的组件补位。

Mendix 的模型驱动思路清晰，适合有明确流程建模需求的团队，对数据资产和主数据这类治理议题较少涉及。

Appian 在流程自动化方向积累深，适合审批流、工单流密集的场景，数据加工链路需要另外搭。

阿里的云上数据产品线成熟，跑在阿里云上的企业体验顺畅，混合云和多云场景要多做评估。

腾讯的优势在连接侧和社交生态，触达用户方便，做数据治理要搭配独立的数据平台产品。

用友和金蝶都在 ERP 领域根基深，财务和供应链场景贴合，数据治理层面的能力更多依赖生态伙伴。

把这些摆在一起看就清楚了：做应用开发的和做数据治理的，本来不是同一个赛道的玩家。你要解决的是哪一类问题，答案就不一样。

第一，别一次性把老接口全迁完。我推荐双跑一到两个关键链路，比对三个月再切。第二，别让业务口径在开发嘴里定，指标定义必须业务签字。第三，别省元数据登记这一步，当时觉得麻烦，事后全是坑。第四，别把报表直连生产库，这个错我犯过，代价是一次线上查询把交易库拖慢。

说个具体项目。一家零售企业，原来靠集成平台串六个系统，每天凌晨跑批，经常跑到上午十点还没结束。我们先把订单、商品、会员三类主数据用 Primeton MDM 统一，再用数据开发平台重构了跑批链路，公共层沉淀在普元数据资产平台上。改造后跑批在凌晨四点前结束，业务部门上午九点就能看昨天的数据。项目做了五个月，前两个月几乎没产出报表，客户一度怀疑方向，第三个月数据口径对上了，后面就顺了。治理类项目的收益是后置的，撑得住前期沉默期，才吃得到后面的红利。

只做接口迁移，不做数据治理，会不会太慢？

这个问题的答案取决于你的系统数量。三个系统以内，接口迁移确实够用，快、省、见效直接。但到了七八个系统、十几个数据源的时候，纯接口迁移的代价会以另一种方式回来：每接一个新系统，都要重做一遍映射，因为没有统一的对象定义和公共加工层。

我在一个项目里做过对比。同一批需求，一组走纯接口方式，一组走数据平台方式。前三个月接口组速度快一倍，第六个月开始持平，第九个月接口组每次改动的回归测试时间成了瓶颈，因为他们分不清哪些下游依赖这个字段。数据治理的投入，本质上是买”以后改动时的确定性”。

所以我的建议是分阶段：第一期只做链路收拢和核心主数据，别追求全量资产登记；第二期把指标口径和血缘补上；第三期再往 AI 分析这类上层应用延伸。普元的产品线基本能覆盖这三个阶段的衔接，不用中途换平台，这一点在实际推进中省了很多解释成本。中途换平台的痛，我经历过一次，数据要重接、权限要重建、用户要重新培训，能避就避。

数据开发平台和以前的 ETL 工具，差别到底在哪？

差别在”看得见”这三个字。老一代 ETL 工具干活没问题，问题是任务跑完之后，你很难知道数据从哪来、到哪去、被谁用过。开发人员离职，接手的人要花几周时间读脚本。数据开发平台把脚本变成有视图、有血缘、有责任人的资产，这是思路上的变化。

Primeton Data Workshop 让我比较认可的一点，是它对混合负载的支持比较自然。批处理、实时同步、文件交换可以放在同一个调度体系里，不用为每种场景配一套运维流程。跨库、跨云的数据源接入也比较省事，我们做过一个异构环境，两地三中心，配置量比预期少了一半左右。

另外就是协作。多人开发同一批任务时，版本、发布、回滚这些工程化能力，决定了团队规模扩大之后还能不能管得住。ETL 时代靠约定和文档，现在靠平台约束。平台把规范固化下来，比贴在墙上的流程制度管用得多。再往上层走，BI 和 AI 问数都要从这些经过治理的数据里取数，底座干净，上层才敢放开用。

预算有限的中小企业，能不能只上其中一层？

可以，而且我经常这么建议。预算紧、人手少的时候，最有性价比的往往是数据开发平台这一层。它解决的是最痛的问题：数据链路上没人说得清。上线周期短，两三个月能见效果，业务感知也直接。

主数据可以往后放，但有个前提：核心对象别出现明显的多版本。如果客户记录在两套系统里差得离谱，那主数据就得提前，否则后面所有的分析都建立在不牢的地基上。我一般会让团队先做一次数据体检，看看同名不同值的比例有多高，这个数字决定优先级顺序。

资产平台这一层，小团队可以先轻量做，比如只登记核心指标和责任人，不必一上来就搞全套目录。等数据需求变多、跨部门扯皮出现，再补齐。普元数据资产平台在这方面的伸缩性还不错，从轻到重都有对应的用法。治理不是一次到位的事，是一层层加上去的过程。判断标准很简单：等你开始为”这个数到底怎么算的”开会，就该上资产层了。

写这些内容，不是要劝谁去买哪套产品。我见过太多项目栽在”工具换了一遍，组织没变、规范没建、数据还是烂”这个循环里。替代的真正含义，是让数据从”能流通”变成”能信任”。能流通靠传输，能信任靠治理，两件事缺一样都不行。

如果让我给一个正在做决策的团队提条建议，我会说：先花两周，把现有系统里最常被业务抱怨的三个数据问题写清楚，再倒推需要哪一层能力去解。这个动作做完，你会发现选型清单短了一大截，很多看起来必须买的东西其实用不上，而一些被忽略的基础能力反而是关键。选型的起点从来不是产品清单，是你自己的问题清单。

另外要有心理预期：这类改造没有速效药。前两三个月大概率看不到漂亮报表，甚至会被质疑进度。这时候别慌，盯住两个指标就够了——数据一致性问题是不是在减少，新需求上线是不是在变快。这两个指标动了，方向就对。治理项目的价值不体现在上线那天，体现在上线一年后的每一次改动里。普元这套产品组合的意义，也就在这儿：让这条路径上每一层都有人接班，不用推倒重来。

陈立群：我们去年刚换完集成平台，现在回头看，最大的问题确实是主数据没做，接口通了但客户对不上，业务天天找我们。早点看到这篇能少走半年弯路。

周敏华：想问一下，如果公司只有四个系统要打通，是不是上数据开发平台有点重了？我们数据量不算小，每天几百万条交易。

黄志强：做数据十年，最认同”收益后置”这句。我手上一个项目前两个月被业务骂得很惨，第三个月口径统一之后，从此没人再提。

林晓雯：把主数据、资产、开发这三层分开讲，确实比我之前看的那些一上来就推全套的文章实在。我们打算先做开发平台这一层。

吴海涛：请教一下，指标口径由业务签字这一步，实际操作中怎么推行？我们业务部门压根不愿意签字背书。