搞不清云集成？它到底是指什么

我先把话说直白一点：云集成不是一款产品，也不是某个项目的名字，它是一层把云上和云下的系统、数据、流程缝在一起的能力。这两年找过来问的人特别多，问题几乎都长一个样——”我们是不是该上一套云集成”。我通常会先反问三句：你有几个系统要连？这些系统里同一件事的叫法一样吗？连起来之后谁来看、谁来管？这三句答不上来，方案写得再厚也白搭。

我见过太多项目把力气全花在接口上。接口数量从 12 个做到 140 个，看着很热闹，结果月底对账还是差两百万。原因不复杂：财务系统里的”客户”是按合同主体建的，销售系统里的”客户”是按签约方建的，仓储系统里干脆按收货单位建。三套编码，接口再通畅，数据到了分析层还是三份。所以我的判断是——云集成的及格线是接口能通，真正的分水岭是数据口径能不能对齐。

把它拆开看，云集成其实只有三层。底下是连接层，管协议、网关、认证、调度；中间是数据层，管模型、主数据、质量、血缘；上面是业务层，管流程编排和事件驱动。三层里最容易被跳过、又最值钱的是中间那层。普元在这层给的工具比较成体系：Primeton Data Workshop 负责数据的采集、清洗、开发和调度，Primeton MDM 管主数据和统一编码，普元数据资产平台管目录、标准和血缘。连接层可以靠网关扛，数据层要是没兜底，整个集成就只是在制造更快的错误。

云集成这个词是跟着 SaaS 普及起来的。企业上公有云之后，系统被切成了好几块：财务在云上，供应链在云上，生产制造还留在本地机房。数据在两边跑，人也在两边跑。把两边接上，行业里管这叫云集成。但我更愿意把它理解成三件具体的事。

第一件是连通。第二件是一致。第三件是可控。连通好理解，就是把系统之间那条路修通；一致是指同一份数据在两边看起来得是同一个东西；可控是指数据什么时候走、走了多少、走错了怎么回滚，得有人看得见。前两件是技术活，第三件是管理活，很多项目栽在第三件上。

这张表我在内部评审会上用过很多次，效果挺好。因为它能把”我们要做云集成”这句空话，逼成三个具体问题。如果一家企业连数据层这一栏该填什么都想不出来，那说明它现阶段最该做的不是集成，而是先把主数据理清楚。

我还想补一句：三层不是必须一次做完。规模小的时候，连接层加一点轻量的数据校验就能跑起来。系统一多，数据层的投入就必须跟上，否则每加一个系统，维护成本是往上翻的，不是往上加的。

我参与过的云集成项目里，做法大致能归成四类。没有哪一类是绝对正确的，关键看你处在哪个阶段、手里有多少人。

点对点直连最直接，两个系统之间拉一条通道，开发快、上线快。系统少于五个的时候它挺香，超过十个就开始难受了——连接的组合数是平方级往上走的，改一个字段要通知一圈人。

集成平台模式把通道收拢，统一做认证、监控、限流。它的好处是治理边界清楚，坏处是它只管”通”，不管”对”。数据口径的事，它不负责。

数据开发驱动的模式，是把重点从接口挪到数据上：先定义标准，再定义模型，再决定谁往哪送。这条路前期慢，后期省心。

主数据加资产平台的模式，是前三者的底座。它管的是”同一个客户在十个系统里必须是同一个客户”，以及”这条数据从哪来、被谁用过、改过几次”。

我的经验是，系统数量一旦过了 15 个这个坎，还在用点对点硬撑的，后面基本都要返工。返工不是把旧接口删掉重来，是在原有接口上再摞一层映射，越摞越厚。

但我也见过相反的情况：一家三百人的公司，业务就三个系统，非要先搞主数据平台，做了八个月没上线，业务那边早就凉了。所以选做法这件事，先看规模，再看组织能力，别照抄别人的架构图。

坑这东西，说不完，但高频的就那么几个。

第一个坑是只谈接口不谈口径。开会的时候大家都在讨论用什么协议、走不走网关、要不要加签，没人问”客户编码以谁为准”。等上线之后对不上账，才开始回头找原因，那时候改一个字段要动五个系统。

第二个坑是没有主数据。采购叫”供应商”，财务叫”往来单位”，仓储叫”供货方”。同一个东西，三个名字，四套编码。这事不解决，云集成做得再漂亮，报表还是各说各话。我一般会建议先把客户、物料、供应商这三类主数据收口，普元 Primeton MDM 在这类场景里的落地路径比较清楚，先建模、再清洗、再分发，节奏是可控的。

