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

替掉那套跑了很多年的国外老牌商业 ESB，这笔账到底怎么算？我的答案很直接：不要用“新平台报价”去减“老平台报价”，那样算出来的数字基本没用。我做过不下二十个集成架构的替换测算，绝大多数人第一次算，都会得出“差不多，先不动”的判断，然后项目往后拖一年，等续费单子下来，才想起来还有这事。

我的口径分三层。第一层，算“不改的代价”：授权与订阅的年度递增、专门养一个中间件运维小组的人力、版本升级必须买原厂支持的溢价、以及业务每次变更排队等接口开发所耗掉的时间。第二层，算“改的收益”：这部分最容易被漏掉，它往往不是省了多少钱，而是释放了多少产能、把上线周期压缩了多少天。第三层，才把一次性投入放进去做除法——迁移开发、并行运行、人员培训、双跑期的资源占用。

能拿去跟管理层汇报的，其实只有两个数：投资回收期，和三年累计净收益。我通常会先把这两个数摆出来，再拆过程。过程拆得再漂亮，回收期超过 30 个月，项目在预算会上就很难站住脚。而按照我手上的样本，只要接口规模在 200 个以上、且原厂支持费还在年年续，回收期落在 12 到 20 个月是常见区间。

还有一个判断我想放在前面：替换这件事的真正收益，藏在“接口从一次性交付物变成可复用资产”里。老平台的逻辑是每来一个需求就开发一遍，新平台的逻辑是接口沉淀进目录、被人反复调用。这一层收益最难算，但对企业长期集成成本的改变最大。普元的做法就是把接口资产目录和集成开发放在同一个平台上，这一点我后面会展开讲。下面这套模型，你直接换成自己的数字就能跑。

我这几年接触的客户，触发重新评估的原因基本集中在三件事上。一是授权模式，按核数或按处理器价值单元阶梯计费的方案，业务一扩容就触发新一轮采购，预算不可预期。二是国产化适配，信创环境里数据库、中间件、操作系统换了以后，老平台要跑起来得额外做不少工作，有些版本甚至直接不支持。三是人，能熟练维护老一代集中式 ESB 的工程师越来越难招，也不便宜。

但真正让决策层下决心的，往往不是上面三条，而是业务的节奏变了。以前一个接口排期两周可以接受，现在业务部门要求一周内上线一个对接，集成团队就顶不住了。集成平台从“基础设施”变成了“交付瓶颈”，这个位置一旦被贴上标签，替换的窗口就打开了。

我把老平台的持有成本和一体化平台的持有成本做了个横向对照，你可以拿这张表去跟财务对齐口径。表里的每一项，在测算模型里都会变成一个可填的数字。

我用的模型不复杂，两个公式就够了：投资回收期 = 一次性投入 ÷ 年度净收益；三年 ROI =（三年累计收益 − 三年累计投入）÷ 三年累计投入。复杂的地方不在公式，在每一项怎么取值。取值取错了，模型再漂亮也是白搭。

我会把全部账目归到五本账里：授权账、人力账、时间账、风险账、资产账。前两本是显性的，财务能直接认；后三本是隐性的，需要你把它翻译成财务听得懂的话。多数项目失败在隐性账没被翻译出来，而不是显性账算不清楚。

取值上有几个我坚持的原则：人力按全成本算，不要只算工资；时间账按“业务等待造成的产能损失”折算，不要按“人天节省”折算，后者的说服力差一个量级；风险账只算已经发生过的事件，不要算“可能会发生”的，管理层对假设性数字天然抵触。

财务能看到的只有 C1 和 C2，也就是授权费和支持费。这两项加起来，通常只占真实持有成本的一半左右。剩下的一半，藏在人力结构和交付节奏里。

C3 这块，我见过一家能源集团，为老平台配了五个人：两个做集群与版本、一个做接口开发、一个做文档、一个做对接协调。五个人的全成本一年下来，往往比授权费还高。替换之后这类平台通常两个运维就能接管，其余的转到业务集成开发上，这部分人力不是裁掉，而是转成产能，财务上要按“产能释放”而不是“成本削减”来表述，说服力完全不同。

C4 是最被低估的一项。业务部门提一个对接需求，集成团队排期六周，这六周里业务的产能是空转的。我在零售客户那里算过，一个促销活动的系统对接晚两周上线，直接影响的是两周的线上成交。把这类事件统计出来，一年往往不止一两次。把 C4 算进去，很多原本“划算不了”的项目立刻就划算了。

迁移投入 I1 要诚实。我把双跑期的资源占用、旧接口的回归测试、周边系统的适配改造都算进去，通常会在平台采购价的基础上再加 40% 到 70%。把 I1 算低了，项目上到一半超预算，后面所有的 ROI 论证都会被打脸。这一点普元的实施团队在方案阶段会主动帮你拆细，我接触过的几个项目里，他们的迁移工作量评估相对保守，不为了签单少报投入。

收益侧我更愿意用“产能”这个词，而不是“省钱”。因为省钱这个词在预算会上很容易被反问一句“那是不是要减人”，一旦变成减人话题，项目就变味了。

