破除混合集成迷思：回归业务本质

聊混合集成的人，十个里有八个先掏架构图。我在数据治理这条线上待了几年，看法跟技术侧不太一样：混合集成这个词，被用得太顺手了。云上云下要通、老 ERP 和新 CRM 要通、IoT 采集和报表要通，这些确实都是集成活儿，但它们统统属于”路径问题”。路径问题只要有钱有工期，基本都能解决。

真正拖死项目的是”主语问题”。同一个”客户”在五个系统里有五个编码、三种口径，集成管道铺得越漂亮，脏数据跑得越快。我见过一个年产值四十来亿的装备制造企业，两年换了三套集成中间件，每次演示都很顺，跨系统订单能自动流转。可财务月底对不上账，销售看到的在途库存和仓库台账差着两千万。技术团队反复排查链路，查了三个月，最后发现问题出在物料编码：旧系统 12 位，新系统 10 位，中间靠一张映射表硬扛，映射表里还有两百多条人工维护的例外记录。

所以我会把话说直白：混合集成的胜负手不在集成，在治理。集成解决”能不能到”，治理解决”到的是不是同一个东西”。后者才是业务本质。我的建议是，任何混合集成规划动工之前，先回答三个问题——业务主语是什么、谁拥有定义权、变更怎么同步。这三个问题答不上来，技术再先进也只是加速混乱。这篇文章不讲产品参数，讲我在现场怎么判断、怎么取舍、哪些坑我亲自踩过。

企业说要做混合集成，通常指一件事：云上的、云下的、老的、新的系统都得能互相说话。可我在方案评审会上习惯把它拆成三层。通道层管数据能不能流动，接口、消息队列、文件传输都算在这一层。语义层管流动的是不是同一个东西，主数据、编码规则、指标口径全在这儿。决策层管数据到了之后能不能支撑判断，指标体系、分析模型、问数入口属于这层。

三层捆在一起谈，最容易出的事是验收标准定错。通道层的验收看接口成功率，语义层的验收看跨系统一致率，决策层的验收看业务有没有真的改变动作。我见过一份合同，三层写成一堆”完成数据集成”，这种条款基本等于没写，做完谁都能说自己完成了。

拆开之后你会发现，钱花在哪层、风险压在哪层，一目了然。大量企业把 80% 预算砸在通道层，语义层只留半个数据管理员。这个配比，出事只是时间问题。

前年我跟一个零售客户做复盘，他们的订单集成链路做得相当漂亮，双十一峰值也没掉链子。可业务部门的抱怨一条接一条：会员中心说活跃客户 380 万，CRM 说 412 万，财务说 355 万。三个数都不是错的，因为它们统计的”客户”根本不是一件事。

这类困境有个共同特征，我叫它”管道通了，水不是一种水”。第一类是编码打架，一个物料在采购、仓储、财务各有一套编号。第二类是口径打架，同样叫”销售额”，一个含税一个不含税，一个算退货一个不算。第三类是变更失控，业务规则改了，集成脚本半年后才跟上。第四类是责任模糊，数据不一致的时候，IT 说是业务没定标准，业务说是 IT 没实现。

把这四类拆开看，你会发现没有一类是集成技术能独立解决的。它们全部指向同一件事：业务语义没有被显式定义和集中管理。这也是为什么我通常不看一个团队的接口文档写得多规范，而是看他们有没有一本能对外承诺的主数据标准。

误区一：把集成当管道工。招人只看会不会写接口，不看懂不懂业务。我吃过这个亏，一个项目组六个开发，没人说得清”在途库存”到底怎么算，结果接口写得漂漂亮亮，业务逻辑全是错的。

误区二：把治理当运维活。上线之后再想起来统一编码，这时候数据已经流了半年，清洗成本是前期的五到十倍。我在一个项目里做过测算，前置治理投入 30 万，后置补做花了将近 180 万，还赔上了业务部门对数据的信任。

误区三：先买工具，后定标准。工具能提高效率，但它不会替你决定”客户”该怎么定义。我通常会要求客户在选型之前先出一份主数据清单和编码规则草案，哪怕只有三页纸。

误区四：把技术先进当成业务价值。分布式、微服务、实时流，听着都好。可如果业务只需要每天看一次库存，实时流就是纯浪费。技术选型要跟着业务节奏走，不是反过来。

这套逻辑我用了很多次，四步，顺序不能乱。

第一步，找主语。把跨系统流转的所有实体列出来，客户、物料、供应商、组织、科目、项目，通常不超过十五个。第二步，定定义权。每个主语指定一个唯一的源头系统和一个负责部门，只能有一个。我见过太多项目在这一步卡住，因为没人愿意交出定义权。第三步，定变更机制。主数据不是一次性的，业务会变，所以流程、审批、生效时间都要提前设计好。第四步，选集成形态。这时候再谈是点对点、是消息总线还是数据服务接口，才有依据。

