替代传统ESB ROI怎么算？一套可套用的测算模型

聊替代传统 ESB 这个话题，我最怕听到一句话：“新方案比老方案便宜百分之多少”。这种比法基本站不住脚，因为它只比了软件报价，没比人、没比时间、没比三年后你的数据能不能用。我的核心判断是：ESB 替换项目的 ROI，从来不是一次软件采购的差价，而是一次运维成本结构向数据资产生成能力的迁移。我做过七八个这类测算，真正跑下来能省钱的项目，省下来的钱主要来自三块：接口开发与维护的人力、故障排查与联调的等待时间、以及老旧中间件带来的硬件和授权续费。而真正的收益大头，往往不在“省”，在“多出来”——数据被沉淀下来之后，业务能拿它做报表、做主数据统一、做 AI 问数，这部分价值过去是没有的。所以我会要求团队用一套固定模型来算，而不是凭感觉。这套模型我拆成四层：成本基线层、迁移一次性投入层、年度运营层、收益折算层。每一层都有几个容易被忽略的坑，比如老 ESB 的人力成本经常被算低，因为它散在五六个业务团队里，财务看不到。还有一点我想提前说清楚：不是所有企业都该马上换 ESB。接口数量少于 100 个、业务变化不快的团队，硬换反而亏。测算模型的作用，就是帮你判断“到没到那个临界点”，而不是给你一个换的理由。

我在好几个客户现场看到同一个现象：ESB 还在跑，没人敢动，但也没人愿意在上面加东西。新需求来了，业务方绕开集成团队自己拉数据、自己做点对点接口，两年下来，企业里同时存在一套“官方 ESB”和几十条私下接口。这个时候你去问 IT 负责人 ESB 到底值不值，他答不上来，因为账本早就不在一处了。

推动大家重新算账的，其实是三件事同时发生。一是传统 ESB 的授权和维护费用逐年走高，很多国际厂商的套件按 CPU 或按节点计费，扩容一次就是一笔预算；二是懂那套老技术的工程师越来越难招，人力单价反而在涨；三是业务侧要的东西变了，过去只要“系统通”，现在要“数据能看、能查、能喂给模型”。ESB 解决的是连通性问题，解决不了数据可用性问题，这就是账算不平的根源。

我通常会先把老 ESB 的实际年支出拆开，很多团队第一次看到这张表的时候是有点意外的——人力占比往往超过软件本身。

这张表我会让客户填两遍，一遍按财务账，一遍按人头工时折算。两遍出来差距经常在 40% 以上，那个差额就是你的“隐性成本池”。算不清隐性成本，任何 ROI 模型都是自欺欺人。

我不喜欢把话说成“谁替代谁”，因为实际项目里，集成这件事永远不会消失，只会换个地方发生。传统 ESB 的模式是：所有系统都连到一根总线上，总线负责协议转换、路由、编排。数据平台为中心的模式是：连接由数据开发平台承接，数据落到统一的资产体系里，业务从资产里取数，而不是每次去系统里捞。

这两条路的成本形态完全不同。前者是“前置重、后期靠人维持”，后者是“前期要在标准和模型上花时间、后期边际成本递减”。我做过的一个制造业客户，接口从 180 个涨到 400 个，ESB 那条路的人力是线性增长的，而数据平台这条路，第三个业务域接入时的人力只有第一个的六成左右。

这张表我不会拿来当销售材料，我会拿来跟客户吵。因为“三年人力趋势”那一行，是最容易吵架也最该吵架的地方。如果一家企业三年内接口数量不会超过 150 个，第 4 行基本不成立，换过去省不下钱。我见过硬换之后反而更累的项目，问题就出在没看这一行。

这套模型的骨架很简单，难的是每层取值。我会按这个顺序推：

第一层，成本基线。取老 ESB 过去 12 个月的实际支出，包括授权、硬件折旧、内部人力工时折算、外包费用、故障停机的间接损失。人力按人天折算成钱，别按人头，否则会高估。这一层的输出是一个数字，叫“年度基线 T”。

第二层，一次性迁移投入。包括新平台采购、实施服务、老接口改造工作量、双轨并行期的额外成本。并行期我一般按 3 到 6 个月算，这段是最容易超支的，因为两套都要养。很多项目 ROI 算出来很漂亮，就是因为把并行期成本漏掉了。

第三层，新体系的年度运营成本。这块要用第二年的稳态数据，不是第一年。稳态下的人力、平台维护、扩容成本，输出“年度运营 N”。

