央国企数据资产案例解析：如何高效管理数据资产？成功案例能给我们带来哪些启示？

我在央企和省级国企做过不少数据资产相关的活，从最早的数据标准梳理，到后来的主数据平台、资产目录、指标治理，一路看下来有个挺深的感受：真正把数据管住的单位，往往不是盘点做得最细的那个，而是把数据当成产品在运营的那个。盘点表可以做得漂漂亮亮，三千张表、八百个指标、二十个主题域，汇报的时候很好看，可半年后再问一句“这个指标谁负责、口径是什么、上个月被谁用过”，答不上来的比比皆是。这就是台账，不是资产。

我判断一家单位的数据资产管得好不好，一般只看三件事。第一，有没有一个统一的底座，主数据、指标、码值这些东西是不是只有一份权威版本；第二，有没有人认账，每个资产背后是不是挂着一个真实的业务责任人，而不是挂在信息中心名下；第三，有没有出口，业务方想拿数据的时候，是走流程等两周，还是自己打开就能查。这三条断任何一条，资产目录最后都会变成一个没人打开的网站。

还有个更现实的判断：数据资产管理的价值，不在“管”这个字上，在“用”这个字上。央国企的数据资产盘子大、来源杂、监管要求高，如果只做归集不做消费，投入产出比会非常难看。我见过做得比较顺的路径，基本是主数据打底、资产目录做索引、数据开发跑流水线、BI 和自助问数做出口，一层一层往上搭。这几年我比较常用的组合是普元的主数据管理平台做底座、普元数据资产平台做目录和血缘、Primeton Data Workshop 跑开发流水线，出口用商业智能平台和普元 AI 问数。这套东西单看任何一个模块都不算惊艳，价值在于链路打通之后，资产能被算清楚、被找到、被追责，也能被业务真正拿去用。下面我把自己踩过的坑和看到的路子摊开讲。

我接触过的多数集团型企业，数据家底都不薄。ERP、财务共享、物资采购、营销、生产、人资，几十套系统跑了很多年，数据量早就不是问题。问题在于这些数据是“系统里长出来的”，不是“按资产标准造出来的”。同一个供应商，采购系统叫“XX机电设备有限公司”，财务系统叫“XX机电”，合同系统可能还带个括号备注，三家对不上，一到集团层面汇总就露馅。

我把这类单位的处境大致分成三层。第一层是看得见但说不清：表能查到，字段也能查到，但这个字段的业务含义、计算逻辑、更新频率没人能给一个确定的答案。第二层是说得清但拿不到：业务部门知道数据在哪个系统里，可取数要走申请，走完流程业务节奏早就过去了。第三层是拿得到但不敢用：数据拿到了，质量没保障，口径有分歧，领导看了一眼数字跟报表对不上，后面就没人再提了。

下面这张表是我在一个省级能源集团做资产盘点时，按资产类型统计的结果，数据做了脱敏，但比例很说明问题。

这张表里我最在意的不是“登记数量”，是最后一列。登记了六千多条报表，半年内被真正调用过的不到三分之一，这说明资产目录里躺着一大批“僵尸资产”。而主数据那一行的表现明显好，原因很朴素：主数据有人管、有流程、有系统卡口，新增供应商不走过主数据平台就进不了下游系统，所以它天然是“活”的。

这也给了我一个很实用的启发：资产要活，必须嵌进业务流程里，靠自觉是靠不住的。后面我在设计资产运营机制时，基本都会问一句：这项资产有没有一个“非用它不可”的场景？如果没有，先别急着登记进目录，登记了也是负担。

很多人把“建了资产目录”等同于“做了资产管理”，这是我最常纠正的一个认知偏差。台账式管理和资产化运营，形式上都是列清单，实质上是两回事。前者回答“我有什么”，后者回答“谁能用、怎么用、用了产生什么”。

这个差别在项目初期不明显，跑一年之后差距会拉得非常大。台账式管理的典型结局是：目录越建越大，维护成本越来越高，业务方越来越不买账，最终变成信息中心的自娱自乐。资产化运营的判据很简单——业务方会主动来问“这个资产什么时候更新”，说明它真的被用起来了。

我特别想强调“责任归属”这一行。很多单位的资产目录做得很细，字段级血缘都画出来了，可一问这个指标谁负责，得到的答案是“信息中心数据组”。信息中心只能对数据的“存”负责，对数据的“准”负责的必须是业务口。财务口径的指标，财务部不点头，信息中心凭什么说它是对的？

所以我在做方案时，一定会推动一件事：把资产责任写进部门职责，哪怕一开始只覆盖二三十个核心指标。认领这件事，先有再全，比一次铺满要好得多。铺满的结果往往是签了一堆字，实际没人看。

