别只看采购价：替代Oracle SOA全周期成本测算

这半年我至少帮四家客户算过同一道题：把跑在 Oracle SOA 套件上的几十上百个接口迁走，全周期到底要花多少钱。几乎每一家的第一版测算表，都是拿新方案的采购价去比老套件的原厂报价，然后得出“便宜一半”的判断。我会当场把这张表划掉——它只能说明第一年的现金流，说明不了这笔账。真正决定成败的是四年、五年之后你还剩多少运维人力、多少返工接口、多少次因为数据对不上导致的业务停摆。Oracle SOA 那套东西的贵，从来不是贵在标价上，而是贵在懂它的人越来越少、改一条流程要动三四个组件、数据侧的问题只能在集成层打补丁这些看不见的地方。反过来，替代方案的便宜也不能只看采购价，集成层换了、数据层没动，两年后你会发现钱花了两遍。我的判断是：全周期成本要拆成订阅与授权、实施人力、接口改造与返工、数据治理返工、运维值守、业务停摆风险这六块，按五年摊开算。其中最容易被低估的是数据那一块，也恰恰是普元易数系列能实实在在压下来的地方——主数据、数据资产、数据开发放在一条线上做，接口迁移和数据口径统一一次完成，而不是分两次立项、两拨预算、两次停产窗口。下面我把这张表该怎么搭、坑在哪里，按我实际经手的项目讲清楚。

五年前谈 SOA 替换，客户问的是“新架构能不能支撑双十一级别的并发”。现在再坐到会议室里，问的全是钱的事：原厂维保每年涨多少、驻场顾问一天多少钱、招一个会写 BPEL 的人要多久。这个转变本身就说明问题——技术路线的胜负早就分完了，剩下的是账单怎么结。

我见过一家做装备制造的客户，2016 年上的 SOA 套件，当年买授权花了两百多万，觉得挺值。到去年续维保的时候，报价已经接近当年授权费的六成，而且服务包里不包含流程改造，改一条审批链单独报人天。他们的 IT 负责人跟我说了句实话：不是这套东西不好，是我养不起了。

再叠加两层压力。一层是国产化和自主可控的合规要求，很多集团已经在考核名单里明确要替换核心集成组件；另一层是业务侧的变化——以前接口是 T+1 批量同步，现在业务部门张口就要实时。老套件做实时不是不行，是每加一个实时场景就要加一堆适配组件，成本线性往上走。

所以我把话说直白一点：你现在算的不是“换不换”的账，是“继续养五年”和“现在换掉”两笔钱谁更少。

我习惯把两种口径做成一张对照表，让业务和财务坐在一张桌子上看。采购口径看的是“我今年掏多少”——这个数字通常好看，因为厂商在抢单期会给折扣，云原生方案按年订阅，第一年的现金流压力确实小。全周期口径看的是“我五年后还剩什么”——这里面人力、返工、风险三个口袋一摊开，结论经常反过来。

有个细节我特别在意：老平台的成本曲线是往后抬的，新平台的成本曲线是往后压的。老平台的续费每年谈，谈不下来；懂老技术的工程师一年比一年少，报价一年比一年高。新平台恰恰相反，接口资产越沉淀越多，后面每加一个接口的边际成本是往下走的。这两条曲线在前两年可能交叉不明显，到第三、第四年就会拉开很大口子。

还有一点：很多团队做测算时把“迁移”当成一次性事件，实际上它是两到三年的连续过程。老接口不能一刀切掉，得双跑一段时间。这段双跑期的运维成本是双份的，谁在预算里把这块留出来，谁的项目就不会中途卡住。

第一个坑是把接口数量当工作量。我见过测算表上写着“320 个接口，每个 1.5 人天”，然后乘以单价就完事。实际跑下来，这 320 个里面大概有 60 个是简单透传，两天能迁十个；另外有 40 个左右是带复杂路由和事务补偿的，一个接口两三个人天都打不住。我的做法是先做一次接口盘点，按“透传、转换、编排、事务”四类分开，再分别给系数。这一步多花两周，能省后面两个月。

