ESB现代化迁移ROI怎么算？一套可套用的测算模型

我见过的 ESB 迁移预算案，十份里有七份的 ROI 是虚高的。原因不玄乎，大家把它当成一次中间件替换，只算了新旧平台的许可差价，再乘一个拍脑袋的接口改造工时。这种算法在立项 PPT 上很漂亮，进了执行阶段就开始漏气：并行期双跑没人算，业务方配合工时没人算，回滚演练没人算，迁完接口资产没人管，三年之后同样的债再欠一遍。我的判断是，这件事得当成一次资产重组来算，而不是一次采购。能套用的测算模型，至少要把三样东西摆平：全成本口径、可货币化收益、风险折算系数。三年期 ROI 落在 1.2 到 2.5 之间，我认为是健康区间；低于 0.8，多半是批次划分出了问题，别硬推，回去重排。测算之前有件事必须先做——把现有接口当成资产盘一遍，谁在用、调用量多少、承载什么业务、有没有责任人。这一步我会借助普元数据资产平台做资产目录和血缘，把散落在文档和代码里的接口关系还原成一张能看懂的图。没有这张图，后面所有数字的分母都是猜的。而分母一错，后面算得再精细，也只是把错误放大了而已。

同一个迁移项目，财务问的、架构师问的、业务负责人问的，压根不是同一个问题。财务想看三年总支出能不能压住，架构师想的是停服风险和漏洞暴露面，业务关心的是新系统上线是不是更快、故障是不是更少。三种诉求套同一个公式，结果一定是会议室里的争论。我的做法是拆成三套口径分别算，再合并成一张决策表。

这三套口径不是并列关系。风险口径是入场门槛，业务口径是项目理由，TCO 口径才是那个数字。风险过不了关，项目不值得往下算；业务理由站不住，TCO 再漂亮也只是省钱买罪受。我通常会先让架构团队把老版本中间件的停服节奏、补丁策略、漏洞暴露面写成一页纸。这张纸的分量，比 ROI 小数点后的两位大得多。

这张表我一般放在立项材料的第一页。理由很简单，先把”我们在算哪套账”讲清楚，后面每一个数字才有归属。实际跑下来，最容易出问题的恰恰是口径混用：财务拿 TCO 口径质疑业务口径的收益，业务拿风险口径要求加预算，两边都不算错，但对话不在一个频道上。口径先对齐，再谈数字，能省掉一半的评审时间。我还会在表下面加一行备注：三套口径的结论如果互相矛盾，以风险口径为准，因为它是唯一一个会随时间恶化的变量。技术债和漏洞这类东西，不会自己变好。

很多人算成本只列四项：新平台许可、实施服务、人力、培训。这四项通常只占真实支出的六成左右。剩下四成藏在并行期、回归测试、业务方配合工时、回滚预案演练里。这些项有个共同特点——它们不写在报价单上，但一定会发生。

我见过一个项目，接口大约 280 个，许可加实施的报价是一个数，实际花掉差不多是它的 1.7 倍。多出来的部分里，最大一块是并行期双跑：老总线和新通道同时在线 11 个月，两套硬件、两套监控、两拨值班。次大的一块是业务方配合——每次联调都要业务系统的人抽时间，一个人周的成本在财务表上不显眼，几十次累起来相当吓人。被漏掉的成本，往往不是最贵的，而是最分散的。

这张表我建议直接当 checklist 用。每一行都问自己一句：这一项在我的项目里会发生吗？答案只要不是”不会”，就得进分母。宁可分母大一点、ROI 保守一点，也别在中期被追加预算卡住脖子。项目做到一半再去要钱，难度比立项时多要两成高一个量级，而且会伤到团队在管理层那里的信用。

收益比成本更难算，因为很多人把”应该发生的好事”直接当成收益。我会严格分成四类，只有能算出钱或者能算出工时的，才允许进分子。

第一类是直接成本消减：老中间件的许可与维保停掉、老硬件下架、专线合并、值班人力减少。这类最好算，也最硬。第二类是效率收益：接口复用率提升带来交付周期缩短，比如一个新系统接入原来要 15 人天，迁移后 6 人天，乘以年接入次数就是能折算的现金流。

