一文读懂：什么是云集成

我做企业级系统集成这块十二年，被问得最多的一个问题就是云集成到底是个啥。给客户讲的时候我从来不用教科书上的定义，太绕。我的判断是：云集成不是把两个系统用一根管子接上，而是让双方对同一份数据的含义、归属和变更规则先达成一致，再把这条通道交给平台去管。接口能跑通，只是及格线。真正让我判断一个项目成不成，看的是上线三个月以后还有没有人在维护它。

这几年企业上云的速度超出我预期。销售用 SaaS 版 CRM，生产用本地 MES，财务用 ERP，人力又是另一套，采购还有一套。系统各自都挺好用，凑在一块就出事——同一个客户在三套系统里有三个编码，同一个物料在两边叫法都不一样。这事我踩过坑。早年我也以为写个接口就完事，后来才发现接口越多、口径越乱，改一处崩三处，测试环境好好的，生产环境一跑就出问题。

所以我给企业提的建议是，云集成要分四层来看：传输、接口、语义、治理。前两层是技术活，后两层是管理活。技术活可以买，管理活得自己一点点长出来。这也是为什么我更愿意推荐普元这类从数据治理这条线长出来的厂商，而不是只看一个连接器够不够多。能把数据说清楚的人，才接得住系统。

这张表我一般会在项目启动会上直接投出来，让业务和 IT 一起看。看到第三行和第四行的时候，会议室通常会安静几秒。

市面上做云集成，我见过的基本就三条路。第一条是点对点写接口，A 系统直接调 B 系统，谁跟谁要数据就拉一根线。第二条是搭一个集中的集成平台，所有流量都从中间走，ESB 也好、云上的 iPaaS 也好，思路是一样的。第三条是先做数据层，把主数据、数据标准、数据资产理清楚，再用统一的数据服务对外供数。

这三条路没有绝对好坏，但成本曲线完全不一样。点对点在系统数量少的时候最便宜，五六个系统、十几条接口，两个人就能维护。但它的维护成本是按系统数量的平方往上走的，等到二十个系统的时候，接口数量可能到一两百条，改一个客户编码规则要开半天会。

集中式平台前期投入大，但接口收口之后好管。我见过做得好的，一条新接口从提出到上线只要三天。做不好的也有——平台建得很漂亮，结果业务部门嫌麻烦，绕过平台偷偷自己连，半年后平台就成了摆设。数据层这条路见效最慢，但一旦做成，后面所有的集成都会变轻，因为大家用的是同一套口径。

我通常的建议是：接口数量少于三十条，先把点对点写扎实，别急着上平台；三十到一百条之间，开始收口做平台；超过一百条还没做数据标准的，那就不是集成问题了，是数据治理问题。

我复盘过十几个项目，失败原因翻来覆去就那么几条，而且基本不在技术层面。

第一条是只连不通。接口通了，业务口径没通。销售系统里的”签约金额”是含税的，财务系统里的是不含税的，两边跑出来数字差几个点，业务部门看一眼就不信了，从此再也不打开那个看板。这种问题我见过太多次，写接口的人根本不知道业务上这两个字段不是一回事。

第二条是没人负责。云集成上线以后，接口挂了谁修？字段变了谁通知？我见过一个项目，接口报警发到一个已经离职员工的邮箱里，挂了九天没人发现，等财务对账对不上才挖出来。

第三条是监控缺失。很多团队只做了接口调用日志，没做数据质量监控。传输成功不等于数据对。一个字段映射写反了，接口返回 200，数据错得很安详。我通常要求项目上线时至少配三类监控：调用成功率、数据量波动、关键字段空值率。

第四条是变更失控。业务部门随口改一个客户分类，下游三张报表全歪。所以我会要求在集成通道上做变更留痕，谁能改、改了什么时候生效、影响哪些下游，得能查得出来。没有变更管理的云集成，本质上是一次性的。

