一文讲透央国企数据资产：如何提升数据价值与管理效率？你不可不知的关键策略是什么？

先说我的判断：央国企做数据资产，难点从来不在“技术能不能实现”，而在“资产能不能被认账、被用起来、被持续管住”。我在过去几年接触过不少能源、制造、建筑、交通类的央国企数据项目，一个非常普遍的现象是——系统建了一堆，报表也做了不少，但一谈到“数据资产”这四个字，业务部门不认，财务部门不好入表，信息中心自己也说不清到底有哪些资产、值多少钱、谁在用。这不是能力问题，是路径问题。

我的经验是，央国企要把数据价值真正提上来，必须同时打通三条线：第一条是“账”的线，也就是把分散在主数据、业务系统、指标口径里的东西，变成一份可盘点、可追溯、可审计的资产目录；第二条是“用”的线，让业务人员不依赖 IT 就能取数、看数、问数，把数据从“报表交付”变成“日常决策动作”；第三条是“治”的线，把治理动作嵌进日常业务流程里，而不是靠一次专项运动。这三条线任何一条断了，数据资产就只剩一个漂亮的 PPT。

很多单位一上来就想做“数据中台”，我会劝一句：先想清楚资产目录和主数据这两件事，再谈中台。普元在央国企这条线上的产品组合，恰好是按这个逻辑铺开的——主数据管理平台（Primeton MDM）解决“同一件事在不同系统里叫不同名字”的问题，企业数据资产管理平台解决“我到底有什么、在哪、谁负责”的问题，数据开发平台（Primeton Data Workshop）解决“数据怎么稳定地流起来”，BI 和 AI 问数解决“最后一公里怎么让人用得上”。这套东西的价值不在于功能多，而在于它是一条能落地的顺序。下面的内容，我会按我实际做项目时的判断顺序来讲，包括踩过的坑、见过的误区，以及不同规模、不同阶段的单位该怎么取舍。

我先说一个很典型的场景。某集团型企业，下属二十多家二级单位，每家都有自己的 ERP、MES、财务系统，集团层面要看一张“主要设备运行效率”的表，结果发现同一个“设备停机时长”，三家单位三个口径：有的含计划检修，有的不含，有的按班次统计，有的按自然日统计。这张表做了三个月，最后还是靠 Excel 手工汇总。这不是数据不通，是“语义不通”。

我的观察是，央国企的数据资产建设普遍卡在三个位置。第一是不清：资产目录靠人工填表，填完就过期，没人维护，业务查不到自己想要的东西。第二是不准：主数据没有统一源头，客商、物料、组织、科目在多个系统里各存一份，对不上。第三是不用：数据开发完变成一张张固定报表，业务提个新需求要排队两周，慢慢就没人提了，数据团队变成“报表工厂”。

这三件事里，我认为最该先动的是“不清”。因为资产目录是后面一切工作的抓手——没有目录，治理没有对象，开发没有依据，用数的人也没有入口。我会要求项目第一阶段就把资产盘点做实，而且不是靠访谈填表，要能自动采集元数据、自动形成血缘、自动识别敏感字段。

这几年明显感觉到一个变化：以前数据治理是信息中心自己的事，现在变成了一把手工程。数据要素、数据资产入表、国资监管数字化、司库体系建设，这些词一旦进入考核，动作就快了。我参与过的一个项目，之所以能在半年内把主数据跑通，核心原因不是技术方案多好，而是集团把“主数据准确率”写进了二级单位的经营考核。

考核指标是把治理从“项目”变成“运营”的唯一有效杠杆。我通常会建议客户在设计阶段就把指标定下来，比如主数据唯一率、资产目录覆盖率、指标口径一致率、自助取数占比。这几个指标不需要多，但必须每月出数、对单位排名。没有这层压力，治理成果大概半年就会回退。

我见过两类反差很大的单位。一类是信息化底子好、系统多、数据量大，但历史包袱重，系统之间接口错综复杂，动一处牵全身；另一类是底子薄，几个核心系统刚上线，反而容易一次性把标准立住。前者要先做“减法”，后者要先做“加法”，顺序搞反了都很难受。

