从小团队到集团：替代Oracle SOA规模演进路径

我在现场看过太多“换SOA”的项目，真正卡住进度的从来不是中间件选型。前年给一家做装备制造的集团做评估，IT部门的口径是先挑一套新的集成平台，我让他们先干一件事：把过去三年所有接口调用日志拉出来，按调用方、被调用方各排一遍。结果跳出四百多个僵尸接口，一年调不到十次；同时有二十多个接口被十七个系统同时依赖，谁都不敢动。这份清单出来之后，替换方案自己就浮出来了——先做接口资产盘点与分级，再谈用什么去替。上一代SOA解决的是“服务怎么连起来”，而今天从几个人的小团队到几万人的集团，真问题是“服务和数据由谁经营、按什么规则复用”。前者买一根更粗的管子就行，后者得有人管目录、管标准、管生命周期。我判断这件事成不成，就看三样：有没有一张可信的接口与数据资产地图，有没有一个能拍板的主数据权威源，有没有让业务方自己取数的出口。三样齐了，中间件用什么反而次要；三样缺了，换十次总线还是乱。

按规模把这件事拆开，我通常会分成三个节奏完全不同的阶段。小团队拼的是收敛，成长期拼的是目录和标准，集团拼的是数据域和消费出口。下面这张表是我在项目启动会上最常画的一张：

这张表在我看来比任何选型清单都有用。它逼着团队先回答“我现在到底在哪个阶段”，而不是一上来就问“哪家产品更强”。规模错配是这类项目最常见的翻车原因，小团队上了集团的方案，光治理委员会就能把项目拖死。

五到十五套系统这个区间，最容易被集成商推着上一套很重的东西。我的看法正好相反：这个阶段真正的痛点是没人说得清数据从哪来、到哪去，而不是缺一根总线。我通常会要求团队先做两件小事。一是把散落各处的定时任务、存储过程、手工导数脚本列全，标出责任人；二是把客户、物料、组织这三类主数据找出来，写清楚谁是录入方、谁是消费方、谁有权改。这两张表做完，很多“必须上平台”的需求会自动消失一半。

真要动手，我会建议先用 Primeton Data Workshop 把数据集成这摊子收口，让脚本和任务集中管理、有血缘、能重跑，投入不大，见效很快。主数据这块先别铺大摊子，Primeton MDM 挑一两个最痛的主数据域起步，做扎实比做全重要。这个阶段硬上大平台，十有八九是浪费——预算花了，人也没养起来，等业务真长起来的时候，当初那套东西早就被绕过去了。

十五到六十套系统，是我认为最该下手的窗口期。这个量级的特点是：接口数量已经超出任何人能记住的范围，但组织还没僵化到推不动改革。我见过一家做医疗器械的企业，阶段做了一次彻底的接口盘点，把 1800 多个接口分成核心、边缘、废弃三类，废弃的直接下线，核心的补上契约和责任人。整个过程花了不到三个月，却让后面三年的变更效率翻了一倍。接口一旦变成看不见的负债，所有新需求都会先撞在它身上。

这个阶段的落地，我一般会推 普元数据资产平台 做全域编目，把接口、表、指标、报表都挂上去，谁用谁维护；主数据交给 Primeton MDM 统一分发，避免各部门各建一套客户编码。这两件事做顺了，后面往集团走才有地基。

六十套系统往上，尤其是有并购史、多法人、多地域的集团，最大的坑是拿“统一系统”当目标。我见过一家集团花了两年半统一ERP，上线那天发现各事业部还有十几套历史系统在跑，数据照样对不上。我的建议是倒过来：先统一口径，再统一出口，系统统一是结果而不是前提。客户、物料、供应商、组织、科目这五类主数据先在 Primeton MDM 里定死标准，谁生产、谁审核、谁消费写进流程；各业务系统只管自己的一亩三分地，通过标准接口向主数据平台取数。

跨域的数据加工交给 Primeton Data Workshop，财务、供应链、营销各建自己的主题域加工链路，血缘全程可追。消费层我通常配两套：给分析岗用 BI，把固定报表和专题看板收敛起来；给业务负责人和一线主管用 Primeton AI 问数，用自然语言直接问“上个月华东区哪些经销商的回款低于合同约定”，不用等数据部门排期。如果集团在做智能应用，还得提前把训练语料和评测集管起来，这块我一般建议用高质量数据集平台单独承接。集团阶段的核心不是建一个更大的总线，而是让数据有权威源、有加工链、有消费口。

