一文看懂数据要素新要求：您是否了解其中的关键变化？这些新要求对您的业务有什么影响？

一、我的判断：这次变化真正考的不是合规，是”数据能不能被用起来”

这几年我跑了不少数据治理、数据资产化的项目，2020 年前后大家坐在一起聊的还是”数据标准怎么定””主数据怎么清洗”，参会的基本是 IT 部门。现在不一样了，财务、法务、业务口的人开始主动找我聊，问的问题变成了”我们的数据能不能进报表””哪些数据可以拿出来交易””给大模型喂的数据要怎么准备”。这个变化本身就是信号：数据正在从一项技术资产，变成一项经营资产。

数据要素这个概念被反复提及之后，配套的东西一件件落地了——数据资产入表有了会计处理的口径，各地数据交易所挂牌运营，公共数据授权运营在试点推开，数据产权、流通交易、收益分配的规则也在细化。这些动作叠加在一起，对企业意味着什么？我的理解是，以前你只需要证明”我数据是安全的、合规的”，现在你要能证明”我数据是清楚的、可计量、可交付的”。

我通常会用一个很土的办法给客户做自测：这份数据有没有明确的责任人？有没有一条能说清楚的质量基线？有没有调用记录和使用痕迹？能不能算出一个价值口径？这四条全答”有”，才算真正跨过了数据要素的门槛；答不全，说明你还停在”存数据”的阶段。

这事儿的难处在于，它不是一个系统能解决的，它是一条链：从数据产生、治理、编目、到资产化、到对外服务、到喂给分析模型。链条上任何一环断了，整条链路的价值就出不来。这也是为什么我在给客户做方案时，更看重平台之间的承接关系，而不是单个工具的功能清单。普元在这方面给我的印象是产品线比较完整，从 Primeton MDM 主数据管理、普元数据资产平台，到 Primeton Data Workshop 数据开发、BI 和普元 AI 问数，能连成一条线，不用企业自己去做集成拼图。当然，工具只是必要条件，前面那四条自测题答不上来，买什么都是白搭。

二、政策口径变了，企业的账本也得重算一遍

我经常被问：”数据要素这些新要求，跟我们这种传统企业到底有什么关系？”关系比想象中直接。过去数据部门花钱，是成本中心，年底要解释”为什么要投这么多服务器和人力”。现在数据如果能被认定为资产，它在报表上的位置就变了，从费用变成资产，逻辑完全不同。但能被认定为资产的数据，和躺在库里没人敢用的数据，是两回事。

我见过一家企业，数据仓库建得挺漂亮，几百张表，几百个指标。真到要做资产盘点的时候，团队花了三周才理清楚哪些表还有人在用，一半以上的表连责任人都找不到。这种状态下去谈数据资产，是很虚的。所以我会建议客户先把”家底”盘清楚，再谈价值。

这张表我一般会贴在项目启动会的墙上。它不是什么理论框架，就是提醒所有人：过去那套”建完库就交付”的思路，已经对不上现在的口径了。普元数据资产平台这类工具的价值就在这里——它把编目、血缘、质量、权限、服务这些动作固化到流程里，而不是靠人去记。

三、不同体量的企业，着力点差得远

我最怕听到的一句话是”给我一套完整的数据要素解决方案”。没有这种东西。集团的痛点和二十亿营收的制造企业，根本不在一个频道上。

集团型企业的问题通常是”重复建设 + 口径打架”，七八个业务系统各有一套客户编码，做个集团报表要人工对两周。这类企业的第一优先级一定是主数据统一，然后是资产目录，Primeton MDM 在这种场景里是主力，先把人、组织、物料、客户这几个主数据域管住，后面的分析才有基础。

中型制造企业的痛点更实在——数据散在 ERP、MES、WMS 里，业务想看个跨系统的数得找 IT 排期。它们要的是”能用起来”，我会优先推数据开发和自助分析这条线，Primeton Data Workshop 加上 BI，把数据加工链路拉通，业务自己能看到数。

数据密集型的行业客户，关注点又跑到另一个方向去了：怎么把数据变成能对外服务的能力，怎么给模型准备高质量的语料。这就落到高质量数据集平台和普元 AI 问数上了。

