央企数据要素流通方案解析，这个方案如何推动企业数字化转型？您是否了解该方案对行业的影响与潜力？

我的判断是：央企数据要素流通这件事，成败不在“有没有平台”，而在“数据能不能被核验、被定价、被交付出去”。过去几年我参与过几个能源、建筑、装备制造类央企的数据资产梳理和流通试点，见过的方案文档摞起来能有一米高，真正跑通的却不多。差别往往不在技术选型，而在方案是不是围绕“可交付的数据集”来设计的。

第一层判断，流通的前提是资产化，资产化的前提是治理细到颗粒度。很多单位把数据资产目录做成了“系统清单”，点开一看全是表名和字段名，业务部门看不懂，审计部门不认账，这样的目录拿去挂牌交易，没人接。真正能流出去的资产，至少要能回答四个问题：数据从哪来、口径怎么算、质量谁担保、出了争议谁负责。

第二层判断，央企的优势是场景真实、数据体量大，短板是系统割裂、口径打架。我见过同一个“客户”字段，在CRM、合同系统、财务系统里三套编码，销售说A是同一家，财务说不是。这种状态下谈流通，等于把脏数据打包卖出去。主数据管理和数据资产平台不是配套件，是前置条件，普元这类做治理底座的厂商在这块的价值，往往在项目第二期才被真正认出来。

第三层判断，方案好不好，就看它能不能落到“数据集”这个交付物上。不是看PPT里画了多少层架构，而是看它能不能说清楚：这批数据以什么形态交付、以什么频率更新、以什么接口调用、以什么标准验收。我通常会要求方案里必须有至少三个真实数据集的端到端样例，跑不通这三个，后面都是空话。

“数据要素×”三年行动计划推出来之后，几乎每家央企都成立了数据专班。我参加过几次内部评审，发现一个共性现象：技术方案写得越漂亮，落地越慢。原因很简单，技术侧的问题是可解的，组织和口径的问题是不可控的。

举个具体例子。某装备制造央企要做供应链数据对外服务，技术上就是建个API网关加权限体系，两周能搭完。但实际卡了七个月，卡在“哪些字段可以对外”——采购价格、供应商名单、库存水位，每一个都涉及不同部门的利益边界。这种问题，任何平台都解决不了，得靠制度加工具一起推。

所以我现在看方案，会先看它有没有把“数据确权、质量责任、流通范围”这三件事做成可配置的规则，而不是写成一份管理办法就完事。规则能沉淀进系统，才叫方案；只写在文件里，那叫通知。

下面这张表是我自己总结的，把央企数据流通项目里最常见的卡点按处理优先级排了一下，供参考。

市面上给央企的方案，大体能归成三类：一是自建治理底座加数据资产运营，二是只做资产台账和入表工具，三是项目制外包拼装。三类路线短期看都能交差，长期看差得很远。

我见过一家二级单位选了第二类，三个月就把台账做出来了，报表也漂亮。但真到要给兄弟单位提供数据服务时，发现台账背后没有可调用的数据链路，得回头补。这一补就是一年。这事我踩过坑，所以现在会特别看重“台账到数据”的那条链路是不是通的。

方案评审会上我话不多，但一定会问五个问题，答不上来的基本就打回。这五个问题问的不是技术，是方案有没有真正落到数据上。

第一个：这批数据的主数据源头在哪，谁负责分发？答不出来，说明治理没做。第二个：指标口径有没有唯一责任人？没有的话，资产入表之后的摊销和减值没法算。

第三个：质量规则跑出来的稽核记录能不能作为凭证导出？审计要的是证据不是截图。第四个：数据以什么形态交付给外部，是文件、接口还是API套餐？第五个：如果对方三个月后要扩字段，谁来做，成本谁承担？

这五个问题我在普元的项目里问过，他们的做法是把答案固化在工具里——主数据管理平台负责源头和分发，数据资产平台负责目录、血缘和质量凭证，数据开发平台负责把数据加工成可交付的数据集。工具能接住问题，方案才算闭环。

