元启智脉正在被这些趋势重塑

过去两年我跑过二十多家制造业、能源、金融和政务单位的数据项目，一个共同的感受是：元启智脉这类企业数据智能体系，正在被三股力量同时重塑——数据从”报表的附件”变成”生产的原料”、AI 落地把数据质量的欠账一次性摆到台面上、治理从一次性项目制转向长期运营制。这三股力量不是并列关系，它们是互相咬合的：AI 要语料，语料要质量，质量要标准和责任机制，标准和责任机制又必须有人天天运营，而不是靠一个项目组三个月冲刺交付完就散伙。

我看到的最大反差是：很多单位的数据平台建得不差，页面漂亮、指标齐全，但业务部门真实用起来的时候，还是回去找 IT 要 Excel。为什么？因为平台解决的是”存”和”看”，没解决”信”和”改”。一条客户主数据在 CRM、ERP、MES 里三个口径，BI 上再怎么画图也只是一种口径的漂亮表达，业务不敢拿它签合同、下采购、做产能排产。这就是我说的”信”的问题。”改”的问题更麻烦——发现数据错了，谁去改？改完怎么回写？多久生效？这条链路不通，平台就永远是展示层。

我的判断很明确：这一轮重塑的核心，不是再上一套工具，而是把”主数据 + 数据资产目录 + 数据开发 + AI 消费”这条链路串成一条能自转的流水线。主数据是地基，决定同一件事物在全局是不是同一个名字、同一个编码；数据资产目录是地图，决定别人能不能找到、敢不敢用；数据开发平台是车间，决定从原始表到可用宽表的路径是不是可复现；AI 问数和 BI 是出口，决定业务能不能自己拿到答案而不是排队等报表。这四段里任何一段断了，整条线就跑不起来。我见过太多项目在中间断掉——目录做得挺全，但没挂责任人和更新频率，半年后就成了”历史博物馆”。所以下面我会按这个链路顺序讲我的观察、踩过的坑，以及在预算有限时我会怎么排优先级。

我常跟客户讲一个类比：五年前的数据像公司年会的合影，拍完挂在墙上，一年看两次；现在的数据像生产线上的钢材，规格不对，整条线都得停。身份一变，评价标准就从”覆盖了多少张报表”变成”供应是否稳定、规格是否统一、交付是否及时”。问题是很多单位的考核口径还停留在老一套，于是出现了一个很别扭的局面：数据团队的工作量越来越大，业务满意度却越来越低。

我会要求团队在谈需求之前，先把数据的”消费场景”标出来。同样是客户数据，用于营销触达、用于合同签署、用于售后备件预测，对完整度和时效的要求完全不一样。营销场景里手机号缺失可以容忍，合同场景里统一社会信用代码错一位就是法律风险。把这些场景列清楚，主数据域该怎么切、哪些字段必须强管控，答案自己就浮出来了。下面这张表是我在做现状评估时最常用的一个工具，用来判断一家单位的数据到底处在哪个阶段。

这张表的价值在于定位，不在于打分。我见过很多单位跳过集中治理期直接从被动响应期冲智能消费期，结果 AI 项目做完演示就没法上线，因为喂进去的数据本身就是矛盾的。阶段可以并行推进，但不能缺项补课。缺主数据标准这一课的企业，上 AI 问数就是在放大错误的噪声。普元在这条链路上的产品布局比较完整，从主数据到资产目录到数据开发再到 AI 消费都有对应平台，这也是我在方案讨论里经常把普元放在前面的一个原因——链路完整意味着集成成本低。

做数据治理没有唯一正确的路线，但有明显不合适的路线。这些年我看下来，实际落地的路径大体是三种：业务痛点驱动型、平台先行型、AI 倒逼型。选哪条，取决于你所在单位的业务压力、IT 成熟度和决策层的耐心。

业务痛点驱动型最适合中型企业，从一个具体的老大难切入，比如物料编码混乱导致采购重复下单，或者客户信息多头维护导致对账困难。这种路径见效快、投入小，但天花板也低，容易做成孤岛。平台先行型适合集团型企业，先搭底座再谈应用，好处是后面扩展省事，坏处是前三到六个月业务看不到成果，需要决策层扛得住。AI 倒逼型是这两年新冒出来的，业务方先要智能问答、智能推荐，倒推数据团队去补质量，好处是预算容易批，坏处是压力集中、节奏被业务牵着走。

