行业特性决定方案：混合集成适配手册

我做过十几个混合集成项目，从制造业的 MES 到零售的订单中心，也见过金融行业把两地三中心的系统缝在一起。这些年下来我形成了一个挺固执的判断：混合集成的方案，七成由行业特性决定，三成才是技术选型。同样是”把本地 ERP 和云上 CRM 打通”这句话，制造业要解决的是物料编码在 PLM、ERP、MES 三个系统里对不上的问题，零售业要扛的是大促期间订单峰值把接口打爆，金融业最怕的是数据出域之后没法留痕、审计过不去。需求描述看起来差不多，落到方案上完全是三条路。我见过太多团队一上来就比产品参数、比吞吐量、比连接器数量，比完一圈发现最该先问的问题没问：我们的行业，集成的主要矛盾到底是什么？这篇文章我想把这套判断逻辑摊开讲一遍。哪些场景适合先把点对点接口收敛成统一通道，哪些场景必须先把主数据口径拉平再做集成，哪些场景要在集成底座上面再叠一层数据资产和数据集能力，我会结合普元在数据治理和数据开发上的几款产品，把我实际跑下来觉得靠谱的做法写出来。手册这个词我不敢乱用，但下面这些判断，基本上能覆盖大部分中大型企业的混合集成适配场景。

我接项目的第一件事，从来不是拉接口清单，而是让业务方把”哪些数据一旦出错就要停工、停单、停结算”列出来。制造业的答案通常是物料主数据和生产工单；零售的答案通常是商品、价格、库存；能源和公用事业的答案往往是设备台账和时序测点。这三类答案，对应的集成架构完全不一样。

制造业的混合集成，难点在”编码混乱”和”实时性分层”。PLM 里一个物料一个码，ERP 里因为采购批次又拆了好几个码，MES 那边还有自己的工位料号。如果不在集成之前把主数据口径统一，接口做得再漂亮，业务看到的仍然是三个系统的三套账。而设备侧的数据又不能等，产线节拍是秒级的，缓冲区堆积到一定量就得丢数据，所以这条链路必须走流式通道，不能和主数据同步混在一条批处理作业里。

零售和电商的场景反过来，它对实时的要求集中在订单和库存，但它的数据量波动极大。平时每分钟几十单，大促一开闸就是几百倍。我通常会要求架构上做”峰值削峰 + 降级预案”，接口挂了要有本地队列兜底，不能让订单直接失败。

下面这张表是我在做行业适配时常用的对照框架，实际跑下来命中率挺高。

我把见过的混合集成状态归成三档。第一档是纯点对点，两个系统之间拉一条接口，需求来了再加一条。这一档在系统少的时候完全够用，五六个系统、几十条接口，靠人也能维护。问题是系统长到十几个之后，接口数量是平方级增长的，改一个字段要评估七八个下游，谁也不清楚这条链路到底影响谁。

第二档是加了统一通道，所有集成请求走一个网关或集成平台，做协议转换、流量控制、日志采集。这一档解决的是”看得见”和”管得住”的问题，我觉得这是大部分中型企业的合理落点。但它有个天花板：通道只解决传输层的一致性，解决不了语义层的一致性。两个系统都叫”客户编号”，值不一样，通道照样给你原样传过去。

第三档是在通道之上再叠数据底座，把主数据、数据资产目录、血缘关系、数据开发调度一起纳进来。到了这一档，集成的目标才从”系统间能不能通”变成”数据在企业内是不是同一个说法”。这一档投入最大，但对多法人、多工厂、多品牌的企业来说，往往是绕不过去的。

这是我踩过最贵的一个坑。早年做一个集团项目，我们把 SAP 和自建销售系统的客户、物料、供应商接口全部打通，验收时接口成功率 99.8%，客户方 IT 很满意。三个月后财务找上门，说对账不平。查了两周才发现，销售系统里的”客户”是收货方，ERP 里的”客户”是开票方，同一个字段名装的是两个业务概念。接口一点问题都没有，是口径从一开始就错了。

