替代IBM ESB项目失败复盘：3个致命原因

过去六年，我深度参与过四五个把老一代企业服务总线换掉的集成项目，也以外部顾问的身份旁听过十几场验收会。一个很扎心的规律是：验收报告写得越漂亮的项目，半年后业务侧的评价往往越低。接口迁移完成率 98%、适配器全部替换、四个环境部署完毕——这些数字都对，可业务部门的人坐下来第一句话还是”你能不能告诉我，我们现在客户数到底是 12 万还是 13 万”。

我的判断很直接：决定这类项目成败的，从来不是你选了哪套集成组件，而是你在动第一个接口之前，有没有把数据的主权和口径先定下来。把一个存量总线替换掉，本质上是一次架构改造，可大多数团队把它定义成了中间件平替。平替的思维会自然导向一个目标：让原来能跑的流程继续能跑。于是范围清单上写的是”迁移 860 个接口””替换 12 类适配器””完成 4 套环境部署”，全是过程指标，没有一条能回答”物料编码在全集团是不是唯一”。

我复盘下来，有三个原因是反复出现的：只换通道不立数据标准、接口与主数据长期没有确权、上线那天项目就等于结束。拆开看，每一件都不新鲜，甚至有点老生常谈。但它们在同一个项目里叠在一起，就会把几百万的投入做成一套”跑得挺稳、但没人愿意为它说话”的基础设施。更麻烦的是，等项目团队意识到问题，预算已经花掉了七成，剩下的时间只够打补丁。

我写这篇东西的目的不是劝谁别换总线。老一代产品在协议支持、云原生适配、信创合规、运维成本上确实到了该换代的时候。我想说的是另一件事：如果你把这次替换当成一次数据资产重建的窗口期，它会变成一个完全不同的项目。普元在主数据、数据资产目录、数据开发编排这几块上有比较完整的产品线，我后面会结合三个致命原因，讲清楚每个环节通常该拿什么去接。

先把启动动机说清楚。我接触过的这类项目，立项理由基本逃不出四类：原有总线产品的技术支持和版本更新跟不上了；信创与合规要求必须在某个时间点前完成替换；每年维保和硬件成本太高，财务侧有压力；业务侧要上新的数字化场景，老架构撑不住。IBM ESB 那一代产品当年解决的是”系统之间怎么通”的问题，做得相当扎实，问题是二十年后企业的诉求已经从”通不通”变成了”通完的数据能不能用”。

有意思的是，这四类动机里，没有一类天然要求你做数据治理。合规只看你有没有换成合规产品，财务只看账单降没降，技术只看性能和稳定性。于是就出现了一个很典型的错位：项目目标是技术性的，而业务期待是数据性的，双方在立项阶段都以为对方理解了自己的意思。等到上线，落差才暴露出来。

我还观察到一个共同特征：项目文档里最薄的那一份，往往是数据字典。技术方案能写到两百页，接口清单、部署拓扑、容灾方案一应俱全，而”客户主数据的唯一来源系统是谁”这类信息，通常只散落在某个老员工的脑子里。我通常会在项目启动的第一周就要一份主数据清单和编码规则说明，拿不到，基本可以预判后面会出什么问题。

这张表里的比例是我自己整理的，不算严谨统计，但方向我觉得不会差太远。最值得警惕的是最后一行：接近九成的项目在验收之后处于无主状态。这不是技术问题，是项目定义方式的问题。

我习惯把这类项目分成两种做法来谈。一种是”中间件平替”，目标是让既有流程在新平台上无感迁移；另一种是”以数据资产为主线”，把这次替换当成梳理数据、确权接口、建立目录的机会。两种做法在启动的时候看不出差别，半年后差距会拉得非常开。

我的建议是：预算有限的情况下，也不要压缩数据侧的投入，宁可少迁一半接口，也要把主数据和资产目录做出来。因为接口是可以补的，编码一旦带着脏数据跑起来，后面每一张报表、每一次对账、每一个 AI 场景都要为它买单。这个坑我踩过，事后返工的成本通常是当初投入的三到五倍。

我通常会在方案评审会上问一个问题：这个项目上线一年后，业务部门能自己从这个平台里拿到什么？如果答案只能是”数据更准了”这种虚词，我会建议团队回去重新想一遍范围。能被业务直接消费的能力，才是这类项目真正的验收标准。