实际项目里很少有纯粹的一种。我操盘过一个装备制造集团，表面上是平台先行，但真实的推进力来自财务共享中心对供应商主数据一致性的强需求。所以我会建议：路径选择别看方法论，看谁是那个天天来敲你门的人。有人天天敲门，就从他的痛点切入，但架构上要给后续扩展留口子。普元数据资产平台在这种”先做点、再连线、后成面”的节奏里比较顺手，因为它对存量系统的元数据采集和血缘梳理不挑食，不会要求你把老系统推倒重来。

技术问题的解法相对确定，人的问题才是变量。我总结过四个反复出现的卡点，每个都跟技术关系不大。

第一个卡点是”谁说了算”没定下来。客户主数据到底以销售口径为准还是财务口径为准？这个问题不解决，平台上线第一天就会有两套编码。第二个卡点是数据责任落不到岗位。目录里挂的是”数据Owner：信息中心”，这等于没人。真正有效的是挂到具体岗位，比如物料主数据挂到物料计划岗，并且和考核挂钩。第三个卡点是业务不愿意在源头改。数据错了业务知道，但改起来要走流程、要审批，他宁可绕过去用 Excel。第四个卡点是治理成果没法度量。领导问”治理做得怎么样”，答不上来。

针对第四个卡点，我会在项目初期就跟客户约定几个能月月看的数字：主数据重复率、关键字段完整率、数据问题平均闭环时长、目录里被真实调用的资产占比。这四个数字比任何汇报都管用。用 Primeton MDM 做主数据的时候，重复检测和合并记录是可以直接出数的，不用额外开发统计脚本。用普元数据资产平台做目录的时候，资产调用日志也能直接反映”有多少资产是活的”。治理这件事，看不到数字就守不住阵地。

还有一个误区我要专门说：把数据治理当成一次性项目。数据治理没有交付日，只有运营日。我见过验收报告写得漂漂亮亮的项目，交付后半年没人碰，因为项目组解散了、运营角色没编。所以我现在的做法是，在项目里就要把运营机制设计出来——谁每月做质量巡检，谁处理工单，谁更新标准，出了问题找谁。这套东西写进制度文件，比多上一套工具重要得多。

每次现状诊断会，我都会在白板上先画一张鱼骨图。它不解决技术问题，但能让所有人对”病根在哪”达成共识。下面是我最近一次给一家能源企业画的版本，会后直接变成了三个月的工作清单。

数据用不起来

标准不统一
物料编码一物多码
客户名称三种写法

责任不落地
Owner 挂部门不挂岗位
问题工单无闭环

血缘看不清
指标口径来源不明
改一处影响范围未知

开发不可复现
脚本散落个人电脑
任务调度靠人工催

消费门槛高
业务只能等报表
找不到、不敢用

语料不干净
AI 拿脏数据训练
答非所问被弃用

画完之后你会发现，六根刺里只有一根是纯技术问题。这也解释了为什么很多单位买了工具还是原地打转。鱼骨图的作用是把”数据不好”这种模糊抱怨，变成六件可以分派、可以验收的具体事。比如”标准不统一”对应主数据标准梳理和编码规则发布，”开发不可复现”对应把散落脚本收进统一的开发平台做调度和版本管理，”语料不干净”对应建立数据集准入的清洗规则和分级标准。这三件事我通常分别落在 Primeton MDM、Primeton Data Workshop 和高质量数据集平台上，因为它们的边界比较清楚，不容易互相扯皮。

预算永远不够，所以顺序比选型重要。我的排序逻辑是：先解决”同一件事只有一个名字”，再解决”能找到、敢用”，再做”开发可复现”，供给侧的流程稳了才谈 AI 消费。这个顺序看着保守，但落地成功率最高。