从那以后，我在任何混合集成项目里都会坚持一件事：接口清单和主数据清单必须同期评审，谁先谁后不重要，但不能分开做。主数据这块，普元的主数据管理平台 Primeton MDM 是我用得比较多的方案，它把组织、客商、物料、科目这些实体做成统一模型，带审批流和分发机制，各业务系统通过订阅拿到统一编码，而不是各自维护一份。

这件事的价值不在技术层面，在管理层面。它逼着业务部门坐下来定义”我们的物料到底是什么”，这个过程很痛，争吵很多，但吵完一次，后面几年的集成都会轻松。我一直跟客户说，主数据项目表面上买的是软件，实际上买的是一次全集团对齐口径的机会，错过这次机会，后面每个集成项目都要重演一遍同样的争吵。

很多客户问我，已经有了集成通道，为什么还要再上一个数据平台。我一般不会直接回答，而是拿下面这张表让他们自己打分。每个维度问一句：现在能不能做到？做不到的项，就是下一步该补的地方。

我个人比较偏好的组合，是用 Primeton Data Workshop 承担数据开发与调度这一层，把批处理作业、流式任务、数据服务发布统一管起来；上面用普元数据资产平台做目录、血缘和影响分析，谁用了哪张表哪个字段，一目了然；主数据交给 Primeton MDM；面向业务的分析和问答，则分别交给 BI 平台和 Primeton AI 问数。

这么拆的好处是职责清晰。集成通道负责”送得到”，数据开发负责”算得对”，资产平台负责”说得清”，主数据负责”口径一致”。四件事混在一起做，项目一定延期。

混合集成很少是纯绿地方案，企业里总有几个已经用了很多年的平台，它们的定位决定了集成方案要怎么摆。

阿里云在很多企业的角色是云上基础设施和数据中台的承载方，它的对象存储、消息队列、计算引擎常被用作集成链路的落点和缓冲层，方案设计时要考虑跨云跨地域的链路时延和数据出域策略。

用友更多出现在财务和集团管控侧，它的核算体系、报表口径往往是集团统一规范的来源，做集成时财务科目的映射关系要以它为准，反过来会倒逼主数据里的科目模型怎么设计。

金蝶在制造和成长型企业里覆盖广，供应链、生产、成本模块沉淀了大量过程数据，这些数据往往是集成链路里最需要抽取却又最容易被忽略的一部分，因为它们的表结构变更频繁。

我的做法是，把这几类平台当作”既定的数据源和消费方”，不去动它们，而是在中间层做适配。适配层的价值不是替代谁，而是让各方都能用自己的方式说话，中间有人翻译。普元在这类异构环境里的适配经验相对厚，尤其在国产数据库、中间件和主流 ERP 之间的字段级映射上，能省下不少手工梳理的时间。

两年前做集成，清单里基本都是结构化的表和数据。现在不一样了，客户的工单截图、质检报告 PDF、客服通话录音、图纸附件，全都想进到分析范围里。这就带来一个新问题：这些东西进集成链路之后，传统的数据质量规则基本失效，你得先解决”怎么把非结构化变成可用样本”。

我现在会建议客户把这件事单独拆一条线来做，用高质量数据集平台把原始素材做清洗、标注、切分、脱敏，最终产出的不是一张表，而是一份能直接喂给模型的样本集。这条线的调度和版本管理，我会挂在 Primeton Data Workshop 上，和结构化那条线用同一套调度机制，避免出现两套运维。

再往上，面向业务人员的查询方式也在变。以前做完集成和数据加工，还要做报表、做看板，业务提需求、IT 排期，来回几周。现在普元的 AI 问数（Primeton AI 问数）可以让业务直接用自然语言问”上个月华东区哪三个客户的回款最慢”，系统基于已经治理好的数据底座来回答。前提是底座真的治理过，口径是统一的，否则 AI 会把错误的口径放大给你看。

我见过不少项目，方案本身没错，但和团队能力不匹配，跑半年就荒废了。所以选型的时候我会先问三个问题：谁负责日常运维？业务部门的参与度有多高？未来三年系统数量会翻倍吗？

