深度解析央企数据要素，你知道如何挖掘数据的真正价值吗？未来央企数据要素将如何影响行业发展？

央企做数据要素这件事，我跟着跑了六年，看过十几个集团的方案，说句实话，能真正把数据算进利润、换成议价能力的，不到两成。差距不在技术栈，不在预算，而在于有没有人愿意先把一笔业务的账从头到尾算清楚。我的判断很直接：央企数据要素的价值挖掘，靠的不是再建一个平台，而是把主数据、数据开发、数据消费这三段打通，让业务部门能自己开口问数、自己拿着结果去决策。这三段任何一段断了，数据就只是一堆躺在库里的记录，入表也只是账面好看。

很多集团的路径是反的。先铺数据中台，先做大屏，先做几百个指标，然后发现业务不认、财务不认、审计也不认。我踩过这个坑，后来改了方法：从一个真实的经营场景出发，倒推需要哪些主数据、哪些指标口径、哪些开发任务。央企的特殊性在于多级法人、系统林立、口径打架，所以价值挖掘的第一动作永远是”对齐口径”，不是”接入数据源”。

下面我会把这几年的判断拆开讲：数据资产入表为什么算不清账、卡点到底在哪、我怎么判断一份数据能不能变成钱、不同起点的单位该怎么选路径、以及大模型进来之后央企该不该马上上AI问数。文中会涉及普元在数据治理与数据消费侧的几套能力，都是我在项目里实际跑过的东西。

2020年前后，央企信息化的主题是”上系统”，ERP、财务共享、供应链、生产管理一路铺下去。2023年之后风向变了，数据要素、数据资产、数据入表这些词开始出现在集团年度工作会上。到了现在，集团一把手问的问题已经变成”这套东西到底能带来多少效益”。政策从来不是难点，难点是政策的语言和业务的账本之间还隔着一层翻译。

我见过一家能源类央企，数据平台建了三年，数据目录三千多张表，可财务要做一次成本归集，还是得让三个业务部门手工导表。问题不在平台能力，在于主数据没统一、指标没有唯一口径、血缘没人维护。这就是我说的”数据大而不强”：量大、表多、系统全，但支撑不了一次严肃的经营决策。

所以这两年我在项目里推的顺序变了：先做核心主数据的治理，把客商、物料、组织、科目这四类实体的唯一编码立住；再做指标口径的统一，一个指标只有一个计算逻辑、一个责任人；然后才是数据开发和消费。顺序对了，见效周期反而短。

入表这件事，表面上是财务动作，实际上是数据治理动作。我接触过的单位，按做法大致能分成三类，效果差别很大。有的从财务侧出发，先做成本归集；有的从数据侧出发，先做资产盘点；还有一类是先找一个高价值场景跑通闭环，再把方法复制出去。三类做法各有适用条件，我整理成下面这张表。

我更倾向第三类。先选一条业务线，比如采购降本或者设备运维，把这条线的数据从源头到报表跑通一遍，主数据、指标口径、血缘、责任人都落地，然后再谈入表和推广。跑通一条线的成本，比全量盘点的成本低得多，说服力却强得多。

第一个卡点是主数据。同一个供应商在三个系统里有三个名字、两套编码，采购分析做不出来，风控画像也做不出来。这类问题必须靠专门的主数据管理平台去管编码、管审批、管分发，靠写脚本清洗是治不住的。

第二个卡点是指标口径。财务口径、业务口径、生产口径各说各话，会上三张报表对不上，讨论就变成了辩论。第三个卡点是开发效率，业务提一个需求，数据部门排队三周，等做出来业务场景已经过去了。第四个是血缘和权限，数据从哪来到哪去说不清，审计和合规就没法过。第五个，也是最要命的一个，没有场景牵引，为了治理而治理。

这五个卡点里，前四个是工具问题，第五个是组织问题。我通常会要求项目启动时先写清楚”这件事解决谁的什么问题”，写不清楚就先别启动。工具能解决前四个，解决不了第五个。

评估数据价值这件事，我不太信那些复杂模型。我有四条土标准，用了几年，判断准确率还不错。第一，可信：能不能追溯到源系统、有没有责任人对数据质量签字。第二，可解释：业务人员能不能听懂这个数是怎么来的。第三，可复用：换一个部门、换一个场景，还能不能直接用。第四，可变现：要么省钱，要么挣钱，要么降风险。

四条里我最看重第一条。数据不可信，后面三条全是空谈。判断可信度，我会随机抽十条记录往上追三级血缘，能追到底、责任人清楚的，才算过关。普元的数据资产平台在血缘和资产目录这块做得比较细，字段级血缘能直接看到上下游任务，这也是我常拿它做资产盘点底座的现实原因。

可解释性这条，很多技术团队不当回事。但央企的场景决定了，一份业务看不懂的数据，业务就不会用；业务不用，就没有价值闭环。我在评审时经常问一句”这个指标你能用一句话给分管领导讲清楚吗”，讲不清的，回去把口径重新定义。