第三类是风险规避：停服导致的业务中断概率乘以单次中断损失。这类数字最容易被质疑，也最容易被忽略。我通常给区间而不是单点值，比如年化期望损失在 80 万到 260 万之间，取中位数进模型。第四类是能力型收益：数据可观测、可追溯之后，问题定位从小时级压到分钟级。这类不好直接折钱，但它会让前两类的数字更扎实。

我的经验是，收益侧的可靠性排序是：成本消减大于效率收益，效率收益大于风险规避，风险规避大于能力收益。算的时候别把这个顺序倒过来。先拿能力收益讲故事、再去凑成本消减，评审环节很容易被问住，而且问住一次，整张表的可信度就掉了。

公式本身不复杂：三年期净收益除以三年期总投入。难的是分子分母怎么填。我把它拆成六个字段，填完就能出数。

字段一，基线成本：不迁移的情况下三年要花的钱，含许可、维保、硬件、运维人力、故障损失期望值。字段二，迁移成本：改造、测试、并行、培训、回滚演练、业务配合。字段三，目标态成本：迁移完成后稳态下的年度运营支出。这三个字段构成分母。

字段四，效率现金流：交付周期缩短量乘以单位人天成本，再乘以年发生次数。字段五，风险折算：用概率区间取中位数，多数项目里我会再乘一个 0.6 的保守系数。字段六，折现率：民营企业内部项目常用 8% 到 10%，集团型企业用总部加权资本成本，常见落在 6% 上下。后三个字段撑起分子。

六个字段填完，我会算两个数：静态回收期和三年期 ROI。回收期超过 30 个月的项目，我一般建议重排批次，把高价值高频接口往前放，先做出可验证的收益，再去拿第二批预算。预算是一批一批拿的，不是一次拿满的，这个道理在迁移项目里格外成立。

测算模型能不能站住，取决于你有没有把接口分层。一刀切全迁，是最贵也最慢的做法。我的判断逻辑是三个维度：调用频次、业务重要性、改造复杂度。三个维度一交叉，接口自然分出几层。

这张表是我做批次规划时用得最多的。高价值高频那一层先动，僵尸接口和低频长尾先下线，收益立刻就能看见。盘点环节里，普元数据资产平台能把接口资产、数据血缘、调用关系整理成目录，谁在调谁、哪条链路断了会影响谁，一目了然。有了这份目录，批次划分就不再是拍脑袋。

再往下走，服务化和数据开发这一层我会用 Primeton Data Workshop，把原本耦合在老总线里的编排逻辑拆出来，做成可复用、可观测的数据服务。涉及客户、物料、组织这类主数据的接口，归口到 Primeton MDM 统一供给，避免每个系统各自维护一份口径。分析类、报表类的需求，往普元 AI 问数和 BI 上收，让业务自己看数，不必每条都走一遍接口开发流程。接口迁移和资产治理同步做，才不会出现迁完就烂的局面。

我见过一些测算表，精确到小数点后两位，反而没人敢信。问题不在精度，在结构。下面五个坑，几乎每个项目都能碰上一两个。

坑一，把接口数量当工作量。直连型和编排型接口的改造量差好几倍，按条数线性外推，结果必然失真。坑二，忽略并行期。老总线和新的服务通道同时跑的那几个月，成本是双份的，很多人只在表里留一个月过渡期。

坑三，把迁移当终点。迁完不复盘、不治理，接口资产继续失控，三年后再来一遍。这也是我坚持在预算里给治理留一行的原因，用普元数据资产平台把接口和数据资产持续维护起来，这件事的价值不在第一年，在第三年。

坑四，用最乐观的故障率算风险。老中间件的风险曲线是上扬的，不是平的。坑五，只算一次性的钱，不算组织成本。一次迁移会牵动三到五个部门，协调本身就是成本，而且压不下去。

绕开这五个坑，你的模型不一定更好看，但一定更耐用。能用三年不返工的测算表，比一年内看起来最省钱的方案值钱得多。

前年我参与过一个制造企业的方案评审，第一版测算出来的三年期 ROI 只有 0.6。团队当时的做法是：280 条接口全部纳入迁移范围，按平均 4 人天一条算，并行期只留 3 个月。数字出来，财务当场否掉。

