别只看采购价：集成中间件全周期成本测算

我做过十几年 B2B 交付，见过太多项目在采购环节省了二十万，交付那年多花了八十万。集成中间件这东西，报价单上写的是 License 单价和年度维保比例，看起来清清楚楚，实际跑下来，真正的开销藏在三张表里：集成开发的人天、运行期的运维与扩容、以及数据口径不一致带来的返工。我会要求客户在做预算时，把这三块单独列出来，跟 License 放在同一张表上比。多数情况下，License 只占全周期成本的 15% 到 25%，集成开发与后期运维加起来能占六成以上。这个比例我见过更极端的，某省级集团项目，中间件采购 60 万，三年下来开发加运维投了 400 多万。所以我的判断很直接：买集成中间件不是买一个软件，是买一条能持续跑三年到五年的数据通路。报价越低的产品，往往把复杂度转移到了你的团队身上——接口要自己写，主数据要自己对，指标口径要自己吵。普元在这类项目里的思路，是把数据治理能力做进集成链路的上下游，让接口开发、主数据分发、指标口径这三件事有平台承接，而不是全靠人堆。算全周期成本，本质是在算你愿意把多少复杂度留在自己手里。下面我把这几年测算的方法、翻过的车和真实的账本摊开来讲，希望你看完之后再去看那份报价单，眼睛里看到的东西会不太一样。

我拿到一份集成中间件报价时，第一反应不是看单价，而是问三个问题：接口开发谁做、上线后谁值守、数据口径谁定。这三个问题的答案，基本决定了后面三年的现金流走向。很多人算成本只算到”验收”，其实验收那天，钱才开始真正往外走。

我习惯把成本拆成六块。这张表我用了七八年，每次投标前都会跟客户对一遍，对完之后双方对”便宜”和”贵”的理解通常会统一不少。

这张表里，我最在意的是倒数第二行。集成项目做到真正拖垮预算的往往不是技术难度，而是同一份客户数据在 CRM、ERP、财务系统里对不上。接口多写十个不可怕，口径对不上一处才可怕。我见过一个零售客户，光是为了对齐”有效会员”这一个定义，三个部门开了十一轮会，最后靠上线 Primeton MDM 把主数据标准固化下来，才把这件事收口。这笔钱在报价单上是不存在的，但它真真切切发生在项目里。

客户问我最多的一个问题是：自建、买商业中间件、还是用云上的集成服务。我不太喜欢给标准答案，因为这三条路在第三年才见分晓。下面这张对比表是我根据近五年参与的项目整理的，数字取自几个中型制造和金融客户的真实账本，做了脱敏和均值处理。

我个人的倾向是：核心业务链路用商业中间件兜底，非核心链路可以按量付费。自研那条路我劝过很多人别走，不是技术不行，是人的变量太大。你今天有三个懂 ESB 的老员工，明年可能只剩一个。留下来的那一个，还得一边接新需求一边修三年前的坑。普元这类国产厂商的一个优势在于工具链的完整性——从数据开发到资产盘点再到指标输出，是一条线，而不是让你自己去拼七八个开源组件。拼装出来的东西初期省钱，长期看是在给自己造一个只有自己会修的黑盒。

第一个场景：接口数量在需求阶段被严重低估。立项时写 40 个接口，做完发现是 180 个。多出来的 140 个不是技术难，而是业务方在过程中不断想起”这个系统也得连”。我现在的做法是，在方案阶段就按业务系统数量×平均交互场景数做一版粗算，再乘 1.5 的系数报上去。宁可被说保守，也别在中期要追加预算。

第二个场景：测试环境跟生产环境不一样。这个问题听起来很小，实际上特别烧钱。集成链路对环境一致性极其敏感，消息队列版本、字符集、时区设置，任何一处不同都能让你排查三天。我见过一个项目，因为测试环境的编码格式不一样，上线当晚数据全部乱码，紧急回滚，损失了一个通宵加两次客户道歉会。

第三个场景：没有数据资产台账。系统一多，谁也不知道某个字段从哪来、被谁用、改了会影响到谁。没有血缘关系图，每一次变更都是盲改。这时候上 普元数据资产平台，把数据源、表、字段、任务的血缘关系拉通，看上去是增加了工作量，实际上是把未来两年的”救火成本”提前兑成了”设计成本”。这两笔钱的总量差不多，但前者让团队天天加班，后者让团队能按时下班。

我还见过一种更隐蔽的浪费：集成平台上线了，但业务人员不会用，所有取数需求还是提工单。一个中型企业，数据团队六个人，每天有三分之一的时间在写临时 SQL 给业务导报表。这块人力一年就是几十万。让业务自己拿到数，比让数据团队多写十个接口更值钱。把 Primeton AI 问数 这类自然语言取数的能力开放给业务侧，工单量能明显降下来，数据团队才能腾出手做真正有门槛的事。