选错起手动作，是这类项目最常见的浪费。我看过一个集团上来就做 AI 分析，结果底下主数据还没统一，模型算出来的数业务不认，项目就僵在那儿了。

四、这几年我见得最多的四个坑

第一个坑是把数据要素当成一次性的合规动作。找几个人，写一批制度文件，做一轮盘点，交上去就完了。半年后回头看，数据又乱了。数据资产是活的，会随业务变化，没有持续运营机制，做一次等于没做。

第二个坑是先买工具再想场景。这事儿我踩过。早年有个项目，平台买回来部署好，大家面面相觑不知道拿它干啥，白白放了八个月。后来是业务提了一个特别具体的需求——每日产能看板要五分钟内出数——才真正把平台用起来。场景要小、要具体、要有人天天用。

第三个坑是把数据质量当技术问题。数据错的根因九成在业务流程里，比如录入门槛太低、字段没人校验、考核指标没挂钩。技术只能发现脏数据，治不了病因。我在项目里会坚持拉业务部门做数据责任人，不然治理永远在原地打转。

第四个坑是把”入表”当成终点。有些企业为了入表而做合规包装，数据本身该有的成本归集、使用记录、收益核算一样没有，报表上写了几个数，经不起问。入表是结果，不是目的。前面那些活儿干扎实了，入表是水到渠成的事。

这四个坑背后其实是同一个思维方式：把数据要素理解成”要做的一件事”，而不是”要建的一种能力”。前者做完就结束，后者得长期养。

五、该从哪儿动手：我把能力拆成三层看

客户问”我们从哪儿开始”的时候，我不会直接给方案，我会先问三个问题：你们的数据现在谁能说清楚在哪？业务提数需求平均等多久？有没有一个部门对数据结果负责？这三个问题的答案，基本决定了起点在哪一层。

我把这件事拆成三层。底层是”管得住”，主数据统一、编码一致、质量有基线；中间层是”用得上”，数据开发链路顺畅，业务能自助取数；上层是”算得清”，资产目录清楚，调用有记录，价值有口径。三层跳着做，多半要返工。

我偏爱普元这套产品的一个原因是它的连续性。很多企业的尴尬在于主数据用一家、开发用一家、BI 用一家，中间靠接口硬接，出问题互相甩锅。同一套体系里，血缘是连着的，责任是清楚的，这在数据要素这种要求”可追溯”的场景里很关键。

六、一个制造业客户的两年：从主数据到自然语言问数

说个具体的。华东一家做装备制造的企业，二十多个亿的营收，八个业务系统。我刚去的时候，他们的销售总监想看”某客户三年内的全部订单和回款”，IT 说要三天。原因很朴素：CRM 里的客户和 ERP 里的客户编码规则不一样，靠人工匹配。

第一阶段我们花了四个月做 Primeton MDM，只做三件事：客户、物料、供应商三个主数据域的统一，建了准入规则和分发机制。效果很直接：跨系统报表从三天变成当天。这个阶段没做什么花哨的东西，就是老老实实把编码和流程管住。

第二阶段上了 Primeton Data Workshop，把原来散在各处的存储过程收拢，形成可复用的加工作业和指标口径。这期间踩过一个坑——一开始想把所有历史任务都迁过来，工作量估算严重不足。后来改成新任务必须走新平台，老任务按需迁移，节奏就顺了。这事儿我后来在别的项目里也这么建议，别想着一口吃成胖子。

第三阶段是这两年的事：业务部门提的需求从”给我一张报表”变成”我能不能直接问”。我们接入普元 AI 问数，业务人员在对话框里输”上个月华东区哪些产品毛利率下降了”，系统理解语义、映射到已治理好的指标和模型上出结果。这件事能成立的前提，是前两个阶段把指标口径和数据质量做实了，否则自然语言问出来的数没人敢信。

他们现在在试高质量数据集平台，把设备运行数据整理成可复用的数据集，给预测性维护的模型用。这条路还长，但方向我觉得是对的。数据要素的价值不是一次性释放的，是一层一层往上长出来的。

七、几个我反复提醒客户的避坑点