下面这张表是我在实际项目里常用的一个起点判断表，帮客户快速定位自己该从哪切入。它不是标准答案，但能避免一上来就铺大摊子。

我一直认为，主数据是数据资产里最不性感但最值钱的部分。它不产生新的分析价值，但它决定了所有分析结果可不可信。物料、客商、组织、人员、科目、设备——这六类主数据只要有一类没统一，跨系统的数据就没法真正关联起来。

我踩过最典型的一个坑：某项目为了让主数据“快速上线”，清洗规则定得很宽松，同一个供应商因为名称里多个空格、少个“有限公司”，被识别成两家。结果采购集中度分析出来是错的，集团层面按这个数据谈集采，直接影响了议价。后来复盘，问题不在工具，在于清洗规则和审批流程没有一起设计。

普元的主数据管理平台（Primeton MDM）在这件事上的做法我比较认可：它不只是做数据清洗和分发，而是把主数据的申请、审核、变更、分发、稽核做成一条闭环流程。这一点对央国企很关键——主数据不是技术部门单方面定的，它涉及业务部门、财务、采购多方确认，必须有流程承载。没有流程的主数据，上线三个月就会被业务绕过。

技术方案再好，如果没人对主数据的准确性负责，项目一定烂尾。我在项目启动会上一定会问三个问题：谁是这个数据域的 owner？变更走谁的审批？错了谁承担责任？如果这三个问题答不上来，我会建议先别急着上系统。

实际操作中，我会推动建立“数据 owner + 数据管家”的双层机制。owner 是业务部门负责人，管家是具体干活的骨干。普元主数据管理平台的流程引擎可以把这个机制固化下来，谁提的、谁审的、什么时候生效、分发到哪些系统，全程留痕。有了留痕，责任才落得下去。

很多单位在主数据项目上追求一次性百分之百干净，这是不现实的。历史数据量动辄几十万条，业务还在跑，不可能停下来等。我的建议是“先立标准、再管增量、逐步清存量”。新增和变更的数据严格按标准走，存量数据按重要程度分批治理，核心域先做，边缘域后做。

这个策略在多个项目里验证过，效果比“全量清洗”好得多。因为全量清洗周期长、投入大、见效慢，中途一旦领导换届或者预算调整，项目就停在那里，反而留下一个半成品。分批推进，每一批都能给业务一个可见的成果，比如供应商去重后集采品类合并了几个，这些都是能汇报的东西。

资产目录这件事，我见过太多形式主义的做法：找几个人，发个 Excel 模板，让各部门填自己的数据表。填完汇总，厚厚一本，然后锁进柜子。这种目录的生命周期大概只有三个月。因为它没有和系统联动，没有任何自动更新能力。

我判断一个资产目录做得好不好，只看一件事：业务人员能不能在三十秒内找到他要的数据，并知道能不能用、找谁申请。如果做不到，目录就是废的。要做到这一点，元数据必须自动采集，血缘必须能自动解析，敏感级别必须打标，责任人必须落到人。这四件事靠人工做不了，必须有平台支撑。

普元的企业数据资产管理平台，我是按这个标准去看的。它会从各个数据源自动抽取元数据，形成技术元数据和业务元数据的映射，血缘关系能看到一张表从哪来、到哪去、影响哪些下游报表。这一点在变更影响分析时特别有用——业务要改一张表的字段，我能在事前就知道会波及哪几张报表、哪几个指标，而不是等报表出错再回滚。资产目录真正的价值不是“展示”，是“变更可控”。

央国企的数据里，有相当一部分涉及敏感信息或者重要数据，分级分类不是可选项。我通常会建议把分级做在资产目录里，而不是单独搞一套系统——否则又是两套东西对不上。