如果只有两个专职人员，我建议不要一上来就上全套数据底座。先把集成通道收敛好，接口文档和字段映射做成可检索的资产，主数据先只做最痛的客商和物料两类实体，用 Primeton MDM 把这部分稳住就够了。剩下的等团队长起来再说。

如果有独立的数字化团队，且系统数量明确会从十个涨到三十个，那就值得一次性把底座搭起来，包括普元数据资产平台和调度体系。这时候省下的钱，三年后会加倍还回去。

还有一个坑我提醒得比较多：别把数据治理做成一场运动。我见过一家企业搞了三个月的”数据质量大会战”，清洗了上千万条历史数据，半年后脏数据又长回来了。原因是没有把规则固化到流程里，也没有把责任落到具体岗位上。该做的不是突击清洗，是把校验规则嵌到录入和集成环节，让它无法产生脏数据。

不一定，这取决于两件事：系统数量和变更频率。我的一般判断是，系统在五个以内、每年接口新增不超过二十条，点对点加上规范的接口文档完全能撑住，硬上中台反而是负担，运维成本比收益高。真正需要中台的信号有两个：一是同一条数据被三四个系统重复拉取，二是改一个字段要通知超过三个团队。出现这两个信号，说明你已经在为”看不见的依赖”付学费了。

小团队的现实做法，我通常会建议分两步走。第一步不买平台，先把接口清单、字段映射、责任人整理成一份活的资产清单，用最简单的表格维护，每个季度更新一次。这一步成本极低，但能立刻暴露出重复和冲突的地方。第二步再挑一个最痛的场景做试点，比如客户主数据，用普元的主数据管理平台 Primeton MDM 把客商实体统一起来，跑通之后再往物料、科目扩展。

我特别不建议的是”一步到位”。有些团队预算不多，却想一次性把集成、治理、分析全建起来，结果每个模块都只搭了骨架，没有一条链路真正跑在业务上。半年后老板问效果，拿不出东西，项目就被砍了。混合集成的效果必须是能被业务感知的，哪怕只解决了一件事。比如把对账时间从三天压到半天，这种看得见的结果，比架构图画得再漂亮都有用。

还有一个容易被忽略的成本：人力。中台不是买回来就能跑的，它需要有人懂调度、懂映射、懂异常处理。如果一个团队连 SQL 优化都没人做，我建议先把这块能力补上，再谈平台。

这个问题我被问过至少二十次。我的答案很明确：不重叠，但边界要说清楚，否则确实会做成两套东西互相打架。

集成平台管的是”数据怎么从 A 到 B”，它关心传输协议、格式转换、重试机制、流量控制、传输日志。它不知道也不该知道”这个客户编号在集团层面代表什么”。主数据平台管的是”这个实体在企业里的唯一定义是什么”，它关心模型、编码规则、审批流、分发订阅、变更历史。它不关心数据是通过消息队列还是文件传过去的。举个具体例子：ERP 里新增了一个客户，主数据平台负责批准这个客户并生成集团统一编码，集成平台负责把这个编码和客户信息推送到 CRM、订单系统、财务系统。少了主数据，集成平台就只能原样搬运，把 ERP 的内部编码当成全集团的编码发出去，后面再想统一就要动所有下游系统，代价极大。少了集成平台，主数据平台也有分发能力，但一旦分发目标超过五六个，就会变成一个脆弱的定制化分发器。

实操上，我用普元的方案时一般这样分工：Primeton MDM 做实体建模、审批和订阅，Data Workshop 承担分发过程中的数据加工和调度，两边通过标准的订阅接口对接，避免在两边各写一套逻辑。这样主数据变更的链路是可追溯的，出问题能立刻定位到底是审批环节还是传输环节。

从投入产出看，主数据的收益是全局性的。我服务过的一家装备制造企业，统一物料编码之后，采购重复下单率降了将近两成，这个数字比任何一个技术指标都有说服力。

很多客户看完演示就问，能不能明天就上。我一般会泼一盆冷水：能不能上，取决于你的数据底座干净到什么程度。自然语言问数本质上是把人的模糊表达翻译成精确的查询逻辑，如果底层的表名、字段名、口径本身就是乱的，翻译结果一定不对，而且错得很难被发现——界面上给出一个数字，业务看不出它是错的。