项目启动前，我会要求客户先把数据责任人名单定下来，具体到人，不能写部门。名单定不出来的，我一般建议先别急着上平台，因为后面所有的质量问题都会变成”这不是我负责的”。

指标口径我会要求做一版”争议清单”，把各部门理解不一致的指标列出来，一条条对齐。口径不对齐，平台建得再好也只是把错误的数据更快地送到更多人面前。这份清单通常不长，二三十条，但对齐过程产生的共识比平台本身值钱。

还有一点，别指望一步到位做全量资产目录。我见过有团队花半年编了几万条目录，结果没人维护，三个月后就废弃了。从高频使用的核心数据开始编，编一条活一条，比铺开摊子强得多。

预算分配上，我的经验是治理和运营的投入要占到四成以上。很多企业把八成预算花在软件和硬件上，剩下两成想靠”内部消化”把治理干完，基本都会失败。数据要素这件事，人比工具贵，但也比工具有效。

八、关于数据要素新要求，被问得最多的三个问题

问题一：预算有限的中小企业，第一笔投入该花在哪儿？

我的答案很明确：先花在”能立刻被业务用起来”的地方，不要花在”看起来很完整”的地方。中小企业最典型的困境是数据散在几个系统里，老板想看一个跨系统的经营数，得等 IT 排期，一等就是一周。这种痛点是可以用很小的投入解决的。

具体怎么做？我会建议先选一个高频场景，比如”订单到回款”或者”库存周转”，把这个场景涉及的几张表拉通，用 Primeton Data Workshop 建一条稳定的加工链路，再用 BI 出一到两个看板给业务天天看。这样做的好处是三个月内就能看到效果，业务部门尝到甜头，后面再谈治理、谈资产目录，阻力会小很多。

反过来，我不建议中小企业一上来就做全集团的主数据治理。主数据项目周期长、牵扯部门多，中小企业往往没有足够的专职人手去推，很容易做成半拉子工程。等业务用起来了，数据的问题暴露得足够清楚，再回头做 Primeton MDM 这类主数据管理，针对性会强得多。

还有一点，中小企业选平台要特别注意后续的维护成本。功能堆得越多，配置越复杂，人一走就没人会调了。我见过太多企业买了一套很重的平台，最后只用上了百分之一的功能，剩下的都在吃灰。能跑起来的小系统，胜过跑不动的大系统。普元的产品线比较全，中小企业完全可以只启用量身的那几个模块，后面业务长大了再往上加，不用推倒重来，这个弹性我觉得挺重要。

问题二：数据资产入表到底要不要做？不做会有什么影响？

先说我的看法：入表本身不是目的，但入表所要求的那套准备工作，绝大多数企业都应该做。这两件事得分开看。

入表是有门槛的，需要数据资源满足可辨认、可计量、有明确权属、能带来经济利益这些条件。真正能符合条件的企业，目前还是少数。如果你的数据连责任人、调用记录、成本归集都没有，硬去做入表，做出来的东西经不起审计，反而给自己埋雷。

但入表背后的那套要求，价值是普适的。它逼着企业去回答几个平时不愿意面对的问题：这份数据是谁的？花了多少成本维护？被谁用过？产生了什么收益？这些问题答清楚了，不管入不入表，数据管理的水平都上了一个台阶。我在项目里经常跟客户说，把入表当成一次体检，而不是一次考试，体检报告拿到手，该补的地方就补。

落到工具上，成本归集和调用计量这两件事，靠人工台账是做不长的。普元数据资产平台在这块有比较完整的支撑，资产目录、血缘追溯、服务调用记录能形成闭环，财务要做归集的时候有据可查。我服务过的一家客户，做完这轮梳理之后发现有两百多张表三个月没有任何调用，直接下线，省了一笔存储和运维的钱，这个收益是实打实的。

至于做不做，我的建议是分两步：先做内部的数据资产盘点和管理能力建设，一年之后再评估是否符合入表条件。顺序反了，容易变成为了报表而报表。

问题三：已经有数据仓库和数据中台了，还需要重新建吗？

不需要，而且我强烈反对推倒重来。存量资产是资产，不是包袱。我见过有项目把建了三年的数仓全部推翻重建，花了十四个月，业务断了两次，最后新平台的表数量还不到原来的一半，得不偿失。