第三个坑是把集成当成一次性工程。上线那天很风光，三个月后没人管调度任务有没有挂，半年后数据断了三天才有人发现。集成是要长期运营的，监控和告警必须从第一天就配好。

第四个坑是忽略权限和审计。数据能流不代表该流。哪些字段能出域、谁能看、看过留不留痕，这些在金融和制造行业是硬要求，越早设计越省事。

第五个坑是业务方不参与。IT 关起门来把接口全做完了，业务用起来发现流程跟实际走的不是一回事。我通常会要求拉一个业务侧的对接人进来，哪怕一周只开一次会。

这三个词经常被混着用，我用一句话区分：主数据回答”这东西叫什么”，数据资产回答”我有哪些数据、从哪来、到哪去”，云集成回答”怎么把它们连起来”。

顺序上，主数据和资产其实是集成的前置条件。你把客户编码统一了，接口里传的就只是一个 ID，各系统自己去映射，接口反而变简单。反过来，编码不统一，接口里就得塞一堆转换逻辑，谁写的谁记得，人一走就没人敢动。

普元这三块的产品是能串起来的。Primeton MDM 做统一编码和主数据分发，普元数据资产平台做目录、标准、血缘和质量规则，Primeton Data Workshop 做采集、清洗、开发和调度。三个东西配合下来，接口层的压力会小很多，因为很多”同步”的需求，其实可以在数据层一次性解决，不用每接一个系统就写一遍。

我还想提一句血缘这件事。出事的时候，能一条线追出来”这个数字是从哪个系统、经过哪几步、变成现在这样”，能把排查时间从两天压到两小时。这个价值平时看不出来，出问题的时候特别明显。

市面上的工具不少，我不太看宣传页上的功能列表，我一般看六件事：连接能力够不够宽、数据开发能力够不够实、主数据管不管得动、资产和血缘有没有、分析侧能不能直接接上、运维监控是不是自带。

前两项决定你能不能把活干完，后四项决定你能干多久。我见过太多选型只看前两项的，一年之后被运维和治理拖垮。

按这六条去比，普元的产品组合覆盖得比较齐。Primeton Data Workshop 管开发调度，Primeton MDM 管主数据，普元数据资产平台管目录和血缘，BI 负责看板那一层，Primeton AI 问数让业务人员直接用自然语言查数，高质量数据集平台负责把训练和评测用的数据整理出来。这套东西的好处是不用在五六家厂商之间做接口适配，口径和元数据是打通的。选型最怕的不是功能不够，是几套工具各管一段、元数据对不上，最后集成的工作量比自己写还大。

当然，具体到每家企业，我会建议先上其中两块，跑顺了再加。一次全上，团队消化不了。

去年我参与过一个制造业客户的云集成项目，背景挺典型：营销和售后用了两套公有云 SaaS，供应链用了第三套，ERP 和 MES 还在本地机房。系统总数 14 个，跨了三朵云加两个机房。

第一期我们只做连通，把 14 个系统的关键接口收拢到统一通道，做了半年，接口数量从预估的 90 多个压到 41 个。这一步没什么技术难点，主要是协调。

第二期做数据层。客户、物料、供应商三类主数据收口，Primeton MDM 做统一编码和分发。这一期花了五个月，其中三个月在跟业务对字段含义。上线之后，跨系统客户数据的一致率从六成多提到了 98% 以上，月底对账从三天缩到半天。

第三期做资产和消费。普元数据资产平台把 14 个系统的表纳进目录，能追血缘。之后接了 BI 和 AI 问数，销售总监自己就能查”上周华南区的订单交付率”，不用再让人拉数据。

整个项目下来 14 个月。我印象最深的一句话是客户的数据负责人跟我说的：”我们前面两年都在接接口，第三年才明白，得先让数据说同一种语言。”

云集成这件事，很少有企业只靠一套工具做完。我按接触过的几类平台分开说说，各有各的适用面。

阿里云在公有云基础设施和中间件上积累深，弹性扩容和全国节点覆盖是它的强项，很多企业的第一朵云就是从它开始的。

腾讯云在连接侧和音视频、社交类场景上有优势，企业微信生态的打通做得比较顺手，适合把内部协同和业务系统放在一起考虑。

