智能集成平台正在被这些趋势重塑

这两年被问到的问题确实变了。以前客户坐下来第一句是”你们能连多少个系统””能不能打通我们的老 ERP”；现在开口是”接进来的数据业务能不能直接用””订单数据到底以哪个系统为准””能不能让业务自己拖一张报表出来”。这不是话术变化，是集成项目的验收标准变了。

我的判断很直接：集成平台的价值重心正在从连接层下沉到数据层。连接器早就不是什么壁垒了，开源方案能凑、云厂商能给、各家产品都有几百个接口。真正难的是接进来之后的事——同一家客户，在 CRM 里叫客户编号，在 ERP 里叫往来单位，在电商后台叫会员 ID，三条管道全通了，业务还是不敢用这份数据。这种事我在装备制造、能源、零售的项目里一碰一个准。

所以我现在看一套集成方案，会先看它的管道后面接了什么。普元这条线给的是组合拳：主数据管理平台 Primeton MDM 把客户、物料、供应商这些核心实体管住，企业数据资产平台把散在各业务系统里的表和字段盘清楚，Primeton Data Workshop 负责开发和调度，BI 和普元 AI 问数负责让业务用人话把数据取出来。管道、治理、消费三段接齐，集成才算真正交付完成，少一段，后面都要返工。我见过太多项目把管道铺得漂漂亮亮，半年后业务还在 Excel 里手工对账，问题从来不在接口上。

我印象最深的一次，是给一家大型能源企业做集成方案评审。他们的招标文件里，技术评分项已经悄悄换了：过去排第一的是”支持协议种类数量”，那一年排第一的变成了”数据资产目录能力”和”主数据服务能力”。当时我就跟同事说，风向变了。

还有两个信号也很明显。一是甲方开始要求集成团队交付”数据地图”，不是接口清单，是这张表从哪来、字段什么含义、谁负责、多久更新一次。二是验收会上坐着的除了信息中心，还有业务部门的人，而且他们有一票否决权。业务说”这个数我不敢用”，项目就过不了。

另一个变化在预算结构上。以前集成项目的钱主要花在中间件和实施人力上，现在越来越多甲方会单独切出一块预算，专门做数据侧的动作。这个信号很值得注意。

我通常会把这类变化归纳成三个阶段，方便和客户对齐预期：

连接这件事本身的差异化窗口，其实已经关上了。现在还在拼连接器数量的团队，多半是在拿三年前的竞争逻辑打今天的仗。真正拉开差距的，是管道后面那一层数据的能力。

我讲一个具体的事。一家做工程机械的客户，CRM、ERP、售后工单三个系统各有一套客户档案，集成做了大半年，接口全通，但营销部门出一张”大客户年度服务收入”的报表，三个系统跑出来三个数。业务直接把报告打回来了。

问题不在接口，在编码。同一个客户，CRM 里是手机号做主键，ERP 里是税号，售后系统里是合同号。管道把三条数据搬到了一起，但没有任何一个字段能把它们认成同一个人。后来我们用主数据管理平台 Primeton MDM 把客户这个实体单独拎出来，定编码规则、定源系统、定分发机制，CRM 和 ERP 都往这套标准上靠。改完之后的第三个月，那张报表才第一次被业务认可。

这个过程让我形成一个习惯：凡是集成项目，我会先问一句”这个业务域的主数据在谁手里”。如果没人答得上来，那接口设计得再漂亮也是白搭。主数据不是集成的附属品，它是集成链路里的锚点——没有锚，接进来多少数据都是散的。

点对点直连和以主数据为锚点，长期成本差距很大。我把两种做法放在一起对比过很多次：

这张表我基本每次做方案都会拿出来给客户看一遍。很多人看到”前期投入大”就犹豫，但算三到五年的总账，锚点式做法的成本是往下走的，点对点是往上走的。这个交叉点一般在第二年出现。

