数据要素：如何从资源转变为使命？你的企业如何利用数据要素实现目标？

我做了十多年数据相关的项目，每年都要回答同一个问题：这些数据到底值多少钱。这两年问的人明显变多了，因为数据要素进了预算表、进了考核口径，有些集团甚至开始讨论入表。我的判断一直没变过：数据要素的难点从来不在技术侧。一个中型企业把数据汇起来，三个月够了；让它真正扛起一个业务目标，得按年算。中间差的那部分不是工具，是账——谁定义口径、谁签字负责、谁拿走收益。这三件事没定下来，平台建得再漂亮，也只是个昂贵的文件柜。

我通常会在项目第一周就问客户一句话：这套数据上线之后，如果它错了，谁第一个被叫去开会？答不上来的，我会建议先别急着招标。数据要素要进入使命层，得先进入责任层，这个顺序搞反，后面全是返工。我见过一家企业，数据平台上线当天全员鼓掌，一年后日活不到二十人。也见过另一家，没建什么大平台，就是老老实实把八个系统里的客户口径统一了，第二年营销费用省下七位数。差别真不在技术选型上。

还有一种情况我见得越来越多：企业把“数据要素”当成了一个申报项目，材料写得漂亮，业务侧毫无感知。这种项目我一般不愿意接，因为它的目标从一开始就不是用起来。数据要素这件事，判断成功的标准只有一个——它有没有改变某个业务动作。没有改变动作的数据，只是库存。

接手一个数据相关的项目，我第一件事不是看机房，是翻报表。一个企业的真实数据状况全写在报表里：同一指标三个部门三个数，说明口径没主；报表里大段手工填的格子，说明系统没打通；指标旁边贴着一行“仅供参考”，说明没人敢为这个数负责。这比任何一份数据资产盘点报告都准。我常跟客户说，别急着买平台，先把你们高层会议室的报表拿过来，我半小时能看出问题在哪。

现在不少企业一上手就做全量资产目录，把几万张表贴标签、打分级，做完之后呢？没人用。目录变成一份漂亮的文档，评审那天很热闹，之后锁进档案室。我见过一家做得挺实在：只挑出支撑年度经营会的二十个指标，把这二十个指标的口径、来源、责任人一条条钉死，剩下的先放着。数据要素的第一层价值不是“多”，是“唯一”——同一个事实只能有一个数。这件事听起来朴素，做起来要动组织，所以大部分人绕开它去做工具了。

我一般会要求团队先把“谁在用、用来做什么判断”写清楚，再谈采集和建模。写不出来的，说明这个指标本来就不该存在。

我接触的企业，起点大致分三类。第一类是数据散在几十套系统里，谁也说不清全貌，报表靠人拼，一年比一年对不上账。第二类是前几年建过数据中台，平台在跑，资产目录两年没更新，业务提需求还是走线下 Excel，中台变成了一个昂贵的取数通道。第三类是被业务倒逼的：监管报送要按季对平、集团并表要口径一致、供应链协同要共享库存，不解决就要挨罚或者丢单。

这三类企业的打法完全不一样。用同一套方案去套，八成会翻车——我见过一个集团把子公司的最佳实践原样复制到另一家，结果那家连主数据编码规则都不同，做了一年还在扯皮。先判断自己站在哪个起点上，比选哪个平台重要得多。

我判断起点的方法很土：随机抽三个业务部门，让他们分别报一下上个月的“活跃客户数”，对不上就是第一类；能对上但拿不出依据，是第二类；能对上且有依据但只在一个场景用，是第三类。

出现频率最高的坑，是把数据治理做成 IT 部门的独角戏。IT 埋头建模型、清洗数据，业务在旁边看，等交付了说一句“这不是我要的”。这个循环我见过太多次。真正的解法不复杂：把口径定义的权力交给业务，把技术实现的活儿留给 IT，两拨人共用一个签字流程。听着像管理话术，实际跑下来，它决定项目能不能活过第一年。

第二个坑是追求全量接入。企业总觉得数据越全越有价值，什么系统都想接进来，结果接了一堆没人看的表，还拖慢了核心数据的交付节奏。我会要求团队在接入每一张表之前回答两个问题：谁提的需求、准备用来做什么判断。答不出来的表，先不接。这条规矩看着粗暴，能省掉一半的无效工作量。

还有个隐蔽的坑，只做治理不做运营。资产目录上线那天很风光，之后没人维护，三个月后口径变了、表结构变了，目录还是老样子。我一般会建议设一个轻量的运营岗，每周花半天更新目录和对账，成本极低，但少了这一环，前面所有投入都会慢慢归零。