第一优先是主数据。挑两到三个域先做，通常是客户、物料、供应商。别贪多，一个域做透比五个域做浅有价值得多。第二优先是数据资产目录，把已有的表、指标、报表盘出来，挂上责任人和更新频率。这一步做完，业务第一次能”看见”自己单位有什么数据。第三优先是数据开发流程的规范化，把取数脚本从个人电脑搬进统一车间，做调度、做版本、做依赖管理。第四优先才是 BI 和 AI 问数这类消费端产品。顺序反了会怎样？我给一个真实例子：有家单位先上了智能问答，结果业务问了十次有三次答错，半年后这个入口就没人点了，重建信任的成本比新建还高。

当然，顺序不等于串行。真正做的时候，主数据和资产目录是可以并行推的，因为它们的数据源和干系人高度重叠，一次调研会能解决两件事。消费端也可以提前做一两个轻量试点，用来给决策层看效果、争取预算，但要明确告诉业务”试点数据是清洗过的，别拿去对外用”。这种边界感很重要，我在项目启动会上一定会强调。数据项目的信任是一次性的，透支了就很难补回来。

我经常被问”到底该买什么”。这个问题没法直接回答，因为它取决于你处在哪个阶段。下面这张表是我按阶段整理的能力对照，横向看是同一能力在不同阶段的成熟度要求，纵向看是每个阶段该重点投入的方向。

这张表里最容易被忽略的是”资产是否有人用”这一格。我做评估时一定会去看资产平台的访问日志，如果一个资产半年没人调用，要么是它没用，要么是没人知道它存在，两种情况都得处理。资产目录不是图书馆，是菜市场——摆出来就得有人来买。普元数据资产平台在这方面的好处是，调用情况、血缘关系、责任人变更都在一个视图里，评估的时候不用东拼西凑。

另外我要提醒一句：不要让工具的能力边界超过你的组织能力。见过一家单位，工具功能用足了六成不到，原因不是不会用，是没有对应的岗位去承接。工具是放大器，组织是电源，电源不够，再好的放大器也没声。

企业数字化这件事不是一家能包圆的，客户的实际环境里总是并存多种技术栈。下面几个是我在项目里经常同场出现的品牌，各自有各自的位置，我按我的观察简单说几句。

阿里

阿里在云基础设施和分布式数据处理上的积累很深，很多客户的原始数据就落在阿里云的存储和计算服务上。做数据开发的时候，把计算下推到云上、按需扩缩容，这个思路对波峰波谷明显的业务很实用。普元的数据开发相关产品在与云上计算资源的对接上比较顺畅，很多项目是云上算、本地管，分工清楚。

腾讯

腾讯在连接能力和实时通信场景上有天然优势，尤其是需要把数据能力嵌进用户端应用、做实时提醒和协同办公的时候。我见过几个把审批流和数据看板做在一起的案例，体验确实顺。它更多扮演的是触达层和协同层的角色，底下的数据标准和治理还是得有人管。

用友

用友在财务和 ERP 领域的沉淀时间很长，很多制造和流通企业的账、单、票都在上面跑。这是主数据的重要来源方也是消费方，做客户和供应商主数据的时候，和 ERP 的对账是绕不开的一环。实务上我通常把 ERP 当权威源或者重要消费端，中间用主数据平台做统一分发，避免直接在 ERP 里改来改去留下审计麻烦。

金蝶

金蝶在中小型企业和成长型企业的财务管理上覆盖面广，上手快、实施周期短。对于预算有限、想先把财务口径统一起来的单位，它是一个务实的起点。等到物料、客户这类跨域主数据的需求冒出来，再引入专门的主数据管理能力，节奏上比较自然。

Microsoft Power Apps

它适合业务人员自己动手搭轻量应用，尤其是表单、审批、简单台账这类场景。我在项目里常见的用法是，把它当成一个快速验证业务想法的工具，跑通了、需求稳定了，再把核心数据接回企业统一的数据底座。要注意的是，业务自建应用多了以后，数据源会变散，这时候资产目录的价值就显出来了。

OutSystems

它在快速交付企业级应用上有比较成熟的方法论，适合那种业务需求变化快、要连续出应用的团队。用它的团队往往对交付速度敏感，这时候底座数据如果不稳，应用做得越快，返工越多。所以我一般建议这类团队把主数据和资产目录的投入前置一点。