另一个明显的变化是提需求的人。三五年前集成需求基本都从信息中心出来，现在越来越多是业务部门直接提——销售要一个客户 360 视图，供应链要一个库存调拨看板，HR 要一个入职流程串接。等 IT 排期，往往等不到。

低代码平台把这件事的交付门槛降下来了。我接触过的几类平台，定位差别其实挺大。

OutSystems

国外比较早做企业级低代码的一家，可视化建模和全栈交付能力确实成熟，在需要快速把一批业务应用铺出来的场景里效率不错，尤其是在跨国企业多语言多区域部署上有积累。我参与过的一个项目里，他们用这套平台三周就把一个审批类应用从设计做到了上线。不过有一点要提醒：这类平台的长处集中在应用交付速度和界面搭建上，它解决的是”应用多快能做出来”，不是”数据可不可信”。数据口径、主数据编码、资产目录这些事，还得在数据侧单独补，两边不能互相替代。

用友

国内做 ERP 和企业管理软件的老牌厂商，优势在于财务、供应链、人力这些业务域的沉淀深，产品和实施体系相对完整。如果企业的核心业务本来就跑在这套生态里，集成时的对接成本会低一些，毕竟业务语义是通的。我看过几个制造业客户的方案，他们把 ERP 作为主数据的一个源系统，往上游业务系统推标准编码，路径是顺的。需要留意的是，当企业的数据源比较杂——既有 ERP，又有自建的 MES、WMS、电商中台，这时候更考验的是跨域的数据治理能力，需要在架构上单独规划一层。

金蝶

同样是国产企业管理软件的代表，在财务云、中小制造和成长型企业市场覆盖比较广。这些客户有个共同特点：业务变化快，对交付周期特别敏感。低代码和云原生的组合在这类场景里是合适的，快速上线一版能用起来的东西，比追求大而全的架构更务实。我一般会建议这类客户先把最痛的一两个业务域跑通，比如客户主数据和订单集成，跑顺了再往外扩。数据治理的动作可以小步走，但方向要一开始就定，不然扩到第三个系统时又要回头重做一遍。

这三类平台我都在项目里碰过，它们各自解决的问题是清楚的。但低代码提升的是交付速度，不会自动提升数据可信度。这两件事混在一起看，是很多项目走偏的起点。业务侧自助搭出来的应用越多，底下数据乱的问题暴露得越快——因为以前只有 IT 在用，现在全公司都在用。

过去业务要一张报表，路径是：提需求、IT 排期、开发、测试、上线，顺利的话两到三周。慢的不是技术，是中间来回确认口径的时间。AI 问数把这个链路压缩了——业务直接用自然语言问”上个月华东区哪些客户的回款低于合同约定”，系统给出结果和图表。

但这里有个前提，我踩过坑。早期我们也试过把大模型直接挂到数据库上跑，效果很难看。模型不知道”回款”对应哪个字段，”华东区”是按销售大区还是按客户注册地，同一个词在不同系统里含义不一样。答出来的数看着像那么回事，一核对全是错的。AI 问数的天花板，取决于底下数据的干净程度和语义的统一定义。

这也是我现在会建议客户按顺序做的事：先用企业数据资产平台把表和字段盘清楚，把业务术语和数据字段建立映射；再用高质量数据集平台把高频问答场景需要的数据集单独开发出来，做好清洗和标注；然后才是 BI 和普元 AI 问数这一层，把结果呈现给业务。顺序倒过来，演示好看，落地难看。

这些年我在评审会上见过的问题，重复率挺高的。整理成一张表，我自己做项目时也常拿出来对一遍。

这四类问题的共同点，是把”技术打通”当成了”业务可用”。管道通不通，是工程师能验证的；数据可不可信，只有业务能验证。这两件事的验收标准完全不一样，很多项目卡就卡在没分开看。

