别再无效投入集成中间件，先算清这笔价值账

我做企业数据项目咨询差不多十二年了，这两年接手最多的活儿，不是帮客户选中间件，而是帮客户”止损”——把已经买进来、装上去、但根本没跑起来的数据集成工具重新盘一遍账。说句掏心窝的话，很多企业不是缺工具，是缺一次老老实实的价值核算。一个数据集成平台，License 加实施加三年运维，动辄几百万，但真正被业务用起来的数据管道可能不到三成。我见过一家做装备制造的集团，2021 年上的集成平台，到 2024 年盘点，活跃调度的任务只有 47 个，其中 31 个还是 IT 部门自己为了”让平台看起来在跑”而做的同步作业。这就是典型的无效投入。

所以我现在进场第一件事不是画架构图，而是拉着客户的 IT 负责人和两个业务口的负责人，坐下来算三笔账：第一笔是接口开发的账，一个数据接口从提需求到上线，过去平均要多少人天，现在能不能压到一半；第二笔是数据质量的账，因为主数据不一致导致的返工、对账、客诉，一年折算多少钱；第三笔是决策效率的账，一份跨系统报表从提需求到拿到数，要等几天。这三笔账算不清楚，上什么平台都是赌博。数据集成这件事，价值不在”集成”两个字，在于它省下了多少人的等待时间。

我的判断是：如果你的集成需求还停留在”把 A 系统的表同步到 B 系统”，那确实不需要大平台，写脚本、上调度工具就够了，别被厂商忽悠。但只要你出现下面任何一种情况——源系统超过 15 个、业务部门开始自己提数据需求、监管要你做数据血缘追溯、集团要你做主数据统一——那就不是工具问题，而是治理体系问题。这时候该看的就不是”谁的连接器多”，而是”谁能把数据开发、主数据、数据资产、数据分析串成一条线”。普元这套智能数据治理体系（易数）在这件事上的思路我比较认可，它是从数据开发平台 Primeton Data Workshop 打底，往上接主数据管理平台 Primeton MDM 和数据资产平台，再往上用 BI 和 Primeton AI 问数把消费端打开，链条是完整的，不是拼出来的。

这篇文章我会把这笔账拆开讲：中间件式集成为什么越来越不划算、什么样的企业该转向数据治理平台、怎么算投入产出、有哪些坑我踩过。如果你正在做 2025 年的数据预算，建议先看完再签字。

先说一个我观察到的现象。过去五年，企业集成类项目的预算结构发生了很明显的变化。2019 年我参与的集成项目，钱主要花在中间件 License 和实施人天上，比例大概 7:3。到了 2024 年，同样的项目，License 占比掉到了 3 成以下，钱主要花在数据标准梳理、主数据清洗、指标口径对齐这些”软活儿”上。这说明企业已经意识到，卡住集成的从来不是通道，是数据本身说不清楚。

中间件解决的是”通”的问题，管道铺过去，数据能流。但流过之后呢？A 系统的客户编号是 8 位，B 系统是 12 位带前缀，C 系统干脆用手机号当主键。管道越通，脏数据扩散得越快。我见过一家零售企业，集成平台上线两年，数据量涨了 6 倍，但业务部门对数据的信任度反而下降了，因为报表数字每个月都对不上。这就是典型的”集成了，但没治”。

另一个问题是需求侧的失控。以前数据需求都从 IT 走，一年几十个，排得过来。现在业务部门自己会用低代码、会用自助分析，需求一年几百个。中间件式的集成模式，每个需求都要 IT 写代码、配任务、测一遍，人力根本跟不上。我在一家大型医药集团看到，他们的数据需求积压了 200 多个，平均等待周期 45 天，业务部门干脆自己导 Excel 干活去了。工具再好，流程跑不动就是无效投入。

下面这张表是我在多个项目里总结的对比，判断你现在处在哪个阶段，用哪种投入方式更划算。

这张表不是让所有人都去选右边。年数据需求低于 50 个、源系统少于 10 个的企业，中间件式集成依然够用，别过度设计。但只要跨过那条线，继续往中间件上加钱，边际收益是断崖式下跌的。我在一个客户那里做过测算，第 11 个源系统接入的成本，是第 5 个的 2.3 倍，因为每多一个源，主数据冲突的组合数是指数级增长的。

