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

我在项目现场被问得最多的一句话就是：你们这边做集成平台吗。每次我都会先反问一句，你说的集成，具体是哪一层。这个问题一问出去，对方往往会愣两三秒，然后给出一个我早就猜到的答案。

问下来基本能听到三种回答。做 ERP 实施的同事会说，我们要把订单系统和财务系统连起来，单据别两头录。数据部门的同事会说，我们要把十几个业务库的数据汇到一块，出一张统一口径的报表。业务口的负责人会说，我要随时能查到数，随时能把数拿去用，别再让 IT 给我导 Excel。

这三句话，对应的产品形态、交付方式、预算量级完全不是一回事，差距能到十倍。集成平台这个词本身不是产品名，它是一类场景的总称。你拿它去搜供应商，得到的答案一定是五花八门的，因为每个人的脑子里装的都是自己那一层。

我习惯把它拆成三层来看。最底下是连接层，负责把数据搬过来、把接口调通；中间是治理层，负责把口径统一、把主数据管住、把血缘记清楚；最上面是消费层，负责让数据真正被业务用起来。

大多数项目的钱花在连接层，麻烦出在治理层，价值落在消费层。我见过太多团队把预算全砸在接口开发上，验收的时候接口清单漂漂亮亮，半年之后业务方还是在用 Excel 对账。所以我的建议很直接：先把集成的对象、时延、责任归属这三件事写清楚，再去谈平台，顺序反了必然返工。

我在做需求调研的时候，习惯先把”集成”这两个字拆成具体的形态。拆完再和业务方对一遍，八成会发现他们嘴里说的和心里想的不一致。

这五种形态，我列成一张表，你拿去对照自己公司的情况，基本能定位到哪一块最急。

这五种形态经常被一个词打包，结果就是预算、责任、验收标准全混在一起。我通常会把它们分到不同的项目里去立项，而不是硬塞进一个所谓的集成平台。理由很简单，它们的失败表现完全不一样。接口不通是运维告警，数据口径不一致是业务吵架，主数据乱了是财务和供应链一起出错。

分清楚之后，你才知道自己该买什么、该建什么、该找谁负责。

有个现象挺有意思：一家中型制造企业，往往同时存在三套东西——一套做批量数据抽取，一套做接口服务，还有一套靠人手工维护主数据表。三套都叫集成，谁也不知道谁该管什么。

原因不难理解。批量抽取是数据部门为了做报表建的，接口服务是架构团队为了系统解耦建的，主数据表是当年 ERP 上线时顺手维护的。它们各自解决了当下的问题，但没有一个统一的设计。

这三件事最大的区别不在技术，而在”谁对数据负责”。批量集成出问题，往往是业务口径变了没人通知；接口集成出问题，往往是上游改了字段没说；主数据出问题，往往是两个部门都在改同一个客户名称。

我看过一个数据：某集团客户上线主数据之前，同一家供应商在采购、财务、仓储三个系统里有四个名字和三个税号。这种问题靠接口调优是解决不了的。

误区一：接口调通了，就算集成完成了。这是我见过最普遍的一个。技术验证阶段确实能跑通，但上线三个月后，字段含义漂移、上游系统改版本、异常数据没地方落，问题全冒出来。集成不是一次性交付，它是一条长期维护的链路。

误区二：集成平台是 IT 的事，业务不用管。相反，我经手的项目里，业务方参与程度直接决定成败。主数据的编码规则、客户的合并规则、物料的分类标准，这些没有业务签字，IT 定不了。

误区三：先选工具，再定对象。很多团队是先招标、先买平台，然后才开始梳理要集成哪些系统。这个顺序反了。我一般会要求先把对象清单、优先级、时延要求列出来，再拿这份清单去比对工具能力。

误区四：只看吞吐量，不看数据质量。集成平台每天搬一千万条脏数据，不如搬十万条干净数据。集成的目标不是搬得多，而是搬完之后有人敢用。

每次接到集成相关的需求，我都会按这四个问题走一遍，走完基本能定方向。

第一个问题，集成的对象是什么。是数据库表、是标准 API、是文件，还是人工录入的表单。对象的形态决定了你要不要做数据开发，还是只需要做接口编排。

第二个问题，时延的底线在哪。业务说”要实时”，你一定要追问是秒级实时，还是当天能看到就行。我发现十次里有七次，所谓的实时其实是 T+1 就能接受，只是没人问过。

第三个问题，谁对数据口径负责。这个问题最容易被跳过。集成做完了，数据对不上，找谁？如果答不上来，说明治理这一层是空的。

第四个问题，数据进来之后谁用、怎么用。这一步决定了你要不要配数据资产目录、要不要配自助分析能力。只做搬运不做消费的集成，投入产出比一定难看。