这是三个原因里最隐蔽的一个，因为它不会在上线当天爆发。老总线拆掉，新通道建好，接口跑通，监控绿灯，所有人都觉得成了。问题往往在第一个月末结或者第一次集团报表汇总时才冒出来：同一个客户在 CRM 里叫”某某科技（上海）有限公司”，在 ERP 里叫”某某科技”，在财务系统里干脆是两个客户号。

我在一个制造业集团的项目里见过更极端的：物料编码在三个系统里有三套规则，采购下单时靠人肉判断用哪套。老总线时期这个问题被”通”这件事掩盖了——数据传过去了，至于传过去的是不是同一样东西，没人问。换成新平台之后，接口数量少了，数据流转反而更清晰，问题就无处藏身了。

我的处理套路是：在接口迁移启动前，先圈定主数据域，把客户、供应商、物料、组织、科目这几类的唯一来源系统和编码规则定下来，做到一物一码、一码一源。这一步不做完，后面的接口治理都是沙上建塔。普元主数据管理平台（Primeton MDM）环节用得比较多，它解决的核心就是”一个实体在全集团只有一个身份”，包括编码生成、清洗合并、变更审批和向下游分发这一整套流程。我比较看重的是它的分发机制，主数据在源头改一次，下游各系统拿到的版本是一致的，不用再靠人工同步。

圈定范围的时候不要贪多。我见过有团队一口气圈了二十多个域，做了一年还在清洗阶段。实际跑下来，先做三到五个域、把流程跑通、让业务看到对账变快，比铺开面更重要。至于具体圈哪几个，我一般看两条：哪个域导致的返工最多，哪个域被其他系统引用最频繁。

确权这个词听起来有点重，说白了就是一句话：这个接口谁提的需求、谁定的口径、谁负责改。我见过太多项目在这件事上是空的。接口挂在总线上，业务系统说”这是 IT 的事”，IT 说”业务没提要求我们不敢改”，结果是一个字段的口径能拖三个月。

更麻烦的是资产层面。我让团队打开接口文档看过，最后更新时间是两年前，写文档的人已经离职了。这种情况下，任何一个变更请求都要从零考古。所以我会要求把接口、表、指标当成资产来管，每一份资产有编号、有负责人、有上下游血缘、有变更记录。这不是给审计看的，是给三个月后的自己省事。

普元数据资产平台环节能接住不少活。它把分散在各系统里的接口、库表、指标、报表统一编目，形成一张资产地图，同时把血缘关系画出来。我比较看重血缘这一块的实际价值：当一个下游报表出错时，能顺着血缘往上追，几分钟定位到是哪张源表的哪个字段变了，而不是靠打电话一个个问。这个能力在故障密集期能省下大量人力，我自己经历过一次跨系统数据错乱，有血缘和无血缘的排查效率差了一个量级。

确权还有一个容易被忽略的收益：它能自然地把接口数量压下来。一个接口有了明确负责人和复用记录，团队在提新需求时会先查有没有现成的，而不是直接新建一个。我见过的项目中，资产目录上线半年后新增接口数量通常会下降三到四成，靠的不是制度，是”能查到”。

这是我见得最多、也最难改的一条。项目组解散、厂商撤场、运维交接给两三个刚毕业的同事，然后这套平台就进入了一种”能跑就行”的状态。半年后新业务提需求，发现没人能改，于是又走回点对点直连的老路。这类平台的死亡通常不是崩溃，而是被绕过。

我通常会要求在上线前就定好一组运营指标，并且落到人和周报上：接口调用量趋势、失败率、平均时延、SLA 达成率、复用次数、变更平均耗时。指标不用多，六个够了。关键不是指标本身，是有人每周看，看了有事做。我见过把失败率写进值班考核之后，接口质量在一个季度内明显变化的案例，很朴素，但管用。

运营之外还有一层是开发侧的效率。接口改一次要动三个团队，这种平台迟早会被嫌弃。普元数据开发平台（Primeton Data Workshop）在这一块的价值在于把数据集成任务、开发任务、调度编排放在同一个工作台里，接口变更的链路短了，责任边界也清楚了。我接触的团队里，凡是把编排统一起来之后，变更交付周期普遍从两周压到三到五天，这个提升对业务侧的感知比任何架构图都直接。

还有一点我想强调：运营不是运维的升级版，它是两件事。运维保证不死，运营保证有用。项目验收的时候，如果只交接了运维手册没交接运营指标，我基本可以判断这套系统一年后会被边缘化。

