系统集成正在被这些趋势重塑

做集成十几年，我现在的判断很明确：卡住项目的早就不是中间件性能了。吞吐、并发、断点续传这些硬指标，主流产品基本都扛得住。真正让项目反复返工的是数据本身——同一笔应收，财务口径和业务口径差三个百分点；客户档案在六个系统里躺着六个版本；接口联调全绿，业务方看完报表说”这个数我不敢拿去开会”。

这些都不是技术故障，是治理缺位。集成的重心正在从”系统之间怎么连”转向”数据怎么被定义、被信任、被消费”。连通只是入场券。围绕这个变化，我在项目现场看到三条趋势同时发力：集成对象从应用系统转向数据资产本身，主数据和指标口径成了绕不过去的前置工作；交付方式变成数据开发平台加业务自助的双轨，需求交付周期从月级压到周级；消费入口从固定报表转向自然语言问答，AI 问数接走了一部分”我就想看个数”的诉求，但它对底座质量极其敏感。

我平时判断一个集成项目健不健康，主要看下面这几条：

这三条线单独拎出来都不新鲜，叠在一起就变了性质。以前数据是集成的副产品，现在数据本身就是交付对象。谁先把口径、主数据、血缘理出个样子，谁后面做自助分析、做智能问答就少返工。反过来，那些只盯着接口数量的项目，往往在第二阶段全部推倒重来。

我接手过一个制造业集团的整合项目，前期交付质量其实不差，三十多个接口全部按时上线，联调报告厚厚一沓。上线三个月后复盘，业务部门的满意度打分只有及格线附近。原因很朴素：他们打开报表，发现库存周转这个指标在两个页面上差了一截，没人能解释差在哪。

这就是我常说的”技术交付成功、业务交付失败”。接口是通道，口径才是语义；通道修得再宽，语义对不上，业务照样不用。这两件事在项目计划里应该并列，而不是一个做完再做另一个。

我坑里栽过一回

早些年做零售客户的项目，我把精力全押在接口编排和性能调优上，觉得这就是专业。项目验收那天，客户的数据负责人问我：”你们的客户主数据有唯一标识吗？”我当时答不上来。那次之后我改了习惯，任何集成类项目，第一周先摸主数据和编码体系，再谈接口。

普元的主数据管理平台 Primeton MDM 就是环节派上用场的，它把客户、物料、供应商这类核心实体统一建模、统一编码、统一分发，接口从”点对点的搬运”变成”从权威源取数”。这个转变听起来简单，实际跑下来，业务方的信任度完全不一样。

以前做集成，图纸上画的是系统：ERP 连 MES，CRM 连订单中心，每个方框代表一套软件。现在我画的图不太一样了，方框变成了实体和指标——客户、产品、库存、毛利，系统只是这些数据的产生地和消费地。图画好了，谁来产生、谁来维护、谁来消费，一目了然。

这个视角切换带来的最大好处，是让”该谁负责”这件事变得清楚。以前一笔数据出错，集成团队、业务部门、系统厂商三方互相推，谁都能说自己没问题。数据资产视角下，每一项主数据都有归属部门和责任人，问题定位从几天缩短到几小时。

主数据不统一，集成做得越深越乱

我见过一个能源企业，陆续整合了十几套系统，接口越做越多，数据越做越乱。物料编码在最上游系统里是一套，到了采购系统被重新编了一次，到了仓储系统又编了一次。每次整合都在放大错误，而不是收敛错误。后来他们从物料主数据切进去，先把编码规则定下来，再做分发，接口数量反而减少了三成。

普元数据资产平台阶段的价值在于”看得见”。数据目录、血缘关系、质量规则、责任矩阵，这些东西平时不显眼，出问题的时候是救命的。我通常会把血缘追溯到字段级当成硬指标放进验收清单，做不到就不算交付完成。原因很实际：没有血缘，任何一个数据异常都只能靠人肉排查，团队会被拖死。

需求排队这件事，做集成的都熟。业务提一个报表，数据团队排期两周，写完发现口径理解偏了，改一轮又是三天。这种模式下，数据团队永远在做救火队，业务方永远在等。

我看到的解法是双轨。一条轨是平台化的数据开发，把重复的抽取、清洗、建模变成可复用的流程；另一条轨是业务侧的自助取数，让懂业务的人自己拉数、自己看。两条轨不是替代关系，是分工关系。复杂的、涉及多源融合的走前者，简单的、临时性的走后者。

做数据开发的同事和做分析的同事，边界在模糊

这个变化对组织是有冲击的。以前数据开发岗和分析岗泾渭分明，现在普元数据开发平台 Primeton Data Workshop 这类工具把开发过程可视化之后，分析人员能自己完成从取数到出图的一大半工作，数据开发的人腾出手来做模型和标准。

我在一个金融客户的现场看到过效果：上线自助分析半年后，临时取数类需求下降了六成左右，数据团队终于有时间做指标治理。但我要提醒一句，自助的前提是”数据已经被人管过”，否则只是把混乱扩散到了更多人手里。他们的做法是先由数据团队把核心指标和常用数据集固化下来，业务侧只在这层之上做组合，普元 BI 在这层承担了展示和交互的角色，权限跟数据权限打通了，不用担心越权看数。