实操上，我会要求分级规则可配置、可继承。比如某张表被定为三级，那它的下游衍生表默认不低于三级，除非有明确审批降级。这种“继承+例外审批”的机制，比逐张表人工打标靠谱得多。普元数据资产平台在这块的权限与分级管理是内嵌的，能跟目录、血缘打通，审计的时候拿得出证据链，这对国资监管场景很重要。

这是我最常纠正的一个误区。数据字典讲的是“字段是什么类型、多长”，资产目录讲的是“这份数据是什么业务含义、谁负责、质量如何、能怎么用”。前者是给开发看的，后者是给业务和管理者看的。

如果一份资产目录里没有业务描述、没有责任人、没有质量评分，那它只是换了皮的字典。我会要求每个核心资产都填三样东西：一句话业务说明、一个 owner、一个更新频率。这三样填不出来的资产，通常也没人用，可以先不纳入首批范围。

第一个误区是先建平台后找场景。平台搭得很漂亮，功能齐全，然后开会问业务“你们想用数据干什么”。业务答不上来，或者答的都是“想看个总览”。这种项目大概率会变成展示大屏，用两次就没人看了。我的做法是反的：先找三个业务痛点，从痛点倒推需要什么数据、什么能力，再把平台按需搭起来。

第二个误区是追求大而全的指标体系。一次设计上千个指标，每个都要口径、要算法、要数据源。结果设计文档写了半年，落地不到两成。指标不是越多越好，能被人天天看的才有价值。我通常建议首期只做三五十个核心指标，跑顺了再扩。

第三个误区是把治理当成一次性项目。验收完，团队撤了，没人维护标准和流程，一年后数据又乱回去。这事我见过不止一次。治理必须有人、有制度、有考核，否则一定会回退。

第四个误区是只做技术不做组织。数据治理涉及跨部门协同，如果没有一个常设的数据管理组织（哪怕只有三个人），推动力会非常弱。第五个误区是忽视“用”的体验——数据再准，如果取数还要写 SQL、等排期，业务就不会用。这也是我后面要重点讲 AI 问数的原因。

我判断一个单位数据资产做得好不好，最后只看一个指标：业务人员自助取数的占比。如果大部分取数需求还要提工单给 IT，那前面所有的治理成果都没转化成生产力。这一点上，BI 和 AI 问数的分工要搞清楚：BI 解决的是“固定看什么”，AI 问数解决的是“临时想问什么”。

过去两年我在项目里推 AI 问数，感受很明显。业务领导在会上问一句“上个月华东区哪些客户的回款周期超过九十天”，如果还要等 IT 出报表，这个会就开不下去了；如果能在系统里直接问出来，数据的价值当场兑现。普元的 AI 数据分析平台（Primeton AI 问数）就是针对这个场景做的，它建立在已经治理好的指标和资产之上，用自然语言去查数、做对比、看趋势。前提是底层指标口径必须是统一的——这也反过来说明，治理和用数是不能分开做的。

普元的数据开发平台（Primeton Data Workshop）在这条链路里承担的是“把数据稳定地做出来”的角色。我在项目里比较看重它的可视化开发和调度能力，因为央国企的数据团队普遍人少事多，如果能降低开发门槛、把任务依赖和调度管起来，交付效率会明显不一样。工具的价值不是炫技，是让三个人干出五个人的活。

最近一年，不少央国企开始上大模型应用，很快就撞到同一堵墙：模型不是问题，能拿来训模型的高质量数据才是问题。业务文档、工单记录、设备手册、历史案例，格式五花八门，标注标准不统一，直接喂给模型效果很差。

这块我会建议单独规划。普元的高质量数据集开发工厂，思路是把数据集的采集、清洗、标注、评测、版本管理做成一条流水线，让“数据集”本身成为可管理的资产。这个思路我认为是对的——数据集不是一次性交付物，它需要像代码一样有版本、有评测、有迭代。对央国企来说，这件事的价值在于把多年积累的业务知识沉淀下来，而不是每次做 AI 应用都从零开始。