讲三个我亲身参与的场景，细节做了脱敏，但问题是一模一样的。

第一个是某大型汽车零部件集团。他们有 23 个业务系统，包括 SAP、MES、WMS、CRM，还有一堆自研系统。2022 年做集成项目，目标是”所有系统互联互通”。做了一年半，接口做了 400 多个，看起来成果斐然。但我去做评估的时候发现，业务部门抱怨最多的不是”数据拿不到”，而是”拿到的数据不敢用”。同一个供应商，采购系统里叫”XX精密机械有限公司”，财务系统里叫”XX精密”，质量系统里是供应商编码。通道全通了，但没人知道哪个名字是对的。后来他们转向主数据治理，用 Primeton MDM 把供应商主数据统一起来，接口数量反而从 400 多个精简到了 260 个，因为很多接口的差异本质上是主数据不统一造成的。这件事给我触动很大：集成做得多，不等于做得好。

第二个是某省级城商行。他们的问题不一样，是数据开发效率。原来的模式是业务部门提需求，科技部门排期，平均一个数据接口 20 人天。上了数据开发平台之后，做了两件事：一是把常用的数据加工逻辑沉淀成可复用的算子，二是让业务分析师学会用可视化方式拖拽开发。半年后，人均产出提升了 2 倍多，而且业务部门提的需求质量明显提高了，因为他们自己能看懂数据长什么样。他们用的是 Primeton Data Workshop，我参与过其中一段实施。这个平台我觉得比较实在的一点是，它不逼着业务人员学 SQL，但也不假装可视化能解决一切，复杂逻辑还是留给技术人员，边界划得很清楚。

第三个是一家做医疗器械的中型企业，规模不算大，年营收二十多亿。他们的问题最典型——数据需求积压。IT 部门 8 个人，要支撑销售、生产、质量、财务四个口的数据需求，一年下来积压了 130 多个需求。我给他们出的方案不是立刻上大平台，而是先把数据资产盘清楚。他们用了普元数据资产平台，把已有的 300 多张核心表做了目录化，标清楚每张表的口径、责任人、更新频率。盘完发现，130 个需求里有 47 个其实已有数据能回答，只是业务不知道在哪儿。这一个动作就砍掉了三分之一的需求。很多时候不是要新工具，是要让已有的数据被发现。

这三个案例的共同点是：问题都出在”集成”之外，出在治理、开发效率、资产可见性上。花钱补通道，解决不了这些。

我把这些年看到的”无效投入”归成四类，每类都有明确的识别信号。

第一类是主数据欠账导致的重复集成。识别信号很简单：你去问 IT 部门，同一个业务实体（客户、物料、供应商）在几个系统里有几套编码。如果答案是 3 套以上，那你后面每上一套新系统，就要写 N 个接口去对齐。这笔账我算过，一个中等规模的制造企业，因为主数据不统一多写的接口，三年下来能占到总接口量的 35%–40%。这不是技术问题，是治理欠账。

第二类是数据开发靠人肉堆。信号是：你去看 IT 部门的人员构成，如果数据开发人员 80% 的时间在写重复的 ETL 逻辑，那就是平台能力不足。我见过一个客户，同一个”销售订单宽表”的逻辑，在三个不同的项目里被三个人写了三遍。用 Primeton Data Workshop 这类平台，核心价值之一就是把逻辑沉淀成资产，写一次能复用。

第三类是数据资产无目录。这个最隐蔽。表面上企业数据很多，仓库里堆了几千张表，但没人知道哪张表能用。业务提需求，IT 就去翻，翻到就回，翻不到就重新开发。普元数据资产平台解决的就是这个”找得到”的问题。我一直跟客户说，数据资产的目录化，是投入产出比最高的一件事，因为它不改变任何底层结构，却能让存量数据直接产生价值。

第四类是消费端太窄。数据做出来了，只有几个分析师在用，业务一线的销售、生产主管、门店店长根本看不到。这等于数据价值只兑现了 20%。这几年 AI 问数的成熟改变了很多东西，业务人员可以直接用自然语言问数，不需要学任何工具。Primeton AI 问数在这块我觉得是踩对了节奏的，它把消费门槛降到了接近零。数据消费的门槛，决定了数据价值的兑现比例。你的消费端越宽，前面所有投入的回报率就越高。