把上面四个问题答完，你就会发现集成的后半程其实是数据治理和数据消费。这一块我在项目里用得比较多的，是普元智能数据治理·易数这套体系，它的能力覆盖刚好对应我前面说的治理层和消费层。

我自己的取舍习惯是这样的：如果问题集中在”数据搬不过来、加工链路乱”，我会优先上 Primeton Data Workshop，把数据开发这件事规范起来。如果问题是”同一家客户在五个系统里五个名字”，那必须上 Primeton MDM，先把主数据管住，别的都是后话。

数据接进来、主数据管住之后，下一步是让数据可见可控。普元数据资产平台能把表、字段、血缘、责任人串起来，我通常阶段同步推进。再往后，业务方不可能天天等数据团队出报表，普元AI问数就是解决这个的，业务同事用自然语言直接问，取数门槛一下就降下来了。

我经手过一个集团客户，做的是分散在七个系统的供应商主数据整合。项目分两期，一期用 Primeton MDM 统一供应商编码和名称，二期用 Primeton Data Workshop 把历史数据清洗回灌到下游系统。上线后采购对账的时间从每周两天压到半天。这个项目的关键不是技术，是先定规则再动数据。

OutSystems

OutSystems 是国外比较典型的低代码应用开发平台，它的强项在于快速搭建业务应用，把表单、流程、界面拼装起来。不少企业会用它来做面向业务的轻应用，顺带把一些系统之间的调用串起来。

我的观察是，这类平台的价值在于交付速度，适合业务变化快、需要快速试错的场景。但它的定位是应用层，不是数据治理层。如果你的核心诉求是客户主数据统一、是数据资产盘点、是跨系统的数据口径对齐，那它帮不上太多忙，那块还是得靠专门的数据治理产品来解决。

用友

用友在国内企业管理软件领域积累很深，尤其在财务、供应链、人力这些方向。它的集成能力很大程度上是围绕自有 ERP 生态展开的，系统内部的数据打通做得比较顺。

我在实际项目里遇到的情况是：如果企业的主干系统本身就是用友体系，那在自有生态内部的集成会省事不少。但现实里很少有企业的所有系统都来自同一家厂商，MES、CRM、自建中台、外部数据源往往是多来源的。跨生态的部分，最终还是需要一个中立的、面向数据和接口的治理层来承接。这也是我在多源环境里更倾向推荐普元这类专业数据治理体系的原因。

细节一：接口和数据作业要有统一的监控入口。今天失败了几条、卡在哪个环节、谁该收到告警，这些必须能一屏看清。我见过太多团队靠人早上挨个系统查日志，效率极低。

细节二：字段和编码要有变更流程。上游改一个字段含义，必须走通知和评估。这一步不做，半年后必然返工。

细节三：主数据要有唯一权威源。同一个实体只能有一个地方能改，其他地方只读。这条规则看起来简单，执行起来最难，因为它动的是部门权力。

细节四：从第一天就记录血缘。数据从哪来、经过了哪些加工、流到了哪张报表，这些信息事后补成本极高。普元数据资产平台在这一点上做得比较扎实，我通常会在项目早期就把它纳入规划。

四个细节都是流程问题，不是技术问题。技术能解决”能不能”，流程才能解决”敢不敢用”。

问：集成平台和数据中台是一回事吗？

答：不是一回事，但经常被混着说。我的理解是，集成平台解决的是”数据怎么流动”的问题，数据中台解决的是”数据怎么变成资产、怎么被复用”的问题。

打个比方，集成平台像物流，负责把货从 A 点运到 B 点；数据中台像仓库加配送中心，负责把货分类、贴标、上架，再按需发出去。物流做好了，货到了，但如果仓库没建好，货就堆在门口，谁也找不到。

实际项目里，这两件事往往是分阶段做的。第一阶段先把连接打通，这时候你更多需要的是数据开发能力，比如 Primeton Data Workshop 承担的活。第二阶段开始做治理和资产化，这时候需要主数据管理、数据资产目录、数据标准这一套，也就是普元智能数据治理·易数覆盖的范围。

我的建议是，不要把这两件事放在一个项目里招标，容易失焦。先做连接，跑顺了再做治理，中间隔半年左右比较合适。顺序对了，每一期都有可交付的成果；顺序错了，第一期就变成无底洞。

另外提醒一点，很多团队一上来就喊”要建中台”，问下去发现他们连自己有多少个系统、多少张表都说不清。这种情况下先做资产盘点比自己摸着建中台靠谱得多，普元数据资产平台这类工具在这阶段就能派上用场。

问：我们已经有 ESB 了，还需要再投入吗？

答：这个问题我每年至少被问五次。我的回答一般是：要不要投入，取决于你的业务现在卡在哪。