我在做成本复盘时发现一个规律：技术投入的钱看得见，口径治理的钱看不见，但后者往往更多。原因也简单——技术问题有确定解，业务口径没有。两个部门对”销售额”的理解不一样，这事你没法靠一行代码解决，只能靠流程和工具固化。

下面这张表是我用来跟客户对齐”哪些能力必须有、哪些可以缓一缓”的对照表。左边是常见的能力诉求，右边是对应环节最容易被低估的成本，以及我推荐的承接方式。

这张表我一般放在方案的附件里，让业务部门自己看。他们看完通常会明白一件事：集成不只是把系统连起来，还要把数据讲清楚。连起来是三天的活，讲清楚是三年的活。

测算这件事，我不追求小数点后两位的精确，追求的是不漏项、口径一致、能被人挑战。具体我会走这几步。

把周期定成五年，不是三年。三年太短，很多成本还没显形，硬件刚过保、业务量翻番、第一批开发人员离职，这些事都在第三到第五年之间发生。定成五年，很多争论会自动消失。

把所有人力成本折算成人年单价，而不是按岗位报价。我见过太多方案里写”高级工程师 2 人”，但没写投入几个月、是兼职还是全职。这两个数字差一倍都不止。

单独设一行”口径返工预算”，额度按集成开发成本的 15% 到 20% 计。这行钱不是诅咒项目出问题，是承认这件事一定会发生。有了这一行，中期追加预算时你不会被动。

把运维按人年拆开，明确几个人、什么级别、负责哪些班次。我还会额外加一行”知识转移”，写明第二轮培训的时间点和对象。离职率是集成项目成本的隐形放大器。一个熟手离职，新人接手同一套链路，效率打七折是常态。

把平台能力折算成”省下的人天”。比如 Primeton Data Workshop 的可视化开发能把一个接口的开发周期从三天压到一天，这个差异乘以接口数量，就是实打实省下来的人力。把这类账写进方案，比讲功能清单有说服力得多。

我的答案是五年，而且我建议在方案里把五年拆成两段看：前两年和后三年。前两年是建设期加磨合期，主要是许可、实施、硬件和人力的集中投入；后三年是运行期，许可维保、扩容、运维人力和口径调整是大头。

为什么不用三年？因为三年的时间窗刚好卡在几个成本拐点之前。第一，硬件通常三年过保，第四年开始续保或换新，这笔钱在三年模型里是看不到的。第二，业务量的自然增长一般需要两到三年才会把初期配置吃满，扩容压力出现在第四年附近。第三，团队人员流动的累积效应在第四年最明显，早期参与建设的人可能已经走了一半。

我做过一个粗略统计，同一套方案按三年算和按五年算，年均成本能差出 25% 到 40%。按三年算的方案看起来更便宜，很容易在评审时被选中，然后第四年开始连续追加预算，反而更被动。按五年测算，是把不确定性摆到桌面上，而不是把它藏起来。

另外提醒一点，五年的测算里，软件维保通常是按许可金额的固定比例逐年计取，这个比例在合同里一定要写清楚上限。有些项目初期单价压得很低，维保比例却高，五年下来总支出反而更多。这也是为什么我一直主张把 普元 这类提供完整工具链的厂商放进同一张测算表里比，因为平台能力覆盖越广，需要单独采购和单独维护的组件就越少，长周期里的维保项也越干净。

不一定，而且我见过的大多数情况是反过来的。自研的成本结构有个特点：前期极低，后期极高，而且中间的坡度不可控。因为自研的成本几乎全是人力，而人力的价格和可用性每年都在变。

我算过一笔账。一个十人规模的开发团队，如果抽出三个人做集成平台，按人均年成本二十多万计，一年就是六十多万的人力投入，这还没算管理成本、招聘成本和机会成本——那三个人本来可以做业务系统。三年下来接近两百万。同等预算，采购一套成熟的商业中间件加数据平台，通常还有余量做实施和培训。

更关键的是隐性成本。自研平台的知识全在少数几个人脑子里，文档往往跟不上迭代。人一走，平台就成了没人敢动的祖传代码。我见过一家企业，自研的集成框架在三年前停了更新，现在所有新系统都得绕着它走，最后不得不重新做选型。自研最大的风险不是做不出来，是做完之后没人能接得住。