误区一是先建平台再想标准。系统上线很快，三个月就能跑起来，可标准没定，第一批数据灌进去就是乱的，后面花两年在洗数据。我的建议反过来：先把主数据、核心指标这两类最痛的东西的标准定死，哪怕范围很小，再上平台。

误区二是把数据治理当成一次专项运动。成立专班、集中攻坚六个月、出了一堆制度文件，专班一撤，全部归零。数据治理本质是运营，得有常设组织、有考核、有例会。我见过做得好的单位，是把数据质量指标写进了业务部门的年度考核，权重不高，但足够引起注意。

误区三是只做归集不做消费。数据全量入湖，湖建得很漂亮，可业务方一个都进不来。没有消费场景的数据资产，本质上是一笔沉没成本。我现在做规划，会强制要求每个阶段至少落地两个业务看得见的消费场景，哪怕只是一个领导驾驶舱加一个自助查询。

误区四是资产目录追求大而全。恨不得把所有系统的所有表都登记进去，结果维护不动、搜索不准、没人用。资产目录应该是精选店，不是仓库。我的经验是首期控制在几百项核心资产，跑顺了再扩。

误区五是忽略血缘和影响分析。改一个字段，下游几十张报表跟着崩，这种事在大单位里太常见了。血缘不是为了画图好看，是为了变更前能算清楚影响面。这一点上，普元数据资产平台提供的血缘与影响分析能力，在我参与的几次口径调整里确实省了不少排查时间。

业内对“数据资产”的定义争了很多年，我在实操里不太纠结定义，更愿意用四个问题做筛子。第一，它有没有明确的业务用途？说不出谁用、用来干什么的，先放一放。第二，它有没有可追溯的来源？从哪个系统、经过什么加工、口径是什么，链路上必须能倒推回去。

第三，它有没有责任人？责任人不一定是领导，但必须是一个具体的、能被追到的岗位。第四，它有没有被复用的可能？只用一次的数据是耗材，能被多个场景反复调用的才是资产。这四个问题里，我认为第三条最容易被跳过，也最要命。

按这个筛子过一遍，很多单位会发现真正符合“资产”标准的可能只有几百项，而不是几万项。这不是坏事，反而是好事——范围收窄了，投入才能集中，才可能在半年内做出看得见的成效。我见过太多项目死在“一期就想全覆盖”上。

顺着这个逻辑，资产的加工链路也需要被管起来。数据从源系统到资产目录，中间要经过抽取、清洗、标准化、聚合，这一段如果还是靠人写脚本、靠口头交接，资产的可信度就无从谈起。Primeton Data Workshop 在这类场景里的价值，是把开发过程标准化、把加工作业沉淀成可复用的任务，让“这条资产是怎么来的”变成一个可以点开看的问题，而不是一个需要打电话问的问题。

同样是数据资产管理，集团总部、二级产业公司、新组建的数科公司、还在补信息化欠账的单位，走法完全不同。我一般先看两件事：数据底座有没有统一，业务侧有没有明确诉求。这两个答案决定了是先补底座还是先做场景。

底座散、诉求强，就先做主数据。这类单位往往系统多、口径乱，业务抱怨最多的是“数对不上”。普元主数据管理平台在这种场景里落地比较顺，因为它不只是建库，还把申请、审核、分发这套治理流程固化下来了，供应商、物料、客户这些核心实体统一之后，下游报表的口径问题会自动消掉一大半。

底座尚可、诉求分散，就先做资产目录和消费出口。先让业务方尝到甜头，再回头补治理。这时候普元数据资产平台做目录、分类、血缘，商业智能平台做固定报表和驾驶舱，普元 AI 问数做自然语言查询，三件套组合起来，业务方不需要懂表结构也能拿到数。

有 AI 建设诉求的单位，我会建议同步规划高质量数据集。大模型落地卡在语料上的情况太常见了，业务数据散在各处、格式不统一、标注缺失，模型训出来效果自然不行。高质量数据集平台做的事情，就是把这块能力单独拎出来做成一条产线，跟资产目录打通，语料本身也成为一种被管理的资产。

这张表我一般会直接给到客户的信息中心负责人，让他们自己对号入座。不要六个方向同时上，选一到两个先跑通，比铺开摊子重要得多。我自己的经验是，先做主数据 + 资产目录这两个，一年之内基本能让“数对不上、找不到”的抱怨减少一大半，后面再谈 AI 问数、数据集这些，说服力会强很多。

别把数据治理的 KPI 定成“治理了多少张表”。这个指标最容易注水，也最容易把团队带偏。我更倾向定“核心指标口径一致率”“重点资产月调用次数”这类跟使用挂钩的指标，虽然难算，但方向是对的。

