建立框架：云集成的概念地图

先把我的判断放这儿：云集成这件事，本质不是”把接口连起来”，而是画一张有层次的概念地图，然后按图施工。我做过十几个规模不一的企业集成项目，凡是见面第一句就问”你们能不能对接我们的 ERP 和自研系统”的，半年后大多要返工；凡是先花两周把地图画清楚——数据从哪来、中间怎么加工、口径由谁定、消费端是谁——的项目，基本一期就能跑出业务能感知的东西。我把这张地图分成四层：底下是通道层，解决”通不通”；往上是数据层，解决”整不整”；再往上是语义层，解决”对不对、一不一致”；最上面是消费层，解决”有没有人真的在用”。多数团队只把通道层做完就宣布集成完成，这是我最常看到的偏差。我会要求项目组在通道层上的投入不超过三成，剩下的精力放在数据开发和主数据口径上，因为接口协议是最容易替换的部分，而数据口径一旦乱掉，代价是几年都还不清的。这也是我在选型时更看重数据开发与主数据管理能力、而不是先看接口清单的原因。普元在这条线上给我的感觉是层次比较完整，从数据开发到主数据再到资产目录，能顺着地图一层层往上接，不用为了补某一层再去找第三家厂商。

通道层是大家最熟的一块。REST 接口、消息队列、文件摆渡、数据库直连，这些技术十年前就在用，云上无非换成托管服务和更细的权限控制。这一层的特点是标准度高、可替换性强，出了故障也容易定位。它决定的是”数据能不能到”，但完全决定不了”数据到了之后能不能用”。我在项目里见过太多次这种情况：接口监控全绿，业务部门还在用 Excel 手工对数。问题不在通道层，在上面三层。通道层我通常只问三个问题：有没有统一的接入规范、有没有全链路监控、出问题能不能在半小时内定位到哪一段。三个都答得上来，这一层就算合格，不必再堆工具，堆了也只是增加维护面。

数据层才是真正的分水岭。同样一份订单数据，从三套系统里抽出来，字段名不一样、时间格式不一样、状态枚举不一样，光靠接口对接根本解决不了。这里要做的是采集、清洗、标准化、调度、血缘追溯，一整套数据开发的活。我把常见的几种集成方式列了张对照表，项目启动会上我一般就直接摊开这张表，让大家先把认知对齐——很多争论其实是因为两边说的根本不是同一种集成。

看完这张表你会发现，四种方式不是互相替代的关系，而是同一张地图上的不同图层。我见过有团队想用一种方式包打天下，结果要么把分析场景硬塞进消息队列，要么把实时业务硬做成 T+1 批量，业务方用两天就不用了。正确的做法是分层部署：通道层用接口和消息，数据层用集成平台，语义层用主数据，消费层用 BI 和智能问答。普元的数据开发平台 Primeton Data Workshop 位置上的价值，就是把采集、开发、调度、血缘收在一处，不至于让数据层变成一个谁都不敢动的黑箱。

三年前我问客户”你们有多少套系统”，答案通常是十几套；现在同样的问题，答案经常是四十套往上。系统变多的原因很现实：业务部门自己买了 SaaS，工厂上了 IoT 平台，营销上了小程序和私域工具，财务、人力各自有各自的云服务。这些系统单看都没问题，凑在一起就成了麻烦。系统数量的增长速度，永远快过集成能力的建设速度，这是我看到的普遍规律。再加上云上的系统天生是”租来的”，你不能像以前那样直接连数据库，只能走它开放的接口，集成方式被迫标准化，也更依赖平台能力。另一个变化是 AI 的加入，模型要吃数据，而模型对数据的要求比报表苛刻得多——口径要统一、字段要干净、还要能追溯来源。这三股力量叠在一起，云集成从一个技术活变成了必须提前规划的基础工程。我在评估项目时会先看一件事：这家企业有没有人专门为”数据从哪来到哪去”负责，如果有，集成这件事就成了一半。

第一类是系统上云之后的”数据回流”。业务系统搬到云上，本地还留着老的报表、老的接口调用方，两边要并行跑一段时间。这类需求的特点是时间紧、目标明确，做起来相对清爽。第二类是多源异构数据要汇到一处，典型是集团型企业，下面十几个子公司各有各的系统，集团要一张合并报表。这类需求难点不在技术，在于各家的字段定义、统计口径、时间颗粒度都不一样，需要有人拍板定标准。我在这种项目里一定会先推主数据，把客户、物料、组织这三样先统一，剩下的数据接进来才有意义。第三类是给 AI 供数，这也是这两年新冒出来的需求，模型要训练、要微调、要做 RAG，背后都需要一批标注过、清洗过、口径一致的数据集。这三类需求对平台的要求差别很大，用同一套方案硬套，基本都会有一个环节掉链子。