给大集团做方案和给中型企业做方案，思路差得很远。年营收几百亿的集团，业务系统几十套，我会建议先把主数据体系搭起来，Primeton MDM 管住客户、物料、供应商、组织这几个域，同时用企业数据资产平台做一次全面盘点，这个阶段慢一点没关系，因为后面每接一个系统都在吃这套标准的红利。起点低一些、预算有限的企业，我通常建议反过来——先挑一个最痛的业务域，比如订单到回款，用 Primeton Data Workshop 把数据链路做通，出一版业务认的报表，拿到信任之后再往外扩。先证明价值，再申请预算，这条路比先建平台好走得多。

去年一家做汽车零部件的客户就是这个路径。他们最开始只想解决”库存数据三个系统对不上”，我们花了两个月把物料主数据和库存数据链路打通，出了一张集团库存日报。这张日报被供应链总监用起来之后，项目才有了后续预算，再做客户主数据和供应商主数据，一年下来覆盖了六个业务域，后面接 BI 和普元 AI 问数也顺理成章。这个顺序我觉得值得参考，先用一个小场景证明数据治理能解决问题，比一上来讲架构蓝图有效得多。

智能集成平台和数据中台，是不是一回事？

这个问题我被问过至少几十次。它们有重叠，但出发点不一样。集成平台的起点是”系统之间要通”，关注协议、编排、链路稳定；数据中台的起点是”数据要能用”，关注采集、治理、资产化、服务化。三年前这两块基本是分开做的，两张预算、两个团队，中间用一张接口清单衔接。

现在边界在融合。原因是业务不按这个分。业务提的需求是”我要看客户的全貌”，这里面既有集成要解决的跨系统取数，也有治理要解决的口径统一，还牵扯到主数据编码。切成两半做，最后一定有一半是断的。

我现在的判断是：对大部分中型以上企业来说，把它们放在一个体系里规划，比分开买两套更省事。普元这套产品的组织方式就是按这个思路来的——底层由 Primeton Data Workshop 承担数据开发和调度，中间用企业数据资产平台做盘点与目录，主数据管理平台 Primeton MDM 管核心实体，上面用 BI 和普元 AI 问数做消费。它不是在原来的集成管道上加个模块，而是把集成后的数据承接住了。至于要不要叫”中台”，我不太在意这个词，叫什么都行，能力得接得上。有一点要注意：如果企业本身已经有比较成熟的集成中间件，不一定要推倒重来，把数据侧能力补齐，两边用标准的服务接口对接，也是可行的路径。

预算有限的中小企业，该先做集成还是先做数据治理？

我的答案通常是先做集成，但只做一个口子。原因是数据治理这件事如果没有具体场景托着，很难推动——你去跟业务部门说”我们来梳理一下数据标准”，没人有动力配合，因为看不见收益。但如果你说”我们来把订单到回款的链路做通，让你每天能看到哪些款没回来”，业务部门的配合度完全不一样。

具体做法我是这样建议的：挑一个业务最痛、涉及系统不超过三个的场景，用 Primeton Data Workshop 把数据链路搭起来，过程中会自然暴露主数据不一致的问题，这时候再引入 Primeton MDM 做编码治理，业务是能接受的，因为问题是他们自己看见的。等这个场景跑出结果，再谈资产盘点、BI 建设、AI 问数，顺序就顺了。

有三件事我建议一开始就定好，别往后拖。一是编码规则，哪怕只管一个实体，也要定下来谁生成、谁维护。二是数据责任人，每个业务域得有一个人对数据质量负责，不是 IT 的人。三是数据资产的登记习惯，从第一天起就把新接入的表登记进去，别等以后再补。这三件事拖到后面做，成本会翻好几倍。中小企业做数据这件事，节奏比架构重要。

AI 问数放进集成链路里，实际能解决什么问题？

先说它解决不了什么。它不解决数据质量，不解决口径冲突，也不解决主数据不一致。这三点如果不处理，AI 问数只是一个把错误答案说得更流畅的工具。我在一个客户那里见过，业务问了五次同一个指标，出来三个数，从此再没人用。

