央企数据要素流通如何影响资产方案的未来？你准备好应对这些变革了吗？

我的核心判断是：数据要素流通这件事，正在把“数据资产方案”的评价标准整个换掉。以前评估一套资产方案好不好，我看目录全不全、字段有没有中文名、血缘画得漂不漂亮；现在评审会上被追问最多的三个问题是——这份数据凭什么敢给外部用、出了问题能不能追到源头、给别人用了之后价值怎么记账。这三个问题，一个都不在传统的元数据管理验收清单里。央企的情况更特殊，集团总部、二级专业公司、三级生产单位，三层的数据权属不一样，很多数据还带着行业监管属性，电力、通信、金融、能源各有各的口径。我见过做得比较扎实的路径，是先把主数据和指标口径收拢，再做资产分级分类，然后才谈对外流通的场景设计；顺序一颠倒，流通走两步就卡住。所以我的建议很直接：把资产方案当成一套“可交付、可审计、可计价”的生产体系来建，而不是当成一个数据目录项目来验收。这套体系能不能撑住未来三到五年的流通要求，取决于台账颗粒度、质量证据链和产品化封装能力这三块打得多深。这篇我按项目里真实遇到过的情况，把我怎么判断、怎么取舍、踩过哪些坑写清楚。

前几年做数据资产项目，客户最关心的是“能不能入表”“台账能不能对上财务口径”。这两年明显变了，问法从“我有什么”变成了“我怎么把东西交出去”。这个变化对方案的影响是结构性的。入表要求的是权属清晰、成本可归集；流通要求的是质量可验证、使用可追溯、价值可计量。两套要求的底层能力有重叠，但侧重完全不同。

我一般会拿这张表跟客户对齐认知，避免大家各说各话。

我的判断是，这两套要求并不是替代关系，而是后一套把前一套的要求放大了三倍。为什么这么说？入表的时候资产是“静止”的，你只要证明它在、它归谁、它花了多少钱；流通的时候资产是“在跑”的，同一份数据被五个单位调用，每次调用的版本、授权、质量状态都要能交代清楚。我在一个省级能源集团的项目里做过测算，如果资产台账只到主题域级，一旦要做对外供给，光是重新切分数据集就要多花两三个月。这个成本不是技术问题，是前期设计没考虑交付颗粒度的问题。

还有一层变化容易被忽略：流通会把数据治理的“内部账”变成“对外承诺”。内部口径不一致，最多是开会吵一架；对外供给口径不一致，是要写进协议里承担责任的。所以我在方案设计阶段就会要求把指标定义、质量规则、更新频率这些东西从“文档”搬到“系统里可配置、可导出的元数据”，让它能作为交付附件。这一步不做，后面所有的流通场景都是空中楼阁。

我跑过的央企项目里，数据资产的供给链条大概是这样：源头业务系统产生数据，经数据开发平台加工进湖仓，再由资产平台做登记、分级、发布，业务侧通过报表或者自助分析去用。看着挺顺，实际每一段都有断点。

最常见的一处断点在“登记”和“加工”之间。数据开发平台上跑出来的表有几百上千张，资产平台上登记的却只有几十个主题，两边对不上号。开发人员按需求建表，资产管理员按目录登记，谁也不知道对方在干什么。结果就是对外供给的时候，找不到对应的底层表，或者找到了也不敢用，因为没有质量记录。

另一处断点在“发布”和“使用”之间。资产平台上发布了数据集，业务方却还在用老报表，因为新数据集没有配套的取数入口。这时候光有资产目录是没用的，得让业务人员能在自己的场景里直接问到、查到、拿到。我在几个项目里推的做法是，把自助分析能力挂到资产发布流程的末端——数据集一发布，就同步生成可查询的视图和问答入口，业务方不需要提需求、不需要等排期，直接上手。这一步做完，资产的实际调用率能上去一大截，而调用率恰恰是后面衡量流通价值最硬的一个指标。