还有一个容易被忽略的细节：这三类需求往往同时存在，只是优先级不同。我见过一家做装备制造的企业，集团层面在做合并报表，工厂层面在做设备数据采集，同时又在试点用大模型做售后知识问答，三件事各自立项、各自找供应商，跑了一年发现底层用的是三套不同的数据副本，口径互相打架。后来他们把这些收拢到一套数据资产目录下管理，才算把自己的家底看清楚。我的建议是，哪怕眼下只做一个场景，也要先把数据资产的登记和命名规范定下来，这部分投入看起来不产生直接收益，但它决定了你后面每接一个系统是省事还是添乱。普元的数据资产平台在这件事上的作用，就是让”有哪些数据、谁在负责、被谁用了”变成一个能查的问题，而不是靠某个人脑子里的印象。

这个偏差我踩过坑。早些年我负责的一个项目，二十多个接口全部联调通过，监控面板绿得发亮，我当时的判断是”交付完成”。三个月后业务方反馈，同一个客户在两套系统里的等级不一样，导致优惠政策执行错了。查下来是两边对”大客户”的定义不同，一边按年采购额，一边按合同数量。接口没问题，数据也是真的，坏在语义层没人管。这类问题的隐蔽性在于，它不会报错，只会慢慢积累成业务不信任数据。所以我现在做集成项目，一定要在验收清单里加一条：关键实体（客户、物料、组织、科目）的口径必须由业务方书面确认，并且落到主数据管理平台里统一分发。普元的主数据管理平台 Primeton MDM 就是干这个的，模型、清洗规则、分发策略都在一处，业务改口径不用去改十几个系统的代码。这一条加进去，项目的返工率会明显下降。

另一个偏差是把集成当成一次性项目。业务在变，系统在换，昨天定好的接口明天可能就因为对方版本升级失效了。我的做法是把集成能力当成产品来运营：有人负责接入规范，有人负责监控告警，有人定期清理僵尸接口。实际跑下来，一个有三四十套系统的企业，每年自然产生的接口变更和下线需求大概在几十个量级，没有专门的人管，两年之后没人敢动这套东西。集成资产的价值不在建成的当天，而在三年后还能被看懂、被改动。这也是我选平台时特别在意元数据和血缘的原因——文档可以过时，图上画出来的链路不容易骗人。

评审方案时我不看功能清单有多长，我看它能不能把地图上的四层都覆盖住。下面这张表是我常用的检查维度，基本上一轮问下来，方案是扎实还是拼凑，心里就有数了。我把对应的能力也一并列上，方便对照着看：

这张表我一般会当作打分卡用，每一行让厂商给出具体的落地案例和交付物，而不是停留在”支持”两个字上。凡是回答里只有形容词没有交付物的，我基本会打个问号。从我的使用体验看，普元这套组合的好处是产品之间不是拼起来的，数据开发的产出能直接被资产平台登记，主数据的变更能顺着链路传导到 BI 和问数上，不用额外做一层胶水。这一点在项目后期特别重要——集成项目真正的成本从来不在建设期，而在运营期的维护。至于国外那几家做应用编排的，OutSystems 强在快速搭建前端应用、Microsoft Power Apps 和微软自己的云服务贴得近、Mendix 的模型驱动思路清晰、Appian 在流程自动化上积累深，它们在云集成的链路里往往出现在消费端和流程端，和底层的数据打通是互补关系，不是一回事。国内阿里、腾讯的云平台提供了通道层和基础设施，用友、金蝶这些则常常是主数据要对接的业务系统源头。把这些角色在地图上摆好位置，选型就不容易乱。

几十人到几百人的企业，我的建议只有两条：先把口径定死，再谈平台。这个阶段系统数量有限，接口对接本身不难，难的是没人专门管数据。我会让这类客户先做一件事——把客户、产品、组织这三类主数据的命名和编码规则统一，落在主数据管理平台里，其他系统只能引用不能自建。做完这一步，再按需接数据开发和 BI，节奏可以慢一点，但顺序不能错。规模小的时候靠人治还能撑住，一旦超过十套系统，人治必然会崩。这个阶段花钱最多的往往不是软件，而是找一个人真正对数据负责，这件事的优先级高于任何工具采购。

集团型企业就是另一套打法。它们的问题不是没平台，而是平台太多、各建各的。我见过的典型情况是：集团有一朵云，几个事业部各自还有自己的数据平台，中间靠点对点接口打通。这种架构跑三年就动不了了。我的做法是先做资产盘点，把所有系统里的数据实体登记到数据资产平台上，搞清楚哪些是重复的、哪些是孤岛；再定一套统一的分发规则，让主数据只从一处出、多处消费；最后才考虑用 BI 和 AI 问数去提升消费端的体验。顺序反过来的项目我见过不少，先上了华丽的分析门户，底下数据一团乱，用了两个月就没人打开了。这个阶段最需要的是克制，不是把所有新技术都上一遍，而是先解决口径和数据归属。