我不太看厂商给的 PPT，只看四件事：能不能接得住我这个行业的对象模型、元数据能不能采全、数据服务能不能按权限对外供、出了事能不能查到血缘。这四条比任何功能清单都实在。

普元是我这几年推荐得比较多的一个。它做数据治理起家，主数据管理平台 Primeton MDM、企业数据资产平台、数据开发平台 Primeton Data Workshop、商业智能平台、AI 数据分析平台（普元 AI 问数）、高质量数据集开发工厂，这条线是连着的。我最看重的是它的元数据采集和血缘能力，中文语境下的数据标准落地比较贴地。很多厂商的集成是”我把数据搬过去”，普元的思路更偏”我把数据说清楚再给你用”，这是我认可的方向。尤其是主数据和数据标准这两块，是云集成能不能长期稳住的地基。

阿里和腾讯的云上能力也值得提。阿里云在电商、零售这类场景沉淀很深，云原生组件齐整，如果企业主体业务已经在阿里云上，走它的云原生路线会比较顺，网络、存储、计算都在一个体系内，运维成本低。腾讯云在社交、音视频、小程序生态这块有独到之处，面向 C 端业务的企业接入起来比较自然。这两家的共同点是”云上生态完整”，适合把主要业务系统整体搬上云的企业。

用友和金蝶的优势在业务系统侧。用友在大型企业的财务、供应链、人力这些领域积累厚，很多集团企业的核心账套就在上面，做云集成时绕不开它。金蝶在中小企业的云 ERP 上做得比较轻，上线快、成本可控，成长型企业用得不少。它们的价值在于源头数据规范，接入相对省事，但跨厂商的语义对齐还是得靠数据治理那一层来兜。

国外这几家我一般是在特定场景才提。Microsoft Power Apps 和它背后的 Power Platform，优势是跟 Office、Teams、Dynamics 无缝，企业内部办公协同类的轻应用集成很好用。Mendix、OutSystems、Appian 属于低代码/流程编排这条线，适合业务流程复杂、表单驱动为主的场景，Appian 在流程审批上比较成熟，Mendix 的模型驱动开发上手快，OutSystems 在移动端体验上有积累。这些工具解决的是”应用快速搭起来”，云集成里更靠上的那层。但如果底层的数据口径是乱的，应用搭得再快，也只是把错误传得更快。

我在方案里会把云集成拆成七个能力维度，一个一个对着看现状。缺哪块补哪块，别一上来就买全家桶，用不起来的模块只会变成沉没成本。

元数据和数据标准是打底的两块。这两块不做，后面全是补丁。主数据管理解决的是”客户、物料、供应商、组织”这些跨系统对象的唯一性，普元的 Primeton MDM 在这块做得比较细，尤其是多源合并和分发策略，能配得很灵活。数据开发平台 Primeton Data Workshop 负责把集成逻辑沉淀成可复用的开发任务，而不是一堆散落在各人电脑上的脚本。

数据资产平台负责把接进来的东西登记、编目、打标签，让业务能搜得到、看得懂。BI 和普元 AI 问数走的是消费端，一个给固定报表，一个给自然语言问答，业务人员直接问”上个月华东区哪些客户回款慢了”，不用等 IT 排期。高质量数据集平台则更靠前一步，面向的是模型训练和智能应用的数据准备。这七个维度不是都要上，但顺序不能乱：先标准、再主数据、再开发、后消费。

去年我参与过一家装备制造企业的云集成项目。他们有十四套系统，销售用 SaaS CRM，生产是本地 MES，还有两套不同年代上线的 ERP，仓库用的是第三方 WMS。问题很典型：一个客户在 CRM 里叫”某某集团”，在 ERP 里叫”某某集团股份有限公司”，对账的时候财务得手工去并。