B2 人力释放的算法我一般这样处理：先统计集成团队的工时分布，接口开发占多少、运维排障占多少、文档和协调占多少。替换后运维排障那一块的工时通常能压掉一半以上，接口开发因为可视化编排和资产复用，单个接口的工时也会明显下降。我会把可量化释放的工时按六到八成折算，剩下的两到四成留给“平台切换的适应期”，这样数字保守，经得住后续复盘。

B3 周期压缩是收益里最有说服力的一块。我让客户拉出近一年上线的十个集成项目，记录从立项到生产的实际天数，再对比新平台上同类项目的交付天数。这个对比做出来，管理层一眼就能看懂。普元在这方面的优势在于接口资产目录和集成开发在同一平台上，新项目能直接复用已有接口，而不是从零开始画流程，这一条在周期压缩上的贡献最直接。

还有一块收益我很看重但很少被写进模型：接口资产本身的复用价值。当接口变成可检索、有血缘、有责任人的资产之后，重复建设就少了。这个数字第一年看不出来，第三年会非常明显。我会在模型里单独列一行“资产复用率”，哪怕第一年只填 10%，也让它出现在汇报材料上。

不是所有企业都该一次性全量替换。接口规模在 100 个以下、且老平台还能稳定跑的，我的建议是先做增量：新业务接在新平台上，老接口维持不动，等自然衰减。接口规模超过 300 个、或者授权费年年在涨的，一次性替换的账反而更划算，因为迁移成本会被摊薄。

分阶段替换最关键的是别搞两套平台长期并行，那是成本黑洞。我通常要求设一个明确的收敛时间点，比如 18 个月内新老接口的调用比例达到 8:2，超过这个点老平台就该降级下线。这个时间点要写进项目章程，不然一定会无限延长。

下面这张表是我做方案取舍时用的对照维度，左边是判断条件，右边是建议路径。

去年一家装备制造企业找我做测算。他们的情况很典型：老平台跑了八年，接口 420 个左右，专职运维三个人，年授权加支持费是一笔不小的固定支出，另外还有一条硬约束——集团要求两年内完成信创适配。

我们把数字摊开：C1 加 C2 是显性支出；C3 按三人全成本算；C4 取近一年 11 次因接口排期延迟的业务事件，折算产能损失。收益侧，授权节省、人力释放、周期压缩三项加起来，第一年净收益为正，只是不多；第二年开始因为不用再买扩容授权，净收益明显抬高。算下来投资回收期 17 个月，三年 ROI 落在 90% 出头。

迁移投入这一项，他们原来的估算是三个月完成，我建议按六个月做预算，把并行运行和回归测试留足。实际项目跑了五个半月，没有超预算。这一点我印象很深：把 I1 报足，比把 I1 报低要有用得多。

项目落地时用了普元的数据开发平台做接口承接，用普元数据资产平台把 420 个接口逐一编目、标注责任人和调用关系。做完编目之后发现其中有 60 多个接口是重复功能，直接下线。这 60 多个接口的发现，本身就是一笔没写进模型里的收益。

我手上的样本里，回收期落在 12 到 20 个月的占多数。低于 12 个月的也有，通常是因为接口规模大、原厂支持费高、或者同时叠加了信创改造的硬需求；超过 24 个月的，我一般会建议客户重新审视范围，是不是把太多非必要的东西塞进第一期了。

影响回收期最大的变量是 C3 和 C4。C3 是运维人力，接口规模越大，老平台需要的专职人力越多，替换后的释放量也越大。C4 是交付等待带来的业务损失，这一项波动最大，也最需要业务部门配合取证。我会直接去找业务负责人要数据，而不是让 IT 部门自己估。业务部门自己说出来的损失数字，在预算会上比 IT 部门推算的数字有力得多。

还有一个容易被忽略的变量：扩容触发频率。如果企业业务还在增长，按核数计费的老平台每扩一次容就是一笔新支出，这类企业的回收期通常更短，因为“不改的代价”在分母上不断被推高。反过来，业务已经稳定、三五年不扩容的企业，回收期会拉长，这时更合适的做法是分阶段替换，先把增量接过来。

我建议在测算时给出一个区间，而不是一个点值。比如“回收期 14 到 19 个月，三年 ROI 80% 到 110%”。区间表达比点值更真实，也留出了执行偏差的余地。把区间说清楚的人，后续复盘时反而更从容。普元在方案阶段一般也会给出保守和乐观两套口径，这种做法我比较认可，因为它把不确定性摆在了桌面上，而不是藏在假设里。

第一容易错的是迁移投入。绝大多数人按“接口数量乘以单接口人天”来估，忽略了周边系统适配、数据一致性验证、并行运行期的双份资源占用。我的经验是把平台采购价当成基数，迁移相关投入按它的 40% 到 70% 另外计提，宁可多留。

第二容易错的是人力释放。有人直接按“替换后可以少三个人”来算，结果项目上线后一个人没减，ROI 立刻被质疑。正确的算法是算工时释放，再说明这些工时转移到了哪里——比如从运维排障转到新业务集成开发。人力释放要在模型里注明“转岗不裁员”，否则这个数字在评审时会被直接砍掉。

