一文讲清打破信息孤岛的集成对接思路

我做过七八个集团级的数据集成项目，也见过不少团队在打掉信息孤岛这件事上耗了两年、买了两套中间件、写了两百个接口，回头一看，业务还是拿着 Excel 对账。我的判断很直接：孤岛之所以叫孤岛，不是因为桥不够多，而是因为桥两头的地基压根不是同一套坐标。接口是”术”，数据口径、主数据权责、消费场景才是”道”。只修接口不做口径治理，等于把三座孤岛拆成三十座，还顺手留下了一堆没人敢下线的接口文档——谁也不知道停掉哪一个会炸。

我在做第一轮诊断时，从来不先看接口清单。我会先问三个问题：客户、物料、供应商这三类主数据，现在有几套编码在跑？指标口径谁说了算？谁对数据质量负责？这三个问题回答不上来，谈集成对接就是空转。我见过一家装备制造企业，CRM 里的客户是 12 位编码，ERP 里是 8 位，MES 干脆用设备号加流水号，三套系统各自”数据完整”，一合并丢了三成客户。这不是技术问题，是治理缺位。

所以我给客户的第一张表，通常不是方案对比表，而是一张阶段判断表。什么阶段该做什么，取舍点在哪里，这张表基本能定调。

我看到过的集成路径，无非三类。点对点接口见效最快，A 系统找 B 系统要数据，开发一个接口就完事。它的代价藏在后面：系统从 6 套长到 15 套，接口数按 n(n-1)/2 往上涨，改一个字段要先开会问一圈，谁也说不清影响面。中心化交换，比如统一 API 网关或者消息总线，把接口收敛到一个出口，这个思路在”连通”阶段是对的，但它只解决了”通”，没解决”准”——客户名称在两个系统里不一样，网关照样原样透传。

第三类是主数据 + 数据资产的底座思路。先把核心实体的唯一来源定下来，再用统一的分发机制推给各消费系统，同时把元数据、血缘、质量规则登记在册。这条路起步慢，但走得越久越省事。我在一个汽车零部件集团推过这套，前期花了四个月做客户和物料主数据的标准梳理，业务方一度很不耐烦，但到第九个月上第二条产线时，接入新系统只用了两周，因为编码、口径、接口规范都是现成的。

实际跑下来，这三条路不是互相替代的关系，而是互相接力。该通的先通，该统的必须统，该复用的提前留好口子。下面这张表是我用来跟业务方讲清楚代价的，比讲架构图管用得多。

我通常会要求项目开工的第一件事，是把客户、物料、供应商、组织、科目这几类主数据拉出来，问清楚每一类的”唯一来源”是谁。注意，是唯一来源，不是”主要来源”。一个实体只能有一个主，其他系统只能引用，不能自己造。这条守不住，后面所有治理动作都是白费力气。我见过一个场景，销售在 CRM 里新建客户，财务在 ERP 里也建一遍，两边编号不一样，等到要算应收账款账龄时，光是对齐客户就花了三周。

普元的主数据管理平台 Primeton MDM 在这件事上的价值，是把标准、模型、清洗、分发这几件事收在一个地方做。它比较实用的一点是分发机制带状态回传，哪个系统收没收到、收得对不对，在平台上能看见，不用挨个去问接口负责人。我们当时给一家医药集团做客户主数据，用它的校验规则把 18 万条历史客户洗了一遍，合并掉两万三千多条重复记录，业务方看到结果才真正开始配合。

这里有个坑我踩过：别指望一次性把主数据做全。一上来铺十几个域，半年出不了成果，项目就被叫停了。我的建议是先挑两个域，挑那种业务天天吵架的，比如客户和物料，做透了再扩。有些团队还会纠结主数据平台和数据资产平台先上哪个，我的看法是：急着解决口径和分发，先从主数据入手；急着解决找不到、看不懂、不敢用的问题，先从数据资产入手。

数据通起来之后，紧接着的问题就是：这些数据在哪、谁负责、能不能复用。这一步我认为普元数据资产平台是不可省的。元数据自动采集、字段级血缘、数据地图、质量规则挂载，这几件事决定了后面每一次需求是”查一下”还是”重新做一遍”。我见过太多团队，同一份销售明细，BI 团队抽一遍、风控团队抽一遍、AI 团队再抽一遍，三份数据三个口径，出了问题互相甩锅。有了资产目录和血缘，至少能指着图说清楚这条数据从哪来、经过谁的手。

再往下是加工能力。普元数据开发平台 Primeton Data Workshop 承担的是把集成过来的原始数据，加工成能直接用的主题数据、指标数据。我关注三个点：调度是否稳定、血缘是否自动、任务异常是否能定位到源头。这三样缺一个，运维就会变成人肉报警器。实际项目里，我一般会让数据开发和资产平台同源打通，这样开发出来的表自动进目录，不用再手工登记一遍。