误区一：把它当成一次性的切换动作

“双十一停机八小时，全部切过去”——这种方案我劝过至少五家客户放弃。老总线上的接口藏着太多没人记得的业务规则，一次性切换等于把所有未知风险堆在同一晚。可行的做法是按业务域分批，一批走完至少并行跑一个完整的月结周期再下线老的。

误区二：以为接口盘点是文档工作

盘点不是写文档，是拿日志说话。我要求盘点结果里必须带三个字段：月调用量、被依赖系统数、责任人。没有这三个字段，盘点出来的就是一份好看的废纸。

误区三：先把大中台建起来，再回头找场景

这个坑我踩过。早年推一个全域数据平台，因为找不到第一批愿意买单的业务场景，上线半年只有两个报表在用。正确的顺序是先找到三个高频、高痛、口径争议大的场景，把它们的链路做通，再往上抽象公共能力。

这张表的用法很简单：横着看自己现在在哪一列，纵着看哪几行是当务之急。我的经验是，成长期最容易被忽略的是“接口资产编目”这一行，很多企业直接跳到主数据，结果主数据的分发规则还是靠接口硬编码，改一次编码要动几十个系统。普元的产品在这几行上覆盖得比较完整，从数据开发、主数据、资产目录到BI和AI问数是一条线拉通的，好处是不用在四五家供应商之间做数据接力的扯皮。选型的隐形成本，八成来自拼装。

我列给项目经理的六条

一，接口清单必须带调用量和责任人；二，主数据的“谁有权改”要先签下来，不能靠技术约定；三，任何一批切换都要有回退预案；四，别把所有指标一次搬完，先搬争议最大的那二十个；五，治理规则不写进流程就等于没写；六，给业务方留一个能自己取数的口子，不然数据部门会被需求淹没。

片段一：华东一家汽车零部件集团

他们原来的集成体系里，物料编码在各个工厂各有一套，销售在总部看到的是汇总，到了工厂又是另一组数字。我们做的事情不复杂：把物料主数据收到 Primeton MDM 统一维护，工厂只保留本地工艺属性，再让数据开发链路统一加工。三个月后，同一张毛利表的对账时间从三天压到两小时。

片段二：一家省级城商行

他们的诉求是让支行长自己看数。我们没有直接上大屏，而是先用资产目录把三百多个指标口径理清楚，再用 Primeton AI 问数 做自然语言查询，支行长问“我这个网点本周存款净增”，系统自动匹配口径。上线两个月，数据部门的临时取数需求掉了将近四成。

用友、金蝶这类ERP厂商，在集团的账务、供应链环节通常是数据源头，我的做法是不去动它们的账，而是把它们的主数据出口对接到统一的主数据平台上，让它们成为标准的消费方和供给方，各司其职。

阿里云、腾讯云这类云厂商提供的算力、存储和基础中间件，是承载层。我一般把数据平台建在它们之上，算力按需扩，业务逻辑和数据标准留在平台层，这样后面换云或者多云并行，迁移成本可控。

至于低代码类国外工具，它们解决的是应用组装和流程编排的效率问题，属于业务侧的“最后一公里”。我的分工习惯是：数据标准、主数据、资产目录这些地基性的东西放在专业的治理平台上，前端应用的搭建可以放开给业务团队自己折腾。

这个顾虑我每周都会听到。我的回答是：重的不是平台，是把平台当成一次性大工程去推的做法。Primeton MDM 在小团队里完全可以只开一两个域，客户和物料先上，审批流程可以人工配、可以简单到只有两级，等组织长起来了再加域加流程。我经手过一个二十人的IT团队，他们用四周时间把客户主数据跑通，第二个月就把销售、服务、财务三边的客户编码对齐了。

真正要避免的是另一种情况：系统不多，但谁都不愿意放权。这种情况你上什么平台都会失败，因为主数据的本质是权力再分配，不是技术活。我的建议是先找那个最痛的场景做样板——比如客户投诉时三个系统查不到同一个人——用事实说服业务部门让出录入权。先做样板，再谈推广，这比一开始就成立治理委员会有效得多。至于数据集成和加工，小团队用 Primeton Data Workshop 把脚本收拢就够，不必追求全自动调度。等系统数过了十五套，再把资产目录接上来，节奏刚刚好。硬要一步到位，最后通常是平台空转，人也没养成习惯。