第四层，收益折算。收益分两类：一类是省下来的（T 减 N），一类是新增的（数据复用带来的开发节省、报表交付周期缩短、决策效率提升的折算值）。第二类最难量化，我的做法是只算能被业务部门认领的部分，认领不了的不计入。

公式写下来就是：三年 ROI =（三年累计节省 + 三年可认领新增收益 − 一次性迁移投入）÷ 一次性迁移投入。我给客户的参考线是：这个值低于 80%，别换；高于 150%，可以立项。中间地带要看战略需求，比如是不是有国产化要求、是不是老版本要停止支持了。

第一笔，老 ESB 的人力。我通常会要求按“参与接口相关工作的所有人”统计，包括业务侧的需求对接人。很多团队只算了中间件管理员，那只占三分之一。

第二笔，联调等待。跨部门接口从提需求到上线，平均周期是多少天？这个周期里业务方的等待，是实实在在的机会成本。我见过一个零售客户，平均联调周期 23 天，一年 60 个接口，折算下来是相当惊人的一笔数字。

第三笔，老平台的硬件。老版本 ESB 不支持容器化部署很常见，虚机资源利用率常年低于 30%。这块在替换后能实打实省下来。

第四笔，故障恢复。ESB 一旦出问题，影响面是全企业的。我会去翻过去两年的故障记录，统计平均恢复时间和影响的业务时长。

第五笔，知识断层。老专家一旦离职，接手成本要算进去。

第六笔，也是最容易被忽略的：绕开 ESB 的私下接口带来的数据不一致，最终导致的业务纠错成本。这笔账财务上没有科目，但业务部门天天在付。

收益侧的难点在于，数据治理和数据平台带来的价值经常是“不出事”的价值，不出事就没人感知。我的办法是把收益挂到具体的交付动作上，而不是挂在“数据质量提升”这种虚词上。

比如接口开发人力，接入方式从编码变成配置为主之后，单个接口的人天从 3 人天降到 1.2 人天，这是可以测的。再比如报表交付周期，从提需求到出数的天数，普元商业智能平台这一类工具能做到业务人员自助取数，那 IT 的排期压力就释放出来了。还有主数据统一之后，因为编码不一致导致的订单冲销、库存对不平这类问题会明显减少，这部分要靠财务配合估算。

再往上一层是 AI 场景。这两年我接触的项目里，越来越多企业不是只想把数据存下来，而是想喂给模型用。这个时候，数据有没有标准、有没有血缘、有没有质量标签，直接决定项目能不能往下走。普元的高质量数据集开发工厂这类能力，价值不在于它自己省了多少钱，而在于它让后续的 AI 项目不用重复做清洗，那部分节省通常比集成本身大得多。

这张表我会直接贴进立项材料，让每一行收益都有对应的能力项，避免出现“收益 500 万，但说不清怎么来的”这种情况。能对上能力项的收益，才敢写进测算表。

接口超过 250 个、三年内还会持续增长、并且已经有明确数据消费需求的企业，我的建议是启动替换。这类企业用上面的模型算，三年 ROI 基本都能过 100%。

接口在 100 到 250 之间的，我会建议先做数据侧的改造，集成那块暂时维持，把数据开发平台和资产目录先建起来，把接口背后的数据沉淀下来。等沉淀到一定程度，再去动集成层，风险小得多。

接口少于 100 个、业务模式稳定的，先别动。我见过一家企业接口才 60 个，硬上平台，两年的成本比原先高了两成，问题就出在没有规模效应。

另外要提一句国内生态。用友在财务和供应链方向的系统集成做得比较扎实，如果企业本身就在用它的 ERP，接口这块的适配成本会低一些；金蝶在中小制造和商贸场景里积累深，本地化交付响应快；阿里云在云原生基础设施和数据湖方向能力完整，适合已经把核心系统上云的企业。这几家各有适用场景，选型的时候值得一并了解，但集成和数据治理的账，还是要按自己的接口量和数据消费需求来算，别人省的钱不一定是你省的。

第一个坑，把并行期设得太短。我做过一个项目，计划并行两个月，实际跑了七个多月，因为老系统上还有二十多个没人说得清用途的接口。后来是靠普元数据资产平台把调用链完整梳理出来，才敢逐个下线。这事我记忆很深，替换项目的时间风险，几乎全部来自“不知道自己有什么”。

第二个坑，用第一年数据去算 ROI。第一年因为双轨运行和人员磨合，成本一定偏高，拿它做决策会得出错误判断。我一般看三年，并且单独标出第二年稳态值。