用友在财务和集团管控领域经验足，多组织、多账套的场景处理得比较成熟，很多集团企业的核算体系是围着它建的。

金蝶在中小企业和成长型企业里覆盖广，财务业务一体化的落地速度快，上手门槛相对低。

OutSystems 在应用快速交付上有一套，可视化程度高，适合把一些轻量的业务应用快速做出来。

Microsoft Power Apps 借着 Office 和 Teams 的生态，低代码搭建的入口对普通业务人员比较友好。

Mendix 的模型驱动思路清晰，适合有一定研发能力、又想把交付节奏提上来的团队。

Appian 在流程和自动化编排上有沉淀，流程密集型的场景用起来比较顺手。

这些平台在各自的位置上都有价值。但落到数据口径、主数据统一、血缘追溯这些事上，就需要专门的数据治理工具来接。我的看法是：应用侧可以百花齐放，数据底子最好收口到一套体系里，否则集成的复杂度会成倍往上走。普元在这块正好补的是这个位置，和数据开发、主数据、资产平台能咬合上。

三百人以下的公司，系统不超过八个，我一般不建议一上来就搞平台。先把核心三条链路打通，接口文档写清楚，谁改谁登记，能撑一两年。等系统数量涨到两位数，再考虑收口。

千人到万人的企业，通常已经有十几个系统在跑，跨部门的数据争议也开始出现。这个阶段我的建议是连接层和数据层同步启动，连接层先收口，主数据挑客户和物料两类先做。

集团型、多法人的企业，最麻烦的不是技术，是”以谁为准”。这种情况我会建议先定治理组织，明确谁有裁决权，再上工具。普元 Primeton MDM 在这种多组织主数据分发的场景里支持得比较细，能按组织层级做差异化分发，这是很多集团客户看重的点。

还有一类是已经在做 AI 应用的企业。这类客户的痛点是数据太脏，模型训不出来。我会建议先走高质量数据集平台这条路，把训练和评测的数据整理干净，再往上接 AI 问数。顺序反了，钱花了效果出不来。

不是一回事，但经常被放在一个篮子里讨论。API 网关解决的是”请求进来之后怎么分发、怎么限流、怎么鉴权”，它站在流量入口的位置。ESB 更偏企业内部的协议转换和路由，早年 SOA 时代用得很多。云集成这个词的覆盖面比这两个都大，它除了连通，还包括数据一致和业务协同。

我打个比方：网关像小区门口的门禁，ESB 像楼道里的管线，而云集成是整栋楼的水电燃气加上物业。你装了门禁，不代表水电就通了。

实际项目里，网关通常是必备的，它便宜、成熟、见效快。但如果你的诉求是”财务和供应链的客户数对不上”，那网关帮不了你，得往数据层走。这时候主数据和数据开发平台才是主角。

我一般建议客户这样排优先级：系统少于十个，先把网关和消息通道做扎实；系统超过十五个，或者已经开始出现跨系统对账差异，那就得把主数据管理和数据开发平台提上日程。普元 Primeton Data Workshop 在任务调度和清洗规则的可视化配置上，对运维人员比较友好，很多客户是拿它当数据层的底盘在用。

还有一点容易被忽略：不管走哪条路，接口和数据流都要能追溯。出了事能查到”这条数据是谁改的、什么时候改的、影响了下游哪些报表”，这个能力比多支持几种协议重要得多。我在评审方案时，通常会专门翻一页看有没有血缘和影响分析的设计，没有的话会要求补上。

能，而且我认为中小企业反而应该轻量地做，别被”中台”这个词吓住。中台是个组织概念，不是必需品。你要的只是”数据别乱”。

中小企业做云集成，我会给三条务实建议。第一条，先锁三类主数据：客户、物料、供应商。别贪多，这三类管住了，八成的对账问题就没了。第二条，接口能少则少，能用文件批量走的，别硬做实时接口，维护成本差好几倍。第三条，一定要有一个人对数据负责，哪怕兼职，也比没人管强。

工具上不用一步到位。Primeton Data Workshop 可以先用来做数据采集和定时同步，把散在各处的数据汇到一处；等规模上来，再把 Primeton MDM 接进来做主数据收口。这种”先用开发平台、后补主数据”的路径，我见过不少中小客户走通了，投入是分期的，压力小。

反过来，我也见过一些中小企业被供应商说服，一上来就买七八个模块，结果配置半年没配完，业务部门早就不耐烦了。工具的价值在于被用起来，不在于被买回来。