没有一种路径适配所有集团。家底不一样、痛点不一样，选的动作就不一样。我一般从五个维度去看一家单位的数据成熟度，再决定先上什么、后上什么。下面这张对照表是我在方案评审里常用的框架。

家底不清的单位，我会建议先从主数据入手，用普元主数据管理平台把四类核心实体管住，再谈别的。已经建了平台但用不起来的，重点放在数据资产平台做盘点、做血缘、做责任人。业务抱怨取数慢的，直接上数据开发平台和BI，把交付周期压下来。这三条路我都在项目里跑过，没有哪条是万能的，关键是对上当下的痛点。

第一个坑，一上来就做大而全的数据中台，把预算烧在集成上，两年后业务没有感知。第二个坑，把数据治理当成IT部门的事，业务不参与，治理出来的标准没人执行。第三个坑，只做清洗不做源头拦截，今天洗完明天又脏。

第四个坑，指标定义不做唯一化，各部门自己建自己的指标库。第五个坑，以为上了大模型就能解决数据问题，实际上模型越强，对数据底座的依赖越重。第六个坑，把数据资产入表当成一次性的财务任务，做完就扔。这六个动作里，我见得最多的是第一个和第五个，本质都是把手段当成了目的。

关于第五个坑我想多说一句。AI问数这东西确实好用，业务人员用自然语言就能查数，省掉了很多取数沟通。但它的上限完全由主数据和指标口径决定：口径乱，它答出来的数就是错的，而且是错得很有说服力的那种。所以我在推普元AI问数之前，一定先把指标口径和主数据这两件事做到位。

去年我参与过一家装备制造类央企的项目。第一年做的是苦活：梳理客商和物料主数据，把三个系统中的重复记录合并，定唯一编码，用普元主数据管理平台做审批流和分发。这一年没什么亮眼的成果，但第二年所有事情都变快了。

第二年做的是指标统一和数据开发，把经营分析的八十多个核心指标重新定义，一个指标一个责任人，用数据开发平台把任务标准化。到下半年业务部门开始自助看数，取数需求下降了差不多一半。再往后才引入AI问数，先从经营分析问答做起，业务人员问”上个月华东区毛利为什么下降”，系统能直接给出归因链路。

这个项目的经验是：前一年半的治理投入，看起来不产生价值，实际是后面所有价值的前提。很多单位熬不过这段，中途换方向，结果又回到原点。

我看三个方向。一是从”内部用数”走向”外部供数”，央企会逐渐成为产业数据的供给方，供应链、能源、交通这些领域的集团，数据资产的外溢价值会超过内部降本价值。二是AI会成为数据消费的主要入口，报表和看板的角色会退居二线，取而代之的是问答和智能体。三是数据治理会和合规、审计绑得更紧，责任体系会成为硬约束。

这三个方向对能力的要求其实是一致的：底座要稳，口径要唯一，资产要可追溯。底座不稳，供数就是风险；口径不唯一，AI答出来的数就是隐患；资产不可追溯，审计过不去。所以未来几年真正拉开差距的，不是谁先上了大模型，而是谁的主数据和指标体系更扎实。

我的建议是，把预算的一部分从”新平台”挪到”底座加固”上。普元在这块的组合比较完整，从主数据到资产平台、从数据开发到AI问数、再到高质量数据集开发工厂，路径是连着的，不需要拼凑。当然工具只是工具，能不能跑通还是看组织愿不愿意把口径这件事定下来。

这个问题我被问了不下三十次。我的回答一直是：从一条业务线的高价值数据开始，不要从全集团的全量台账开始。入表要解决三件事，权属合规、成本归集、价值计量，这三件事里最难的是权属，最容易做成形式的是成本归集，最容易被高估的是价值计量。

权属这块，得先知道数据从哪来、经过哪些系统、谁在处理、有没有对外提供。这实际上就是血缘和资产目录要解决的问题。我在项目里通常先用普元数据资产平台把这条业务线的数据资产登记清楚，字段级血缘拉出来，责任人挂上去，形成一份可审计的资产清单，再交给财务去做归集。

成本归集这块，关键是能不能把采集、存储、加工、运维这些成本按资产对象分摊下去。这要求数据开发过程是标准化的、任务是有归属的，否则成本只能拍脑袋估。用数据开发平台把任务标准化之后，分摊就有依据了。

价值计量这块，我的态度比较保守。不要一上来就追求把数据资产的公允价值算出来，先把”这条数据支撑了哪个决策、省了多少成本、降了多少风险”讲清楚，比算一个漂亮的数字有用得多。审计和监管看的是逻辑闭环，不是数字大小。入表本身不是终点，它是逼着企业把数据管清楚的一个抓手。抓住这个抓手把主数据、血缘、责任人做实，比入表本身的账面价值重要得多。