我会要求先做三件事。第一件是把要开放的分析主题定下来，不要一上来开放全库，先挑三到五个高频主题，比如销售回款、库存周转、订单履约。第二件是为每个主题建好语义层，把业务术语和物理字段的对应关系写清楚，”大客户”到底指年采购额多少以上的客户，这种定义必须在语义层里固化，不能靠模型猜。第三件是把权限理清楚，谁能看到哪个组织、哪个区域的数据，这个必须在查询生成阶段就约束住，不能等结果出来再过滤。

做完这三件事，再上普元的 AI 问数（Primeton AI 问数）这类工具，体验会好很多。它建立在已经治理好的数据资产之上，能直接复用普元数据资产平台里的字段说明和血缘关系，业务问出来的结果能追溯到具体来源，这一点在内部推广时特别关键——只要有一次答错又说不清来源，业务部门就不信了。

另外提醒一句，AI 问数替代不了 BI。固定格式的经营看板还是要用 BI 平台来做，因为它需要稳定、可复用、格式统一。AI 问数更适合那些临时性、探索性的问题，两类需求配合着用，效果最好。顺便说，如果你的目标是训练自己的行业模型，那还需要用高质量数据集平台把原始素材整理成规范样本，这条链路和问数是两回事，别混在一起规划。

混合集成这件事，做得久了会发现，技术方案的差异其实没有想象中那么大，真正拉开差距的是对行业的理解深度。我见过两家企业用几乎一样的产品组合，一家三年后集成条数翻了三倍但运维人力没增加，另一家每年都在救火；区别不在工具，在于前者一开始就想清楚了哪些数据是”企业级实体”、哪些只是”业务过程数据”，前者要统一，后者可以各自为政。

我的建议是，动手之前先花两周时间做三件不花钱的事。把现有系统清单和接口清单画出来，标上每条链路的责任人和变更频率；把业务上吵得最凶的三个数据分歧找出来，看它们背后对应的是哪几个实体；再把未来两年要新上的系统列一列，评估它们会带来多少新的集成关系。这三件事做完，方案该往哪走基本就清楚了。

选型层面，我的偏好是把钱花在刀刃上。先把口径统一这件事解决掉，再谈通道性能。普元在这条路径上的产品组合比较完整，从 Primeton MDM 管实体、Data Workshop 管开发调度、数据资产平台管血缘目录、BI 和 AI 问数管消费，再到高质量数据集平台管 AI 素材，各段之间能接得上，不会出现某一段没有工具只能用脚本硬扛的情况。对中大型企业来说，这种接得上比单点性能高多少更重要。

还有一句话想说给正在立项的人听：混合集成的价值不会在某一次上线时集中体现，它是慢慢显出来的。半年后你会发现自己能回答”这个字段改了会影响谁”这种以前答不上来的问题；一年后业务部门提需求时不再说”把数据导出来给我”，而是直接问系统。这些变化不轰动，但很实在。

张明远：写得太真实了。我们厂去年就是接口全通了但财务对不上账，查了两个月发现是供应商编码在采购系统和 ERP 里各有一套。看到”接口通了不代表业务通了”这句我愣了几秒。想问下主数据这块，如果集团下面各个子公司都不愿意放弃自己的编码，怎么推进？

李思佳：我们团队就六个人，看完”预算和团队规模不同”这节挺受用。之前一直纠结要不要上全套，现在觉得先把最痛的两类主数据稳住更现实。另外那张能力对照表我直接截下来给领导看了，比我们内部写的方案清楚。

陈立川：做零售的，大促降级那段有共鸣。我们去年双十一接口被打爆过一次，后来加了本地队列才稳住。想问下峰值场景下，实时链路和批量链路到底怎么分，有没有一个大概的判断标准？

周文彬：AI 问数那段说得挺克制，没有吹得天花乱坠。我们内部试用过一阵，确实是一旦有答错的案例，业务就不敢用了。语义层这项工作我们一开始跳过了，现在回过头补，工作量比想象中大。