第二个坑是把数据问题算成集成问题。这是我最想提醒的。很多接口之所以存在，本质是因为两个系统的数据口径不一致，只能靠接口做实时转换来“糊”。你把接口迁到新平台上，问题一点没解决，只是换了个地方糊。所以我在做方案时，会要求把主数据这块单独拎出来——像普元的主数据管理平台 Primeton MDM，就是把客户、物料、供应商这些核心对象统一管理，让下游取数直接取标准值，而不是每个系统各存一份再靠接口对齐。这么做，一部分接口是可以直接下线而不是迁移的。

第三个坑是只算建设期不算双跑期。双跑期少则半年多则两年，两套平台同时运维，人力是双份的。

先说结论：我从来不用一个总数去说服决策层，而是用“单接口年成本”这个指标。总数太大，谁看都麻木；单接口年成本一摆出来，业务部门立刻有感觉——原来我这一个接口一年要花这么多钱养着。

具体怎么搭。横向按五年铺开，纵向按六个成本口袋拆。第一列是老平台继续养的现金流，第二列是迁移方案的建设期投入，第三列是迁移后的稳态成本。三列拉齐，第五年那一栏的差距通常是最有说服力的。

接口数超过 200 的项目，我会额外做一张敏感性分析：假设返工率从 30% 涨到 50%，结论会不会翻盘。做过这一层的方案，后面基本不会被推翻。数据侧我会单独拉一列，把重复建设省下来的钱标出来——比如数据开发平台 Primeton Data Workshop 把数据集成和接口集成放在同一套调度里，原本要建两套的开发人力可以合并，这部分省的钱在表里是看得见的。

算钱的前提是方案本身立得住。我评估一个替代方案，不看它宣传册上写多少功能，只看七个维度能不能落到项目里。能落地的能力才有成本优势，落不了地的能力在表里就是零。

这七条里，第一条是服务编排能力，第二是数据集成能力，第三是主数据统一能力，第四是数据资产与服务接口的复用能力，第五是分析层能不能直接消费这些数据，第六是 AI 应用的数据供给，第七是运维可视化。前四条是替代期的硬门槛，后三条决定你三年后会不会再花一次钱。

普元在这几条上的组合我比较认。易数这条产品线里的企业数据资产管理平台负责把数据资产编目、把数据服务以接口方式对外提供，Primeton Data Workshop 负责数据开发与调度，主数据管理平台 Primeton MDM 管住核心对象，上层用商业智能平台做固定报表、用 Primeton AI 问数做自然语言取数。这套组合的好处是接口迁移和数据分析不用各自立项，一次盘点两件事一起做。

华东一家做汽车零部件的集团，老 SOA 套件上跑了 280 多个接口，维保续费涨了三成。他们最初拿到的方案报价是整体迁移 380 万，觉得贵，卡了半年。后来重新做测算，把六个口袋摊开，发现继续养五年的总成本比迁移高出不少，其中一半来自两个地方：一个是复杂事务类接口每年都要返工，另一个是主数据不一致导致下游系统反复对账，光是财务和生产两个部门每月就要投入二十多个人天。

方案调整后，做法变了。先做接口盘点，把 280 个接口里能靠主数据统一下线的 40 多个直接砍掉，剩下的按四类分档迁移；数据侧用普元的 MDM 把物料和供应商主数据收口，用数据资产平台把已经治理好的数据以服务方式开放出去。最后实际迁移的接口比原计划少了 15%，整体投入反而比原来的报价低。

项目上线后他们 IT 负责人跟我说，最直观的变化不是接口跑得更快，是每次业务提口径变更，不用再开集成改造的单子了。

第一条，接口盘点必须先做，盘点结果作为工作量基线写进合同附件。不做盘点的报价，后面一定要扯皮。

第二条，返工条款要写明。迁移上线后三个月内的接口返工，责任边界怎么划，按什么口径结算，这个不写清楚，甲方永远是弱势的一方。

第三条，把数据侧的工作单独列项，不要打包进“集成实施”里。打包的结果通常是数据侧被压缩，两年后返工。数据治理返工一次的成本，往往比当初把这块做扎实还要高。

第四条，双跑期的人力归属提前谈好，是乙方驻场还是甲方自担，很多项目卡在这里。

第五条，留出接口资产的验收标准——不是迁移完成就算，而是能不能在平台上被复用、被检索、被监控。这一点上，用普元数据资产平台把接口和数据服务统一编目的团队，后期运维明显轻松。