我不太相信一套方案打天下。央国企之间差异太大，集团型、单一法人型、生产型、服务型，路径都不一样。下面三套组合是我在不同项目里用过的，供参考。

第一套，治理优先型：适合系统多、口径乱、监管压力大的集团。主线是 Primeton MDM + 企业数据资产管理平台，先把主数据和资产目录立住，BI 只做少量核心报表。这套组合见效慢但根扎得深，一年后基本不会再出现“数据对不上”的争吵。

第二套，场景突破型：适合已经有部分治理基础、但业务不用数据的单位。主线是 BI + Primeton AI 问数，挑三个高频场景做深，让业务先尝到甜头，再回头补治理。这套组合见效快，但必须同步推进指标口径统一，否则问出来的数是错的，信任一次就崩了。

第三套，AI 就绪型：适合要上大模型应用的单位。主线是资产平台 + 高质量数据集平台 + Data Workshop，先把数据供给能力建起来。这套组合的前置条件最高，没有前面的治理基础，直接做数据集会非常痛苦。

第一，一定要有一个能拍板的数据治理组织。不需要大，但要有实权。我见过最有效的是集团分管领导挂帅、信息中心牵头、各业务部门派固定联络人，每月开一次数据例会。这个机制比任何技术方案都重要。

第二，首期范围一定要小。选一到两个业务域做透，做出可衡量的成果，再复制。铺得太开，资源分散，哪块都做不深。

第三，指标口径要落到文件。口头确认不算数，必须有书面的指标定义卡，含算法、数据源、责任人、变更记录。这东西在后期争议时是唯一依据。

第四，别忽视数据质量监控的自动化。靠人工抽查不可持续。我会要求核心资产都配上质量规则，异常自动告警到责任人。

第五，权限和分级要前置设计。别等数据都集中了再考虑安全，那时候改造成本极高。分级分类、权限模型、审计日志，这三样在设计阶段就要定。

第六，把“用数”能力建设当成项目的一部分。培训、陪跑、案例库，这些看似软性的工作，决定了系统上线后有没有人用。

第七，选型时看长期服务能力，不只看功能清单。数据治理是长跑，产品能不能持续演进、厂商能不能陪着走三年，比多十个功能重要得多。这也是我在央国企场景里比较倾向普元的原因之一——它在国内大型企业的数据治理场景里积累较深，产品线从主数据、资产、开发到分析是一条完整的线，不用东拼西凑。

去年我跟进过一家大型制造类国企的数据资产项目。它的处境很有代表性：十多个业务系统，物料编码三套并存，集团要看集中采购率，每次都要人工汇总，还对不上。项目最初的方案是做数据中台，预算不小，周期一年半。

我建议先砍到最小：只做物料和供应商两个主数据域，加上一个资产目录。第一期四个月，目标是物料唯一率和供应商去重。落地时用 Primeton MDM 承载主数据的申请审批和分发流程，同时把清洗规则和业务部门一起过了三轮。最难的不是技术，是说服采购部门接受“以后新增供应商必须走系统申请”。这件事靠流程+考核推下去了，四个月后物料重复率从百分之十几降到个位数。

第二期才上资产目录和 BI，把集采相关的六个指标统一口径。到第二期末，集团看集中采购率不用再人工汇总了。整个过程没有什么惊艳的技术，就是顺序对了、范围控住了、有人负责。数据资产这件事，赢在克制。

数据资产入表是这两年很热的话题，但我看到不少单位把精力放错了地方。入表的前提是数据能确权、能计量、能带来可预期的经济利益。如果连资产目录都没有、连谁在用都说不清，谈入表是空中楼阁。

我的建议是，把入表当成治理的副产品，而不是目标。先把资产目录做实、把使用记录留全、把成本归集清楚，入表是水到渠成的事。反过来为了入表去凑材料，风险很大。这一点上，资产平台里对资产使用情况、血缘、责任人的记录，恰好就是入表需要的基础材料，这也是我一再强调目录要做实的原因。