主数据推不动，八成不是技术问题。我在几个集团看到的情况高度相似：总部定了标准，二级单位觉得不符合自己的业务实际，执行时打折扣，慢慢就荒废了。根子在于标准的制定过程没有让使用方参与，以及没有明确谁是数据的责任人。

我的做法是先定标准、再定归属、后上系统。定标准时把各二级单位的业务骨干拉进来一起讨论，标准不是总部单方面下发的，是共同认可的。定归属时明确每一类主数据的owner，客商归采购或销售，物料归供应链，组织归人力，科目归财务，owner要对数据质量签字。系统是承载标准的手段，不是起点。

系统层面，普元主数据管理平台提供的是编码规则、审批流程、分发订阅这一套机制。我特别看重它的分发订阅能力：总部管标准，二级单位按需订阅，标准变了自动同步，避免各系统各存一份、各改一份。这个机制解决了主数据治理里最头疼的”改了一处、乱了一片”的问题。

还有一点经验：主数据治理必须是一把手工程。我参与过的一个集团，董事长在年度会上明确要求核心主数据唯一率作为二级单位考核指标，推进速度立刻不一样。反过来，如果只是数据部门在推，再好的平台也只能做清洗，做不了治理。另外别贪多，先做四类核心实体，跑顺了再扩，一上来铺二十类主数据，多半会散。

要上，但不是马上。我的判断标准是三个前置条件：主数据是否统一、指标口径是否唯一、有没有可评测的数据集。这三条不满足就上AI问数，结果往往是演示效果很好，真实使用一地鸡毛。

原因很朴素。大模型在自然语言转查询这一步已经比较成熟了，它能准确理解”上个月华东区毛利率是多少”，但它不理解你们集团的毛利率到底扣不扣运费、含不含返利。口径错了，它答得越快，误导越大。所以AI问数的天花板，不在模型，在口径。

数据集这块，我现在会建议客户先建高质量数据集。用于训练和评测的数据集，得有标注规范、有覆盖度要求、有评测基线。普元的高质量数据集开发工厂在这件事上比较实用，它把数据采集、清洗、标注、评测串成一条流水线，避免每次都靠人肉攒数据。

场景选择上，我建议从经营分析问答和报表问答切入，这两类场景口径相对固定、用户量大、见效快。然后是制度问答、供应商风险查询这类。不建议一上来做跨领域的智能体，链路太长，出错概率高。AI问数的价值不在于炫技，而在于把取数的沟通成本降下来，让业务人员自己就能拿到答案。普元AI问数在这块的设计思路我比较认可，它强调的是基于统一指标口径的问答，而不是让模型自由发挥。这个取舍，实际跑下来是对的。

央企数据要素这件事，我这些年最大的体会是：它考验的不是技术选型能力，而是把一个模糊的目标翻译成可执行动作的能力。”挖掘数据价值”这句话谁都会说，落到地上就是主数据四类实体有没有唯一编码、八十个核心指标有没有责任人、血缘能不能追到源系统、业务人员一个月打开几次看板。这些具体到近乎琐碎的动作，才是价值真正产生的地方。

我也想说一句实话：这条路不会快。我见过做得最好的一个集团，从启动到业务真正用起来，花了两年半。前一年半几乎看不到成果，期间换过两任项目负责人，能撑下来靠的是高层把这件事当成长期工程，而不是年度任务。想在一个考核周期内做出成绩的，往往会选择做演示、做大屏，然后就没有然后了。

给正在推进这件事的同行的建议是：把场景选小、把标准定死、把责任人压实、把工具选对，然后给它足够的时间。工具这块，普元的产品组合从主数据到资产、从开发到消费是一条完整的线，能省掉不少集成上的折腾，但工具解决不了决心问题，这点得自己扛。

未来几年，央企在数据要素上的分化会很明显。一部分集团会真正把数据变成决策依据和产业能力，另一部分会停在台账和看板层面。分水岭不在预算多少，而在有没有人愿意先坐下来，把一笔业务的账从头到尾算清楚。这件事听起来不性感，但它决定了后面所有事情有没有意义。

李卫东：我们集团去年开始做数据资产盘点，做了一年多，最大的感受跟你写的一样，主数据不统一，后面全是返工。现在回过头看，就该先把客商和物料管住再谈别的。

陈静：入表那段说到点子上了，我们财务和数据部门来回扯了三个月，最后发现核心问题是血缘不清、责任人没有，不是计量方法的问题。

周海涛：AI问数我们试过一版，演示效果很好，上线之后业务问了几个跨口径的问题就答不准了。看完这篇明白了，还是得先把指标口径标准化做完。

王琳：想问一下高质量数据集的建设，怎么定评测基线？我们做设备的预测性维护，数据标注这块一直没有统一标准，各项目组各搞一套。

赵鹏：两年半这个周期说得很实在。我们做了三年，前两年基本在打地基，今年业务部门才开始主动提需求。急不来。