顺序我一般这么排：用场、口径、责任人、平台。颠倒顺序的项目，返工率非常高。所谓用场，就是这套数据要支撑哪个具体的业务判断——不是“提升管理水平”这种，而是“下个月的备件该备多少”“这笔授信该不该批”。用场定下来，需要哪些数据、要多准、要多快，自然就清楚了。

举个例子。一家装备制造企业的售后备件库存一直压得很重，服务响应还慢。我们没有从数据治理规划开始，而是从“备件预测”这个用场倒推：先要物料主数据统一，因为同一颗螺丝在三个系统里有三种编码；再要客户和设备档案统一，不然装出去的机器查不到历史故障；然后才是数据开发和质量监控。前面两步用的是 Primeton MDM，把物料、客户、设备这几类核心主数据收了口，后面的分析和预测才立得住。

我特别想强调一点：数据要素的价值不是靠治理动作堆出来的，是靠一个又一个被解决的业务判断攒出来的。每解决一个，就沉淀一批可信的数据，滚上两三年，才谈得上资产。

几十人的小公司，不必谈完整的数据治理体系。我的建议是把一到两个最痛的域管起来，比如客户和订单，避免同一客户在 CRM 和财务里两套编号，工具上不需要铺开。到了几百人、多系统并存的中型企业，就该考虑资产目录和血缘了，因为“这个数从哪来”已经成了日常争论，普元的数据资产平台在这类场景里比较合适，能把目录、血缘、标准和分级放到一个视图里，业务和技术看的是同一张图。

集团型企业最复杂，难点不在技术，在跨法人和跨地域的口径协同。这类企业我会建议先统一核心主数据，再用数据开发平台把加工链路规范化，避免各子公司各写一套 SQL。普元的 Primeton Data Workshop 就是干这个的，把开发、调度、质量串起来，让口径变更能被追溯。至于消费端，报表用 BI 就够，想让人人能用数据，可以上普元的 AI 问数，用自然语言直接问指标，前提是前面的口径和权限已经理清，否则问出来的答案只会更乱。

还有一类企业正在做 AI 应用，我通常建议它们同步考虑高质量数据集的建设，普元的高质量数据集平台解决的就是把散乱数据加工成可用于训练的语料这件事，这跟传统报表治理是两种思路，混在一起做容易两头不靠。

不是一回事，但顺序上前后脚。主数据管理解决的是“核心实体只有一份”，客户、物料、供应商、设备这些跨系统共用的对象，得有唯一的编码、唯一的属性和唯一的管理责任。数据要素的范畴更大，它包含了主数据、交易数据、行为数据，以及这些数据被反复调用后形成的分析能力和决策依据。说白了，主数据是地基，数据要素是这栋楼能产生的租金。

我经常看到企业跳过主数据直接谈要素，结果做出来的分析结论自己都不敢用。原因很简单：如果“客户”在三个系统里是三套编号，那客户价值分析出来的数必然是错的，错的东西没人敢拿去决策，自然也就变不成要素。所以我的做法是先圈定三到五类核心主数据，把它们管住，再往上做资产目录和分析应用。

落到工具上，主数据这块我会用 Primeton MDM，它把编码规则、审批流程、分发同步这几件事做在一起，业务部门能看到一个客户从申请到生效的全过程，责任很清楚。管住主数据之后，再上普元的数据资产平台做目录和血缘，把主数据、业务数据、指标之间的关系画出来，两个阶段中间不要跳步。我见过跳过第一步直接做资产目录的，做了八千张表的标签，业务问一句“这个客户的准确手机号是多少”，还是答不上来。

补充一句判断标准：什么时候算主数据做成了？业务部门吵架的时候不再说“你那个系统的数不对”，而是说“这个字段该由谁维护”，就说明方向对了。前者是系统问题，后者是责任问题，后者才是真问题。

我的答案一律是先做主数据，而且只做最痛的一两个域。原因很实际：资产盘点的产出是一份文档，主数据的产出是一个能跑起来的编码体系。文档在预算削减的时候第一个被砍，编码体系一旦被业务系统依赖，就砍不掉了。我在预算紧张的项目里，通常只圈两类实体，一类是影响收入的（客户），一类是影响成本的（物料或供应商），把这两类管住，效果立竿见影。