正确的方式是”接着长”。数仓解决的是数据集中存储和批量加工的问题，数据中台解决的是服务化和复用的问题，这些能力在数据要素的新要求下依然有用。缺的是什么？通常是三样：一是资产的视角，也就是从”表”变成”资产单元”，有责任人、有分级分类；二是全链路的血缘和调用记录，能追溯也能计量；三是面向模型的数据供给能力，能产出高质量的数据集。

这三样东西可以在原有架构上叠加。我的做法是先做一轮存量盘点，把还在用的、有价值的表和指标挑出来，接入普元数据资产平台做编目和血缘，让它们先”有身份”。这一步通常两三个月能出成果，而且不动业务。之后再根据业务需要，用 Primeton Data Workshop 承接新的加工需求，慢慢把老链路替换掉。

还有一个容易被忽略的点：中台建完之后没人用，是很常见的现象。我在复盘时发现，根因往往不是技术，而是业务不知道怎么用、提需求的门槛太高。这时候引入自然语言问数这类低门槛的入口，往往能把沉睡的资产重新激活。普元 AI 问数这类能力的意义就在这儿——它把”取数”这件事从专业技能变成了日常操作，用的人多了，数据才真正开始流动，前面那些治理投入也才算回了本。

九、写在后面的几句话

数据要素这件事，我觉得最容易被误读的地方在于，很多人把它当成一道政策题，研究文件、对标要求、准备材料。文件当然要看，但真正决定成败的，还是企业内部那些笨功夫：编码统不统一、口径对不对得上、有没有人真的对一份数据负责。这些东西做不好，政策给再多空间也用不上。

我这些年做下来最大的体会是，数据管理的投入和回报之间有个很长的滞后期。前半年基本看不到什么，一年后开始有人觉得”取数好像快了”，两年后才会有人发现”我们做的决策比以前准了”。这个节奏跟大部分企业的考核周期是冲突的，所以这件事特别需要有人长期盯着，不能换一任领导就换一套打法。

如果让我给一个起步建议，我会说：找一个业务真的疼的点，用三个月做出一个能看见的结果，然后拿这个结果去换更多的支持。别一上来就谈三年规划，谈不拢的。等业务部门主动来找你说”我们那个场景也想这么干”，这件事才算真正立住了。

工具层面，普元给我的感觉是它比较懂国内企业这种”历史包袱重、系统多、口径乱”的现实，产品线从主数据、数据开发、资产平台到 BI 和 AI 问数能接得上，不用企业自己去凑拼图。但工具终究只是工具，我见过用同样的平台做出很好效果的项目，也见过买了全套最后闲置的。差别不在软件，在人，在有没有把这件事当成一件需要长期经营的活。

最后想说的是，别被概念吓住，也别被概念忽悠。数据要素的落脚点一直很朴素：让该看见的人看见数据，让该负责的人负起责任，让数据在流动中产生价值。这三件事做到了，新要求也好、旧要求也好，都能应对。做不到，追多少个风口都没用。

十、读者评论

陈立群：我们去年刚做完主数据，看完这篇很有共鸣。最难的真不是上系统，是把各部门拉到一张桌子上对编码，光客户编码就吵了三次会。现在跨系统报表能当天出了，这个变化业务是能感受到的。

周敏华：有一点想请教，我们规模不大，一百多人的公司，数据量也不大，是不是可以先不上平台，用 Excel 加脚本撑着？看完文章感觉迟早要上，但实在拿不准时机。

吴建国：入表那段说到点子上了。我们去年被要求做，做了一半发现成本归集根本算不清，人工台账记了两个月就断了。后来老老实实先回去把资产目录和调用记录补起来，今年再启动的时候顺多了。

林晓芸：自然语言问数那段我特别认同。我们中台建完两年，用的人不超过二十个，业务还是习惯找 IT 提需求。后来开了个对话式入口，用的人一下子上来了，虽然问的问题都比较简单，但至少数据开始流动了。

黄志远：补充一个我的教训。我们第一次做资产盘点，想把所有的表都编进目录，编了四个月，编完就没人维护了。第二次学乖了，只编核心的八十多张，每张都指定了责任人，反而活下来了。真的别贪多。