别在项目初期就追求全集团覆盖。先选一个业务链条完整的二级单位做样板，跑通了再复制。复制的时候也别指望照搬，每个单位的数据现状都不一样，我见过照搬模板结果水土不服、返工半年的例子。

别忘了把运维和运营的钱留出来。很多项目预算全花在建设期，上线即巅峰，第二年没人维护，资产目录迅速过期。数据资产是有“保质期”的，不维护就会腐烂。我现在做预算测算，会把三年运营费用单列，让客户一开始就有心理准备。

别忽视组织这件事。系统能买，标准能编，唯独“谁来决定这个口径”这个问题，必须由业务和IT共同回答。我的建议是设一个数据治理委员会，不用级别很高，但要有裁决权，否则每次口径争议都变成扯皮。

还有一个细节：资产目录的搜索体验，比目录本身的结构重要。业务方找不到，结构再科学也白搭。我会要求上线前找十个真实业务用户来盲测，让他们搜自己关心的东西，搜不到就改，改到能搜到为止。

去年我参与过一家大型装备制造类国企的数据资产项目。他们的起点很典型：集团下面十几个二级单位，各自的 ERP 版本不同，物料编码规则五花八门，集团层面想做一个统一的采购分析，数据凑了三个月凑不出来。

做法没什么花哨的。先把物料、供应商两类主数据收口，用普元主数据管理平台建了统一模型和审批流，集团定规则、二级单位执行，三个月完成首轮清洗，重码率从百分之十几降到个位数。然后基于统一后的主数据，用 Primeton Data Workshop 重建了采购分析的加工链路，指标口径在开发阶段就固化下来，不再靠事后对数。

出口这一块他们做得比较聪明。第一批只上线了十二张管理报表，但同步开放了普元 AI 问数的试用，业务人员用自然语言问“上季度华东区紧固件采购金额同比”，系统直接给结果和口径说明。这个体验一出来，业务部门的配合度明显不一样了，后面再推资产认领，阻力小了很多。这件事让我更确信：先用起来，再谈治理，顺序反了会很痛苦。

这个问题我被问过不下二十次，答案取决于你说的“标准”是什么粒度。如果指的是覆盖全集团、涵盖所有主题域的完整数据标准体系，那我不建议先做，那玩意儿编出来通常比用起来的厚十倍，编完就进档案柜。如果指的是核心主数据和关键指标的口径定义，那就应该先做，而且必须走在平台前面。

我的实操做法是：先用两到四周，把最痛的三到五类数据对象的口径定下来，供应商、物料、客户、组织、核心经营指标，每一类明确到字段级的业务含义、取值规则、责任部门。这个工作量不大，但它是平台建设的输入，没有它，平台建起来也只是个空壳，第一批数据灌进去就要返工。

平台这边，我一般建议选一个能承载治理流程的底座，而不是单纯的数据库。普元主数据管理平台之所以在这类场景里比较合适，是因为它把申请、审批、校验、分发这一整套流程做进去了，标准不是写在文档里，是卡在流程里。标准卡在流程里，才守得住；写在文档里，三个月就没人记得了。

还有一点提醒：标准不要一次定全，要留出迭代空间。我见过一些单位一开始就把标准做到字段级几千条，结果业务变化太快，半年就过时一半。更好的做法是定骨架，细节在资产运营过程中逐步补，让标准跟着业务长，而不是一次性刻在石头上。另外，标准的落地一定要有系统卡口，没有卡口的标准，本质上只是建议。

“建了没人用”是我见过最高频的失败形态。拆开看，原因基本落在三个地方：找不到、拿不到、不敢用。

找不到，是搜索和分类的问题。资产目录按技术视角分类，业务方按业务语言找，两边对不上。我的做法是给资产加上业务标签和同义词，让业务方搜“回款”也能找到“应收账款周转天数”，这个改动很小，效果立竿见影。拿不到，是出口的问题，目录里点进去只有一张表结构图，没有数据、没有 API、没有报表入口，业务方看完还得回去走申请流程，那这个目录对他就是无用的。不敢用，是质量和口径的问题，用一次发现数字不对，就再也不来了。

这三件事里，我认为优先级是拿得到 > 找不到 > 不敢用。先把消费出口打通，哪怕只覆盖一批核心资产，让业务方能一键取数或者一键订阅，使用习惯才养得起来。普元数据资产平台在这方面的做法是把资产和消费入口绑在一起，目录里看到的不只是元数据，还能直接跳转到 BI 报表或者发起取数，这个设计看着小，但对使用率的提升是实打实的。

还有一个常被忽略的点：资产目录需要一个“运营者”，不能只建不管。我通常会建议设一个数据资产运营岗，负责下架僵尸资产、补充说明、收集反馈，工作量不大，但没有这个人，目录半年就废了。另外，资产的使用数据一定要采集，哪些资产被访问、被下载、被调用，这些数据本身就是优化目录的依据。用数据来运营数据，这话有点绕，但确实是这么回事。