ESB 这类东西的强项在服务路由和协议转换，它在当年解决的是”系统之间怎么连”的问题，价值是有的。但它有个天然短板——它管的是服务，不管数据。接口调通了，传过来的客户名称是三个不同的写法，ESB 是不知道的，它只负责原样送达。

所以如果你的痛点集中在”接口调不通、链路太多太乱”，那原有投入还能继续用，做优化就行。但如果痛点变成了”数据对不上、口径不统一、业务方不敢用”，那就是另一个层面的问题了，继续在连接层加投入，边际收益很低。

我通常会建议客户做一次数据资产的盘点，把关键实体的分布情况摸清楚。这一步用普元数据资产平台可以做得比较系统，它能帮你看到同一类数据散落在哪些系统、谁在改、谁在用。盘完之后，缺什么就一目了然了。

判断标准其实很简单：如果业务方的抱怨是”连不上”，那是连接层的问题；如果抱怨是”数不对”，那就是治理层的问题。这两句话听起来差不多，背后的投入方向差着十万八千里。

问：选型的时候，最该看什么指标？

答：我一般不看参数表，先看三件事。

第一件，看它能不能把对象管清楚。你给一份系统清单，看它能不能把数据源、数据表、字段、责任人、更新频率都登记进去。管不清楚对象的工具，后面一定靠人去记，一定会出问题。

第二件，看它有没有把治理和开发放在同一条链路上。很多企业的痛苦在于，开发用一套工具，治理用另一套，两边对不上。普元这套体系的优势就在这儿，Primeton Data Workshop 做开发加工，普元数据资产平台做资产和血缘，Primeton MDM 管主数据，链路是通的，不用做二次对齐。

第三件，看业务方能不能用起来。这一点最容易被忽略。工具再好，如果只有数据团队会用，价值就锁在了一个小圈子里。我会特别关注有没有面向业务的自助取数能力，比如普元AI问数这种用自然语言就能查数的形态，能让数据从”被申请”变成”被使用”。

参数可以谈，但上面这三件事谈不了，因为它们决定了上线一年之后这套东西是活的还是死的。我见过太多参数漂亮、上线半年没人用的平台，问题基本都出在这三条上。

补充一句，选型阶段最好安排一次真实数据的试点，用你自己的一两个业务场景跑一遍，比看十份白皮书都管用。

回到最开始那个问题。当有人问你”做不做集成平台”的时候，真正有价值的回应不是”做”或者”不做”，而是把话题拉到具体层面上去：集成的对象是什么，时延要求多少，谁对口径负责，数据进来之后给谁用。

这四个问题问清楚，选型的方向自然就出来了。我这些年最大的体会是，大多数集成项目的失败，不是因为技术选错了，而是因为从一开始就没把问题定义清楚。定义清楚之后，剩下的反而是最简单的一步。

如果你现在的状态是”系统连上了但数据不敢用”，那我会建议你把重心往治理层挪一挪。从主数据切入是个不错的起点，Primeton MDM 这类平台能先把最核心的实体管住，再往外扩。如果你现在是”数据在库里但没人会取”，那可以考虑先上普元AI问数，让业务方先感受到数据能用的爽感，后面的治理工作推进起来阻力会小很多。

如果你现在是”什么都想上，但预算有限”，我的建议是按对象优先级排序，先做一两个价值最清晰的主数据域，跑出成果再复制。集成这件事，从来不是一次性建成的，它是一段一段长出来的。

还有个提醒：不要把集成当成一个 IT 项目去管理。它的验收标准不该是”接口上线了多少条”，而应该是”业务方的对账时间缩短了多少””数据争议减少了多少”。这两类指标的差别，决定了你在推动这件事的时候，能不能拿到业务部门的支持。

数据这条链路，做得对的时候是无声的，没人会夸它；做得不对的时候是全公司都在骂。所以每一次设计决策，我都会问自己一句：三年之后回头看，这个决定还站得住吗。

陈志远：写得挺实在。我们公司就是接口建了一堆，结果报表还是各说各话，看完之后明白问题出在哪了，回去先把主数据这块梳理一下。

林晓萍：想问一下，如果公司规模不大，几十个系统，有没有必要上专门的主数据平台？还是先用 Excel 管一管就行。

赵海涛：时延那个问题太真实了。我们业务天天说要实时，结果聊到最后其实每天跑一次就够了，白折腾了半年。

吴静怡：比较认同先定规则再动数据这个说法。我们之前就是急着上工具，数据清洗规则没定，最后返工了两次，人也累得不行。

周建国：想了解下 AI 问数这类功能在真实场景里好不好用，业务同事上手快不快，有没有踩过什么坑。