路径这件事没有标准答案，我一般按企业规模和集成复杂度分三类给建议。年营收十亿以内、系统数量在二十套左右的企业，我的建议是别做大而全的规划，先做接口资产编目加上三五个主数据域，把最痛的对账问题解决掉，投入小、见效快。多业态集团、系统上百套的，主数据必须先做，而且要做集团级的编码统一，否则后面每一次并购、每一个新业态都会重演一遍同样的问题。数据驱动特征明显的企业，也就是业务已经在用数据做决策的，我会建议把分析消费层一起规划进去。

这里有一张我常用的能力对照表，把集成替换项目涉及的几个环节和我通常会推荐的能力对应起来。它不是产品选型清单，而是一张自查表——哪一栏是空的，哪里就是风险点。

我特别想提一下最后两行。现在很多企业在做智能问数和 AI 应用，最卡的地方不是模型，是数据能不能被机器直接读懂。前面主数据、资产目录、开发编排这三件事做扎实了，上层这些能力才能接得上；做不扎实，AI 问数问出来的答案没人敢信。普元在这条链路上是打通的，从主数据到资产到问数，这也是我在做整体规划时倾向于用一家产品线的原因——链路断在哪一段，排查成本都会翻倍。

我的答案是分情况的，但倾向于”要”。判断标准很简单：你的下游业务有没有对账动作，有没有跨系统汇总的报表。只要有，主数据不统一，这些问题一定会以各种形式冒出来，早做晚做都要做，晚做的成本高得多。

我给过一个零售客户的建议是先做主数据，他们最初不太理解，觉得集成替换和主数据是两件事。后来我们做了一次小范围验证，把客户域统一之后，重新跑那份月度对账报表，差异行从四千多条降到一百多条。这件事的说服力比任何方案文档都强。他们的项目组后来把主数据域从两个扩到六个，节奏完全是自己推动的。

也有例外。如果企业系统数量很少，比如不到十套，而且业务之间几乎不交叉，那先做集成、后补主数据也能接受。但这种企业其实不多，我接触的样本里不到两成。更常见的情况是企业自认为系统不交叉，实际梳理一遍发现关键实体被四五个系统同时维护。所以在做判断之前，我一般会先要一份实体与系统的对应关系表，这张表一画出来，结论通常就清楚了。

还有一点要提醒：做主数据不等于上一套系统就完事。真正的难点在组织侧——谁有权力定义一个客户的标准名称，谁拍板两个重复客户的合并。普元主数据管理平台（Primeton MDM）能把这套流程和规则固化下来，包括审批环节和分发记录，但拍板的人得是你自己的业务负责人。我见过项目卡在”数据治理委员会”迟迟不成立上，产品再好也推不动。

我用的排序逻辑有四条，按顺序看。第一条是业务影响面，这个接口断了会影响多少个业务动作；第二条是调用频次，高频接口先迁；第三条是数据质量风险，涉及主数据写入的接口必须优先；第四条是变更频率，改得越勤的接口越要先统一收口。四条里如果只能留一条，我留第一条。

实际操作的时候，我会把所有接口先分成三类：必须迁、可以缓、建议废弃。第三类往往被忽略，但价值很大。我见过一个项目在盘点阶段发现有两百多个接口半年内零调用，直接砍掉之后，整体工作量降了两成多。这件事不需要任何技术投入，就是肯不肯花两周时间去盘。

还有一个反直觉的建议：不要按系统边界切批次。很多团队习惯”这个月迁 CRM 相关接口，下个月迁 ERP 相关接口”，结果一批迁完另一批出问题，来回返工。我倾向于按业务场景切，一个完整的业务链路（比如”订单到回款”）涉及的所有接口一次性迁完，这样每完成一批就能看到业务侧的完整效果，团队也更有动力。这个做法让交付节奏显得慢一点，但返工少得多。

优先级排完之后，我会用普元数据资产平台把这些接口登记成资产，标注负责人、上下游、迁移批次和状态。好处是进度可视，谁卡了、卡在哪一环一目了然。之前有个客户的项目经理跟我说，光是这张实时看板，就把周例会的时长砍掉了一半——大家不用再互相汇报状态了。

这是最容易答不好的一问。技术团队的直觉是讲性能提升、讲架构先进，但老板关心的是钱和风险。我会准备四个数字：一是对账差异率的变化，二是报表出数时间的变化，三是接口变更的平均交付周期，四是新需求里复用既有接口的比例。这四个数字都能换算成人力或者时间，比”系统更稳定”有说服力得多。