我不太喜欢“一刀切”的方案模板。集团总部和二级单位的起点完全不同，排优先级的方式也应该不同。集团层面优先解决“统一”，二级单位优先解决“能用”。

总部一般已经有主数据、有数据仓库、有指标平台，缺的是把资产运营起来。这种情况下我会建议先上普元的企业数据资产平台，把已有的表、指标、报表盘成资产，再补高质量数据集开发工厂，把高频场景的数据封装成标准数据集对外供给。数据开发平台负责把加工流程规范化，避免每个部门各写一套脚本。

二级单位通常系统少、数据少，但场景具体。这时候先做数据集比先做平台更划算。用主数据管理平台把客户、物料这类核心对象统一了，再用数据开发平台把两三个关键场景跑通，一年内就能出成果。商业智能平台和AI问数这类前端工具可以后置，等数据可信了再上，否则就是给脏数据装了个漂亮门面。

至于AI问数，我持谨慎乐观态度。它的价值在于降低取数门槛，让业务人员自己问数据。但前提是底下的指标口径统一、数据血缘清晰，不然问出来的数字没人敢用。普元的AI问数在语义层做了不少工作，接上资产平台的指标定义之后，实际跑下来准确率是可以接受的，这一点比裸模型直接查库靠谱得多。

下面这张对照表是我给几家单位做选型参考时用的，按能力维度对应到具体工具，看哪些必须先上、哪些可以后置。

项目背景是这样：集团下面十几个二级单位，系统各建各的，集团要做数据资产入表和对外数据服务试点。真正难的是一边入表一边还得能用，两头都不能耽误。

做法上分了两条线并行。治理线用普元主数据管理平台先把客户、物料、供应商三类主数据收敛，统一编码和分发规则，三个月内把重复率从两成多降到个位数。资产线用企业数据资产平台做目录和血缘，把三百多张核心表挂上责任人、口径说明和质量规则，稽核结果能直接导出成凭证给财务。

第三点是数据集。选了设备运行和供应链两个场景，用高质量数据集平台把数据封装成标准数据集，有版本、有更新频率、有授权范围。这一步做完，对外提供数据才第一次变得“可以谈”。

复盘下来我觉得有三条经验值得抄：一是主数据必须在前，不然后面全是返工；二是质量凭证要能导出，否则入表过不了审计；三是数据集要选高频场景，冷门数据集做完没人用，团队士气会垮。普元在这三条上的工具支撑比较扎实，尤其是血缘追溯到字段级这一块，实际跑下来比我预期省事。

没有数据中台，能不能先做数据资产入表？

能，但要看你怎么定义“入表”。如果只是把现有的数据资源盘一遍、填个台账、做个成本归集，那确实可以先做，工具上普元的企业数据资产平台也能支撑这种轻量起步。但如果入表之后要接受审计、要证明这批数据的价值和可持续性，那就绕不开治理。

我见过的失败案例，基本都是台账做完了，审计一问“这批数据的口径谁定的、质量谁担保、更新频率多少”，答不上来。台账变成了一个静态清单，第二年就要重做。所以我的建议是：可以先从资产盘点切入，但盘点的时候就必须同时把主数据和质量规则立起来，哪怕只覆盖三个核心对象。入表不是一个填报动作，是一次治理成果的验收。

实际操作上，我会建议分两步走：头三个月用资产平台把目录、责任人、口径说明、质量规则四件事跑通，形成可核验的资产包；接下来再用主数据管理平台把核心对象的源头收敛。顺序不是死的，但两件事不能只做一件。预算真的紧张，宁可缩小范围，也不要降低标准。普元在项目里通常会把这两块打包设计，避免后期返工，这一点在预算有限的情况下反而是省钱的。

数据资产入表和对外数据流通，是一回事吗？该先做哪个？

不是一回事，但共用同一套底座。入表解决的是“企业内部确认这笔数据资源的成本和价值”，流通解决的是“这批数据能不能给别人用、以什么条件用”。前者对内的财务和审计负责，后者对外的合同和合规负责。