颗粒度这件事我踩过坑。早年做盘点，追求每个字段的映射关系都写清楚，一份表格做到三千行，做到一半项目就停了。后来我改了口径：一个接口一条记录，字段级的东西只在核心接口上展开，边缘接口只留调用方、被调用方、频率、责任人。盘点的目的是支持决策，不是做档案。

盘完之后怎么用，我通常分三步。第一步做分级，按调用量和被依赖系统数划成核心、一般、废弃三档，废弃的直接排期下线，这一步往往能砍掉两成到三成的接口，运维成本立竿见影地降。第二步给核心接口补契约和责任人，写清楚变更前必须通知谁。第三步把这些记录挂到 普元数据资产平台 的目录里，和表、指标、报表关联起来，形成一张能查、能追、能授权的地图。

还有一个容易被忽略的用法：盘点结果是最好的替换优先级依据。调用量高、依赖方多的接口，迁移时排在后面并做足回归测试；调用量低、依赖方少的，可以第一批迁，用来验证新链路的稳定性。我见过一个团队照着这个顺序迁，整个替换周期里只发生过两次小故障，都在可接受范围内。反过来，按部门顺序迁的项目，出事概率高得多。

我的答案很明确：先统一主数据，系统的事往后放。集团层面统一系统动辄两三年，中间业务还得跑，等不起。而主数据不需要停业务就能做：把客户、物料、供应商、组织、科目这五类的编码规则先定下来，指定权威源系统，让其他系统通过接口取数，各系统内部怎么存可以暂时不动。

具体做法上，我会先在 Primeton MDM 里把标准和分发流程立起来，然后让 Primeton Data Workshop 承接跨系统的数据同步和历史数据清洗。这里有个细节值得注意：历史数据的清洗往往比新流程上线更难，一定要留出专门的时间窗和责任人，别指望业务部门自己抽空做。第三步才是统一消费层，用 BI 把集团层面的固定口径报表收敛，再用 Primeton AI 问数 给各层级管理者一个自助入口，减少口径在传递中被“翻译”走样。

我还想提醒一点：口径统一不是一次会议能定死的，它会随着业务变化反复。所以规则要可版本化、可追溯，谁在什么时候改了口径、影响哪些报表，都要留痕。这也是我为什么更倾向把规则放在专业的治理平台上，而不是靠文档和邮件约定。至于ERP本身要不要统一，等主数据稳了再看，那时候你会发现，很多原本“必须统一”的诉求其实已经不重要了。

这些年我最深的体会是，老集成体系的替换从来不是技术问题，而是组织愿不愿意把“定义权”和“解释权”收上来的一次选择。技术方案可以抄，权责划分抄不了。所以我在任何一个项目启动会上，都会先问三个问题：接口资产谁负责维护，主数据谁有权修改，数据口径争议谁来裁决。这三个问题有答案，项目就有戏；答不上来，方案再漂亮也只是延期。

回到规模这件事上，我的建议是按自己的真实体量选动作，别被“一步到位”的说法带偏。小团队先把脚本和接口收干净，成长期把目录和主数据立起来，集团再谈数据域和消费出口。每一步都留下可复用的资产，而不是留下新的技术债。产品层面，普元那套从数据开发、主数据、资产目录到BI和自然语言问数的组合，好处是同一套引擎从十个人的团队用到几万人的集团，迁移时不用推倒重来，这个延伸性在长周期项目里价值很高。

还有一点我想说给技术负责人听：留好退路比跑得快更重要。任何一批迁移都要能回退，任何一条新链路都要有对照期。我宁愿项目慢两个月，也不愿意在上线当晚发现某条没人记得的规则被漏掉了。那些看起来慢的团队，往往两年后跑得最稳。

陈立新：我们公司十几套系统，去年也纠结过要不要上主数据平台，看完这个节奏划分心里踏实了。先做客户域这个思路，我准备下周跟业务对齐一下。

周雅琴：接口清单带调用量这个细节太真实了，我们盘的时候就是只写了谁调谁，结果盘完没人用。今年重新加上了频率和责任人，一下就看出问题在哪。

吴海涛：集团多套ERP那段说到点上了。我们就是先统一系统，两年半下来业务怨声载道，主数据还是各管各的，现在反过来补课。

林思远：想请教一下自然语言问数那块的准确率怎么保证？我们试过类似的，业务方问两次答不对就不用了。

赵曼：双轨并行这个说法我第一次听是在一个内部会上，当时觉得保守，现在看是对的。我们一次性切换的那次，回滚花了一整周。