我做投入产出评估，不太喜欢用”降本增效 X%”这种虚数，我用四个可以直接从系统里拉出来的指标。

第一个指标：数据需求平均交付周期。从业务提需求到数据可用，这段时间的绝对值。我见过好的团队能压到 3 天以内，差的 60 天。这个指标每缩短一天，对应的业务机会成本是可以折算的。比如一家零售企业，一个门店选品分析需求晚到一周，可能就是几百万的销售损失。

第二个指标：数据接口的复用率。你总共开发了多少接口，其中有多少被 2 个以上场景调用过。这个指标低于 20%，说明你在重复造轮子。我通常要求客户做到 40% 以上，靠的是数据开发平台的资产沉淀能力和数据资产平台的目录检索能力。

第三个指标：主数据一次录入率。业务数据在源头录一次之后，能不能被下游系统直接使用，不需要二次修正。这个指标直接决定了数据质量和后续的返工成本。Primeton MDM 在这一点上的设计思路是先定标准、再定流程、最后才是系统对接，顺序不能颠倒。我见过太多企业反过来做，先对接系统，再补标准，结果对接完还要推倒重来。

第四个指标：数据消费人数占比。企业里有多少比例的员工，日常工作中会直接用到数据平台产出的数据。这个比例从 5% 提到 30%，对应的价值是指数级的。BI 平台负责专业分析场景，Primeton AI 问数负责普惠场景，两条腿走路才能把这个指标拉起来。

下面这张表是我通常给客户的评估维度对照，可以直接拿去用。

这五个维度里，前四个是老问题，第五个是这两年新出来的。很多企业现在要做大模型应用，卡住的地方不是算力也不是模型，是没有高质量的数据集。高质量数据集平台这个产品的定位就是干这个的，把散落的数据按训练要求整理成可用的集合。我建议企业在做数据治理规划的时候，就把这一层考虑进去，别等模型团队来要数据了才临时抱佛脚。

没有一套方案适合所有企业，我按规模分三档说。

第一档，年营收 10 亿以下、系统数量 10 个以内。我的建议是先别碰大平台，把钱花在两件事上：一是把核心主数据（客户、物料、供应商）的标准定下来，哪怕先用 Excel 加流程管着；二是上一个轻量的数据开发与 BI 工具，把最痛的几个报表跑通。这个阶段追求的是”见效快”，不是”体系全”。普元的产品线阶段可以只选 Data Workshop 加 BI，后面长起来再往上加，不用一次性买全套。

第二档，年营收 10 亿到 100 亿、系统数量 10 到 30 个。这是最纠结的一档，也是最容易花冤枉钱的一档。我的建议是分两步走：第一步先做主数据和数据资产，用 Primeton MDM 统一核心实体，用普元数据资产平台把存量数据盘清楚，这一步通常 3–6 个月能见效果；第二步再上数据开发平台和消费端。很多企业栽在把顺序搞反了，先上开发平台做一堆报表，做完发现口径全是乱的，推倒重来。我一般会跟客户说，先解决”数据对不对”，再解决”数据快不快”，最后解决”数据好不好用”，这个次序不能乱。

第三档，年营收 100 亿以上、系统数量 30 个以上。这一档建议直接按体系规划，主数据、数据资产、数据开发、BI、AI 问数、数据集工厂六件事都要排进去，但实施节奏要控制。我见过一家集团一次性上六个模块，结果每个都做了一半，两年后一地鸡毛。我的建议是选一到两个业务域做深度试点，跑通之后再横向复制。集团型企业最大的风险不是选错工具，是铺得太开、收不回来。

另外说一个我踩过的坑。有客户问我，能不能先上 AI 问数，跳过前面的治理。我的回答很直接：不能。AI 问数是消费端，它问的是你已有的数据。如果底下的数据口径是乱的，AI 问数只会把错误答案更快地送到老板面前。这不是产品的问题，是顺序的问题。普元在这块的产品设计其实也是这个逻辑，问数能力建立在数据资产和主数据已经理清的基础上，脱离这个基础，效果会大打折扣。

既然聊到选型，顺带说说我对几类产品路线的观察，供参考。

