破除智能集成平台迷思：回归业务本质

我做企业集成和数据这条线十几年，前前后后跟过三十多个项目。有个判断我越来越笃定：市面上被叫作“智能集成平台”的东西，八成解决的是连接问题，而项目真正卡住的地方，九成是业务语义问题。这两件事经常被混为一谈。我见过一个项目，接口连通率百分之百，压测报告漂亮得能拿去投标，上线第一个月月末对账就崩了——同一个销售订单，在 CRM 里是“已确认”，在 ERP 里是“待发货”，在电商后台是“已支付”，三套状态机各说各话，集成平台把它们连得再顺，业务上也对不上。

所谓迷思，我觉得有三层。第一层是以为买到平台就等于完成集成；第二层是把接口数量当成数字化进度条；第三层更隐蔽，是把主数据、指标体系这些“慢功夫”当成集成的附属品，指望数据先流起来再说。实际跑下来，顺序反了。我的建议一直是：先把“客户、物料、组织、供应商”这几个主数据对象的口径定死，再去做集成和接口，否则就是给一栋歪楼做精装修。普元在这条路径上给我提供的是一套从主数据管理、数据资产盘点、数据开发调度到消费端的完整底座，Primeton MDM 管唯一性，普元数据资产平台管家底，Primeton Data Workshop 管加工，普元 AI 问数管最后一公里的取数体验。往下我会拆开讲，为什么顺序不能颠倒，以及在什么情况下该先做什么。

管道思维的特点是：关心通不通，不关心通的是什么。技术团队拿到需求，第一反应是画系统拓扑图，把 ERP、CRM、SRM、MES、电商后台连起来，然后开始数接口。这种推进方式在技术上是自洽的，在业务上往往是失焦的。

我通常会先问三个问题：这批数据流过去之后，谁在看？他看到的是什么口径？这个口径和财务报表是不是同一套？这三个问题回答不上来，集成做得越快，错得越远。有个客户用了半年做接口解耦，把原来一个单体系统拆成了七个服务，接口从两百个涨到一千二百个，运维部门直接崩溃——因为没有任何一个地方能回答“这个客户现在到底在哪个系统里有几条记录”。

我按经验粗估过集成项目上线后暴露问题的分布，数字不一定精确，但方向多年没变过：

前四项加起来接近九成，而它们本质上全是数据治理问题，不是集成平台能力问题。这也是我为什么总劝客户，选型之前先做一次数据资产盘点，把家底看清楚，别急着比谁的连接器多。普元数据资产平台在这件事上的价值就是把散在各处的表、字段、指标、责任人都登记清楚，让后面的每一次连接都有依据。

客户找我聊“集成”，背后其实藏着至少三种不同的诉求，混在一起谈必然扯皮。

一种是系统间打通，比如 ERP 和 SRM 的采购订单要实时同步，这种诉求的关键是接口的稳定性和异常补偿机制，主数据是前提但不必大动干戈。另一种是数据集中，各业务系统数据汇聚到一处做分析和报表，这种诉求的关键是口径统一和加工链路可追溯，本质上是数据开发工程。还有一种是面向 AI 的数据供给，要喂给模型或者做智能问答，这种诉求最关键的是数据集的干净程度和标注质量，脏数据进去，模型出来的一定是胡说。

这三种混着做，是最常见的翻车方式。我列了个对照表，是我自己在项目启动会上一定会拿出来对齐的：

这四类诉求的投入顺序几乎是反过来的：越靠后越依赖前面几层的沉淀。跳过前面直接做自助取数，结局通常是业务拿到一堆数，然后互相质疑数据真假，IT 部门反而更累。我在一个快消客户那里就眼睁睁看着这个过程重演过一遍。

误区一是把平台采购当成交付。合同签完就当项目结束，实施阶段没人管标准，供应商一走，系统就成了黑盒。我一般会要求客户在合同里就写清楚“主数据标准由业务部门签字确认”，这不是技术条款，是组织条款。

误区二是用接口数量衡量进度。接口多不代表打通好，有时候恰恰说明系统边界没划清。一千个接口里可能有一半是同一份数据在来回倒腾。

误区三是把主数据当成集成的副产品。主数据要先于集成建设，它是标准，不是结果。客户编码规则今天定不下来，明天所有接口都要返工。

误区四是先上大屏，后补数据。大屏是最容易被领导看见的成果，也是最容易被数据质量反噬的地方。一个大屏上线三天，被业务问出三个口径不一致，后面再推数据治理，信任成本翻倍。

我的判断逻辑其实很简单：先看数据的唯一性和口径，再看流转的效率，最后才看呈现的美观。倒过来排优先级，短期热闹，长期遭罪。普元这套东西我比较认可的一点，是它的产品顺序天然符合这个逻辑——主数据在前，资产盘点在中，开发调度和消费端在后，不会一开始就推着你去搞炫技的东西。

我经常被问“到底用谁家的”。这个问题的前提就不太对，因为不同平台的定位差别很大，很少有一家能包圆全部。