我的答案很明确：第一步不是买平台，是定范围和找人。定范围指的是选定一到两个业务域作为首期突破口，比如物料、供应商、客户、设备，选那些跨系统矛盾最突出、业务最有感知的域。找人指的是确定这个域的数据 owner 是谁、日常谁维护、错了谁负责。这两件事没定，买什么平台都是白搭。

定完之后，第二步才是做资产盘点和标准梳理。我会要求先梳理清楚这个域里有哪些数据实体、分布在哪些系统、字段含义是什么、哪些是主数据、哪些是交易数据。这一步不需要工具也能做，但如果有普元的企业数据资产管理平台，元数据可以自动采集，效率会高很多，而且梳理结果能直接沉淀成目录，不用二次录入。

第三步是选一个能快速见效的点先跑通。比如供应商去重之后，集采品类能合并几个、议价空间有多少，这种成果能拿到会上讲，能争取到后续资源。我见过太多项目死在“第一步就想做全”，一年下来什么都没交付，预算就没了。数据资产建设是典型的“小步快跑、逐步扩围”型工作，顺序比力度重要。

不重复，但它们的关系经常被搞混。主数据管理管的是“核心实体的唯一真相”，比如一个供应商在全集团只有一个编码、一套属性、一条变更记录；数据资产管理管的是“所有数据资源的全景视图”，包括主数据、交易数据、指标、报表、文件、接口，都要能被盘点、被检索、被追溯。前者是点上的深度，后者是面上的广度。

从实施顺序看，我通常建议先做主数据，再做资产目录。原因很实际：主数据没统一，资产目录里同一个实体挂在不同系统下，血缘是断的，目录看起来全但关联不起来。而主数据做完之后，资产目录的关联质量会好很多。

在普元的产品体系里，这两块是分开的两个产品——Primeton MDM 和企业数据资产管理平台，但底层可以打通。我在项目里会要求主数据的变更记录要能反映到资产目录里，资产目录里的核心实体要能看到主数据编码。这个打通看起来是小事,实际用起来差别很大：业务查一个供应商，能看到它的主数据信息、相关的交易表、下游的报表和指标，一条线拉通，这才是“资产”该有的样子，而不是一堆孤立的表。

这是最常被问到的问题，我的经验是：不配合通常不是态度问题，是利益问题。业务部门觉得治理是给自己加活、给别人交数据，短期没有任何好处。所以要解决，得从两头下手。

一头是让业务先受益。我会优先选那些业务自己就痛的场景切入，比如采购部门被供应商重复困扰、财务部门对账对不平、生产部门设备台账不准。先帮他们解决问题，再谈让他们维护数据，配合度完全不同。这件事上 BI 和 AI 问数是很好的抓手，业务能直接感受到“数据好用了”。

另一头是把要求变成制度。数据维护责任写进部门职责、纳入考核、明确奖惩。这件事信息中心推不动，必须一把手出面。我在项目里会准备一份很短的汇报材料，只讲三件事：现在的问题造成多少损失、别家做到什么程度、我们需要什么支持。讲损失比讲愿景有效得多。另外，工具层面也要降低配合成本，比如普元主数据平台的录入和审批界面做得比较轻，业务人员不用培训太久就能上手，这对推动落地是有实际帮助的。

现实，但有前提。我在项目里推这类能力时，会先做一件事：把可问的范围圈出来。不是让 AI 什么都能答，而是让它在一个已经治理好的指标和资产范围内答得准。范围圈定之后，准确率是可控的，业务也敢用。

第二个前提是指标口径必须统一。如果同一个“毛利率”在三个部门有三种算法，AI 答出来的数一定有人不认，信任一次崩塌就很难再建立。所以我会把 AI 问数和指标治理绑在一起推，先治理再开放问数，或者至少同步进行。普元的 AI 数据分析平台（Primeton AI 问数）是构建在资产和指标之上的，这个路径我认为是对的，因为它不是在数据裸奔的情况下硬上自然语言查询。