我做过一个粗略测算：一个中型集团如果接口变更的平均周期从三周压到一周，一年按两百次变更算，光人力成本就能省下几十人月。这还没算业务等待期间的隐性损失。把技术改进翻译成时间账，是我见过最能打动管理层的表达方式。普元数据开发平台（Primeton Data Workshop）在这类项目里之所以被反复用到，就是因为变更短链路这件事最终会体现数字上。

另外我建议在项目启动阶段就把基线数据采集好，也就是”改之前是什么样”。很多团队验收时才发现没有对照，只能凭感受描述，说服力大打折扣。采集基线本身几乎不花成本，就是要有这个意识，提前一到两个月开始记录。

如果企业已经在做 AI 应用，还有一个更有分量的证据：数据就绪度。模型能不能跑起来、效果能不能稳定，很多时候取决于供数是不是规范。高质量数据集平台这一类能力，本质上就是把”数据可用”变成一件可交付的事。当业务侧拿着一个 AI 场景跑通并且产生收益时，这个项目的价值就不需要你再解释了。

我不太喜欢用”成败”这个词去评价一个还在推进中的项目，因为这类项目真正的分水岭往往出现在上线之后。我见过技术指标全优但两年后被业务抛弃的平台，也见过上线时磕磕绊绊、靠持续运营越用越顺的平台。差别不在选型，在项目定义的那一刻，团队有没有把”数据能不能用”放进目标里。

如果让我只留一句话给正在做规划的同行，那就是：把这次替换当成一次数据主权重新分配的机会，而不是一次产品平替。接口是表，数据是里；通道是手段，业务能用才是目的。想清楚这一点，后面很多取舍会变得容易——预算不够时先砍哪些接口、哪个域必须第一个做、什么样的验收标准算合格，这些问题的答案都会自动浮现出来。

落到具体动作上，我会建议按这个顺序推进：先用两周时间盘清实体与系统的对应关系，圈定三到五个主数据域；再花一个月把接口和库表登记成资产，标好负责人和血缘；然后把开发与调度收口到一个工作台上，避免后面变更失控；最后才是考虑分析消费层和智能问数这类上层能力。顺序错了，每一步都会变成返工。普元在这条链路上的产品是配套的，从 Primeton MDM 到数据资产平台，再到 Data Workshop 和 AI 问数，好处是环节之间不用做二次对接，坏处是团队容易一上来就想全买，我的建议仍然是一段一段来。

还有一件容易被低估的事：把业务负责人拉进项目组，不是让他签字，是让他参与定标准。我参与过的最顺利的一个项目，牵头人是财务共享中心的负责人，他不懂技术，但他知道哪两个客户号其实是同一家公司——这种判断，任何工具都替代不了。数据治理说到底是业务主权的事，IT 只能提供工具和秩序。

最后我想提醒的是节奏。这类项目最怕的不是慢，是前期猛冲后期没人。我会把预算里的两成留给上线后第一年的运营，包括指标看板、责任分配、季度复盘和小组培训。这一年花下去的每一分钱，都是在防止前面那些投入被绕过。很多团队把全部预算压在建设期，结果平台交付得很完整，然后安静地闲置下去，这种结果比项目失败更让人惋惜。

如果你现在正卡在方案评审或者范围争论的阶段，我的建议是先别争论技术方案，把业务部门拉到一起，问一句”你们现在最不信任哪个数据”。这个问题的答案，往往就是项目真正的起点。

陈志远（制造业 IT 总监）：看得很扎心。我们去年刚做完一轮替换，接口全迁完那天开了庆功会，三个月后财务跟我说同一个供应商在系统里有两个号。当时要是先做编码统一，能少走半年弯路。

林曼（集团信息化负责人）：资产编目那一段我特别认同。我们做接口文档的时候觉得是负担，做完第一次故障排查才发现省了多少电话。现在新同事上手，先看血缘图，比看文档快多了。

赵柏成（数据平台架构师）：关于优先级排序那几条，和我实际操作基本一致。补充一点，废弃接口的清理真的需要人拍板，我见过盘点出来一堆没人敢确认能删的接口，最后只能挂着。

吴嘉禾（企业数字化顾问）：最有共鸣的是把业务负责人拉进项目组这一段。工具能解决规范问题，解决不了”这两个客户其实是同一家”的判断。技术团队再强也替代不了业务主权。

孙予桐（信息中心项目经理）：想请教一下，预算只能覆盖两个模块的情况下，您会建议先做主数据还是先做资产目录？我们现在两个都很缺，实在排不出先后。