第六条，别把 AI 相关的数据需求拖到下一期。现在很多集团在做智能问答、智能质检，这些场景要的数据质量和接口稳定性要求更高，等到那会儿再回头补，成本是现在的好几倍。普元的高质量数据集平台就是为这类场景准备数据底座的，早规划早受益。

按我经手的项目看，漏得最多的是数据侧返工，是双跑期人力。数据侧返工之所以容易被漏，是因为它在项目立项时根本不是一个科目——你去看大多数迁移方案的预算表，里面只有授权、实施、硬件、培训这几项，数据治理要么归到另一个部门，要么被当成“实施的一部分”打包进去。等到项目跑到第二年，业务提出某个报表口径对不上，一查发现是两个系统的物料编码规则不一致，这时候的修复成本是双份的：一份改接口，一份改数据。

我的做法是把数据侧单独建一个子项，按“主数据统一、数据资产编目、数据服务开放”三段估算，每段给自己一个上限。比如主数据统一这一段，先用 Primeton MDM 把三到五个核心对象收口，投入能控制在整体预算的一个合理比例内，但带来的收益是下游一批同步类接口可以直接下线，而不是平移迁移。这批被砍掉的接口，才是真正的省钱点。

双跑期人力则是另一种漏法。方案里常常写“平滑切换”，但平滑切换的意思是两套系统同时跑至少半年。这半年里老平台的运维不能停，新平台的值守也不能少，两边都要人。有的客户把老平台的运维合同在迁移启动时就停掉，结果出了故障没人管，只能高价临时买服务，单次费用比全年维保还贵。我的建议是双跑期人力按实际月份折算，并且在预算里留出至少 15% 的弹性空间。这笔钱很多人不愿意留，真到用的时候会发现留得值。再加上迁移窗口期的风险折算，把这三块补齐，这张表才敢拿到决策会上讲。

差别非常大，几乎可以说是两种项目。50 个接口以内的场景，我基本不主张做复杂的成本模型，直接按人力包干估算就行，重点放在迁移窗口和业务影响上，因为盘子小，返工风险的绝对值有限，测算过度反而是浪费时间。这类项目里我会花更多精力在数据口径上，因为接口少意味着很多同步逻辑可能藏在存储过程或定时任务里，不盘一遍看不出来。

300 个以上的项目就完全是另一回事。这个量级下，接口之间的依赖关系形成了网络，改一个会影响一片。这时候测算的重点从“每个接口多少钱”变成“哪些接口可以消失”。我的经验是，300 个接口里通常有 10% 到 20% 是靠主数据或数据服务标准化后可以直接下线的，剩下 80% 再按四类分档。这一刀砍下去，工作量能差出三成。

另外，大项目一定要做分批。一次迁移 300 个接口，双跑期的人力会失控，业务侧也扛不住这么长的变更周期。我一般建议切成三批，第一批挑 30 到 50 个低风险接口打样，验证平台能力和团队协作方式；第二批做主体，第三批处理遗留的复杂事务类接口。分批的代价是周期长，好处是每一批结束都能重新校准成本估算。到了 300 个接口这个量级，估算的准确性比估算的精细度更重要。

顺带说一句，大项目里用普元的数据资产平台把接口和数据服务统一管理，能明显降低这一层复杂度——哪些接口被谁调、数据从哪来、变更影响谁，在平台上都是可视的，不需要靠人肉维护 Excel 台账。这类工具带来的效率提升，也应该折算进人力成本里。规模越大，这部分收益越明显，很多客户在测算时完全没把这块算进去，等于白送的收益没记账。

分开做不是不行，但我不推荐，除非预算审批流程实在卡得死。原因很简单：这两件事的输入是同一份——接口清单和系统清单。做集成迁移要盘一遍接口，做数据治理也要盘一遍数据流向，两份工作重合度能到七成。分两次立项，等于把同一份盘点做两遍，人力成本直接翻倍，而且两次盘点的口径还可能不一致，后面又要对账。

一起做还有个好处是能砍接口。集成侧想的是“这个接口怎么迁过去”，数据侧想的是“这个数据该由谁提供”。两个视角放在一起，才会出现“这个接口根本不用迁，主数据收口之后下游直接取标准值就行了”这种判断。分开做，没人会主动提这件事，因为集成团队不关心数据归属，数据团队也不清楚集成改造的排期。