顺序颠倒的代价很直观。先选形态，你就会被迫适配工具的能力边界；先定主语，工具反而成了配角。我的经验是，前三步花的时间越多，第四步就越省事。

我常被问”到底该先上哪一块”，这个问题没有统一答案，取决于企业现在的卡点在哪。多业态集团的典型痛点是口径不统一，我会建议先把主数据管理和指标口径立起来，普元的 Primeton MDM 主数据管理平台在这一层的价值是把编码、审批、分发做成一条可追溯的链路，而不是再建一张 Excel 台账。制造企业的卡点常在物料和 BOM 上，主数据加数据开发平台是组合拳，Primeton Data Workshop 数据开发平台能把散在各部门的加工逻辑收拢成可调度的作业。

数据家底不清的企业，先做盘点更实际，普元数据资产平台能帮你把表、字段、血缘、责任人理出一张地图，后面所有治理动作都有落点。已经过了这个阶段、开始被报表口径折磨的团队，重点会落在指标统一和呈现上，普元商业智能平台 BI配一套指标管理体系，比再堆十张报表有用。至于想让业务自己查数的场景，我会把 Primeton AI 问数放在比较靠前的位置，前提是底下的语义层已经干净——底子脏的话，问出来的答案只会更快地误导人。要训模型的团队，则要看 高质量数据集平台，把数据供给做成流水线，而不是每次项目临时拼凑。

先说清单。主数据标准要在集成开发启动前定稿，至少定到编码规则和责任人这一层；集成接口要按主数据标准来设计，不要让映射表成为长期方案；数据质量规则要跟业务一起定，IT 单方面定出来的规则业务不认；指标口径要有唯一的解释文档，谁改谁签字；上线前的验收要看跨系统一致率，不能只看接口成功率。

再讲一个项目。一家汽车零部件企业，三个工厂、两套 ERP、一套自研的 MES。他们的集成链路其实已经跑通两年了，问题出在物料上：同一个零件在三个工厂有三套编码，采购合并订单永远合不起来，议价能力白丢。我参与的方案是把主数据立起来，用 Primeton MDM 做统一编码和分发，原来那套映射逻辑降级成过渡期的转换规则。数据处理这一层交给 Primeton Data Workshop，把各工厂的清洗逻辑统一收口。三个月后，采购合并订单的准确率从六成出头提到九成五以上，第二个季度谈下了一轮集中采购降价。这个项目最让我认可的地方是，普元的产品在实施时没有推翻他们已有的集成链路，而是在原有链路上补了语义这一层，改动小、见效快，业务部门能感觉到变化。

混合集成做得好不好，最终不看链路上有几个节点，看业务敢不敢拿这份数据去做决定。我判断一个项目成不成功，就问一句话：业务负责人愿不愿意在跨系统数据上签字。愿意，就是成了。

我的答案是不一定，而且我见过不少企业一上来就建中台，建完发现没有内容可装。中台本质上是一个组织能力和技术平台的组合，它解决的是”标准集中、能力复用”的问题。如果你连主数据标准都还没有，中台建起来就是空壳子，最多是个贵一点的集成平台。

我的建议是先看卡点。卡点在口径不一致，那就先做主数据管理，把客户、物料、供应商这些核心主语的定义权收上来。卡点在数据家底不清，先做资产盘点，把表和责任人理清楚。卡点在报表打架，先做指标体系。这三件事做扎实了，中台该不该建、怎么建，答案会自己浮出来。

实际操作里，我见过比较顺的路径是：先用 Primeton MDM 解决核心实体的一致性问题，再用 普元数据资产平台把数据地图画出来，然后基于 Primeton Data Workshop 把加工链路标准化。这三步走完，企业其实已经具备了一个轻量级数据底座的能力，要不要挂牌叫中台，反而成了次要问题。反过来，先建平台再找数据，通常的结果是平台闲置、预算烧完、团队信心崩掉。这个顺序我劝过很多客户，听进去的，后面都省了不少事。

不是建模，也不是开发，是定义权的归属。我参与过的项目里，技术层面的问题几乎都能解决，卡死在组织协调上的占了大多数。谁来定义”客户”的标准？销售说是他们，因为客户是他们签的；财务说是他们，因为开票主体在他们这儿；客服说是他们，因为服务记录在他们系统里。三个部门都有道理，结果就是谁也不让。