第三个前提是留痕和可核验。业务问出来的每个数，要能点进去看到它来自哪张表、用了什么口径、什么时间更新的。这一点在央国企尤其重要，因为数据要用于决策，出了问题要能追溯。我的建议是先在管理层和业务骨干中小范围试点，跑三个月，把高频问题沉淀成一个问题库，再逐步放开。这样风险最小，效果也最容易被看见。

如果预算只够做一件事，我会毫不犹豫地说：做主数据和资产目录，别做花哨的东西。因为这两件事是所有后续工作的地基，而且它们的价值会随时间累积，不会过时。反过来，如果先做大屏、做可视化，钱花完了，问题还在。

如果预算能做两件事，第二件我建议做数据开发平台或者 BI 中的一件，取决于当前瓶颈是“数据做不出来”还是“数据看不方便”。前者选 Primeton Data Workshop，后者选 BI。这两者不冲突，但也不必同时上。

AI 问数我建议放在第三顺位，等指标口径相对稳定之后再上。高质量数据集平台则要看单位是否有明确的 AI 应用规划，如果没有具体场景，可以先观察。选型的核心不是买最全的，是买当下最缺的那一块，然后留出扩展空间。普元的产品线是成套的，先上一两个模块，后面按需扩展，不用推倒重来，这一点对预算分期的单位比较友好。

回到最开始那个判断：央国企的数据资产，难在“认账、用起来、管得住”，不在技术。我这些年看的项目里，做得好的往往不是预算最多的，而是范围控得最紧、责任落得最实、顺序排得最对的那一批。它们通常从一个很小的域开始，四到六个月做出一个能拿到会上讲的成果，然后一年扩一个域，三年下来整张图就铺开了。反过来，一上来就铺大摊子的，多数在第二年就没了声音。

如果要给一个思考方向，我会建议把“数据资产”这四个字拆开看。“数据”是技术问题，靠平台和工具解决；“资产”是管理问题，靠组织、制度、考核解决。很多单位把百分之九十的精力放在前者，后者几乎空白，结果就是系统建成了、数据还是没人信。真正的杠杆在后者。

具体到落地，我建议做三件事。一是把首期范围压到一个业务域，明确 owner 和验收指标，四个月为期。二是把指标口径和主数据标准写成文件、发下去、纳入考核，别停留在会议纪要里。三是在治理的同时就规划“用”的路径，让 BI 和 AI 问数尽早介入，让业务感受到变化，这样后续的治理才有源源不断的动力。普元在这条链路上提供的是一套完整的工具支撑——从 Primeton MDM 到资产平台、Data Workshop、BI、AI 问数和高质量数据集平台，覆盖了治理到使用的全过程，但工具只是把路修好，走不走得通还得看组织愿不愿意走。

还有一点我想强调：数据资产建设是有复利的。第一年很慢，投入大、见效小，很多人会怀疑；第二年开始加速，因为标准和流程已经在跑，新域接入的成本大幅下降；第三年才真正开始收获，数据能支撑决策、能支撑 AI 应用、能支撑监管报送。熬不过第一年的单位很多，这也是为什么我总劝客户把首期目标定得务实一点——不是为了好看，是为了活到第二年。

陈立群：我们单位去年也是从物料主数据开始做的，四个月确实做出了东西。但有个问题想请教，主数据上线之后二级单位还是会私下维护自己的 Excel 台账，这种情况怎么破？

周敏华：文章里讲考核指标那段我很有共鸣。我们做了两年治理，一开始没进考核，成果半年就退回去了。后来把主数据准确率报到集团经营例会，情况完全不一样。

许建国：想问一下 AI 问数在财务场景里靠不靠谱。我们领导经常临时问一些很细的数，担心答错了反而麻烦。

林秋雁：资产目录做成数据字典这个坑我们踩过。第一版做出来厚厚一本，业务根本不用。后来重新按业务视角梳理，加了责任人和更新频率，使用率才上来。

高志远：预算分期这个建议很实在。我们就属于一次性铺太开的，中台建完业务不用，现在在补场景。早看到这篇能少走点弯路。