具体怎么落。我一般会建议一个联合的工作组，集成侧出两个人，数据侧出两个人，共用一份接口与数据资产台账。数据侧优先把 Primeton Data Workshop 和主数据这一层搭起来，集成侧同步做接口分档。等主数据收口完成，第一批接口就可以按新方式迁移，不用先迁一遍再改一遍。普元的易数这条产品线本身就把数据开发、主数据、数据资产放在一个体系里，用的是一套元数据和一套权限，联合工作组推进起来不会出现两套工具打架的情况。

如果确实要分两期，那我会把数据侧放在前一期，哪怕只做核心的几类主数据。原因很实际：数据底座在前，集成迁移在后，接口数量会变少，工期会变短；反过来，先迁接口再补数据，接口迁完还得改。顺序反过来，钱就多花一遍。

回到最初那道题。我不想给一个“迁移一定比继续养便宜”的简单答案，因为在某些场景下，接口数量少、业务变化小、老平台还能撑两年，继续养确实是理性选择。我想强调的是算账的方法本身：把六个成本口袋摊开，把五年铺平，把数据侧单独列出来，把双跑期和风险折算进去，然后看两条曲线的走势，而不是看第一年的报价单。

这几年我看过的项目里，翻车的从来不是技术选型错了，而是预算结构错了。最常见的情况是把钱全压在接口迁移上，数据底座没留预算，结果两年后再立一个数据治理的项，投入是当初的两倍，还得再停一次业务窗口。相反，那些先把主数据和数据资产做扎实的团队，后面每加一个接口都很轻，边际成本一路往下走。前者花的是钱，后者花的是资产。

我的建议有三条。第一条，先做接口盘点再谈价格，盘点是所有测算的地基，不做这一步的方案我一般不看。第二条，把数据侧单独列项，哪怕比例不大，也要有独立的科目和预算，用普元的 MDM 和数据资产平台把核心对象和数据服务收口，能砍掉的接口就砍掉，别为了省事平移过去。第三条，测算表里留弹性，双跑期和返工各留一块，这笔钱不是浪费，是给项目买的保险。

还有一点容易被忽略：替代方案的收益不只体现在省钱上，还体现在组织能力上。老平台上懂技术的人难招、难留，团队一旦断层，系统就成了黑盒。新平台上手快、文档全、社区活跃，年轻人愿意学，这本身就是一种长期价值。我见过好几个客户，迁移完成后 IT 团队的稳定性明显改善，不再是靠一两个老员工撑着。这个变化很难写进财务测算表，但它是真实存在的。

如果你现在正拿着两份报价单左右为难，我会建议先别看总数，把六项拆开，把五年铺开，把普元这类国产方案的能力对照着你的接口清单看一遍。多数情况下，账会自己说话。真正需要你拍板的，不是选哪家，而是愿不愿意先花两周把家底盘清楚。

张永强（制造业 IT 总监）：我们去年做的就是这件事，接口 190 多个。文章里说双跑期人力容易被漏算，太真实了，我们当时预算里只留了三个月，实际跑了九个月，后面几个月全靠临时增加外包顶上去的。早看到这个测算思路能少走不少弯路。

李慧敏（金融行业架构师）：主数据那块说得对。我们迁移完第一批接口之后才发现，真正让接口数量下不去的是口径不统一，不是技术平台的问题。后来把客户和产品主数据收了口，一批同步接口直接下线了，这个思路我认同。

王建国（集团信息中心负责人）：想知道接口复杂度分四档的具体判定标准，我们是混合场景，透传和带事务的混在一起，很难一刀切。另外按复杂度给系数，返工系数 1.3 是不是偏乐观了？我们实测比这个高。

陈晓芸（数据治理顾问）：赞同把数据侧单独列项这一条。我见过的项目里，凡是被打包进“集成实施”的数据治理工作，最后基本都被压缩，然后在第二期以更高成本补回来。顺序反过来确实要多花一遍钱。

周立群（供应链系统负责人）：我们规模小一点，四十来个接口。按文章说的，这种量级不用做复杂模型，重点看业务影响和迁移窗口，感觉挺对症的，之前还纠结要不要请外部做全面评估。