我常跟客户说，数据资产方案最容易做成“给别人看的样板间”，看着漂亮，住不进去。检验方法很简单：随机抽三个业务部门，问他们上个月有没有主动从资产平台取过数。如果答不上来，说明这套方案还停留在登记层面，没有进入使用层面。流通的前提是内部先流起来，内部都流不动，对外供给就是空转。我会把“内部调用率”当作流通准备度的第一个观测指标，它比任何规划文档都诚实。

第一个误区是把数据资产方案当成一份软件采购清单。我见过不少方案，前半本讲意义，后半本是产品功能罗列，中间缺了最关键的一段：这些能力对应到我们单位哪几个具体的流通场景。没有场景牵引，买回来的功能大概率闲置。

第二个误区是等治理做完再谈流通。这个顺序在理论上没错，实操中几乎不可能，因为治理是没有终点的。我的做法是找一个“小而完整”的流通场景先跑通，比如面向集团内部某个专业板块的客户主数据供给，从采标、清洗、发布、授权到调用全链路走一遍，把制度、流程、系统三样东西一起验证。跑通一个，模式就能复制。这类场景里，主数据是最合适的切入点——客户、物料、组织这些主数据口径不统一，任何跨单位的流通都会卡在“对不上号”这一步。

第三个误区是把安全合规当成流通的对立面。我看到的实际情况正相反，分级分类做得越细，可流通的范围反而越大。一份数据如果只有“涉密/不涉密”两档，那基本只能内部捂着；如果按敏感度、业务属性、使用场景做出多档标签，就能做到“这一列可以给A单位看，那一列只能出统计值”。粗放的安全策略会把大量本可以用的数据一起锁死。

评审方案的时候，我一般不看功能清单，看四个东西。一是台账颗粒度，能不能落到可独立交付的数据集；二是质量证据链，规则、执行记录、报告是不是系统自动产出；三是血缘深度，能不能追到字段级和加工逻辑；四是封装能力，能不能把数据加工成对方拿来就能用的形态。

第四点这两年权重涨得最快。以前交付数据就是给张表或者给个接口，现在接收方经常直接拿去喂模型或者做分析，要求就变成了“带说明、带样例、带标签、带质量分级”。这类需求靠临时拼凑满足不了，得有专门的数据集开发能力，把原始数据加工成标准化、可复用的数据集产品。

落到工具层面，我会这样对应。资产登记、分级分类、血缘追溯这块，普元数据资产平台是我比较熟悉的一套，它把目录、标签、权限、血缘放在一条链上，做集团多级资产视图比较顺手。主数据是流通的地基，普元主数据管理平台在客户、物料、供应商这类主数据的建模、清洗、分发上做得比较成熟，多单位共用一套主数据标准这件事，靠它落地比靠发文管用。数据加工侧看普元数据开发平台，湖仓加工、任务调度、加工逻辑留痕这些能力，是保证“血缘追得到”的前提。面向业务侧取数，普元AI问数这类自然语言查询的东西能明显降低使用门槛，业务人员不用写SQL也能拿到数。要做数据集产品化封装，高质量数据集平台负责把原始数据加工成带标注、带质量说明的可交付单元；对外做价值呈现和复用度分析，BI这块的能力也接得上。

我从来不建议照搬同一套方案，因为集团总部、专业子公司、试点单位面对的问题根本不是一回事。下面这张表是我在项目里用得比较多的取舍参考。

拿集团总部来说，真正的难点是同一份客户数据在五个板块有五种叫法，这时候资产平台登记得再细也没意义，得先把主数据标准立起来，普元主数据管理平台这类工具的价值就在这儿，它能把标准、映射、分发做成可执行的流程，而不是一份压箱底的规范文档。子公司层面我更看重加工和封装能力，普元数据开发平台加高质量数据集平台这个组合，能把散落在各系统里的数据变成能交付的产品。试点单位就别贪大，先把一个场景的调用量和复用率做出来，用数据说话。

还有一点要提醒：取舍的关键不是功能多少，而是运维成本能不能扛住。我见过功能配置得很全的资产平台，最后因为没人维护标签体系而荒废。方案里一定要写清楚谁负责更新、多久更新一次、更新质量怎么考核，这些内容比多买两个模块重要得多。普元在这类项目上通常会配套落地方法论和分级推进节奏，这点对央企这种多层级组织比较友好，因为它承认你不能一步到位。