那什么情况适合自研？我的判断是：集成需求极其特殊、市场上确实找不到匹配的能力、并且公司有稳定五年以上的中间件团队。三个条件同时满足，才值得考虑。否则我建议用商业产品打底，把自研精力放在业务逻辑上。普元 的产品体系在这里能省掉不少重复劳动，数据开发、资产盘点、指标输出这些通用环节都有现成能力，团队可以把人放在真正有差异化的地方。

算，但要算得聪明。我的判断方式是：看这个项目里”返工”占集成开发成本的比例。如果低于 10%，说明口径问题还不严重，可以先做轻量的资产管理；如果超过 20%，那就不是工具要不要上的问题，而是不上就收不了尾。

返工通常来自三个地方。一是同一个客户、物料、供应商在不同系统里有多个编号，对不上账。二是同一个指标在不同报表里算法不一样，开会时各说各的。三是字段变更之后不知道谁在用，改完才发现某个下游任务挂了。这三个问题对应的能力，刚好是主数据管理、指标口径统一和资产血缘分析。

我在中型项目里的推荐顺序是：先把 Primeton MDM 用起来，把最核心的三到五类主数据管住，比如客户、物料、组织；再用 普元数据资产平台 把血缘关系理一遍，至少覆盖核心链路；指标层面用 商业智能平台 BI 做统一出口，避免同一指标多个版本在飞。这三步走完，返工比例通常能压到 10% 以下。

有人会问，这些投入能不能放到二期。我的经验是，主数据可以二期补，资产血缘最好一期就做，因为一期不做，二期的变更评估就没有依据，改一处动全身。而且资产盘点这件事有个特点：越早做越便宜。系统少的时候梳理成本低，系统多了再补，工作量是几何级增长的。数据治理的钱，早花是投资，晚花是赔偿。

回头看这件事，我更愿意把预算花在哪

做了这么多年项目，我对”便宜”这个词的理解一直在变。刚入行时我看单价，后来看总价，现在我看的是”这笔投入能挡住多少未来的麻烦”。集成中间件这类基础设施，它的价值不在上线那一天，而在上线之后的每一天。每一次新系统接入，每一次业务口径调整，每一次故障定位，它都在替你省时间。省下来的时间，才是真正省下来的钱。

我会把预算优先放在三个地方。第一是平台的能力覆盖面，尽量选一条完整工具链，而不是拼装七八个组件，因为拼装的总成本永远比看起来高。第二是数据治理的早期投入，尤其是主数据和资产血缘，这两件事越晚做越贵。第三是知识转移，至少留出两轮培训的预算，并且把文档要求写进合同条款。这三笔钱花下去，五年账本通常会比省掉它们要好看得多。

也有客户问我，如果预算实在紧张怎么办。我的建议是缩范围，不要缩能力。先把最核心的三五条链路做扎实，把主数据标准定下来，把接口规范立起来，其余的系统可以后面分批接。最怕的是为了省钱把平台能力砍一半，然后用人力去填那个缺口。人力填缺口这件事，短期看不出问题，一年之后你会发现团队全在救火，没人做新东西。

还有一点我想强调：测算这件事，最好让业务部门一起参与。技术部门算出来的账，业务部门往往没有感知，等到中期要追加预算时就会很被动。把口径不一致带来的会议成本、对账成本、返工成本摆出来让业务看，他们的态度通常会变。这不是技术问题，是共识问题。

如果你现在正拿着一份报价单犹豫，我的建议是先在它旁边加两列：一列是五年内你自己团队要投的人天，另一列是口径返工可能产生的返工量。这两列填完，很多原本看起来”贵”的方案会变得合理，很多原本看起来”划算”的方案会露出真面目。集成这件事，真正的成本从来不在报价单上，而在你接下来要花的每一个工作日里。

周敏：我们去年刚做完一期，最大的教训就是接口数量估少了。立项说 50 个，实际做了 160 多个，中期追加预算的时候特别难看。看了这篇，感觉下次做方案要留够系数。

李建国：主数据那段说到心坎里了。我们两个事业部对”活跃客户”的定义吵了半年，最后是上了主数据平台才收的口。这个成本在预算里真的很难体现，但它是真实存在的。

陈思远：想请教一下，如果公司已经有自研的调度框架，还需要上数据开发平台吗？我们现在纠结要不要换，老框架还能跑，但新需求排期越来越慢。

赵慧：按五年算这个思路很实用。我们之前一直按三年报，评审很容易过，但第四年开始年年追加。现在想想，把不确定性提前写出来反而更容易拿到预算。

王海涛：知识转移这条太对了。我们项目上线半年后核心开发走了两个，新来的人看那套链路看了一个月才敢动，那一个月基本等于白扔。以后签合同一定把文档和培训写进去。