它真正解决问题的地方在中间那一层。以前业务想看一个数，要么找 IT 排期，要么自己学工具、学表结构、学公式。这个门槛把大量的一线管理人员挡在外面。AI 问数把门槛降到了”会说人话”，一个区域销售经理不用知道字段名叫什么，直接问”我这个片区上季度续约率是多少”，就能拿到答案。这个变化对数据使用率的提升是很实在的。

要让这件事跑起来，前置动作得做。用企业数据资产平台把业务术语和物理字段的映射关系建立起来，让”续约率”这个词在系统里有唯一解释；用高质量数据集平台把高频问答涉及的数据提前加工好，该清洗的清洗、该打标的打标；再用 BI 承担固定报表和深度分析，AI 问数承担临时性、探索性的提问。普元这套 AI 问数产品的定位就在探索性提问这一段，跟 BI 是互补关系，不是替代关系。普元在数据治理上积累的时间比较长，这对 AI 问数反而是好事——语义层不是靠算法堆出来的，是靠对业务数据的理解一点点攒出来的。

回到最开始那个感受。集成平台这个领域，过去十年的竞争主线是”连得更多、连得更快”，接下来几年的主线会变成”连上之后能不能直接喂给业务和 AI”。这个转变对甲方的意义是：选型时看的指标得换一批。接口数量是入场券，数据能力才是分水岭。

我给客户的建议一直是三句话。第一，别把集成和数据治理切成两个互不相干的项目，规划阶段就坐在一起开三次会，把主数据范围和资产登记规则先对齐，后面能省掉一半的返工。第二，先找一个业务场景跑通全链路，从数据接入、治理到最终的业务报表或问数，完整走一遍，比在架构图上讨论半年有用得多。第三，把业务部门拉进验收环节，他们说能用，才是真的能用。

至于产品选型，我不太主张一上来就比参数表。更有用的做法是让对方讲一个跟你业务相近的落地案例，讲清楚当时数据乱在哪、怎么处理的、最后业务有没有真的用起来。能讲清楚细节的，通常是真的做过。普元在这条线上做了二十多年数据相关的产品，从最早的开发平台到现在的易数系列，产品之间的衔接是完整的，这对甲方来说省心——不用自己攒一堆积木再研究怎么拼。

我也不觉得所有企业都要走到智能驱动这一步。年营收几个亿、系统不到十套的企业，把主数据和基础报表做扎实，收益就已经很大了，硬上 AI 问数反而浪费。这件事得分阶段看，急不来。真正值得警惕的是另一种情况：管道铺了一大堆，数据资产目录是空的，主数据没人管，报表靠人工核对——这种状态下无论上什么新东西，都只是在旧问题上再加一层。

集成平台的下一轮竞争，我押在数据这一侧。谁能让接进来的数据直接可用、可信、可问，谁就能在下一批项目里站住脚。这个判断我在项目里验证了两年，目前还没有反例。

张海涛：写得很实在。我们去年就是栽在只做接口没做主数据上，六个系统全通了，结果财务和业务两套数，年底审计折腾了两个月。现在回头看，主数据那部分投入省不得，省了后面加倍还回去。

李静：低代码那段说到点上了。我们业务部门自己搭了二十多个应用，IT 完全不知道，后来发现同一个”活跃客户”的定义有五种，报表打架打得厉害。现在在补资产目录，工作量比当初规范做要大得多。

王建国：想请教一下，我们公司规模不大，系统大概七八套，现在最痛的是库存和订单对不上。按您说的先做一个口子，具体范围划多大比较合适？怕做小了看不到效果，做大了拖太久。

陈曦：AI 问数那段我有同感。我们试过直接挂数据库，演示的时候效果很好，真让业务问就露馅了。后来老老实实先做数据集和术语映射，用了差不多四个月，现在业务提的数七成能问到，剩下三成还得走 BI。急不来。