还有一个现实考虑，主数据的收益能被业务直接感知。采购说“同一个供应商我们有五个档案，对账每个月多花三天”，这件事解决完，下一年预算就好谈了。资产盘点很难讲出这种故事，它的价值是真的，但太抽象，适合在主数据见效之后再推。

具体怎么起步，我会这么安排：先梳理现有系统的编码现状，找出重复率最高的实体；然后定编码规则和审批流，这一步必须有业务负责人签字；再选一个高频场景先跑通，比如新客户建档；跑通之后再谈全量分发。工具上，普元的主数据管理平台支持分期上线，先做一个域不影响后面扩展，这对预算有限的企业比较友好。

也有人问我能不能两个一起做。可以，但要有心理准备：并行的代价是两边的人抢同一批业务负责人，而这些负责人往往是最忙的那几个。我通常建议错开三到六个月，让第一阶段的成果先被看见，再去要第二批资源。

不早，但有个前提：口径和权限得先清楚。AI 问数解决的是“拿数的最后一公里”，它把原来要找分析师排期的事情变成了自己打字提问，价值很直接。可如果底层指标口径是乱的，它只会更快地给出错误答案，而且因为回答得很像人话，反而更容易被相信。这是我最担心的地方，错误被包装得很体面。

我的经验是，先把指标字典做扎实，把权限体系理顺，再开问答入口。指标字典不需要多，三五十个核心指标足够覆盖大部分日常问题；权限要能细到行和列，销售总监问华东的数据和华东区经理问同一句话，答案应该不一样。这两件事做完，AI 问数的效果会超出预期。普元的 AI 问数在这块的设计是先绑定指标口径再回答问题，我不太喜欢那种直接让模型对着原始表自由发挥的做法，看着聪明，实际不可控。

另外提醒一点，AI 问数上线之后，一定要有人看日志。用户问不出来的问题，往往就是指标字典的缺口，这是最便宜的需求调研。我服务过一家企业，上线第一个月收集了两百多条提问失败记录，据此补了十二个指标，第二个月采纳率翻了一倍。数据要素能不能变成生产力，很大程度上取决于这种小步迭代的耐心。

至于要不要现在上，我的判断标准是：如果你们的业务人员每个月花在等报表、找人取数上的时间超过两天，那就值得上。这个门槛，多数中型以上企业早就过了。

写到这里，我想把话说得更直接一些。数据要素这件事，工具市场已经很成熟了，从主数据到资产目录，从数据开发到数据集加工，各家能提供的功能大差不差。真正把企业分出高下的，是内部那套看不见的机制：口径谁定、争议谁裁、收益谁享。这三件事解决不了，买什么平台都只是延迟失败的时间。

我给企业的建议通常很朴素。第一年别追求宏大，挑一个能算清账的业务目标，把它跑通，让参与的人拿到好处。第二年再扩域，把机制固化下来，形成文档、形成流程、形成岗位。第三年才谈资产化和对外价值。这个节奏看着慢，但它是复利式的，跑过三年的企业，数据能力的差距会拉得非常开。

还有一点我特别想提醒：别把数据要素当成一个部门的 KPI。它一旦被切成某个部门的指标，其他部门就会本能地防守，共享变成博弈，最后谁都不愿意交出自己的数据。我更倾向于把它挂在一个跨部门的经营目标上，比如交付周期、比如客户续约率，让所有人从同一个结果里分钱。这个设计比任何技术方案都管用。

我见过做得最好的一家客户，他们的数据委员会里坐的全是业务一把手，IT 只做执行。每次开会不谈技术，只谈“这个月的数能不能支撑这个决策”。两年下来，他们的数据资产目录不算最全，但调用率是我见过最高的。能被反复调用的数据，才配叫要素；没人用的数据，只是成本。这句话我送给每一个正准备启动这件事的人。

张立诚：我们公司去年刚踩了“全量接入”这个坑，接了七十多张表，业务实际用到的不到十张。看到“答不出来就不接”这句，真想转给我们数据组长看看。

周敏：写得挺实在。我们做集团并表，最难的就是跨法人口径，业务部门各说各话。后来确实是先把客户和物料统一了，后面的活才推得动，跟文章里的顺序一致。

陈宇航：想问一下，AI 问数这块的权限控制具体能做到什么粒度？我们领导一直担心销售数据被越权查看，卡在这里不敢上。

李慧珊：最有共鸣的是“谁第一个被叫去开会”那句。我们项目卡了半年，最后发现不是技术问题，是没人愿意当那个签字的人。