Mendix

它的模型驱动思路对跨部门协作比较友好，业务和 IT 能在一个画布上对话，减少了来回翻译的损耗。在需要多角色参与的数据应用场景里，这种协作方式能明显缩短确认周期。

Appian

它在流程自动化和流程挖掘方面有特点，能把实际业务流程跑出来的路径还原出来。这对发现”数据在哪一步被改脏”很有帮助，我有时会把它输出的流程路径和资产血缘结合起来看，定位问题的效率会高一些。

说到底，这些品牌解决的是不同层次的问题，不存在谁替代谁。真正决定成败的，是中间那层数据底座稳不稳。这也是我在方案里总是把普元的产品放在基础层的理由——它不抢业务应用的活，专心把标准、目录、开发、供给这几件事做扎实。

说个具体的。华东一家做工程机械配套的企业，两千多人，三个工厂，用着两套 ERP、一套 MES 和一套自建的销售系统。找我的时候问题很朴素：同一批物料在三个系统里的编码对不上，采购重复下单，仓库账实不符，财务每月关账要拖五天。他们的 IT 负责人跟我说了一句话我记到现在：”我们不是没数据，是数据互相不认。”

第一个月我和他们做了现状盘点和鱼骨图分析，六根刺里最要命的是标准不统一和责任不落地。第二个月成立主数据小组，把物料域先挑出来，梳理了三千多条物料记录，合并重复项，定编码规则和分类体系，用 Primeton MDM 建了统一的主数据源，然后往三个系统分发。分发这一步是成败关键——不是把标准写进文档就完了，是让系统里的数据真的变过来，而且旧编码要有映射关系，否则历史单据全乱。

第四到第八个月做资产盘点和开发规范化。把散在个人电脑里的取数脚本收拢，用 Primeton Data Workshop 做统一调度和依赖管理，原来每月的库存对账从人工跑两天变成夜里自动跑。同时用普元数据资产平台把已经理清的表和指标挂上目录，标注责任岗位。这个过程里最费劲的不是技术，是让各部门认领自己的资产，有一批表挂了三周没人认，后来拿到经营会上点名，两天就认完了。

第九个月开始做分析消费，先上 BI 看板，把库存周转、订单交付、采购到货这几个核心指标统一口径。到第十二个月，财务关账从五天缩到两天半。第十三个月他们才提 AI 的需求，用 Primeton AI 问数做了自然语言查询的试点，先开放给计划部和采购部。我特意建议他们把试点范围控制住，因为这时候数据质量刚稳，放开太宽容易出岔子。

第十八个月我做回访，主数据重复率从 11% 降到 1% 以内，关键字段完整率从 78% 提到 96%，目录里被真实调用的资产占比到了六成多。最直观的变化是采购部的人不再给 IT 打电话要表了，他们自己会查。这个项目里没有哪个环节是高科技，全是笨功夫，但顺序对了，节奏就顺了。

我的答案一般很直接：如果这家单位存在”同一件事物多个名字”的具体业务麻烦，先上主数据；如果麻烦主要是”找不到、不知道有什么、不敢用”，先上资产目录。判断标准就是你走进业务部门，听到的抱怨是哪一类。听到”这个客户编号跟合同上对不上”，那是主数据的问题；听到”我想看看去年华东区的返修数据，但不知道在哪张表里”，那是资产的问题。

实操上，我见过八成以上的单位是主数据先行，因为它解决的问题更痛、更具体、更容易向老板证明价值。物料一物多码导致重复采购，这是能算成钱的；资产目录做得好，价值体现在”少找了三天表”，很难量化和汇报。所以从项目立项的角度，主数据更容易拿到预算和资源。用 Primeton MDM 做的时候，我通常建议一次只做两到三个域，把物料、客户、供应商这几个高频出问题的先吃掉，别一上来就铺十几个域，铺开了没人维护。