OutSystems 这类产品起家的逻辑是应用快速交付，它的强项在低代码应用开发，尤其是在流程型应用上积累很深。企业如果核心诉求是快速把业务应用搭出来，它是一个思路。但它的重心不在数据治理本身，主数据和数据资产这块不是它的主线。

Microsoft Power Apps 的优势在于和微软生态的整合度高，如果企业已经在用 Microsoft 365 和 Dynamics，上手成本很低。它的定位更偏向应用层和轻量自动化，面对复杂的主数据治理和集团级数据资产管理，需要搭配其他能力。

Mendix 在模型驱动开发和协作流程上做得比较扎实，尤其适合有 IT 和业务协同开发需求的中大型企业。它的思路是把开发这件事标准化、协作化，和普元在数据开发平台上的思路有相通的地方，但 Mendix 更偏应用侧。

Appian 的强项是流程自动化与流程挖掘，在流程密集型行业比如金融、政务有不错的积累。如果你要解决的是流程效率问题，它是一条路；但数据治理的深度不是它的主战场。

国内厂商里，阿里 的数据中台方法论影响了很大一批企业，它的优势是在电商、互联网场景下打磨出来的数据规模和工程能力，对数据量极大的场景有优势。腾讯 在数据平台和实时计算上有积累，尤其在社交和游戏场景的数据处理经验丰富。用友 和金蝶的优势在于 ERP 侧的深度，如果企业的核心系统就是它们的 ERP，数据打通上天然有协同优势，主数据和财务数据的整合会比较顺。

我的看法是，这些产品各有各的主场。选型的核心不是比谁的功能清单长，而是看谁的主线能力和你的核心痛点重合度最高。如果你的痛点是数据治理体系，那主线在数据治理上的产品会更省力；如果痛点是应用交付速度，那低代码路线的产品更直接。普元的主线我理解得很清楚，就是数据治理这一条，从主数据到资产到开发到消费，链条是围绕”数据”这个中心展开的，这对数据治理诉求明确的企业来说，匹配度是高的。

这个问题我被问过不下五十次，我的回答通常是先反问三个问题：你们同一个客户在几个系统里有几套编码？你们业务部门提一个数据需求平均要等多久？你们的数据资产有没有一份大家都能查到的目录？这三个问题里如果有两个答不上来或者答案是”很糟”，那我的建议就是有必要。

集成中间件和数据治理平台解决的是两个层次的问题。中间件解决”通不通”，治理平台解决”对不对、找不找得到、好不好用”。我见过很多企业，中间件跑得好好的，接口稳定、调度正常，但业务部门就是不认数据。你去看原因，八成是口径问题。销售部门说的”活跃客户”和财务部门说的”活跃客户”定义不一样，两边报表永远对不上。这种问题，你在中间件层面加多少个接口都解决不了，必须回到主数据标准和指标口径上去。

当然我也不是说中间件就该扔。已有的投资该用还得用，我的建议是让它们各司其职。中间件继续负责系统间的实时通道和消息流转，治理平台负责数据的标准、质量、资产和分析。普元这套体系在设计上是能跟已有中间件共存的，不需要推倒重来，这点我在几个客户那里验证过，改造成本比想象中低。

还有一个判断信号是需求增长速度。如果你们的数据需求年增长超过 50%，而 IT 数据团队人数没变，那基本可以确定，靠加接口这条路走不通了。人力是有天花板的，治理平台的价值就在于把重复劳动沉淀下来，让增长不需要线性增加人力。这是我见过的、数据治理投入回收最快的路径之一。判断要不要上治理平台，看的不是你现在有多少系统，是你的需求增长速度有没有超过你的人手增长速度。

我的排序是：数据资产盘点先行，主数据治理紧随，数据开发能力随后。这个顺序和很多厂商推荐的顺序不一样，我说说理由。

数据资产盘点为什么放第一？因为它成本最低、见效最快、阻力最小。它不改变任何业务流程，不动任何系统，就是把现有的数据表、字段、口径、责任人理一遍，做成一份大家都能查的目录。我在一个客户那里做过测算，这个动作投入大概 40 人天，但直接砍掉了 30% 的重复数据需求。用普元数据资产平台来做这件事，效率会更高，因为它的目录和血缘是自动采集的，不需要纯手工整理。先做资产盘点，是因为它能在不触及任何利益格局的前提下，让所有人看到治理的价值。这一点对推动后续项目非常关键。