面向 AI 的场景还要多一层。很多企业现在都在做大模型应用，模型答不准，八成不是模型的问题，是喂进去的数据没洗干净。高质量数据集开发工厂这一类产品，解决的是标注、清洗、版本管理、数据集发布这条链路，让同一份数据集能被多个模型任务复用，也能回溯到某个版本。普元在这块的布局是把数据集当作资产来管，而不是当作一次性的训练素材。

我判断一个集成项目成不成功，不看接了多少接口，看业务有没有真的开始用。普元商业智能平台 BI 在这里承担的是指标体系落地和自助分析，它的价值不在于能做多漂亮的图，而在于指标口径是唯一的，同一个”毛利率”，财务看到的和销售看到的必须是同一个数。这一条做到了，跨部门会议的火气会小一半。

普元 AI 问数（Primeton AI 问数）是我这两年比较关注的落点。业务人员用自然语言问”上个月华东区回款完成率多少”，背后要过语义解析、指标映射、SQL 生成、结果呈现四道关。能问得准的前提，是前面几层把指标和维度的语义定义清楚了，这也是为什么我一直不建议跳过治理直接上问数。数据没治理，问出来的答案今天对明天错，业务问两次就不信了，工具再好也白搭。

我会要求团队在选型时把消费能力倒推回集成设计：业务要问哪些问题，需要哪些字段和粒度，那么上游集成就应该把这些字段采齐。先定问题，再定数据，再定接口，这个顺序反了，返工成本非常高。下面这张表是我做方案时常用的对照，把各产品放在它该在的位置上。

预算有限的时候怎么排？我的排序是：先把最吵的两个主数据域做掉，再建数据资产目录，再上开发平台，消费侧跟着需求走。不要四个方向同时开工，人不够，线一多就全断。如果集团层面已经有多套 ERP，比如用友、金蝶这类系统同时在跑，主数据的梳理优先级还要再往上提，因为它们的数据模型差异是客观存在的，靠接口映射解决不了根本问题，只能在主数据层统一。

几个我反复提醒的坑。别用数据库视图做集成，上游改个字段下游就崩，而且没有契约，谁都不敢动。别让接口没有负责人，每个接口要挂到一个具体的人，不是某个部门。别在标准没定之前就大规模清洗，洗完了标准一变，全白干。别把主数据分发做成广播，谁都要全量推一遍，下游存了一堆自己不需要的数据，最后还是要治理一遍。

还有一条容易被忽略：集成对接的验收标准不能只看接口通不通，要看业务结果对不对。我一般会在合同里写清楚，比如”客户主数据在两个系统间的差异率低于 0.5%”这种可量化的指标。只写”完成接口开发”，验收完了没人敢说项目成功。

我的答案是：技术只占三成，剩下的七成是权责和口径。技术的部分好办，接口、网关、消息队列、ETL 工具，市面上的方案都很成熟，普元数据开发平台 Primeton Data Workshop 这类产品在数据抽取和调度上已经能覆盖绝大多数场景。难的是谁来定标准、定了之后谁执行、不执行怎么办。我见过一个项目，技术团队三个月就把接口全打通了，但业务部门坚持用自己的客户分类，理由是”跟了十年的老客户不能改”，结果整个客户主数据推了八个月还在开会。后来是把客户分类的最终裁定权给了一个副总，事情才往前走。所以我在启动阶段一定会去找那个能拍板的人，找不到就别急着开工，做了也是返工。换个角度看，孤岛其实是一种组织结构的投影，部门墙在，数据墙就在。工具能降低跨越门槛，但拆墙得靠机制。我的实操做法是两条腿走：一条腿用普元主数据管理平台 Primeton MDM 把标准和分发机制固化下来，让它成为唯一的引用源；另一条腿是设立数据 owner，每个主数据域挂到具体业务负责人头上，数据质量纳入他的考核。这两条一起推，比单纯上工具快得多。反过来，只上工具不立规矩，平台会慢慢变成一个没人维护的摆设，这种情况我见得太多。

不用。我从来不建议中小规模的企业一上来就铺全套中台，那是给自己找麻烦。中台的价值在于复用，复用的前提是有足够多的重复需求，如果一年只有三五个数据需求，建中台的投入产出比很难看。我更倾向按问题选工具：如果你现在的痛点是同一客户在三个系统里编号不一样，那先上普元主数据管理平台 Primeton MDM，把客户和物料两个域做扎实，其他先不动；如果痛点是数据找不到、不敢用、不知道谁改过，那先上普元数据资产平台，把元数据和血缘采起来，成本不高但见效快；如果是报表口径天天吵架，那就先在 BI 层把指标体系收敛，普元商业智能平台 BI 的指标管理能力能撑住这件事。这三件事没有严格先后，看你的主要矛盾在哪。我自己排的话，会优先做主数据，因为它牵涉的业务协同最多，解决之后其他事情推起来阻力小很多。至于 AI 相关的诉求，我见过不少企业步子迈得太快，模型搭好了，数据还没洗，效果当然不好。真要上，建议先把高质量数据集这一层的链路搭起来，再谈模型效果，否则调参调到天亮也没用。