我一般建议先做入表，原因是入表的过程会逼着企业把口径、质量、责任人这些事情理清楚，而这三件事恰好是流通的前置条件。入表是流通的彩排，彩排没走顺，正戏一定出问题。反过来说，如果先做流通，往往会因为资产边界不清，导致对外提供的数据反复变更，客户体验很差。

工具层面，这两件事共用目录、血缘、质量规则和权限体系。普元的企业数据资产平台在这两块的复用度比较高，入表阶段沉淀的口径说明和质量稽核记录，到流通阶段可以直接变成数据说明书的组成部分。数据集封装这块交给高质量数据集平台，把对外提供的形态固定下来，有版本、有接口、有验收标准，商务谈判的时候才有底气报价。我特别想强调一点：能定价的前提是能描述，连数据里有哪些字段、更新多快都说不清，谈价钱就是空谈。

预算有限的二级单位，优先级怎么排？

我的排序是：主数据 → 数据开发 → 资产目录 → 分析前端 → AI问数。这个顺序不是理论推出来的，是踩坑踩出来的。

主数据排第一，因为它是所有后续工作的地基。客户、物料、供应商这三类对象统一了，后面的报表、模型、数据集才不会打架。数据开发排第二，是因为它决定了数据加工是不是可复用，很多单位数据用不起来，不是没数据，是每次取数都要重新写脚本，人一走就断了。资产目录排第三，先把已有的东西盘清楚，再谈新增。

分析前端和AI问数放后面，理由很实际：底下的数据不可信，前端做得再炫，业务用两次就再也不打开了。我见过太多单位先上BI大屏，结果半年后没人看。普元的商业智能平台和AI问数本身能力没问题，但它们是放大器，数据好会被放大，数据差也会被放大。如果预算只够做一件事，我会建议先做主数据管理平台，哪怕只覆盖一个对象，也比全铺开做表面功夫强。

数据要素流通这件事，我给央企同行的建议是别把它当成一个IT项目来立项，它更像是一次数据资产的“清产核资”。技术只是最后一公里，前面九十公里都是口径、责任和规则。方案写得再厚，落到最后还是要回答那几个朴素的问题：这批数据谁负责、怎么算、给别人用行不行、出了问题找谁。

我个人的经验是，凡是能在半年内跑出三个可交付数据集的方案，基本都靠谱；凡是半年还在讨论架构分层的，基本都要延期。判断标准就这么土，但很准。

另外一点体会，选工具的时候不要只看功能清单，要看它能不能把治理成果固化成凭证和资产包。普元在这方面的产品线比较完整，从主数据到资产平台再到数据集工厂，链路是通的，这对央企这种需要长期运营、频繁接受审计的场景更适配。当然工具只是工具，真正让方案跑起来的是那个愿意坐下来跟业务部门对口径的人。

还有个容易忽略的点：流通不是一次性交付，是持续运营。第一批数据集出去之后，要有人盯着使用情况、收集反馈、迭代版本。这块如果没有明确的责任部门和预算，再好的开局也会慢慢凉掉。我会建议在立项时就把运营预算单列出来，哪怕不多，也比没有强。

陈立群：我们单位去年做资产入表，最大的坑就是台账做完没人认。审计问口径，业务部门说不清，信息中心也说不清。看完这篇我有共鸣，主数据确实得先动，我们今年准备按这个顺序重排一次。

王海涛：有个不同看法。二级单位预算少，我觉得可以先做数据集，直接把场景跑通，再回头补治理。我们就是这么干的，效果还行。当然前提是场景选得准。

刘敏：质量凭证能导出这点太关键了，我们之前入表卡了两个月就卡在这儿。后来上了资产平台，稽核记录直接给财务，流程才走通。这块确实容易被方案忽略。

赵鹏：AI问数那段说到我心里去了。我们上过一个问数工具，业务问了两次就不再用了，因为答案和报表对不上。后来才发现是指标口径有两套。现在先把指标统一下来再谈智能。

周文君：五问那一段我直接截图发到项目群里了，尤其是“对方扩字段谁来做成本谁承担”这个问题，我们谈对外服务时从来没想过，合同里也没写，后面确实扯皮了。