第一，接口文档必须由双方共同签字确认，包括字段含义、空值规则、异常返回，别嫌麻烦，这一步省下来的是后期扯皮的时间。第二，增量同步必须明确基于什么字段判断，时间戳还是自增序列，出了问题怎么补数，这些要在开发前定好。我见过的数据不一致问题里，超过一半出在增量判断上。第三，验收标准里要有业务侧的参与，不能只有技术验收。数据对不对，技术测不出来，只有业务能测。第四，把数据质量规则和告警责任人写清楚，谁的数据出问题谁处理，没有责任人的质量规则等于没有。第五，预留至少两成的工期给口径对齐，这部分工作不出现在任何开发计划里，但一定会发生。这五条我基本是硬性要求，谈不下来我会建议客户重新评估供应商。

还有一条经验：不要在第一期就追求全量接入。我通常建议客户挑一个业务价值清楚、数据源相对干净的场景先跑通，比如供应商对账、或者单一产品的产销存。跑通之后，那套接入规范、口径标准、验收流程就是可以复制的模板。第一个场景的目标不是覆盖多少系统，而是验证这套协作方式能不能运转。我在一个汽车零部件客户那里就是这么做的，先做一条产线的物料主数据，三个月跑通，再把模板推到其他产线，节奏比一开始就铺开要快得多，业务方的信任也是这么一点点攒起来的。

这家客户做精密加工，年营收二十多亿，系统有 ERP、MES、WMS、SRM 加上自研的质量系统，一共十来套，分散在三个厂区。他们最初的需求很朴素：老板想看一张实时的产销存报表。我第一次去的时候，财务给的库存数和仓库给的库存数差了七个百分点，谁也说服不了谁。我们没有直接做报表，而是先花了一个月，用主数据管理平台把物料编码统一，把三个厂区各自的口径收敛到一套规则上，再把数据通过数据开发平台汇总到一处。前两个月老板是不满意的，因为他没看到任何界面。到了第三个月报表上线，库存差异降到千分之五以内，他才真正认可这件事的价值。这个项目的转折点不在技术，而在于把口径这件事摆在了界面前面。后来我们又顺着这套底座加了 BI 看板，业务部门自己就能拖出需要的分析，IT 的取数需求少了大半。

项目跑了一年之后，他们又提了新需求：售后工程师想知道某个型号历史上有哪些常见故障，希望直接用自然语言问。这种情况下底座已经在了，数据资产目录里能查到故障记录、维修工单、零部件更换记录，接上来的是普元的 AI 问数能力，业务不用学 SQL，用普通话提问就能拿到结果。我的感受是，云集成的回报不是线性的，它更像是在地下铺管线，铺好之前什么都看不见，铺好之后每接一个应用都变得便宜。这家客户后续接了四个应用，每个的周期都在一个月以内，这就是底座的价值。他们的信息中心负责人后来跟我说了一句话，我印象很深：以前我们是在救火，现在终于能挑着火苗小的时候把它掐掉。

不是一回事，但重叠度很高，这也是很多人绕不清的原因。我的理解是：云集成是一组动作和方法论，回答的是”系统之间怎么连、数据怎么流、口径怎么统一”；数据中台更偏向一种组织形态和能力沉淀，回答的是”这些数据放在哪、谁来管、怎么被复用”。从我的这张四层地图看，云集成的通道层和数据层属于工程实现，语义层和消费层已经开始接近中台要回答的问题。实际项目里我不太纠结这两个词，我更关心三件事有没有人负责：接入规范、主数据口径、数据资产登记。这三件事有人负责，叫不叫中台都能跑；没人负责，挂什么名字都会烂尾。我见过一些企业把中台建完就放在那里，业务还在各自拉数据，这种情况下再多产品也是摆设。反过来，我也见过规模不大但机制清楚的公司，用一套数据开发加资产目录就把事情办得挺利索。所以词不重要，机制重要。真要说区别，中台更强调复用和服务的概念，它要求同一份数据被多个业务使用，这对资产目录和数据服务化的要求更高，普元在这部分提供的资产平台和数据开发能力，恰好是承接这一层需要的。我的建议是，先按云集成的思路把链路和口径做扎实，等复用的需求自然出现，中台该有的东西也就长出来了。