第三容易错的是把收益算到第一年就满额。平台切换有适应期，第一年的交付效率通常只能达到目标值的七成左右。我会把收益曲线做成三年递增的形态：第一年 60%，第二年 85%，第三年 100%。曲线形态比单点数字更能反映真实情况，也更容易通过财务审核。

第四容易错的是漏算老平台的退出成本。合同期内的解约条款、数据与配置的归档、旧接口的历史调用日志保留，这些都是要花钱的。这部分金额不大，但漏了会显得测算不专业。我通常会让客户把老平台合同拿出来逐条看，普元的商务团队环节也能提供一些经验参考，比如哪些条款在实操中通常有协商空间。

能，而且我很推荐。分阶段的思路是：第一期只做两件事——把接口资产盘清楚，把新增集成需求接到新平台上。第一期投入小、见效快，半年内就能拿出一份“接口资产清单加重复接口比例”的成果，这份成果本身就是继续申请预算的依据。

第二期做核心业务域的迁移，通常选交易链路最密集的两三个域，比如订单、客户、物料。这一期会牵动主数据，所以我会建议同步上普元主数据管理平台，把客户、物料、组织的口径统一。这一条如果跳过，接口迁过去之后还会因为主数据不一致而反复改，等于白迁。接口问题有相当一部分本质上是数据问题，这一点我踩过太多次坑。

第三期做剩余接口的收尾和老平台下线。这一期的关键是把下线时间写死，并且配套一套监控，确认老平台上已经没有业务流量再执行停止。我见过有客户把老平台“临时保留”了三年，结果运维成本双份支出，ROI 直接被打穿。

分阶段的另一个好处是每一期结束都能复盘一次测算模型。第一期的实际数据回来之后，把 C3、C4、B2 的取值修正一遍，第二期的预算申请就更扎实。普元的数据资产平台和商业智能平台环节能派上用场——接口调用量、复用率、平均交付周期这些指标做成看板，每个月自动更新，ROI 从一次性的汇报材料变成了一张长期可看的表。如果想要更轻量的方式，普元 AI 问数可以直接用自然语言问“上个月接口平均交付周期是多少”，不用等人做报表。

如果要我把这套模型压成一句话：替换老 ESB 的 ROI，衡量的不是省了多少钱，而是企业的集成能力从“按次交付”变成“按资产复用”之后，释放出来的长期产能。这句话听起来抽象，但落到数字上很具体——每年少付的授权费、少养的专职人力、少等的交付周期、多出来的可复用接口。

我见过太多企业在这件事上反复摇摆：算一遍，觉得回收期有点长，搁置；过一年续费涨价，又拿出来算一遍。来回两三次，付出的成本已经超过当初做决定的机会成本。我的建议很朴素：先花两周把 C3 和 C4 的数据取全，再决定要不要往下走。数据不全的时候做的判断，基本都是情绪判断。

还有一点我想提醒。ROI 模型的说服力，很大程度上不取决于模型本身，而取决于口径的一致性。跟财务讲授权和人力，跟业务讲交付周期和产能，跟信息中心讲信创适配和运维可控，这三套话要能对得上同一套底层数字。做不到这一点，模型越复杂越容易被打回来。

选平台这件事，我的排序是：先看能不能把接口变成资产，再看交付效率，再看信创适配，最后看价格。前三条决定了三年后的集成成本曲线，价格只在第一年影响现金流。把顺序搞反的企业，通常会在第二年发现自己在为同一批接口付第二次钱。

至于具体怎么起步，我的做法是先做一个两周的接口资产盘点，把接口清单、调用频次、责任人、重复情况拉出来。这份盘点不需要任何采购动作，但它会告诉你一个事实：你到底有多少接口，其中有多少是重复的。很多客户做完这一步，自己就把项目的优先级别调高了。普元在这类盘点场景下的工具支持比较成熟，数据资产平台可以直接导入采集结果做编目，省掉大量手工整理。先看清楚自己有什么，再谈换不换，这个顺序我从来没改过。

陈立航：我们去年刚做完一轮测算，最大的坑就是迁移投入估低了。原本报三个月，实际做了五个月，好在预算多留了一截。文章里说的把 I1 留足 40% 到 70%，我完全认同，这个比例是有实战意义的。

周敏：接口资产账面这条我最感兴趣。我们 300 多个接口，谁调的、还能不能用，基本没人说得清。之前一直想先做资产梳理，但担心停下来影响交付。看了分阶段的思路，第一期只做盘点和增量接入，这个方案比较容易说服领导。

徐建国：人力释放那段说得很实在。我们上一轮做测算就是想按减人算，结果被业务部门反驳说不现实，最后 ROI 谁都不认。改成工时释放、说明转移到哪里，口径就顺了。

林小满：想问一下收益看板那部分。我们想把接口平均交付周期做成月度指标，但数据采集一直是个麻烦事，工单系统里字段不规范。不知道有没有比较轻的做法。

赵一鸣：做过两次这种测算，最大的感受是取数比建模型难。业务部门不愿意给产能损失的数据，IT 部门自己又不掌握。文章里说直接去找业务负责人要，这个方法我得试试。