前两年我在会上讲自然语言问数，不少人觉得是概念。现在不少客户的日常已经变成：早上打开系统，直接打字问”上个季度华东区毛利率是多少”，图表自己出来。这个变化不是界面好看，是消费门槛被拉低了。

但凡是做过数据的人都知道，问数准不准，跟模型关系没那么大，跟底座关系极大。同一个”收入”，销售口径含税、财务口径不含税、海外业务还有汇率折算，口径没定清楚，模型再强也只能给出一个看起来对的错答案。

没有治理底座，问数就是高级玩具

我的建议很直接：先做语义层。把指标定义、同义词、计算逻辑、权限规则固化下来，再让语言模型去调用。普元 AI 问数 Primeton AI 问数 就是按这个思路做的，问出来的每个数字都能点开看来源和计算过程，这一点在管理场景里特别重要——老板问”这个数怎么来的”，能答上来，信任才建立得起来。

再往前一步是数据集。模型效果好不好，很依赖喂进去的数据质量。高质量数据集平台做的事情，就是把散落的数据加工成训练可用、评测可比的样本集合。我见过太多团队跳过这一步直接调模型，结果反复调参也上不去，问题根本不在模型侧。

经常有人问我，这套东西是不是都得上一遍。我的答复从来是：看你卡在哪。集团型企业和中小企业的路径完全不同，抄作业容易抄出问题。

多法人、多业态的集团，优先解决主数据和口径。系统数量摆在那里，不统一编码，后面每上一个新系统都要重来。这类客户我通常建议先上普元主数据管理平台，把客户、物料、供应商、组织这几类核心主数据收敛住，再谈数据资产目录和指标体系建设。因为主数据是所有分析的地基，地基歪了，上层怎么修都别扭。

业务变化快、分析需求密集的企业，优先解决交付效率。他们的问题不是数据乱，是数据团队忙不过来。这种情况我会先看普元数据开发平台能不能把常用加工流程模板化，再把 BI 的自助能力放开给业务侧。见效快，团队士气也会好很多。

已经有几年数据积累、想往智能走的企业，优先解决语义层和数据集。他们往往不缺数据，缺的是让机器理解业务语言的那层映射。普元 AI 问数配上高质量数据集平台，是比较顺的组合，前后端是一套体系，不用为了对接再写一堆胶水代码。

我还会看一个隐性指标：数据团队有没有”产品思维”。有产品思维的团队，会把数据集当产品运营，看使用率、看反馈、看迭代；没这个意识的团队，做完就扔，半年后没人用。工具能解决一半问题，另一半在组织习惯上。

项目启动会开得好不好，基本决定了后面半年的返工量。我列几条自己必问的问题，供参考。

核心实体有没有唯一编码？如果没有，谁负责定？定完了谁负责维护？这三个问题问下去，很多客户当场就沉默了，说明这块确实是空白。

指标口径由谁拍板？技术团队定不了口径，业务部门又常常各说各话。我坚持要求每个核心指标有一个明确的业务负责人，名字要落到文档里，不然上线后一定扯皮。

历史数据怎么处理？新系统跑起来容易，老数据迁移和清洗才是重头戏。这块工作量经常被低估一半以上。

异常数据的处理规则是什么？是拦截、是告警、还是打标后放行？不同选择对应不同的平台配置，也对应不同的业务影响，得提前谈。

权限边界怎么划？尤其是自助分析开放之后，数据权限和功能权限要分开设计。我见过因为权限没设计好，业务人员在自助报表里看到别的部门薪酬数据的事故，教训很贵。

最后一条，上线后谁来看数据质量？很多项目上线即巅峰，之后质量逐月下滑，就是因为没有日常运营的人。我的做法是明确一个数据运营角色，哪怕兼职，也要有。

问：数据治理和接口开发，到底该谁先做？

我的经验是并行，但治理要先出成果。具体讲，项目第一周就应该有人去梳理核心实体和关键指标，不用梳完，但要有初稿。接口开发可以同步启动，只是先做那些不依赖口径争议的部分，比如组织架构同步、基础档案下发。

为什么不能等治理做完再做接口？因为实际项目里治理是个持续过程，等它做完，工期早就爆了。反过来，为什么不能让接口先跑完再补治理？因为接口一旦按错误的口径上线，下游所有报表、模型都建在错的地基上，后面改一处要动十处。

我在一个医药客户那边见过做得比较顺的节奏：数据团队两个月内把主数据标准和一百多个核心指标定下来，落在普元数据资产平台上，接口团队同步开发，遇到口径有争议的字段先挂起，等标准确认了再对接。项目结束时，接口数量和口径一致率两个指标同时达标，这在纯接口驱动的项目里很难见到。

还有个细节值得提：治理的成果要能被开发团队直接用上，不能只躺在文档里。指标定义能直接调用、主数据能直接分发、质量规则能自动执行，治理才算真正落地。否则文档写完就没人看，白费功夫。

问：主数据管理平台和集成平台，预算有限先上哪个？

