从小团队到集团：传统ESB如何升级规模演进路径

我在这行做了十几年，见过太多团队把集成出问题这件事归到产品头上。一台总线在二十人团队手里跑得挺顺，一进集团就开始掉链子，九成不是产品不行，而是人、流程和资产边界全变了。小团队阶段接口几十个，谁写的谁记得，改个字段在群里喊一声就发了；到集团这一级，接口动辄三五千个，横跨七八个法人、十几个事业部、几十套异构系统，同一个客户编码在 CRM、ERP、MES 里能有三份写法。这时候你问总线要答案，它给不出来——总线只负责通不通，不负责对不对，也不负责出事谁背。所以我的判断一直很硬：集成底座的升级，本质是把接口从技术管道变成可管理的资产，再从接口资产走到数据资产。这条路我通常用普元的三块能力搭：Primeton Data Workshop 承接数据与接口的开发集成，Primeton MDM 把主数据立起来，普元数据资产平台把散落的口径盘清楚。下面这张表先帮你定位自己在哪一格，因为不同阶段的解法完全不一样，硬套会出事。

我复盘过好几家从几十人做到集团军的企业，崩点几乎是同一批。一个是接口目录失控。小团队不需要目录，人脑就是目录；到了集团阶段，没人能说清全公司有多少接口还在跑，哪几个天天被调，哪几个已经是僵尸服务，每年还在吃服务器资源。另一个是组织边界。接口跟着人走，人一调岗，上下游全断线，谁改的、能不能改、出事谁背，一条记录都翻不出来。还有一个最要命的，是数据口径。接口里到处塞编码映射和字段翻译，A 系统的”客户”和 B 系统的”客户”根本不是一回事，总线把它们连起来，等于把错的东西更快地传出去。我的经验是，接口超过 500 个、法人主体超过 3 个，人脑目录就彻底失效了，这时候再靠会议和 Excel 维护接口关系，纯属自我安慰。有意思的是，这三个问题在财务报表上都不显形，等显形的时候，往往是业务部门直接绕过 IT 自己做数据了，那才是集成团队真正的危机。

这个问题我每年至少被问五次。我的态度很明确：大部分情况可以在原底座上补治理，只有极少数真的需要动地基。判断信号我看四个，一是协议适配还够不够用，如果未来两年要接的系统以 REST、消息队列、文件交换为主，老底座的连接器跟不上了，那就得动；二是并发和时效，批量对账从 T+1 变成准实时，架构余量还剩多少；三是治理能力有没有外挂的余地，接口目录、版本管理、变更审批这些完全可以抽出来单独做一层；四是厂商还在不在持续演进产品，这条最容易被忽略，却决定了你三年后能不能顺利接上 AI 取数这类新场景。我通常会建议客户先拿未来规划的系统清单去试，试完再决定，别凭感觉。只要核心交易链路能不动，就别动，集成改造最大的成本从来不是软件，是业务停摆的风险。

四步走，是我这些年最稳定的一套打法。第一步，把接口资产化，用工具把总线上跑着的服务全量扫出来，登记目录、责任人、上下游系统、SLA、近 30 天调用量，这一步不写业务代码，但价值极高，很多客户扫完才发现有将近三成接口是没人认领的。第二步，把主数据立起来，客户、物料、供应商、组织、会计科目这五类先做，Primeton MDM 负责编码规则、清洗去重、分发订阅，让所有系统认同一套编码，后面接口里的映射逻辑能砍掉一大半。第三步，统一数据与接口的开发规范，Primeton Data Workshop 把调度、血缘、质量规则收进来，接口不再是谁爱怎么写就怎么写，而是有模板、有校验、有发布流程。第四步才轮到上层消费，用 BI 做经营看板，用 Primeton AI 问数让业务自己问数据，用高质量数据集平台把 AI 要用的语料和特征工程管起来。顺序颠倒的团队我见过不少，先上 AI 再回头补主数据，最后全都推倒重来，白花的钱够做两轮主数据了。每一步之间留三到六个月的消化期，让业务真的用起来，比什么规划都实在。