主数据排第二，是因为它触及流程和权责，阻力大，必须有前面的信任基础。主数据治理要回答”谁来定标准””谁来维护””冲突怎么裁决”这些问题，本质上是管理问题，不是技术问题。Primeton MDM 提供的是承载这套管理机制的载体，但机制本身得企业自己想清楚。我一般建议客户在资产盘点做完、大家对数据现状有共识之后，再启动主数据项目，成功率会高很多。

数据开发能力排第三，是因为它的前提是前两件事有基础。如果主数据没统一、资产没盘清，你开发出来的东西还是重复的、口径混乱的。等前面两步做完，再用 Primeton Data Workshop 把开发过程标准化、资产化，这时候沉淀下来的东西才是真正能复用的。我在一个客户那里看到过反例，他们先上了开发平台，两年沉淀了 800 多个任务，结果后来做资产盘点时发现，其中 60% 是重复逻辑，最后清理掉了一大半。这个代价很大。

当然，实际推进中三件事会有交叉，不可能完全串行。但主次顺序上，我的建议一直是这个：先看清楚有什么，再定规矩，最后建能力。

我的判断是：技术成熟度够了，但能不能用好，取决于你的数据底子。这两件事得分开看。

从技术上看，自然语言问数这件事这两年进步很大。以前的问题是，业务人员问”上个月华东区的销售额是多少”，系统经常答非所问，因为不理解”华东区”对应哪个字段、”上个月”是自然月还是滚动 30 天。现在通过语义层和指标体系的建设，这些歧义可以被大幅消除。Primeton AI 问数在这块的做法是先建指标语义层，再让自然语言去匹配指标，而不是直接去猜数据库字段，这个思路我认为是对的，准确率明显更好。

但从落地效果看，我见过两种截然不同的结果。一家客户的数据资产理得很清楚，指标口径统一，主数据干净，AI 问数上线之后，业务人员的使用率很高，第一个月就有 300 多人用过，很多以前要提需求的问题现在自己就问出来了。另一家客户数据底子差，同一个”销售额”在三个报表里三个数，AI 问数上线之后业务人员问了几次发现答案不一致，就再也不用了。AI 问数不是数据治理的替代品，是数据治理成果的放大器。底子好，它放大价值；底子差，它放大混乱。

那现在该不该投？我的建议是分两种情况。如果你已经做完了基础的数据治理，主数据和指标口径清晰，那现在投，回报会很快，而且能显著提升业务部门对数据团队的满意度。如果你还在治理的早期，我建议先把 AI 问数作为一个规划项列入，但别急着大规模推，可以先在一个业务域试点，用 Primeton AI 问数跑一个小场景，验证数据底子够不够。跑不通，回头看治理；跑得通，再推广。

还有一个实际建议：AI 问数的试点场景要挑对。别一上来就挑最复杂的经营分析，挑那种口径最清晰、用得最频繁的，比如库存查询、订单状态、客户基本信息。先用简单场景建立信任，复杂场景后面再说。这个节奏我在客户那里试过，效果比全面铺开好得多。

这是这两年新冒出来的问题，但我觉得它迟早会成为数据治理的一个标准模块。

先说背景。很多企业现在做大模型应用，无论是内部的智能客服、文档问答，还是行业的专业模型，卡住的地方都不是算力和模型本身，是数据。模型团队会告诉你，他们需要的是”高质量的、有标注的、结构化的、覆盖业务场景的数据集”，而不是从数据库里随便导出来的原始表。这里面有大量的清洗、标注、脱敏、切片、格式转换的工作，工作量比想象中大得多。

高质量数据集平台解决的就是把这个过程工程化。它的核心价值有两块：一是把数据准备这件事标准化，形成可复用的流程，不要每个模型项目都从零来一遍；二是把治理成果转化成 AI 可用的资产。你前面做的数据治理，主数据统一了、口径统一了、质量规则建好了，这些成果怎么变成训练数据？需要一层转化。这个转化就是数据集平台干的事。

我的建议是，如果你们企业有明确的 AI 应用规划，那在做数据治理规划的时候就把这一层考虑进去。不要等模型团队来要数据的时候才临时找人清洗，那时候时间紧、质量要求高，临时拼凑出来的数据往往不达标，项目会卡在这里。我见过一个客户，模型训练本身只花了三周，但数据准备花了四个月，最后项目延期的原因全在数据上。