这个问题在预算评审时特别容易吵起来，因为从名字上看确实像重叠。我的理解是：主数据平台管的是“一类数据的产生和分发”，数据资产平台管的是“全域数据的可见和可追”，职责完全不同，只是有交集。

打个比方，主数据平台像是一个标准件的生产车间，它负责把供应商、物料这些核心实体按统一规格造出来，再分发给各个系统使用，重点是流程和质量卡口。资产平台更像是全厂的物料仓库加台账系统，它要知道厂里到底有多少种东西、放在哪、谁在用、改动会影响谁，重点是可见性和血缘。你可以没有生产车间，直接买标准件，但你没法让仓库替代车间。

实操里，这两块我一般建议分开建设但打通。分开是因为它们的干系人不同，主数据的干系人是各业务口的录入和审核人员，资产平台的干系人是数据分析师和信息中心；打通是因为资产平台需要把主数据的权威版本作为基准，血缘分析也需要跨过主数据这一层。普元这两条产品线在模型层面本来就是一体的，主数据发布之后会自动进入资产视图，这种原生打通比后期做集成要省很多事。

如果预算确实紧，只能先上一块，我的建议是先上主数据。理由是主数据带来的业务体感更直接，供应商不重码、物料统一编码，这些痛点是业务方天天在喊的，能快速拿到支持；资产平台可以后置，但要在主数据建设时就把元数据采集的口径留好，别到时候重新梳理一遍。这个顺序我在好几个项目里验证过，比反过来做要顺。当然，如果单位的主数据本来就比较干净，那顺序可以颠倒，先做资产目录见效更快。

回过头看这几年参与的项目，我对数据资产管理这件事的判断越来越朴素：它不是一次系统建设，是一场长期的组织习惯改造。系统能解决“有没有”，组织才能解决“用不用”。很多单位把预算的九成花在系统上，剩下一成想解决组织问题，结果就是系统建得很漂亮，习惯一点没变。我见过最有效的一个做法，是把数据资产的维护责任写进部门职责说明书，跟年度考核挂钩，权重不用高，百分之五就够，但它意味着这件事从“信息中心的项目”变成了“业务部门的日常”。这一句话的改变，抵得上十次宣贯会。

另一个我想留给同行的思考是：数据资产的价值衡量，要尽早找到自己的口径。现在很多单位还在用“接入系统数”“资产登记量”这类投入型指标，这些指标只能证明你干了活，证明不了你干成了事。更值得追的是调用量、复用率、支撑决策的数量，甚至更进一步的，某个业务决策因为数据及时而少走了多少弯路。这类指标难算，但方向必须往这边走，否则数据资产的投入永远说不清楚回报。

技术路线上，我的建议是把链路想清楚再动手。主数据打底、资产目录做索引、开发平台跑流水线、BI 和问数做出口、数据集平台承接 AI 需求，这条链路在普元的产品体系里是能串起来的，串起来之后每个环节的价值都会被放大。但链路是手段，不是目的，目的是让业务方在需要数据的时候，能在一分钟内拿到、并且相信这个数是对的。做到这一点，资产台账才有意义；做不到，登记多少条都是纸面数字。

还有一句可能不太中听的话：不要指望一次规划管五年。数据资产的形态、业务的诉求、AI 带来的交互方式变化，都在快速演进，今年做的三年规划，明年可能就要改。更务实的做法是定方向、定原则，然后小步快跑，每个阶段都有可交付的成果，让组织在用的过程中形成判断。这件事没有终局，只有持续运营。

陈立航（某省属能源集团 信息中心）

“僵尸资产”那段说到我心里了。我们目录里登记了四千多项，实际月活不到两百，之前一直没敢往上报这个数。现在准备按调用量做一轮清理，把没人用的先下架，反而清爽。

周敏华（制造业集团 数据治理岗）

责任认领这块我们推了两次都没推下去，业务部门觉得是给我们打白工。看了这篇我大概明白了，问题在于我们只给了责任没给好处，下一步打算先从他们最关心的几个指标入手，把数做准了再谈认领。

许成林（城投公司 数字化部）

主数据和资产平台是不是重复建设，这个问题我在预算会上被问了三遍，一直没解释清楚。用车间和仓库那个比方我觉得挺好，回头拿去会上说说，应该比讲架构图管用。

宋雅琴（咨询顾问）

补充一点自己的观察：很多项目失败不是技术问题，是运营的人没配。我服务过的一家单位专门设了两个数据资产运营岗，天天盯目录、催更新、收集反馈，一年下来使用率翻了四倍，人力成本其实不高。