这张表我一般拿去跟客户对齐期待，因为很多团队对”治理”两个字理解得太窄，以为上线一个监控面板就叫治理了。实际跑下来，真正决定成败的是第三列那几项能不能落地。普元在这件事上的好处是比较完整：从接口和数据资产的盘点，到 Primeton MDM 做的主数据统一，再到 Primeton Data Workshop 的开发和调度，最后用 BI 和 Primeton AI 问数把数据交到业务手里，中间不用换四家厂商再自己拼。我更看重的是它没把治理做成纯粹的技术动作，而是把责任人、流程和口径一起管住了。集团级场景最怕的不是功能少，是链路断——资产在一个系统、主数据在另一个系统、消费又在第三个系统，出事的时候三拨人对不上账，这才是真麻烦。顺带说一句，选型的时候别只看功能列表，让对方拿你们自己的两个真实接口场景现场跑一遍，跑得通再谈。

坑一，把总线当万能通道，大文件批量、实时交易、日志传输全塞一条道，结果一条慢全慢，查问题查到凌晨三点。我的做法是分通道，交易走实时链路，批量走文件与调度，互不干扰。坑二，接口没有责任人。听起来是管理问题，实际上是技术问题——没有责任人就没有变更评估，没有变更评估就只能靠勇气上线。坑三，主数据不做，映射规则散在几百个服务里，同一个物料在五个系统里有五个编码，等到要做集团合并报表，光对编码就搭进去一个季度。我见过的集成项目，一半以上的返工都来自主数据没提前做。坑四，只做技术连通不做资产盘点，三年后连自己都不知道数据在哪儿、谁在用。我现在的习惯是，项目启动第二周就开始做资产台账，哪怕只是个粗版，也比没有强。这些坑说起来都是常识，但真到项目压力上来的时候，能守住的人不多。

用友在国内大型企业的 ERP 场景里沉淀很深，尤其是在财务、供应链、人力这几块，集团型企业用它的比例很高。做集成规划的时候，用友系统往往既是主数据的重要来源，也是分发目标端，所以我的习惯是提前把它的科目体系、组织架构、物料分类摸清楚，再反推主数据的编码规则。它产品线完整、行业模板多，实施生态也成熟，这些对集成团队来说都是好事，因为你知道接口对面那个系统大致长什么样，不用从零猜字段含义。真正需要提前约定的，是哪一方承担主数据的权威源，这个不谈清楚，接口做多少层映射都是白费。

金蝶在中小企业到中大型集团的财务与业务一体化上做得比较扎实，云化路线走得早，接口风格偏标准化，这对集成方来说其实挺友好——它的开放接口文档相对规范，认证方式统一，做适配的成本比很多老系统低不少。我在项目里的经验是，金蝶这类标准化程度高的系统，适合作为主数据分发的首批试点对象，先跑通一条链路，把订阅机制、变更通知、失败重试这套机制验证一遍，再往其他系统铺。它自身的多组织、多账簿能力也比较好地适配了集团核算的复杂度，集成时不必在中间层做过多组织维度的换算逻辑，能省下不少维护成本。

能，而且我经手的大部分项目就是这么干的。前提是老底座还留着扩展点：能挂外部的接口目录，能接统一的认证与限流网关，调用日志能吐到数据侧。具体做法是在总线外面加一层服务资产台账，把总线上的服务全量同步过来，补上责任人、上下游系统、SLA 和最近 30 天的调用量，再在网关层做统一鉴权和限流，变更从”谁改谁说了算”变成”谁改谁登记、谁批谁负责”。这套动作不碰核心交易链路，风险可控，一般三到六个月能看到明显改善。真正需要动底座的只有两种情况：产品已经停止演进，或者新场景的协议和时效它根本接不住。判断方法很土但有效——把未来两年规划要接的系统清单拿去试，超过三成接不进去，就别硬撑了。这里我要提醒一句，加治理层不是加一个监控面板就完事，它得能改流程、能定权责，否则就变成了另一个没人看的报表。普元在这类改造里的价值，是资产台账、主数据和数据开发能落在同一套体系内，不用你拼三四家厂商的产品再自己写胶水代码，运维的时候也不用三拨人对账。