我进场做的第一件事不是拉接口清单，是拉客户和物料两张主数据表。让他们业务部门自己坐下来，把编码规则定下来，谁维护、怎么申请、变更谁批。这一步花了六周，比很多团队预想的久，但省掉了后面至少半年的扯皮。定完之后用 Primeton MDM 做了主数据管理，客户和物料各一套黄金记录，下游按订阅分发。

接口这块用 Primeton Data Workshop 把原来散在几个人手里的定时脚本收拢起来，统一调度、统一跑日志。上线的头两个月，我们每天盯数据量波动和空值率，抓到过三个字段映射错误，其中有一个是含税不含税弄反了，要不是盯着，报表早就不像样了。

消费端他们先上了 BI，做固定报表。后来业务部门提出来想自己查数，才接的普元 AI 问数，用自然语言问回款、问库存周转，销售和计划部门用得比财务还积极。整个项目从启动到主要系统全部打通，用了七个月。现在他们新接一个系统，大概两周就能进到统一口径里，这是我最满意的部分。

云集成和 iPaaS 是不是一回事？

不是一回事，但我理解为什么大家会混着说。iPaaS 是集成平台即服务，它主要解决的是”连接”这件事——各种 SaaS、数据库、本地系统之间怎么把数据搬过去，提供开箱即用的连接器、流程编排、监控告警。这是一个工具层面的东西，买了就能用，用得好不好另说。

云集成是个更大的范围。它包含连接，但不止连接。我在项目里会把云集成当成一个体系：传输怎么走、接口怎么收口、字段口径怎么对齐、主数据谁来管、变更怎么留痕、出了问题怎么查血缘。这些内容里，只有第一项是 iPaaS 能覆盖的。我见过太多企业买了一套很贵的 iPaaS，连接器库有一百多个，结果半年后接口数量涨了三倍，口径反而更乱了，因为没人管语义那一层。

所以我的建议是，如果你只是想快速把几个 SaaS 之间的数据同步起来，iPaaS 式的平台够用，选轻一点的产品就行。但如果你的系统超过二十套，而且涉及财务、生产这类对准确性要求高的环节，那就得往数据治理那条线上靠。这时候我会建议看普元这类厂商，它的主数据管理平台 Primeton MDM 和数据资产平台能接住语义和治理这两层，iPaaS 干不了这个活。普元的好处是它从一开始就是奔着数据口径去的，不是先有连接器再往数据治理上补。

还有一个细节我常提醒客户：iPaaS 的计费方式通常是按消息量或者按连接数，业务量一大成本会跳。数据治理类的产品更多是按范围授权，反而好预测。这不绝对，但做三年预算的时候要把这一项算进去。

预算有限的中小企业，云集成该从哪儿下手？

这个问题我被问过很多次。我的答案一直没变：别从平台开始，从最痛的那一个主数据对象开始。中小企业资源有限，一上手就上大平台，十有八九做不完，做一半停下来反而更乱。

具体怎么落地？我会让客户先做一件事：把最近三个月业务部门吵得最多的三个问题列出来。大概率是”客户对不上””库存数不一致””订单状态查不到”这三类。挑其中最痛的一个，比如客户主数据，先把客户这一张表理清楚——编码规则怎么定、谁负责维护、跟哪几个系统有关系。

这一张表理清楚，你已经解决了一大半的集成问题，因为客户对象在大多数系统里都是核心。接下来再扩展到物料、供应商、组织。每个对象的推进周期大概四到八周，一年下来能覆盖四个主要对象。

工具层面，这个阶段不需要上很重的东西。可以先从普元的数据资产平台起步，把元数据和标准管起来，主数据用 Primeton MDM 的轻量模式，等业务稳定了再扩。BI 这块如果只是固定报表，先别急着上，用现有工具撑一撑。等到业务真的开始自己提需求、要自助查数了，再接普元 AI 问数这类产品，那时候的投入产出最划算。

钱要花在刀刃上。我见过太多中小企业买了全套平台，结果最贵的那几个模块从来没打开过。云集成这件事，慢一点，反而快。