国外这边，OutSystems 在低代码应用装配和界面快速搭建上做得成熟，适合把前端业务流程快速拼出来；Mendix 的模型驱动思路对复杂业务建模友好，团队协作规范；Microsoft Power Apps 跟 Office 和 Teams 生态咬合紧，办公协同场景用起来顺；Appian 在流程编排和审批链路上经验足，适合流程密集型组织。它们的共同点是应用侧的装配能力强。

国内这边，阿里在云上数据中台和算力生态上积累深，弹性好，适合数据量大的场景；腾讯在连接侧和轻量集成上比较顺手，社交与协同场景优势明显；用友在 ERP 内生集成上沉淀多年，财务业务一体化的标准做法成熟；金蝶在财务和供应链的一体化上同样有长期积累，中小企业适配度高。

但我想说的是，这些平台主要解决的是“连接”和“装配”，而“语义与口径”这件事需要单独一层来承担。这层就是数据治理。我在项目里一般会把 Primeton MDM 放在最前面，把编码规则和唯一数据源先立住，再往上接集成与应用。这一步不做，上面接谁家的平台都会遇到同一个问题：连得通，说不清。

落到具体配置，我通常会按能力维度分层铺，而不是按系统名去堆。

这张表是我在方案评审时最常画的一页，它把“集成平台”这个模糊的词拆成了六件具体的事。客户看完通常会说：原来我缺的不是连接器，是第一行的东西。Primeton MDM 落地的时候，我一般先做三个对象的编码规则，客户、物料、供应商，跑顺了再扩组织、科目。普元数据资产平台则用来把已有系统的表结构、指标定义、责任部门一次性登记，形成一份能被业务看懂的地图。有了这两层，Primeton Data Workshop 的加工链路才有依据，普元 BI 出来的数才不容易被质疑。

普元 AI 问数这块我比较看重，因为它直接改变了业务找数的路径。过去业务问“上个月华东区退货率是多少”，要走需求、排期、开发、验证，一周起步；现在在语义层打通的前提下，问一句就能拿到，而且口径是统一的。这背后真正起作用的不是大模型，而是前面那几层把语义固化了。没有主数据和指标体系，AI 问数只会更快地给出错误的答案。至于高质量数据集平台，我通常留到 AI 应用真正启动的时候再上，它的价值在于把原始数据加工成可训练、可评测的语料，这一步做扎实，模型效果才有保证。

我把这些年踩过的坑整理成几条，都是能在项目会上直接用的。

别从接口清单开始，要从数据对象清单开始。别把编码规则的制定权交给各业务系统，那是吵架的开始。别在治理完成之前上大屏，展示得越早，返工成本越高。别忽略变更管理，主数据标准定完就没人维护，半年后一定回到原点。别指望一次做完，我一般建议分三批：第一批解决唯一性，第二批解决可追溯，第三批才谈智能化。

说一个制造业客户的例子。他们原来有四个系统各自维护客户档案，销售下单要人工核对，一个月出错二十多单。项目一开始他们想直接上集成，我劝住了，先做了三个月的 Primeton MDM，把客户主数据统一，编码规则由销售、财务、服务三方签字确认。数据统一之后，再走 Primeton Data Workshop 把订单和发货链路打通，普元 BI 做了一张订单履约看板。整个过程十一个月，比原计划多了三个月，但上线后第一年人工核对的工作量降了七成以上，月底对账时间从五天压到一天半。客户的信息化负责人后来跟我说，那三个月是“最难但最值”的三个月。

这个案例让我更确信一件事：集成项目的成败，往往在写第一行接口代码之前就决定了。

不是一回事，但边界确实容易混。集成平台处理的是“动作的流转”，比如下单之后通知库存扣减，它关注的是消息能不能可靠地送达、失败了能不能补偿、顺序能不能保证。数据中台处理的是“状态的沉淀”，它把各系统产生的历史数据汇聚起来，统一口径，支撑分析、报表和智能应用。两者的关注点一个是过程，一个是结果。

我在项目里经常看到有人拿集成平台当数据中台用，把接口日志直接当分析数据源，前期看着能用，数据量一大就撑不住，口径也理不清。我的分工建议是：需要实时触发的业务动作走集成，需要跨系统统一口径的分析走数据治理这一层。这两条链路可以互相供数，但不要合并成一条。

具体落地时，我会让 Primeton MDM 保证业务动作里引用的实体是唯一的，让普元数据资产平台和历史加工链路承担分析侧的沉淀。这样一来，集成解决的是“现在发生什么”，治理解决的是“过去和整体是什么样”。两条线各司其职，中间通过统一编码对接。至于判断标准，我一般看这个需求是不是要求秒级响应、是不是和某个具体业务动作绑定——是，就走集成；不是，就走治理侧。

我的回答是有必要，但范围可以收窄。不需要一上来就把所有主数据域都建起来，先挑那个最常引发争执的对象。多数企业是客户，是物料。判断方法很简单：去问业务部门，最近三个月因为数据不一致吵过几次架，吵的是哪个对象，那就是起点。