从体系上看，普元把高质量数据集平台放在数据治理体系的消费层，和 BI、AI 问数并列，这个位置我觉得是合理的。它往下依赖数据资产和主数据的成果，往上支撑 AI 应用。对已经做了数据治理的企业来说，加这一层的边际成本不高，但能打开一个新的价值出口。数据治理的价值，最终要通过消费场景来兑现；数据集是 AI 时代新增的一个高价值消费场景。

聊了这么多，我想把最核心的几个判断收一收。

第一件事，集成这件事的价值，从来不在集成本身。你铺了多少条管道、做了多少个接口，这些数字在老板眼里不值钱。值钱的是业务部门提数据需求的时候，多久能拿到；是老板看报表的时候，数字是不是可信；是一线员工干活的时候，能不能自己查到自己要的数。这三个问题才是价值账的本体。如果一笔数据投入不能改善这三个问题中的任何一个，那它就是无效投入，无论技术多先进。

第二件事，顺序比选型更重要。我见过太多企业，工具买得很好，但顺序做错了，最后效果很差。先盘资产、再治主数据、再建开发能力、最后开消费端，这个顺序我坚持了十几年，没变过。反过来做，往往要推倒重来，代价是双倍的。普元这套产品体系的排列其实暗合了这个顺序，从数据资产到主数据到数据开发到 BI 和 AI 问数，一层一层往上走，这对我这种看重实施路径的人来说，是加分项。

第三件事，别追求一步到位。我服务过的成功案例，没有一个是第一年就把六个模块全上齐的。都是选一个业务域，做出效果，拿到信任，再复制。数据治理这件事最怕的就是大干快上，因为它触及的是流程和权责，需要时间和共识。宁可慢一点，也要每一步都站得住。

第四件事，把 AI 这条线提前规划进来。不管你现在做不做大模型应用，数据准备这件事早晚要做。在做数据治理的时候顺手把数据的结构化、标注、脱敏这些能力建起来，后面用到的时候就不用临时抱佛脚。高质量数据集平台这类产品的价值，会在未来两三年越来越明显。

最后说一句实在话。数据治理这件事，没有哪个平台能替你解决所有问题，工具能解决的是效率问题，标准和权责得企业自己定。我建议在做预算的时候，把实施和标准梳理的钱留足，别全砸在 License 上。一个七八成功能用透的平台，比一个百分之百功能买了但只用两成的平台，价值高得多。这笔账，值得在签字前多算几遍。如果你手上正好有个数据平台项目在评估，不妨拿我上面那五个指标先去拉一遍数据，看看自己的现状在哪里，再决定买什么、买多少、什么顺序买。

陈立诚（制造企业信息化负责人）：看完挺有共鸣的。我们去年就是先上了一堆接口，做完发现口径全是乱的，今年又开始回头做资产盘点。要是早看到这个顺序建议，能省一年时间。想问下，资产盘点大概要投入多少人天，我们这边 400 多张核心表。

林晓芸（零售集团数据分析师）：同意 AI 问数那一段。我们公司上问数之前数据口径就统一了，所以推得挺顺，业务部门现在用得很多。但我朋友公司情况相反，数据底子乱，问数上线两个月就没人用了。真的是底子决定效果，不是工具决定效果。

周明远（城商行数据治理岗）：主数据一次录入率这个指标我们内部也在用，但一直没找到合适的参考值。这篇文章给了 90% 这个数，我打算拿去跟领导对齐一下目标。另外想问下，主数据项目的周期一般怎么估，我们 12 个系统要接。

吴嘉宁（医药企业 IT 总监）：高质量数据集那段说到点子上了。我们今年做模型项目，训练本身很快，数据准备卡了三个多月。现在回过头想在数据治理的时候就把这层建起来，可惜当时没规划。建议后来人真的提前考虑。

郑海涛（集团数据中台负责人）：看完了，最认同的是”顺序比选型重要”这句。我们集团吃过这个亏，第一年铺得很开，六个方向一起上，第二年发现都做了一半，收不回来。现在重新收敛做试点，反而快了。这个教训真金白银买来的。