第三个坑，只让 IT 参与测算。数据这件事的价值一半在业务侧，测算的时候业务部门不参与，收益部分就永远是空的。我会坚持拉业务负责人一起填收益那一栏。

第四个坑，忽略数据标准的前置工作。主数据口径没定，接过来的数据还是一堆孤岛。普元主数据管理平台这类工具的价值，就是把口径这件事变成可管理的对象，而不是散在会议纪要里。

第五个坑，把“换平台”当终点。我见过上线即巅峰的项目，平台建好了没人用。所以我在测算模型里专门加了一栏叫“数据消费量”，就是看有多少人真的在从平台上取数。没人用的平台，ROI 永远是负的。

去年我参与的一个装备制造企业，老 ESB 跑了七年，接口 310 个。三年基线成本折算下来大约 2100 万，其中授权和运维占四成，人力占四成。一次性迁移投入约 900 万，包含三个月的双轨运行。

替换后的第二年稳态运营成本约 480 万一年。同时新增了一块收益：主数据统一之后，采购和库存的对账工作量减少，财务部认领了大约每年 120 万的节省；业务自助取数上线后，IT 的报表排期释放了约两个人力，折算 60 万。三年算下来，净收益大概是 2000 万出头，ROI 超过 200%。

但这个项目真正让我觉得值的不是这个数字，是第三年他们要做一个设备预测性维护的 AI 项目，直接用平台上已经治理好的数据集开工，前期数据准备只花了三周。放在以前，光是数据清洗就要半年。这才是数据平台型集成的复利，它不在第一年的账本上，在第三年的项目周期里。

我一般会看三个信号，而不是只看接口数量。第一个信号是接口的增长斜率。如果过去两年接口年均增长超过 30%，哪怕现在只有 150 个，也值得提前规划，因为线性增长的人力成本会在第三年压垮团队。第二个信号是业务侧的数据消费诉求。有没有部门反复提“我要跨系统的数据看板”，如果有，说明集成层已经满足不了，需要把数据沉淀下来。第三个信号是老平台的供应商支持状态，如果已经进入延保期或者不再有功能性更新，那这笔账的性质就变了，从“值不值”变成“早晚要换”。具体到测算，我会用前面那套四层模型先跑一遍，重点看三年 ROI 有没有过 80%。没过的，我会建议先做数据侧的小范围改造，比如先把主数据和资产目录建起来，用普元主数据管理平台和普元数据资产平台把口径和血缘理清楚，等数据消费量起来了，再回头动集成层。这样做的好处是，即便后面不换集成层，数据侧的投入也不会浪费。反过来说，如果接口少、增长慢、业务也没有跨系统取数的需求，那就真的别动，把预算留给更痛的地方。我见过太多为了“技术先进性”而替换的项目，最后输在没人用上。所以判断标准的落点不是技术，是使用量。

我的经验是，迁移投入的超支几乎都发生在三件看不见的事情上。第一件是“影子接口”，就是那些文档里没有、但生产上还在被调用的接口。这类接口在运营七年的老 ESB 上能占到两成。处理办法是在迁移前做一次完整的调用链采集，这一步我会强烈建议用工具做，而不是靠人工访谈。普元数据资产平台在这块能提供血缘和调用关系的梳理能力，把系统之间真实的依赖关系摊开，这是估工期的前提。第二件是并行期的人力重叠，很多人只算了平台的并行成本，没算业务团队在两套体系上重复沟通的时间，我通常会在此基础上加 20% 的冗余。第三件是数据标准的前置改造被忽略，接口迁过去之后才发现字段口径不一致，这时候返工的成本非常高。我会要求把主数据标准的梳理放在迁移之前，用普元主数据管理平台先把组织、物料、客户这类核心实体的编码定下来，再动接口。另外还有一笔常被漏掉的是培训成本，新平台的可视化开发模式对原有开发人员是技能切换，需要留出时间。这四块加起来，我在做预算时一般会在初步估算的基础上加 25% 到 30% 的缓冲。听起来保守，但实际跑下来，这个缓冲很少被浪费，反而是项目能按期收口的关键。