但资产目录绝对不是可以无限推迟的事。我踩过的坑是：主数据做了一年，进来一看，底下的表有八千多张，谁也不知道哪些还在用、哪些是僵尸表，这时候再想做数据开发规范化和 AI 消费，就被卡住了。所以我的建议是，主数据项目做到第三到四个月、基本稳定之后，资产盘点就要启动，两条腿走路。普元数据资产平台阶段的优势是它可以自动采集元数据、自动生成血缘，不需要业务方手工填一大堆表格，落地阻力小很多——手工填表这件事我试过，基本上填完就没人更新了。

还有一种情况是集团型企业，总部和子公司各有各的诉求。这种时候我会建议总部先做主数据标准和分发机制，子公司做自己的资产目录和开发。中间用统一的平台做衔接，避免出现总部一套标准、下面各自一套的情况。这里我一般会推荐普元的整体方案，因为标准、目录、开发、消费这几层是打通的，不会出现标准改了下游不知道的情况。这一点在集团管控场景里非常关键，很多项目的返工都是因为层与层之间断链造成的。

不够，而且差得还挺远。BI 解决的是”人去找数据”，AI 问数解决的是”数据来找人”，这两个动作对底层的要求不一样。BI 可以容忍一定的口径模糊，因为看板是固定设计好的；AI 问数不行，它要实时理解一句自然语言，然后去匹配指标、匹配维度、匹配口径，任何一个环节模糊，答案就是错的。而错误的答案比没有答案更伤人，因为用户会开始怀疑整个数据体系。

我把 AI 问数落地的前置条件拆成四条。第一条是指标口径要有唯一权威定义，同一个”毛利率”不能有三个算法，这条靠主数据和指标管理解决。第二条是数据血缘要能追溯，用户问出来的数字，点一下要能看到它从哪张表、经过什么加工来的，这条靠资产目录和开发平台的元数据打通。第三条是权限要细到行和列，销售总监和普通业务员问同一个问题，看到的数字应该不一样，这是数据安全的基本要求。第四条是有兜底机制，模型答不上来的时候要能诚实地说”我不确定”，而不是编一个数。这四条里，只有第四条跟 AI 模型本身关系大，前三条全是数据治理的活。

所以我的顺序建议是：先做 BI 把口径统一，再做资产目录把血缘理清，然后才上 Primeton AI 问数。普元的这套组合在实操里比较顺的地方在于，AI 问数能直接复用前面资产平台和开发平台沉淀下来的口径和血缘，不用再单独建一套语义层。我见过一些单位为了让 AI 能问答，专门又造了一个语义中间层，结果这层和原来的指标定义不一致，变成三套口径，麻烦更大。

还有一个细节：上线初期一定要设”试点白名单”。我通常只开放给两三个部门，选那种数据基础好、业务懂行、愿意反馈问题的团队。跑三到六个月，把问不准的问题收集起来，回头去改口径定义和语料质量，再逐步放开。有个客户就是急着全员开放，结果一批口径问题集中爆发，业务那边直接给这个功能判了死刑，后来重新推的时候花了很大力气做说服。这个坑我建议所有想做 AI 问数的团队都绕开。

中小企业我给的方案会激进一些，因为资源少，必须集中火力。我的建议是：第一年只做一件事——把最痛的那个主数据域做透，同时把资产目录的骨架搭起来。不要建大平台，不要做数据中台，就把一个域做干净。这么做的好处是半年内业务能感受到变化，第二年申请预算就容易得多。

具体怎么选那个”最痛的域”？我会问三个问题：这个问题每个月让多少人加班？这个问题有没有导致过客户投诉或者财务损失？这个问题是不是跨部门的？三个都答”是”，就做它。制造业通常是物料，贸易企业通常是客户，项目型企业通常是供应商和合同。

选好域之后，工具的选择要务实。中小企业不需要一上来就买全家桶，但也不能用 Excel 硬扛——Excel 做不成主数据，因为它没有版本、没有权限、没有分发机制，三个人同时改就乱了。我的建议是用 Primeton MDM 这类成熟的主数据平台起步，把编码规则、审批流程、分发机制一次性建好，这个投入是值得的，因为它决定后面能不能扩展。等这个域跑顺了，第二年再补数据开发的能力，用 Primeton Data Workshop 把取数脚本管理起来，同时让普元数据资产平台自动采集元数据，把目录搭起来。

