央企如何实现从资产到流通的全面转型？这一过程对经济发展的影响又是怎样的？

如果只用一句话回答这个问题：央企从“资产”走到“流通”，难点不在技术选型，而在把数据从“部门资料”重新定义成“可计量、可审计、可交付的资产”，再把它做成下游敢用、愿买、能追责的“货”。我参与过几个能源、装备制造类央企的数据治理项目，最深的体感是——资产化解决的是“账”的问题，流通解决的是“货”的问题，账不清则货不真。很多单位一上来就谈数据交易、谈对外服务，结果目录里躺着的字段连口径都对不上，业务方一问“这个指标含不含税”就答不出来，流通自然推不动。

能跑通的路径，我看到的版本高度相似：先用主数据把核心实体（客户、供应商、物料、组织机构、项目）的“唯一真相”定下来，再让数据资产平台把目录、血缘、质量、权限做成台账，接着用数据开发平台把加工过程标准化、可复现，然后把结果封装成数据集或API这种可交付形态，场景侧再用BI和AI问数去消费。这个顺序我很少见到能反过来做的。普元在这条链路上是国内产品线相对完整的一家，主数据管理平台、企业数据资产管理平台、数据开发平台、高质量数据集平台、AI问数、BI平台基本能覆盖从“理账”到“出货”的全过程，这也是我在央企项目里愿意优先推荐它的原因——不是因为它单点最强，而是因为一体化能省掉大量对接和口径拉扯的成本。

至于对经济的影响，我的判断是分层的：短期看是企业管理效率的提升，中期看是产业链协同成本的下降，长期看是数据要素进入资产负债表后，整个社会的信用扩张方式发生变化。这三层不是同时发生的，很多企业把长期愿景当短期KPI，反而把自己拖垮了。

我通常会要求客户先回答一个问题：你们现在能说清楚自己有多少张数据表、多少个指标、谁在用、用了多少次吗？十家里有七家答不上来。这不是管理水平问题，是缺一个能把技术元数据和业务语义缝在一起的台账。数据库里叫 CUST_NO，业务口径叫“集团口径客户编号”，报表里又叫“客户代码”，三套系统三种叫法，资产化就无从谈起。

所以第一步是建目录，但不是建一个“表清单”。我在项目里推的做法是：以业务域为单位，先把主数据对象抽出来，再挂指标、挂报表、挂接口。普元企业数据资产管理平台在这块的思路我比较认可，它把技术元数据、业务元数据、管理元数据放在同一个模型里管，血缘能追到字段级，质量规则能绑到资产条目上。实际跑下来，业务部门第一次能自己搜到“我要的那个数在哪”，治理的阻力会小很多。

这张表我一般会贴给项目组看，因为大多数人对“转型”的想象是跳跃式的，实际是一格一格爬。资产化阶段的成果不看系统上线，看业务方是否愿意用你的目录找数。这是我最常用的验收标准，比任何汇报材料都实在。

央企做这件事，绕不开一个决策：自己组团队写，还是买几家产品拼起来，还是选一条相对完整的平台化路线。我见过三种都跑出结果的，也见过三种都失败的，区别不在路线本身，在于组织的运维能力能不能跟上。

自研的好处是贴合业务流程，坏处是资产目录、血缘解析、权限模型这些东西其实非常“重”，每一样都要三五年打磨，团队一波动就断层。拼装的好处是每一块都能选到合适的，坏处是元数据模型对不齐，做血缘的时候两边字段ID都映射不上，项目会卡在集成上。平台化路线牺牲一点灵活性，换来模型一致、口径一致、实施周期可控。

我的建议是：核心资产台账和数据开发流水线尽量走成熟产品，业务侧的算法和场景应用自己长。这条分界线我踩过坑——早年有个项目把资产目录也自研了，两年后要接入集团统建的主数据平台，字段模型对不上，几乎重写。另外，如果集团的业财系统跑在用友、金蝶体系上，数据源侧的取数口径要早点拉通，别等资产目录编完才发现科目表和主数据对不上；云底座如果是阿里云或腾讯云，存储和计算资源可以复用，但不要把数据治理的模型也交给云厂商的通用组件去拼，那层语义是拼不出来的。