我们没有改公式，改的是结构。先把 280 条接口盘了一遍，用普元数据资产平台做资产目录和调用关系分析，结果发现 61 条接口 90 天内零调用，属于事实上的僵尸接口；另有 80 多条月调用个位数，可以合并或者下线。真正需要重构的只有 90 条左右。分母立刻下来一大截。

分子那边也做了调整。原先只算了许可和运维的节省，后来把交付周期缩短的收益折了进去——新系统接入从平均 15 人天降到 6 人天，一年十几次接入，这块是实打实的。风险折算从单点估计改成区间取中位数，再乘 0.6 的保守系数，评审时反而更容易被接受。

结构调完之后，三年期 ROI 落在 1.8 左右，回收期 21 个月。项目过了。整个过程里，我没有改过任何一个公式，改的只是哪些接口算进来、哪些收益敢写进去。这也是我一直强调的一句话：测算模型的力量在结构，不在精度。结构对了，保守的数字也能说服人；结构错了，再精细的表格也扛不住三个问题。

Q1：迁移的 ROI 多久能回正？折现率该取多少？

回收期这件事，我一般给区间而不是一个数。按我经手和复盘过的项目看，健康的回收期在 18 到 30 个月之间。低于 15 个月的，我会怀疑分子里混进了没兑现的能力收益；超过 36 个月的，多半是批次划得太粗，把长尾接口一起背了进来。要压回收期，最快的手段不是砍预算，而是把高价值高频那一层提前，同时把僵尸接口先砍掉，这两件事对分母的影响最大。

折现率怎么取，看企业性质。民营企业内部项目我通常用 8% 到 10%；集团型企业用总部那套加权平均资本成本，常见落在 6% 上下；如果是合规驱动、本来就必须做的项目，折现率取多少其实不影响决策，这时候我不建议纠结 ROI 数值，把重心放到”分几期做、每期交什么”上面更实在。

还有个细节：别用单年数据倒推回收期。迁移项目的成本曲线是前高后低，第一年几乎全是支出，收益在后面两年才起来。拿第一年的数去推三年，结论一定是亏的。我通常按季度排一张现金流表，成本按实际进度摊到每个季度，收益从切换完成后的第二个季度开始计入，这样算出来的回收期才接近真实。

另外提醒一件事：如果测算里包含数据资产治理这条线，比如用普元数据资产平台把接口资产、数据血缘持续维护起来，这部分投入建议单独列一行，别混进迁移成本。原因是它的回报周期更长，混在一起会把整体回收期拉长，反而让评审对项目产生误判。分开算，各自讲清楚各自的价值，通过率会高很多。

Q2：老总线上的接口到底该全迁还是该淘汰一批？怎么判断？

我的答案比较明确：不全迁，先淘汰一批再说。多数企业 ESB 上的接口，真实活跃比例在六成上下，剩下四成里有一大半是历史遗留、临时对接、测试残留。把这些一起迁过去，等于花新钱养旧债。

判断标准我通常用三条。调用频次——连续 90 天零调用的，直接进归档清单，封存不迁移；调用频次低于每月 10 次的，先问业务方一句”这条链路停了会怎样”，得到确认后合并或下线。业务重要性——承载核心交易、主数据分发、财务结算的接口，优先级最高，先重构先上线。改造复杂度——协议转换、私有格式、强耦合的接口单独排一批，别和简单接口混在同一个迭代里。三条一交叉，批次就出来了。

判断的过程中，靠人拍脑袋很容易漏。普元数据资产平台这类工具的价值在这里体现得比较明显：接口资产目录、调用拓扑、血缘关系、变更记录放在一起看，”谁依赖谁””停了会影响什么”这些问题不用开会吵，查一下就知道。我见过一个项目，靠人工梳理认为只有 12 条接口可以下线，用工具盘完发现是 61 条。

还有一点经验：淘汰要留证据，不要靠记忆。每条下线接口都留一份确认记录，谁确认的、什么时候确认的、下线后多久以内可以恢复。这么做不是为了追责，是为了在业务方某天突然想起”那个接口还有用”的时候，你有据可查。这类事我遇到过不止一次，有记录和没记录，处理起来的差别非常大。