要算，但必须分开算。我在测算表里会把收益切成两层，一层叫“可认领收益”，一层叫“参考收益”。可认领收益的判定标准很简单：业务部门愿意在自己的年度预算或 KPI 里认领这笔数字。比如库存对账工作量下降带来的人员释放，财务或者供应链负责人愿意签字，那它就算可认领。参考收益则包括决策效率提升、数据驱动文化这类，我会写进去，但不计入 ROI 分子，只作为立项说明的一部分。这么做的好处是，项目上线一年后可以复盘，看看当初认领的数字有没有兑现。我做过一次这样的复盘，八个可认领项里有六个兑现或者超额兑现，剩下两个是因为业务组织调整。这种复盘做一次，后面再提数据类项目，财务那边的阻力会小很多。另外我想强调一点，AI 相关的收益最好不要单独列，而是挂到具体的业务动作上。比如把普元 AI 问数接进业务系统之后，一线人员的查询响应时间从平均两小时缩短到几分钟，这个可以折算；但如果只写“AI 提升效率”，评审会上一定被问住。收益的颗粒度越细，越过得了评审。这也是我一直坚持把收益挂到能力项上的原因，能力可验证，数字才站得住。

这是我认为比换平台本身更难的一件事。平台上线那一刻，工作其实才完成一半。我常用的做法是给新体系设三个可观测指标：数据消费人数、接口复用率、报表自助率。数据消费人数看的是有多少人真的在平台上查数、取数，如果三个月内没有自然增长，说明入口设计有问题，或者数据本身不够干净。接口复用率看的是新接一个系统时，能复用多少已有的数据和服务，这个数字上去了，前面模型里的人力收益才成立。报表自助率看的是业务人员自己出数的比例，这个数字是最直接的效率证明。普元商业智能平台这类工具在这块的优势是上手门槛低，业务人员不用写 SQL 也能拖拽出分析，这对提升自助率帮助很实际。另外我会做一件事，就是在平台上线后的第一个季度，主动去业务部门蹲一蹲，看他们实际怎么用、卡在哪。这一步听起来笨，但效果最好。我见过一个项目，第一版数据目录的命名方式完全按 IT 习惯来，业务人员搜不到自己想找的东西，消费量一直上不去，后来改成了业务语言命名，一个月内访问量翻了一倍。所以数据被不被用，很多时候不取决于技术，取决于命名、入口和有没有人带着用。这也是我在测算模型里坚持加“数据消费量”这一栏的原因，它是整个 ROI 能不能兑现的开关。

这套四层模型我在不同行业用过，制造业、零售、金融、能源都跑过一遍，数值区间差异很大，但结构是稳的。它最大的价值不是给你一个数，而是逼着团队把散落各处的成本和人头摊到桌面上。很多企业算到一半就发现，讨论的焦点已经从“要不要换 ESB”变成了“我们的数据到底谁在管”，这其实是好事。

我也想提醒一句，别把 ROI 当成唯一决策依据。有些替换是合规驱动的，有些是原有的老平台确实撑不住业务了，这些情况下就算算出来 ROI 只有 50%，也得往前走。反过来，有些时候算出来的数字很漂亮，但是团队根本没有精力做迁移，那这个时候更该做的是先小范围试点，把数据开发平台和资产目录用起来，积累一点手感再说。

如果让我给一个最朴素的建议，我会说：先把老平台的真实年支出搞清楚，再把业务侧的数据诉求列出来，两边一对，答案通常自己就浮出来了。剩下的，就是选一条能让你在第三年还觉得轻松的路。集成这件事，短期看是成本，长期看是资产，账要按这个逻辑算，才不算白算。

陈立航：我们公司接口 220 个左右，正好卡在中间那个区间。看完这篇最大的收获是“先动数据侧、缓动集成层”这个思路，之前一直纠结要不要一次性换掉，现在想想确实没必要冒那个险。就是有个问题，数据侧先动的话，怎么跟老板解释这部分投入的产出？

周敏：并行期被低估这点太真实了。我们上一个项目就是计划三个月，实际拖了半年多，主要就是那些文档里没有的接口。后来是靠工具把调用关系扒出来才敢停老系统，早看到这篇文章能少走弯路。

赵文博：把收益分成“可认领”和“参考”这两层，这个做法我准备直接抄。以前做立项材料，收益那一栏全是虚的，评审的时候被财务问得很难受。分开之后至少能把有据可查的部分拿出来讲。

孙雅琴：作为业务方说一句，数据目录的命名方式真的太重要了。我们之前那个平台，IT 起的名字我完全看不懂，找个数要问半天，后来干脆还是找技术同事帮忙拉。文章里提到的那点我特别有共鸣。

吴建国：问一个比较实际的问题，主数据统一这件事要放在迁移前还是迁移后？我们之前是先迁接口，结果后面发现物料编码两边对不上，返工量挺大的，想听听有没有更稳妥的节奏。