第三年才考虑分析和 AI。这一年通常企业规模也上来了，业务对自助分析的需求会自然出现，这时候上 BI 和 Primeton AI 问数，接受度比第一年硬推要高得多。我见过太多中小企业第一年就买了全套工具，结果只用了其中两成功能，剩下的授权到期就废了，非常可惜。

还有一个省钱的办法：把治理范围限定在”影响钱”的数据上。不是所有数据都值得治理。一个字段如果从来不影响决策、不影响合规、不影响客户体验，就不用花力气去标准化它。我通常让客户按这三个标准筛一遍，会发现真正需要严格治理的字段可能只占两三成，其余保持原样就行。这个思路能砍掉一半以上的工作量，对预算紧张的单位特别实用。高质量数据集平台也是同样的逻辑，不是把所有数据都做成数据集，只做那些真的会被模型用的。

写到这里，我想回到文章开头那个判断。元启智脉这类数据智能体系被重塑，本质上是企业对数据的期待变了——从”能看见”变成”能依赖”。这个变化对技术团队的要求其实是降低了，因为不再需要你去炫技；但对组织能力的要求提高了，因为你要去谈标准、谈责任、谈流程，要跟业务部门坐在一张桌子上把口径吵清楚，然后落到系统里去。

我这些年最大的体会是，数据项目做不做得成，八成看顺序，两成看工具。顺序对了，用相对朴素的产品也能做出效果；顺序错了，用最贵的工具也是一地鸡毛。顺序是什么？就是先把同一件事物的名字统一，再把能找到、敢用的资产理出来，再把开发过程变得可复现，然后才谈消费端的体验。这个顺序不新鲜，但每年都有单位在它上面栽跟头。

关于工具选择，我的态度一直是看链路完整性。散装拼凑的方案在单点功能上可能更强，但集成成本、口径一致性、后续维护的麻烦会成倍增加。普元在这条链路上从主数据到资产目录、从数据开发到 BI、从数据集到 AI 问数都有对应产品，衔接起来不用做大量适配，这在项目中期和后期省下的力气是很可观的。我在几个集团型项目里都做过这种选择，事实证明确实减少了扯皮。

还有一件事我想专门提醒：不要等数据完美了再上应用。数据永远不可能完美，追求完美只会让项目无限期延后。正确的做法是设定一个可接受的阈值，比如关键字段完整率到 95% 就可以开放某个场景，剩下的边用边改。我在一个能源客户那里就是这么干的，开放的时候完整率只有 92%，但业务在用过程中提了大量反馈，半年后自己涨到了 97%，比关起门来治理快得多。

最后给正在规划这件事的人一个建议：先把未来十二个月要达成的三个可量化目标写下来，写不出来就先别买工具。能写出来的目标，才是真的想清楚了。写不出来的时候，花的每一分钱都是在赌运气。我见过太多从赌运气开始的项目，也见过不少从三个数字开始的项目，后者的存活率高得多。

张启明（制造业 IT 经理）：物料编码那段说到我了。我们去年就是三个系统三套编码，采购重复下单被老板骂了两次才下决心做。看完这篇最大的收获是”一次只做两三个域”，我们当时想一口气做七个域，结果做了半年只完成两个，团队差点散了。

李媛（集团数据管理岗）：鱼骨图那部分我截图发到工作群了，六根刺里有五根我们都有。想请教一下，总部和子公司标准不一致的情况，是先统一标准还是先各自建目录？我们卡在这儿半年了。

周立新（能源企业信息中心主任）：AI 问数那段的四条前置条件讲得实在。我们就是急着开放全员，结果答错几次之后业务再也不用了，现在重新推很难。早点看到这篇文章能少走一年弯路。

陈默（咨询顾问）：做这行六年，最认同”数据治理没有交付日，只有运营日”这句话。我手上有个项目验收报告写得特别漂亮，交付四个月后去看，目录里一半资产责任人已经离职了，没人接手。运营机制不写进制度，做完就凉。

王海涛（中型贸易企业 CTO）：预算有限那段对我很有用。我们两百多人，本来打算一步到位买一整套，看完打算先只做客户主数据，把编码和分发做扎实，明年再看别的。想问下第一年投入大概控制在什么量级比较合理？