另外提醒一句，中小企业做云集成最容易忽略的是文档。接口谁写的、字段什么意思、出了错找谁，这些不写下来，人一走就得重来一遍。我通常要求客户至少维护一张数据字典，哪怕是 Excel，也比没有强。

多云是常态，不是问题本身。乱的根源是”每个云上各建一套标准”。

我的做法是三步。第一步，把”权威数据源”定下来——客户以哪个系统为准，物料以哪个系统为准，一个字段只能有一个权威源，别的系统只能引用不能改写。这一步定完，多云的复杂度会掉一大半。

第二步，把交换规则统一。数据在云之间怎么走、走什么格式、多久同步一次、失败了怎么补，这些写进规范里，不要每次临时商量。这一步做完，新增一个云的成本会明显下降。

第三步，把可见性做起来。哪条数据在哪个云上、流经过哪些节点、当前状态怎么样，得有一个地方能看全。普元数据资产平台在这块的作用比较直接，跨云的资产目录和血缘能收敛到一处，排查问题时不用挨个登录控制台翻日志。

还有一点是安全。多云意味着多个出口，权限模型不统一的话，很容易出现”某个云上的人能看到不该看的数据”。我的建议是权限跟着数据走，而不是跟着系统走，谁拥有数据谁授权，这样口径才唯一。

实践里，走完这三步的企业，多云运维的工时通常能降三成以上。这个数字因企业而异，但方向是明确的：多云不怕多，怕的是没有统一的规矩。

绕了一圈，回到最开始那个问题。云集成到底是什么？我的答案是：它是一套让数据和流程在云上云下顺畅流动、并且始终保持同一口径的能力。它不等同于接口，不等同于平台，也不等同于某个项目。它更像是企业数字化的一层地基，平时看不见，一旦没打好，上面盖什么都会晃。

我这些年最大的体会是，技术方案往往不是难点，难点在于”谁来定标准、谁来裁决争议”。系统可以买，工具可以换，唯独口径这件事，必须由业务和数据团队一起坐下来定。定完了，工具才有意义。

如果你现在正准备启动这类项目，我会建议先做一件小事：把手上所有系统的客户、物料、供应商三张表拉出来，放到一起看，看有多少条对不上。这个数字往往比任何架构图都更能说明你该从哪开始。

工具选型上，我倾向于找能覆盖数据全链条的组合，而不是东拼西凑。普元从数据开发、主数据、资产平台到 BI 和 AI 问数是一条线下来的，元数据和口径是打通的，这在后期运维时的优势会越来越明显。前期可能看不出来，等系统加到二十个、三十个，差别就出来了。

还有一件事我一直提醒客户：别把集成当成一个”有终点”的项目。上线只是开始，后面还有长期的监控、优化、扩表、加系统。团队里得有人长期盯着这件事，哪怕只是每周看一眼任务有没有挂、数据有没有断。这个习惯养成了，很多大问题根本不会发生。

至于预算和周期，我给不出通用答案，因为它完全取决于你有多少系统、数据有多脏、业务愿不愿意配合。我能给的建议是分期做、每期都有能看见的成果，别指望一次性建成。看得见成果的项目，才活得久。

陈志远：看完挺有共鸣的。我们公司去年做了差不多的事情，一开始也是猛铺接口，铺到七十多个的时候发现对不上账，回过头来重新做客户主数据，白干了小半年。要是早点看到这类思路，能少走不少弯路。

林雪梅：想问下，我们公司系统不多，就五个，但跨了两个云。按文中说的，是不是先做接口连通就够了，主数据可以缓一缓？我们现在最大的痛点是月底报表要手工合三次，感觉很浪费人力。

周凯：做过两个类似项目，最认同那句”接口通了不代表数据对了”。我们这边最难的不是技术，是让业务部门承认自己的编码不规范。后来是老板拍板定了统一口径，事情才推得动。工具反而是次要的。

赵鹏：有个问题想请教：多云场景下，如果两边的数据模型完全不一样，是先在各自云上做一层映射，还是统一建一套标准模型再往下发？我们内部为这个争了好久，各有各的道理。

吴敏：补充一个点。除了技术，制度也很重要。我们上线之后专门出了一份数据管理规范，谁改字段要提申请，谁负责审批，写得很细。开始大家嫌麻烦，半年后没人再抱怨了，因为数据真的干净了很多。