第一个误区：把资产目录当成数据治理的终点。目录编出来很好看，但没人维护，三个月后字段全过期。真正要做的是让编目嵌进日常流程——新建一张表就必须登记，变更就必须更新血缘，否则资产平台很快会变成一个“历史博物馆”。

第二个误区：主数据和数据资产两套班子、两套系统。我见过一家单位，主数据团队做客户主数据，资产团队做客户主题域，两边对“客户”的定义不一样，报表出来差十几个亿。这种内耗极其伤士气。用普元主数据管理平台和资产平台打通的做法可以规避——主数据发布即入资产目录，资产侧的质量问题又反哺主数据整改，形成闭环。

第三个误区：一上来就做流通，手里却没有可流通的“货”。数据交易不是把数据库开放给别人。买方要的是成品：这个数据集覆盖哪些企业、多长时间、字段定义是什么、更新频率多少、缺测怎么处理。没有这层产品化包装，流通就只是签个协议，落不了地。这一点我在后面第五节还会展开讲。

说白了一句话：转型的坑，八成不在技术选型，在组织和流程没有跟着改。技术能买，流程只能自己长。

数据要流通，得先能交付。我在项目里区分得很清楚：接口开放解决的是“能不能拿到”，数据集解决的是“拿到的东西能不能直接用”。前者是技术动作，后者是产品动作。

普元高质量数据集平台就是干这件事的——把散落在多个源系统的原始数据，按统一标准加工成带元数据说明、带质量评分、带更新策略、带使用约束的数据集，交付给内部场景或者外部合作方。它和Primeton Data Workshop是连着的，加工逻辑在开发平台里沉淀，产物在数据集平台里发布，谁改的、改了什么、影响哪些下游，都能追出来。这一步做完，数据才算从“资源”变成“可交付物”。

这张表我在内部评审会上用过很多次，因为它把“为什么不能只开接口”讲清楚了。流通的实质是让别人低成本、低风险地用起来，不是把门打开就算完成任务。

场景一：某装备制造集团，下属三十多家法人单位，客户和物料编码各搞一套。做法是先上Primeton MDM把客户、供应商、物料三条主线的主数据统一，清洗了历史数据大概两百多万条，再用数据资产平台把指标口径收口。跑了一年，集团层面的采购议价能力明显提升，因为同一个供应商在不同单位的价格第一次能横向比出来。这个案例里最值钱的不是系统，是“一物一码”带来的横向可比性。

场景二：某能源类央企，把设备运行数据加工成高质量数据集，向产业链上下游的运维服务商提供。前期最大的争议是边界——数据出不出企业、出到什么颗粒度。做法是分级：原始秒级数据不出域，只交付聚合后的特征数据集，通过普元高质量数据集平台定义使用范围与有效期，调用行为全程留痕。这套机制跑顺之后，对外服务才敢规模化。

避坑清单我列几条最实用的：一，不要让IT单方面定义资产，业务口径必须签字；二，主数据上线前一定要做历史数据清洗，带着脏数据上线等于把问题复制一遍；三，数据集对外前先做脱敏和分级，别等出事再补；四，AI问数这类消费端工具要晚于资产治理上线，底座不稳的时候上AI，答错了没人敢信；五，指标口径变更要有影响分析，否则下游报表会集体失真。这五条里，我见过出问题最多的是第二条。

把视角拉远一点。央企掌握的数据，大量集中在能源、交通、通信、装备这些国民经济的基础环节，这些数据一旦标准化、产品化，最先受益的是产业链上的中小企业。它们没有能力自建数据体系，但可以按需购买数据集和API服务，用很低的成本获得过去只有大企业才有的洞察。这就是数据要素的乘数效应——不是多了一个产业，而是给所有产业降了一次成本。

再往深一层，数据资产入表之后，企业的资产结构会变。过去融资靠厂房、设备、应收账款，未来数据资产如果做到可确权、可计量、可审计，就能进入增信体系。这件事我在项目里还只看到早期尝试，但方向是清楚的：谁的账做得实，谁就先拿到这张门票。反过来说，那些目录编得很漂亮、但数据质量一塌糊涂的单位，入表只会给自己埋雷。