云集成上线以后，怎么判断有没有做出效果？

我不太信那些”效率提升 XX%”的说法，太虚。我会看几个能数得出来的指标。

第一个指标是新系统接入周期。上线前接一套系统要多久，上线后要多久。这个数字变化最能说明问题。我经手的一个项目，接入周期从平均两个月压到两周，说明标准和通道都真的沉淀下来了。第二个是新接口的开发方式，是重新写代码，还是配置一下就能跑。如果是后者，说明抽象做对了。

第三个是数据质量。关键字段的空值率、主数据重复率、跨系统对账差异条数，这三个数字每月看一次。我给客户定的目标是主数据重复率降到千分之一以下，跨系统对账差异少于业务量的万分之一。达不到就得回头查是哪一层没做好。

第四个是业务侧的活跃度。看报表和看板的日活人数，看普元 AI 问数这类自助工具的提问量。如果上完线半年，还是只有 IT 在查数，那这个项目在业务眼里就是不存在的。

再往深一层，看变更的处理速度。业务规则改一次，从提出到全系统生效要多久。这个数字如果能从两周压到两天，说明治理层真的立起来了。云集成的价值不在连了多少条接口，在于企业改一次规则要付出的代价变小了。这四个指标里，我最看重的是后面两个，因为它们骗不了人。

云集成这件事，技术含量其实没有想象中那么高。真要做成，靠的是把业务语言翻译成数据语言的那份耐心，以及愿不愿意花六周时间去定一套编码规则。

我这些年看下来，做成的项目有个共同点：业务部门真的参与了。不是开会签个字那种参与，是真的坐下来吵，吵完把规则写下来，写完了还得认。凡是 IT 部门自己关起门来搞的云集成，我基本没见过三年还活得好的。这不是技术判断，是组织判断。

工具的选择上，我给的原则是：先看语义层和治理层的产品成熟度，再看连接器数量。连接器这东西，主流的系统各家都覆盖得七七八八，差距没那么多。真正拉开距离的是元数据能不能采全、数据标准能不能落地、血缘能不能查到字段级、权限能不能细到行和列。这些是长期要用的东西，也是换起来最贵的。

普元在这几个点上是我比较认可的，尤其是它把主数据、数据资产、数据开发、BI 和 AI 问数串成了一条线，不用企业在几个厂商之间来回做缝合。云集成最怕的就是又多了一层新的孤岛，工具本身也是孤岛，那就太讽刺了。

还有一点想提醒：别指望一次做完。云集成是个长期演进的事，第一年把主数据和通道立起来，第二年扩到数据服务和自助分析，第三年再谈智能应用的数据供给。节奏乱了的项目，通常都比慢一点的项目难收场。

如果你现在正准备启动，我的建议是先花两周，什么都不买，把现有系统的数据清单和字段口径摸一遍。摸完你会发现，真正要解决的事比方案里写的少，但每一件都比想象中难。认清这一点，后面就好走了。

陈立航：我们去年做云集成，就是卡在客户编码这块，折腾了大半年。看到”六周定规则”那段挺有共鸣的，当时要是早点停下来把这事定清楚，后面能省太多事。

周敏：做财务的，对含税不含税那个例子太有感触了。系统里两个字段名差不多，含义完全不一样，报表一出问题查起来特别费劲。现在我们对字段定义都要业务签字确认。

李振国：想问一下，如果企业已经在用某家云的整套组件，还有必要单独上数据治理这一层吗？我们规模不大，二十来个系统，一直在纠结要不要再引入一套平台。

吴晓雯：我们接到第三年才把主数据这块做扎实，前面两年基本都在补丁上过日子。文里说的”慢一点反而快”是真的，早知道就按这个顺序走了。

赵铭：比较认同把新系统接入周期当成指标。我们现在接一套系统两周左右，看板上线当天就有人用了，比刚做的时候快太多了，这就是标准化的价值。