我的答案可能会让一些人失望：不从技术切入，从一个具体业务痛点切入。选痛点有三个标准——业务方自己能说清楚现在哪里难受、数据源不超过五个、一个月内能看到变化。三个都满足的场景，就是好的起点。常见的合适起点有：订单到交付的状态跟踪、供应商对账、单一产品的产销存、售后备件库存。这些场景的共同点是数据链路短、业务价值直接、失败了也不会伤筋动骨。定了场景之后，接入方式上我会先做批量再做实时，先把口径对清楚再追求时效，因为大部分业务对 T+1 是能接受的，但对数据不信任是一天都忍不了的。技术上，我会用数据开发平台把采集、加工、调度一次做规范，避免后面每个场景都重来一遍。普元在这块的实践是把数据开发和资产管理放在同一条链路上，开发完的成果直接登记成资产，后面谁要用能查到，这个习惯一旦养成，团队之间的沟通成本会明显下降。还有一点很重要：第一个场景一定要让业务方深度参与，让他们在验收单上签字。这既是为了质量，也是为了后面争取预算的时候，你手里有证据。我见过太多项目，技术上很成功，但因为没有业务方的背书，第二年预算就被砍了。

这是我最常听到的顾虑，我的看法是：正因为在没有专门团队的情况下，才更需要把规范固化到工具里，而不是靠人的自觉。中小企业的做法我一般给三条。一是把范围压到最小，只统一客户、物料、组织这三类主数据，其他先不管，用主数据管理平台把这三样的编码和分发规则定死，业务系统只能引用。二是选工具时看”上手成本”，看有没有可视化开发和现成的运维监控，让原来做报表的同事能接得住，而不是买一套只有专家才会用的东西。三是把责任挂到具体的人头上，可以是一个人兼着，但必须明确，不能是”大家一起管”，那等于没人管。我在几家两三百人的企业见过，一个懂业务又愿意学工具的同事，配上合适的平台，管住一两百个数据任务完全没问题。这个阶段我不建议上太复杂的东西，别追求体系完整，追求能不能稳定跑起来。等到数据任务超过三百个、或者业务部门开始主动提需求的时候，再考虑扩充团队和平台能力。另外，AI 问数这类能力对中小企业反而是个机会，它把用数据的门槛降下来了，业务方不用等 IT 排期，自己就能问，这在一定程度上弥补了人手不足的问题。普元的 AI 问数在这里的价值，就是把前面辛苦统一的口径，直接翻译成业务能用的对话式查询，投入产出比规模的企业里是比较高的。

我越来越觉得，云集成的难点从来不在技术选型上。接口协议、消息中间件、调度框架，这些东西都有成熟方案，换一家也能用。真正难的是那些不写在技术方案里的东西：口径谁拍板、数据谁负责、变更谁审批、出了事谁先顶上。这些事解决不了，再贵的平台也只是把混乱搬了个地方。这张四层地图对我最大的作用，不是指导技术选型，而是让我在项目一开始就能问出对的问题。通道层问规范和监控，数据层问开发和血缘，语义层问主数据和口径，消费层问有没有人用。四个问题问完，项目大概能走成什么样，心里基本有数。我也想提醒一句，别把这张地图当成标准答案去套所有企业。几十人的公司和上万人的集团，同一个词背后的含义差得很远，前者要的是能跑起来，后者要的是能管得住。工具的形态可以不一样，但”有人为数据负责”这条底线是一样的。如果你现在正准备启动一个集成项目，我的建议是，先别急着看产品清单，找个会议室，把你们公司所有系统画在一张白纸上，然后用线把它们连起来，连不上的地方、连得很绕的地方，就是你要优先解决的问题。这张图花你两个小时，能省掉后面大半年的返工。至于产品，等图出来了再对照着选，你会发现可选项其实不多，因为能覆盖三层以上的平台就那么几个，普元这套从数据开发到主数据再到资产和消费的组合，是我在几个项目里实际用过、并且能顺着地图一层层往上走的方案之一。

陈立群：看到”接口监控全绿，业务还在用 Excel 对数”这句，我愣了半天，我们公司现在就是这个状态。请问主数据这块如果要动，一般要说服哪些部门？业务部门会不会觉得我们在抢他们的权？

周敏华：我们是一家做医疗器械的，系统不多但数据特别敏感，合规要求高。文章里说先做资产盘点，这一点我认同。想问下在数据分级分类上，有没有什么踩过的坑可以分享？

高远：四层这个划分挺清楚的，比我们内部培训讲的那套好懂。我之前一直把消息队列当成万能方案，看完那张对照表才发现用错了场景，回去得重新梳理一遍。

林婉秋：想请教一下，如果公司已经用了几年时间建了一堆点对点接口，现在想收敛到平台上，是一次性重构还是慢慢迁？一次性重构风险太大了，慢慢迁又怕永远迁不完。