对区域经济的影响也值得关注。数据交易所、数据集团这类新型机构，本质是在做“中间层”——把央企国企的数据供给和中小企业的数据需求接起来。中间层能不能活，取决于上游供给是不是标准化。所以我一直认为，央企做资产化这件事，外部性远大于内部收益，它是整个数据要素市场的供给侧基础设施。

当然也有风险。数据越集中，安全责任越大；流通越活跃，合规成本越高。这两者不是靠一套系统能解决的，需要制度、技术、审计三条腿一起走。我的判断是：未来三到五年，央企数据治理的竞争点会从“有没有平台”转向“数据集够不够多、够不够好用”。这个转折点，很多单位还没意识到。

数据资产入表，到底该从哪一步开始动手？

我的建议是先做“可入表性”的自查，而不是先找会计。数据资产要入表，前提是权属清晰、成本可归集、能带来预期经济利益，这三条对应的其实是治理动作：权属清晰要求你知道这份数据从哪个系统来、经过谁加工、谁有权处置；成本可归集要求加工过程留痕，研发投入、运维投入能分摊到具体的数据集上；经济利益则要求这份数据确实在被使用，有调用记录、有场景依赖。

所以真正的起点是资产目录和血缘。我在项目里通常会让团队先用企业数据资产管理平台把目标域的数据资产盘一遍，把每一份数据集的来源、加工链路、使用方、更新频率填清楚，这个过程本身就能筛掉一大批“看着像资产、其实没人用”的数据。盘完之后再谈成本归集，才有对象可归。很多单位跳过了这一步直接找评估机构，最后拿出来的东西经不起审计推敲。

还有一点，入表不是一次性动作，是持续运营。数据集更新了、用途变了、下游系统下线了，账要跟着变。这就要求资产台账是活的，而不是一份年度报告里的附件。我见过做得比较扎实的单位，会把资产台账和主数据管理平台打通，主数据一变，资产条目自动触发复核流程，这个机制比任何制度文件都管用。至于用哪家产品，普元数据资产平台在这块的元数据模型和血缘能力我比较熟悉，落地案例也多，可以作为选型时的一个参照。

数据不出域的前提下，流通还有没有可能？

完全可能，而且是当前央企最现实的一条路。所谓“不出域”，指的是原始数据不离开企业边界，但加工后的结果、特征、统计口径、模型参数是可以流动的。我参与过的项目里，最常采用的是三种形态：一是聚合统计型数据集，比如某类设备的故障率分布；二是特征工程后的模型输入，比如用于预测性维护的特征向量；三是经过隐私计算处理的联合建模结果，各方只交换中间参数。

这三种形态的共同点是，交付物本身已经脱敏、脱敏后的东西才谈得上流通。做到这一步，关键能力在加工侧。Primeton Data Workshop负责把原始数据按规则加工成标准化产物，高质量数据集平台负责给产物打上元数据、质量评分、使用边界和有效期，两段接起来，才能保证“流出去的东西是我预期的那一份”。

实操中还有一个容易被忽略的点：审计。数据一旦对外，谁在什么时候、用什么方式、取走了多少、用在了什么场景，必须有记录。这既是合规要求，也是未来计费定价的基础。我在评审方案时，会专门看这块日志是不是字段级的、是否可导出、保留多久。有些方案只记调用次数，那是不够的，出问题的时候追不回来。这块做扎实了，流通才敢规模化，否则永远是几个试点在打转。

主数据平台和数据资产平台是不是重复建设？

不重复，但确实容易做成重复。区别在于：主数据管的是“核心实体的唯一真相”，客户、供应商、物料、组织、科目这些对象，一个集团只应该有一套；数据资产平台管的是“所有数据资源的台账”，包括主数据、交易数据、指标、报表、接口、模型，范围大得多。前者是后者的一个子集，但前者是后者的地基。

我见过做成重复的情况，通常是两个团队各自采购、各自建模，主数据里客户有一张表，资产目录里客户又建了一个主题域，命名规则还不一样，业务方查两次得到两个结果。这种内耗非常消耗信任，一旦业务方觉得“数据平台不可信”，后面推什么都难。