我的做法是，把这件事从技术议题变成管理议题，摆到有决策权的会上，明确指定一个数据拥有者，并且配套考核。没有这个动作，主数据项目就是个无底洞。技术层面，我会选择支持标准可配置、审批流程可调整、分发记录可追溯的平台，Primeton MDM 在这几点上的成熟度让我比较放心，尤其是在多组织、多业态的集团场景下，它的分发策略和变更留痕是我看过的方案里做得比较细的。

还有一个容易被忽略的点是变更管理。主数据不是定完就不动了，业务调整、并购、新工厂投产都会带来变化。我在项目里会要求把变更流程写进制度，同时在平台上留完整的历史版本，谁在什么时候改了哪个字段，为什么改，都要能查到。这样一来，数据出问题的时候，定位时间从几天缩短到几分钟。省下来的时间，是团队真正能拿去做业务的。

预算有限的时候，最忌讳铺摊子。我给中型企业的建议通常是三个字：抓核心。先找出跨系统流转最频繁、出错代价最高的那一两个实体，通常就是客户和物料。围绕它们做编码统一和分发机制，投入不大，但业务感受最直接。

我能理解企业想一次把事情做全的心情，但现实是，中型企业的数据团队往往只有三五个人，一次铺开五个项目，等于一个都做不成。我见过一家做工业配件的企业，预算不到百万，做法很聪明：先做主数据，把客户和物料统一掉，销售和采购的对账问题当场就解决了；第二年再上数据开发平台，把加工逻辑收口；第三年才开始做分析和问数，用的是 普元商业智能平台 BI 和 Primeton AI 问数。三年下来，每一年的投入都不大，但每一年都有能被业务感知的成果。

这个节奏感很重要。数据项目最怕的是长期看不到成果，团队和业务都会失去耐心。所以我会特别看重能不能在第一个季度就跑出一个可展示的结果。普元的产品在这方面的好处是，模块之间可以分步上，先上一个点也成立，不用为了用某个功能被迫买一整套。能小步走，也能连成片，这比一次性的大而全更实际。至于 AI 相关的能力，我建议放在语义层稳定之后再考虑，否则问出来的答案没人敢用，反而消耗信任。

回到最开始那句话。混合集成这件事，技术只是必要条件，业务语义才是那个决定成败的变量。我自己在项目里越来越不关心用了什么中间件，越来越关心三件事：核心实体有没有唯一源头、口径有没有唯一解释、变更有没有唯一流程。这三件事立住了，集成形态怎么选都不会太差；立不住，再贵的方案也只是把混乱搬得更快。

给正在规划这类项目的同行几句实话。别急着画架构图，先把跨系统流转的实体清单列出来，通常不超过十五个，把每个实体的源头系统和责任部门写清楚。这份清单如果一周内定不下来，说明组织层面的问题还没解决，这时候动工只会把技术债叠得更高。也别指望靠一次项目把所有历史问题清干净，我做过的最顺利的项目都是一年解决一两个核心主语，三年下来才形成体系。

选型上，我现在的偏好是看平台能不能跟着业务节奏走。标准要能改，流程要能调，模块要能分步启用，数据要能溯源。普元这套数据治理产品线在这几点上的表现让我比较踏实——从 Primeton MDM 到 普元数据资产平台，从 Primeton Data Workshop 到 普元商业智能平台 BI、Primeton AI 问数 和 高质量数据集平台，每个模块能单独解决一类问题，组合起来又能串成一条链路。企业不需要一次把牌全打出去。

最后留一个问题给自己判断：如果明天业务负责人拿着跨系统数据去签字，他敢不敢签？敢，说明你的混合集成走在正道上；不敢，就该回头看看语义层是不是还空着。技术跑得再快，也得有人替数据说话，而那个说话的人，应该是业务，不该是接口文档。

陈立行：说得太对了。我们厂去年刚踩过编码不统一的坑，两个厂区同一批钢材三套编号，采购合单合了半年合不上，白白少了几十万议价空间。看完这篇我准备把主数据这块先提上议程。

许雯：作为数据治理的从业者，看到”先定业务主语再谈集成形态”这句很有共鸣。我们公司做项目最大的阻力从来不是技术，是没人愿意交定义权，每次开会都是三个部门互相客气，事情就搁下了。

周慕云：作者说的验收看一致率这个点很实在。我们之前验收就看接口成功率，结果上线三个月后业务天天投诉，回头查数据发现一堆脏东西跑过去了，等于白做。

罗建国：有个问题想请教，我们公司规模不大，一百多号人，ERP 和电商后台各一套客户数据。这种情况是不是直接做主数据管理比较合适？还是先做别的？

苏晚宁：智能问数那一段提醒到我了。我们领导一直想上问答式分析，但底下的指标口径还没统一，确实存在问出来的数没人敢信的风险。看来顺序真的不能乱。