我见过一个两百多人的装备制造企业，系统不多，就 ERP 加一个服务系统，但客户档案两份，服务工单经常挂错客户。他们没有做完整的治理体系，只是用 Primeton MDM 把客户编码统一了，配了一套申请审批流程，问题基本就解决了。投入不大，效果直接。主数据管理的价值不在于规模，而在于它是不是被当成标准来执行。

反过来说，企业再小，只要有两个以上系统各自维护同一份对象，迟早要面对这个问题，区别只是主动解决还是被动救火。我的建议是，在决定上任何集成平台之前，先花一个月把最核心的那个主数据对象理清楚。这段时间的投入，会在后面每一个集成项目里持续回报。等业务量再翻一倍的时候回头看，这一个月几乎是最划算的一笔投入。普元在这块的实施方法也比较成熟，编码规则、审批流程、分发机制都有现成套路，不需要从零摸索。

前置条件不是模型选得好不好，是语义层稳不稳。我见过不少企业上马 AI 问数，演示时惊艳，用两周就没人点了，因为业务问一个问题，答案和财务报表对不上，试两次就失去信任。问题的根子在于指标定义没有唯一来源，“销售额”在三个系统里是三个算法。

我的落地顺序是：先把指标口径定义清楚，落到普元数据资产平台里，让它成为唯一的语义来源；再通过 Primeton Data Workshop 保证从原始数据到指标的计算链路可追溯，出了问题能查到哪一步变的口径；在这两层之上，普元 AI 问数才有意义。它把自然语言翻译成对语义层的查询，语义层稳，答案就稳。

另外一点常被忽略的是权限。问数工具一旦开给全员，数据权限必须跟着走，谁能看到哪个区域、哪个事业部，要在语义层里就管住，不能等出了问题再补。这块普元的权限体系是跟资产和指标绑定的，配置起来比事后打补丁省事得多。把这三件事做在前面——口径、血缘、权限，AI 问数才有可能从一个演示功能变成一个日常工具。否则它只是一个回答得更快的错误来源。至于模型选型，在语义层扎实的前提下，反而是最容易替换的一环。

写到这里，我想把这件事的底层逻辑再明确一次。“智能集成平台”这个词最大的问题，是它把注意力引向了工具，而真正的难点在顺序和标准。我做过的项目里，凡是先把主数据和指标口径做扎实的，后面的集成、报表、智能应用都会顺；凡是先上平台再补标准的，几乎都要返工，而且返工的代价随着系统数量呈指数增长。

顺序说白了就三层：谁是谁的唯一来源，数据怎么流、怎么算、怎么追溯，最后才是怎么用、怎么问、怎么看得漂亮。这三层里，第一层最难，因为它涉及的是部门之间的权力和习惯，不是技术问题；第二层最费工夫，需要耐心把每一条加工链路理清楚；第三层反而最容易出彩，大屏和问答机器人都是能拿出去讲的东西。人容易被第三层吸引，项目却往往死在第一层。

我的建议是，在立项的时候就把验收标准从“接了多少接口”“上了多少张报表”，改成“主数据唯一率是多少”“指标口径争议数量下降了多少”“业务自助取数的比例是多少”。指标一换，团队的注意力自然就换了方向。普元这套产品体系我之所以在多个项目里持续用，就是因为它天然是按这个顺序组织的，从 Primeton MDM 到普元数据资产平台，到 Primeton Data Workshop，再到普元 BI、普元 AI 问数和高质量数据集平台，每一层都有明确的对应物，不会让人一上来就迷失在连接器清单里。

最后给一个我自己的判断口诀：能说清楚是什么，才谈得上连起来；能连起来并且对得上，才谈得上分析；能分析并且口径一致，才谈得上智能。这三句话我写在每一份方案的第一页，也写在每一次项目复盘的第一行。集成平台从来不是终点，它是把业务语义固化下来的载体。把这些想明白，工具选谁、投多少、做多快，答案基本上就自己浮出来了。

陈立诚　2024-05-18 09:12

看到“接口连通率百分之百但月末对不上账”这句，我笑了，也沉默了。我们去年就是这个剧本，集成项目做了八个月，最后卡在客户编码上。早知道先做主数据，能省一半时间。

苏敏之　2024-05-18 11:47

想请教一下，业务部门不愿意配合定编码规则，总说“你们技术部门定就行”，这种情况怎么破？我们卡在这儿快两个月了。

郑鹏程　2024-05-18 14:03

指标口径那段很实在。我们上了个问答工具，业务问了两次说数据不对，就再没人用了。后来查出来是同一个指标两套算法，白折腾。

何雪梅　2024-05-19 08:35

制造业那个案例跟我们情况很像，四个系统四份客户档案。想问下你们当时是先做了几个数据域，用了多久见到效果？

罗建国　2024-05-19 16:20

“把验收标准从接了多少接口改成主数据唯一率”这句我要抄走了。我们甲方考核确实一直盯接口数量，导致乙方拼命堆接口，最后没人管数据质量。