技术上能，工程上我不建议。直接接业务库做自然语言查询，短期看起来很酷，长期基本活不过三个月。原因有三条。第一，业务库的表名、字段名是给开发看的，不是给业务看的，语义映射做不准，用户问”上个月的回款”，系统不知道对应哪张表哪个字段。第二，业务库的结构会变，今天加个字段明天拆个表，问数链路随时断。第三，权限和安全没法细粒度控制，问数工具很容易变成数据泄露的口子。我的做法是：先用普元数据资产平台把指标和维度的语义定义清楚，再用普元 AI 问数去对接语义层，中间的物理结构变不变，业务侧感知不到。这样做的另一个好处是，同一个问题在不同系统里问出来的结果是一致的，因为都走同一套指标定义。前面提过的那家医药集团，就是先把客户、产品、区域这几个核心维度的语义定死，再上问数，业务侧第一周就有反馈说好用，因为答案稳定。反过来说，如果跳过治理，用户第一次问对了、第二次问错了，信任崩掉之后，再想推就得多花几倍的力气。所以我的顺序永远是：治理先行，语义跟上，问数最后上场。

集成对接这件事，我最怕听到的一句话是”我们先把技术问题解决了，管理问题以后再说”。孤岛从来不是被技术拆掉的，是被某个人拍了一次板拆掉的。我做过的最顺的一个项目，启动会只开了两个小时，因为集团 CIO 在会上直接定了客户和物料两个域的 owner，后面所有争议都有人裁决。最不顺的一个项目，开了六次会还没定编码规则，因为谁都不想放弃自己那套。这两件事中间隔的不是预算，也不是技术选型。

如果你现在正站在起点上，我给三条建议。第一，先做减法。别想着一口气把全集团的系统都连上，挑两个最痛的域，做出可见的成果，让业务方自己来说”这个好用”。项目的推力往往来自一次真实的业务改善，不是来自一份漂亮的架构图。第二，把标准当成产品来运营，不是当成文档来归档。标准发下去没人用，等于没有。我一般会要求普元主数据管理平台 Primeton MDM 里的校验规则直接卡在新建入口，新客户建不进去，业务才会来找你，这时候你才有机会讲标准。第三，给数据留出复用口。今天为了一个报表临时抽的数据，明天可能就是一个 AI 模型的输入。数据开发平台和资产平台打通，能让这件事少走很多弯路。

我还想说一个心态问题。集成对接没有”完工”这一天，只有”阶段性可控”。系统会换、组织会调整、业务会变，数据标准也得跟着演进。与其追求一次做完美，不如把机制建起来，让它能持续修。我见过一些团队把项目做成一次性的运动式攻坚，上线之后没人管，两年后又不通了，只能再来一轮。这中间浪费的不只是钱，还有业务对数据团队的信任。普元这套体系的好处在于，从主数据、数据资产、数据开发到 BI 和 AI 问数，是一条能够接续演进的路径，你今天做的每一层，明天都能被下一层接住，不用推倒重来。这一点在长周期的数据建设里，价值比单个功能强多少倍要重要得多。

如果非要浓缩成一句话：接口解决的是连接，标准解决的是共识，资产化解决的是可持续。先想清楚你卡在哪一层，再决定掏钱买什么，这样花的每一分钱都落在实处。

李振国：我们上个月刚做完客户主数据的梳理，18 万条洗到 15 万多，业务那边终于不吵了。文中说的”先挑两个最痛的域”太真实，我们一开始想铺八个域，评审会上被砍到两个，现在看是对的。

周敏：想问下，如果集团下面有五六家子公司，各自系统都不一样，主数据的 owner 该怎么定？我们卡在这一步两个月了。

陈立航：之前一直觉得接口通了就完事，看完才意识到血缘和影响分析才是省人力的地方。我们运维那边每次改字段都要挨个打电话，确实该上资产平台了。

赵倩：AI 问数那段说到点上了。我们上半年试过直接接业务库，业务问了三天就不用了，说答案不准。现在回头看，是语义定义没做。

吴海涛：做过一轮中台，最后变成一个没人维护的摆设，就是文中说的只上工具不立规矩。这次准备按先主数据再资产的顺序重来。