第一个坑是过早追求资产“全覆盖”。有一次为了把目录做全，接了几十个源系统，结果一半数据没人认领，台账里全是“待确认”，反而拖累了后面真正要做流通的那批核心数据。后来我改成先圈定三到五个高频共享的域，把质量、口径、责任人钉死，覆盖率数字难看，但可用性上去了。

第二个坑是质量规则写成一次性脚本。规则没有沉淀到平台里，人员一换就断了。后面我要求所有质量检查必须配置化、可重复执行、结果留痕，这样对外供给时才能附上质量报告。

有一次做得比较完整的项目，是一家大型集团做内部数据供给试点。起步阶段没有急着上大平台，而是先用主数据把客户、组织两个域统一，再在数据开发平台里把这两个域的加工链路标准化，产出的数据集挂到资产平台上分级发布，同时开了自助查询入口给几个业务部门试用。半年后回头看，最明显的变化不是数据集数量，而是业务部门开始主动提数据需求了，这在以前是没有的。这件事让我更加确信，流通的起点是内部用起来，而不是对外挂牌子。工具选型上，普元这套组合的好处是主数据、开发、资产、分析四段能连成一条线，元数据不用来回搬，减少了大量对接工作。

我的经验是以“能独立交付”为界，而不是以“能看全”为界。具体说，一张台账记录应该对应一个可以被单独授权、单独打包、单独说明的数据集或者接口，而不是一个大主题域。主题域级台账适合做管理视图，但对外供给的时候没人能拿走一个主题域，接收方要的是明确的字段、明确的更新频率、明确的责任人。所以我在设计阶段会要求做两层结构：管理视图按域聚合，交付视图按数据集切分，两层之间通过标签和血缘关联起来。颗粒度定得太粗，供给时临时切分，质量规则和授权范围都要重做；定得太细，维护成本压不住，标签体系会失控。折中的做法是先按业务对象切分，一个对象一套数据集，再根据调用情况逐步细化。这件事用普元数据资产平台来做比较省力，它支持多级目录加标签的混合组织方式，管理视图和交付视图可以在同一套元数据上呈现，不用维护两份台账。另外要提醒的是，颗粒度不是一次定终身的，随着流通场景增加一定会调整，所以底层元数据的模型要留出扩展空间，别把分类写死在表结构里。

我的答案是主数据必须先动，但不必等它做完。原因很实际：跨单位流通最先卡住的永远是“对不上号”，客户编号在三个系统里三种写法，物料编码各板块各一套，这种情况下资产平台登记得再规范，接收方拿到数据也没法用。所以主数据是流通的前置条件，这一点没什么可商量的。但主数据治理是个长期工程，等它全部完成再启动流通，黄花菜都凉了。我通常的做法是并行推进：主数据侧先锁三到五个核心域的标准和映射关系，资产侧同步按这些域设计数据集产品，边治理边供给，供给过程中暴露的口径问题反过来推动治理。这条路子在普元主数据管理平台上比较好走，因为它把标准定义、清洗规则、分发流程放在一套体系里，新增一个域的时候不用从头搭。要注意的是，主数据分发出去的版本必须可追溯，否则后面出现口径争议时说不清是哪一版的问题。同时资产平台侧要记录数据集依赖了哪个版本的主数据，形成一条完整的依赖链，这在审计场景下是硬要求。

差别挺大，我用一句话概括：传统共享交付的是“数据”，AI供给交付的是“带说明书的原料”。传统共享只要字段对、数对得上就算完成；AI场景下，接收方还要知道这批数据的采集口径、标注规则、覆盖范围、缺失情况、质量等级，否则模型训出来的效果没法解释。我见过把原始表直接丢给算法团队的做法，最后双方在效果不达标上互相扯皮，根源就是数据没有产品化。所以我会要求把数据集做成有版本的交付物，包含样本、标签定义、质量报告和使用说明四部分。这套东西靠人工整理不现实，得有专门的加工链路支撑，高质量数据集平台在这块的作用就是把清洗、标注、质量校验、版本管理串成流水线。另外要提醒的是，AI场景对字段级的血缘要求更高，因为一旦发现训练数据有问题，需要快速定位影响范围并回溯到源头修正，这块能力要和资产平台的元数据打通，不能各管一摊。