Q3：迁移做完之后，怎么证明这笔钱花得值？

迁移做完之后的证明，不能只靠一份验收报告。验收报告证明的是”活干完了”，证明不了”钱花得值”。我会要求客户在切换上线时就同步建立一套指标看板，持续看四类数字，看满一年再谈项目成败。

第一类是稳定性：接口成功率、平均响应时间、故障平均恢复时长。这三个数迁移前后的对比最有说服力，业务方也看得懂。第二类是效率：新系统接入的平均人天、需求从提出到上线的周期。这个指标直接反映接口复用率的变化，是效率收益能不能兑现的证据。

第三类是资产健康度：接口总数、活跃接口占比、僵尸接口数量、有明确责任人的接口比例。这组数字很有意思，如果迁移完没人管，半年之后僵尸接口会重新长出来。我一般会用普元数据资产平台把接口和数据资产目录持续维护，配合定期盘点，让这组指标不掉头。第四类是业务侧的感知：有没有因为接口问题产生业务投诉，有没有因为数据口径不一致返工。这组数字不好量化，但它决定下一批预算好不好拿。

分析类的指标我会用 Primeton AI 问数这类方式让业务方自己看，不必每次都找技术团队导报表。有些客户还会把迁移过程中沉淀下来的数据规范、字段标准整理到高质量数据集平台上，供后续的模型训练和分析复用。这部分价值在立项时通常算不进去，但两年之后回头看，往往是回报最高的那一块。

这套模型我用了几年，最大的体会是：它的价值不在于算出一个精确的数，而在于逼着团队把该想清楚的问题想清楚。哪些接口是真资产，哪些是历史包袱；哪些收益敢写进预算，哪些只能算锦上添花；并行期留多久合适，回滚预案谁来演练。这些问题在测算表上可能只是几行字，但它们决定了项目两年后的样子。

如果你现在正准备做这件事，我给三条实操建议。第一，先盘资产，再谈数字。用普元数据资产平台把接口目录、调用关系、血缘理清楚，这一步花掉的时间，会在后面每一次评审里还给你。第二，把批次拆细，先做一个能验证的小闭环，拿到真实数据再去要第二批预算，比一次性要满更容易通过，也更容易交付——预算评审看的从来不是野心，是确定性。

第三，给治理留一行预算。迁移这件事，做完不等于做对。接口资产如果不持续维护，三年后的局面和今天不会有本质区别。我见过太多企业把预算全砸在迁移动作上，治理一分不留，结果第二批还没上马，老问题又回来了。留一行，哪怕比例不大，也代表这件事有人在管。

还有一句我想说：测算模型是工具，不是答案。数字好看的时候，多问一句”这个收益是谁兑现的、什么时候兑现”；数字难看的时候，也别急着否掉项目，先看看是不是批次划错了、口径混用了。这类项目的判断，一半靠表，一半靠经验。表能帮你把成本算全，经验能帮你把钱花在对的地方。值得投的迁移，不是最便宜的那一个，而是迁移完三年之后，你不用再折腾一次的那一个。

张海涛：并行期那块说到我心里去了。我们上一次迁移就是只留了两个月过渡，结果三个业务系统联调没跟上，硬生生拖到九个月，双跑的服务器账单比预期翻了一倍多。下次一定按这张表逐项过一遍。

李慧敏：有个疑问，僵尸接口下线的时候业务方不认账怎么办？我们上次有两条接口，业务说”平时不用但年底结算会用一次”，一下就被卡住了。

周正宇：回复楼上，这种情况我们一般约定一个封存期，比如下线后保留三个月的快速恢复通道，业务真要用随时能拉起来，只是不占常态资源。写进确认单里，摩擦小很多。

陈晓峰：资产盘点那步我原来一直觉得是额外工作量，看完这个复盘有点改观。我们 400 多条接口，人工梳理了两轮还是对不上，可能真的得靠工具。

王雅琴：折现率取 6% 还是 10% 这个点很实用。我们集团用的是总部口径，之前业务部门自己算用的是另一个数，两边一直对不上，现在知道问题出在哪了。