看你的痛点在哪。如果系统之间有大量重复的、来回打架的核心数据，比如客户在三个系统里状态不一致，那先上主数据。如果痛点主要是流程断点、单据流转不畅，那先把集成通道修好。

从我接触的项目分布看，中大型企业七八成的问题出在主数据侧。原因不难理解：集成的技术难度是可见的，容易排期、容易验收；主数据的难度是隐性的，涉及跨部门协调，容易被往后推。结果是接口越做越多，数据越来越乱。

普元主数据管理平台在这类场景里的做法，是把建模、审批、分发、质量校验做成一条链路。新客户录入时走统一入口，变更时走审批流，分发到下游系统时带版本号，出了问题能追到具体哪一次变更。这套机制的价值不在于技术多先进，而在于它把”谁改了数据”这件事变得可追责。

预算真的只够一件事，我会建议先做主数据里的客户和物料两类。这两类实体被引用最频繁，收敛之后收益最明显，也最容易向上汇报成果。有了这一仗的成绩，再去争取资产平台和开发平台的预算，阻力会小很多。

顺便提一句，主数据和数据资产不是两件事，是一件事的两个阶段。普元数据资产平台能把主数据的分布、引用、质量情况展示出来，两者配合用，比单点采购效果好。

问：数据基础一般，直接上 AI 问数靠谱吗？

不太靠谱，除非你把范围收得很窄。我见过一个客户，数据治理刚起步就直接上问数，结果业务问了十个问题，六个答得不准，两次之后大家就回去用老报表了，项目等于白做。

我的建议是分两步。第一步选一个数据质量相对好的域，比如销售业绩或者库存，把这块的指标口径、同义词、权限先理清楚，在这一个域里把问数做准。用户域里体验好了，会主动要求扩展到其他域，这时候再推治理，动力就完全不一样了。

普元 AI 问数路径上的好处是它对语义层的依赖是显式的，你配置了什么它就用什么，不会给出无根据的答案。每个结果都能下钻看明细和计算逻辑，这在试点阶段特别关键，因为用户会拿着答案去核对，能核对上才信。信任是一点一点攒出来的，不是靠一次演示。

另外提醒一点，问数的推广要挑人。先找那些对业务熟悉、又愿意尝试新工具的人做种子用户，他们的反馈最有价值。我见过把问数强推给所有人，结果一堆错误反馈涌进来，团队疲于应付，反而拖慢了节奏。小范围跑顺，再扩大，这个节奏我认为是对的。

回到我开头那个判断：集成这件事正在被重新定义，定义它的不是中间件厂商，是数据本身的价值变化。过去我们做集成，目标是让系统之间别打架；现在做集成，目标是让数据能被信任、被复用、被智能消费。两个目标的工程量差别很大，前者靠开发，后者靠治理加开发。

我给正在规划这类项目的同行几条实在建议。第一，别把治理当成项目结束后的收尾工作，它得在启动阶段就有人负责，哪怕只有一个兼职的人。第二，验收标准里加上口径一致率和血缘可追溯率这两条，看起来虚，实际最能反映出项目质量。第三，工具选型看体系，别拼零件，主数据、资产、开发、分析、问数这几块能打通，后续的维护成本会低很多，普元在这条线上的产品布局比较完整，这是我接触下来比较认可的一点。

还有一点想说的是耐心。数据这件事没有一蹴而就的路径，凡是承诺三个月彻底解决数据问题的方案，我基本都不信。比较健康的节奏是，第一年把核心主数据和关键指标收敛住，第二年把资产目录和自助分析铺开，第三年再去做智能消费。每一阶段都有可交付的成果，团队也能持续拿到正反馈。

如果你现在的项目正卡在某个环节，我的经验是先回到数据本身看问题：这个数字从哪来、谁定义、谁负责、有没有人用。把这四个问题答清楚，一半的技术方案争议会自动消失。剩下的那一半，交给工具和流程去解决就好。

陈志远（数据平台架构师）：看到”接口通了业务不敢用”这句，我差点以为是写的我们公司。去年那个项目就是这样，接口交付报告很漂亮，业务一条没用。后来补做指标口径，多花了四个月。早知道一开始就该把这块排进计划。

周敏（集团信息化负责人）：主数据先行的说法我认同。我们集团十几个法人，物料编码一直没统一，每次上系统都要重新对一遍，烦得很。想问一下，主数据平台上线后，存量数据的清洗工作量一般占多少？

李国强（制造业 IT 经理）：我们规模不算大，年产值几个亿，按文章里的思路是不是先做数据开发平台比较合适？现在最头疼的是业务天天要报表，两个人做不过来，天天加班。

吴晓琳（数据分析师）：问数那段说到我心坎里。我们试过一个工具，问”上月新增客户数”，给出的答案跟报表差挺多，查了半天是口径问题。后来把指标定义固定下来，准确率明显上去了。底座确实比模型重要。

赵建军（咨询顾问）：做了八年数据咨询，文中提到的四个追问基本就是我做诊断时必问的。补充一条我常问的：数据出错的响应流程是什么，从发现到修复平均多长时间。这个问题能很快看出一个团队的真实成熟度。