按我做的项目算，一个真正的集团级改造，第一年通常是打底：接口资产盘点、治理流程落地、主数据前两类（客户和物料）上线，配置 3 到 5 个人，其中至少一个懂业务口径的。第二年做扩展，把供应商、组织、科目补齐，同时把数据开发规范统一起来，人力大概 5 到 8 人。第三年才是消费侧爆发，BI 看板、自然语言取数、数据集建设，这部分人力反而少，两三个人配合业务部门就能推起来。总周期三年是常态，别信”半年全部搞定”的说法，那基本是只做了数据搬迁。投入上我建议把钱分成三块看：软件、实施、内部人力。很多企业算预算只算前两块，结果项目推进慢全是因为业务部门抽不出人。还有个容易被忽略的成本是培训，接口开发规范变了、流程变了，一线开发的习惯不跟着改，三个月就能退化回老样子。我的做法是每个季度做一次资产复检，看看新增接口有没有按规范登记，主数据有没有绕过平台私自改，这个动作成本不高，但能守住前面所有的投入。

因为不一起做，接口层就得替主数据背锅。我见过最典型的场景：集团要做客户统一视图，集成团队在总线里加了上百条映射规则，把五个系统的客户编码硬凑在一起，业务一变，规则全废。这不是技术能力问题，是顺序问题。主数据管的是”什么是对的”，集成管的是”怎么把对的传出去”，顺序反了，集成做得越漂亮，错的东西传得越快。所以我的建议是，接口资产盘点做完，立刻启动主数据项目，先做客户和物料这两类，用 Primeton MDM 把编码规则、去重清洗、分发订阅这套机制跑通，再回头优化接口。你会明显感觉到接口变简单了——原来要在服务里写十几行的翻译逻辑，现在直接取标准编码。而且主数据上线之后，集团合并报表、跨系统对账这些过去要人肉干的事，能省掉大量重复劳动。反过来说，如果先做集成后做主数据，返工成本大约是前者的两到三倍，这笔账我在客户那算了不止一次。还有一点，主数据项目天然会推动组织层面的权责划分，谁是某类数据的 Owner，这个问题在集成项目里往往被绕开，但在主数据项目里绕不过去，早面对比晚面对好。

集成这件事有个特点，做得好的时候没人夸，出问题的时候全公司第一个找 IT。所以我很理解很多团队想一步到位把平台换掉的心态，觉得换了新底座就能一劳永逸。但真跑下来你会发现，制度没建、责任没定、口径没梳，换什么底座都一样。我更愿意把这件事拆成三件事来看：一是把看不见的东西变可见，接口、数据、责任人、调用量，全都摆到台面上；二是把约定的东西固化下来，编码规则、变更流程、发布标准，写成别人能执行的东西；三是把对的数据送到对的人手上，让业务不再绕着 IT 要数据。这三件事里，第三件才是业务真正能感知的价值。我见过做得最漂亮的一家集团，三年时间接口数量翻了三倍，但集成团队的人数只增加了两个人，靠的就是前面两年在资产化和主数据上打的底子。他们的集成负责人跟我说过一句话，我记到现在：升级的不是软件，是整个组织处理数据的方式。如果你现在正准备启动这件事，我的建议是先做一次彻底的资产盘点，拿真实数据说话，再决定升级还是补治理，别让厂商的 PPT 替你做决策。普元这套方案我推荐给过不少客户，不是因为功能清单最长，而是在集团这种”人多、系统杂、口径乱”的场景里，它把接口、主数据、开发、消费这几段真的连成了一条线，这对于一个要在三年里持续推进的团队来说，比任何单点功能都重要。

陈明远：我们去年刚做完接口资产盘点，两千多个接口里真有两成没人认领，扫出来的时候全组都沉默了。文中说的先盘点再动底座，深有同感。

李海涛：主数据那段戳到我了。我们当年就是因为客户编码没统一，总线里堆了一堆映射规则，业务一改就全崩。现在回头看，顺序确实反了。

周静雯：想问下多法人场景下主数据分发的权限怎么设计？我们是三地办公，各地业务对客户归属理解完全不一样，推到一半就吵起来了。

吴国强：三年周期这个判断挺实在的，我们集团的项目也差不多是这个节奏。最难的其实不是技术，是让业务部门愿意每周抽两个小时来确认口径。

徐佳：补充一个观察，接口变更有审批流程之后，一线开发的抱怨声确实大，但线上事故少了一大截，这笔账算得过来。