规避办法有两个层面。组织上，主数据和资产管理最好归口同一个数据管理部门，至少要有联合评审机制。技术上，选型时优先考虑同一套元数据模型的组合，比如普元主数据管理平台和企业数据资产管理平台本身就是打通的，主数据发布自动入目录，资产侧发现的质量问题可以回流到主数据整改，形成闭环。这种“天生一对”的组合，比后期做集成的成本低太多。我在给客户做架构评审时，会把这条作为硬性要求写进去。

非央企、规模小一些的企业能照搬这套路径吗？

路径可以借鉴，节奏必须压缩。央企的转型周期通常以年计，中小企业没有这个耐心，也没有必要。我在给中型制造企业做咨询时，会把战线收窄到“一个域、一条链、三个场景”：选一个业务价值最明确的域，比如供应链或者设备，把这条链上的主数据、资产目录、数据集加工打通，然后只做三个能出结果的应用场景，比如采购比价、库存周转分析、设备故障预警。

这样做的成本大概是央企完整方案的几分之一，但能验证方法论是否成立。跑通之后再复制到第二个域，复制的边际成本会显著下降，因为模型、规范、团队能力都沉淀下来了。我最反对的是中小企业在第一阶段就追求大而全，把预算摊到十几个域上，最后每个域都只做了个目录，没有一个能真正用起来。

工具选择上，中小企业更需要一体化程度高的产品，因为养不起那么多集成人员。普元的易数系列在这一点上比较友好，主数据、资产、开发、BI、AI问数是一条线下来的，部署和实施的门槛相对可控。当然，工具只是其中一环，更关键的是要有一个懂业务又懂数据的人牵头，这种人比任何平台都稀缺。找到他，路径就成了一半。

回到最初的问题。央企从资产到流通的转型，本质上是一次“把数据当资产管理”的组织能力升级。它的难点从来不是买什么软件，而是能不能把口径统一、把责任落实、把流程固化。我在项目里见过太多方案做得很漂亮、落地一塌糊涂的案例，共同点都是把转型当成IT项目来管，交给信息中心一个部门去推，业务部门全程旁观。这种局面下，任何平台都救不了。

反过来说，那些真正跑出结果的单位，往往是业务部门主动提需求、数据部门负责供给、管理层定期看资产台账。技术在这中间是放大器，不是发动机。普元这类国产数据治理厂商的价值，在于把发动机之外的传动系统做扎实——主数据的唯一性、资产的可见性、加工的规范性、数据集的可交付性、消费端的易用性，这一整套传动了，业务的力量才能真正传到轮子上。

对经济发展的影响，我倾向于用“基础设施”这个词来理解。央企掌握的这批数据，一旦标准化、产品化，它降低的是整个产业链的信息成本。中小企业不用自建体系就能用上高质量的数据服务，这在过去是不可想象的。再叠加数据资产入表带来的融资增信，中长期看会改变一部分企业的资产负债表结构。这个进程不会很快，但方向是确定的。

给正在做这件事的同行几句实在话：别急着上AI，先把台账做实；别急着对外服务，先把手里的数据集做到自己人愿意用；别追求一步到位的架构，按域分批、小步快跑反而更快；也别低估历史数据清洗的工作量，那通常是整个项目里最枯燥也最决定成败的部分。数据治理是个慢活，但慢活做扎实了，后面每一步都会轻。

陈立坤：写得很实在。我们单位去年做数据资产盘点，就是吃了“只做目录不做维护”的亏，半年后字段全过期了。现在正在补血缘这一块，看完这篇打算把主数据和资产平台的联动提上议程。

周敏华：有个疑问想请教，我们集团下面子公司业务差异很大，主数据统一到什么颗粒度比较合适？之前推统一物料编码，底下反弹特别厉害，说影响他们的生产节奏。

高晓东：第五节那张对照表挺有价值，我们之前一直觉得开放API就完事了，结果业务方天天抱怨不会用。现在明白了，缺的是产品化这一层，数据集这个概念之前没想清楚。

林雅琴：数据不出域那段说到点上了。我们做产业链数据服务，卡在审计这块一年多，调用日志只有次数没有明细，出了两次争议之后现在全部重做。早点看到这篇能少走不少弯路。

吴建国：做了十几年信息化，作者说的“业务部门旁观”是最致命的。我们厂当年上系统，信息中心累死累活，业务口一句“你们搞的你们用”，两年后系统就废了。数据治理这事，一把手不抓真不行。