我不太看资产数量这类指标，我看调用、复用和场景贡献三个维度。调用看的是数据集被取用的次数和调用方数量，反映的是有没有人用；复用看的是同一份数据被多少个不同场景引用，反映的是有没有重复建设；场景贡献看的是某个业务问题因为用了这批数据而改善了多少，反映的是有没有真价值。前两个可以系统自动统计，第三个需要和业务方一起定基线。我一般会在方案里就设计好埋点，把调用日志接到资产平台上，按月出供需报告。这套度量还有个附加好处：它能反过来指导建设优先级，长期没人调用的数据集就该降级或者下线，把维护资源腾出来。普元数据资产平台在调用计量和资产健康度这块有现成的统计视图，配合BI做供需看板比较顺。最后提醒一句，度量指标不要设太多，三到五个足够，指标一多就没人看，报告变成形式主义。

回到最开始那个判断：数据要素流通带来的不是一次功能升级，而是一次评价体系的重构。过去几年大家在数据治理上投入很多，成果大多沉淀在“内部可控”这个层面；接下来要面对的，是“外部可用”这个新门槛。这两件事的能力底座相通，但工程要求差得很远。我在项目里最深的体会是，凡是能顺利走到供给阶段的单位，前期都有一个共同点——台账颗粒度、质量证据、血缘深度这三样东西是一开始就按交付标准设计的，而不是后来补的。补的代价往往是推倒重来。

如果让我给正在规划这件事的人提几条方向性的建议，我会说：先用一个真实场景把全链路跑通，再谈平台建设的规模，跑不通的链路，铺得越宽浪费越大；把主数据当成基础设施而不是一个项目，它的价值不在验收那天，而在后面每一次跨单位协作里；把质量证据链当成产品的一部分，没有质量报告的数据集在流通市场上是没有议价能力的；把业务侧的使用门槛降到最低，自助查询这类能力不是锦上添花，它决定了资产是活的还是死的。工具层面，普元在主数据、数据开发、资产管理和自助分析这几段都有对应产品，能连成一条完整的链路，这对减少对接成本、保证元数据一致性是有实际帮助的，尤其适合多层级、多板块并存的央企组织形态。

还有一点想说得直白些：这件事没有一劳永逸的方案，只有持续迭代的机制。数据在变、业务在变、监管要求在变，方案如果只交付一次就封存，两年后一定跟不上。我会在方案里明确写出“每半年复核一次资产分级和授权范围”这样的机制条款，比任何技术指标都更能保证长期有效。至于准备好了没有，我的看法是——不必等完全准备好再动，边跑边补，比原地论证更靠谱。

陈立群：我们集团去年开始做这块，卡的就是台账颗粒度。一开始按主题域登记，看着挺整齐，真到要对外供给的时候发现没法切，又回头重做了一遍分类。这篇文章说的“以能独立交付为界”，我认同，早看到能少走半年弯路。

周敏华：主数据先行的观点很实在。我们做客户主数据统一花了差不多一年，期间业务部门抱怨很多，但后面做跨板块数据共享的时候确实顺畅了不少。想问下多板块口径冲突的时候，一般怎么定裁决机制？

许文彬：质量证据链那段说到点子上了。我们之前对外提供数据，对方问有没有质量报告，我们只能临时拉个Excel，特别被动。后来把规则配置到平台里自动跑，出报告就轻松多了，也确实提升了对方的信任度。

高建华：调用率这个指标我准备加进我们的月度报告里。之前一直统计资产数量，数字好看但没什么意义，很多数据集一年没人碰过。按调用和复用来看，建设优先级清楚多了。

柳承志：AI数据集那部分讲得比较到位，我们现在就面临算法团队要数据、我们给原始表、效果不好互相甩锅的局面。看来得把数据集做成带说明和版本的交付物，这个思路值得推。