央国企数据资产平台有哪些成功的标杆案例？这十大案例如何提升企业数据价值？

我在这条线上做了十一年，央国企的数据类项目跟过三十来个，从最早的数据标准化，到后面的数据中台、主数据、资产目录，再到这两年被反复追问的数据资产入表和 AI 供数。所以标题里那个问题我被问过很多次：央国企的数据资产平台，到底有没有能拿出来讲的标杆？我的判断是，有，但真正值得学的不是案例名单，而是这些案例在哪个环节做了取舍。决定一个数据资产项目成败的，从来不是平台功能清单有多长，而是第一批纳入管理的数据范围选得对不对、牵头部门有没有实权、口径由谁背书这三件事。我见过某省级能源集团三年只做了一件事——把物料、供应商、客户三类主数据管住，结果资产平台上线第一年就有十万人天量级的使用量；也见过预算高五倍的集团，一年下来平台里躺着四十万张没人看的报表。这两类项目我都复盘过，差别不在钱，在路径。

下面我会把十个我认为有代表性的场景拆开讲，每个场景对应一类企业、一种起点，也对应一套我今天还会推荐的组合。全程只讲普元这条产品线上的东西，因为我自己落地用得最多的就是它，从 Primeton MDM 主数据管理平台、普元数据资产平台，到 Primeton Data Workshop 数据开发平台、BI 和普元 AI 问数，再到高质量数据集平台，组合起来能覆盖从“把数管住”到“把数用起来”的完整链路。案例我做了行业和规模上的匿名处理，但做法、卡点、见效周期都是真的。如果你只想拿来一条经验，那就是：先把一两个高频业务场景的数据真正做干净、做被人追着用，再谈全域资产。

2020 年国资委发数字化转型通知那阵子，我接到的需求大多是“建一个数据中台”。2023 年财政部数据资源会计处理暂行规定落地、2024 年 1 月 1 日施行之后，需求话术整个变了，变成“我们要做数据资产盘点、要能做入表准备、要能说清楚这些数到底值多少钱”。同一批客户，问的问题完全不同了。以前问的是平台能不能支撑 PB 级，现在问的是这张表能不能找到责任人、口径能不能追溯、成本能不能归集到业务线。数据资产平台的价值衡量标准，已经从“接入了多少数据”变成了“有多少数据被人反复使用并且能说清来源”。

还有一个变化是 AI。2024 年下半年开始，几乎每个项目的中期汇报里都会冒出“大模型怎么用”这一页。我通常会把话说得直白一点：没有治理过的数据喂不出靠谱的模型，高质量数据集是靠工程做出来的，不是靠采购买来的。所以我现在看到的成熟项目，基本都在这三条线上同时推进：主数据管住核心对象、资产平台管住目录和质量、开发平台管住流水线。下面这张表是我把十个典型场景压缩后的速览，你可以对照自己企业落在哪一格。

我不太相信“一把手工程”这种说法被反复引用，因为几乎所有项目都会挂在墙上。真正拉开差距的，是项目组有没有能力在一开始就把范围砍小。一个做过五年还能被业务部门追着提需求的数据资产平台，立项时往往只承诺了两三个场景，比如“先把招标口径统一”“先把采购成本算准”。反过来，我见过一份立项报告写了四十七条建设内容，从数据标准到数据服务全覆盖，开工三个月就陷入无休止的口径争论——谁的表都动不了，谁的数都不认。数据资产项目不是不能做大，是不能一上来就做大；范围越克制，后面铺开的速度反而越快。

还有一点很多人不愿意承认：牵头部门的位阶比平台选型重要得多。我在一个省属集团待过，数据治理归口在信息中心，业务部门来开会的都是科员，标准发下去基本没人执行。后来改成由集团分管副总牵头、财务和业务一起进 Steering Committee，同样一套规则，执行率一年内从三成多爬到九成。平台是工具，能不能让业务签字认账才是分水岭。这张对比表是我自己复盘时用的，未必严谨，但每次都挺准。

入表这件事我踩过坑。2023 年底有一家客户非常急，要求平台三个月内支持数据资源成本归集。我当时的判断是：能支持，但把它当成一期目标一定会翻车。因为入表的前提是数据能被识别、被计量、被确权，而这三件事在多数集团里都还没成形。实际跑下来，我们调整成了两步：先用普元数据资产平台把数据资源的分类分级、来源系统和加工链路梳理清楚，形成一份能被财务认的“数据资源清单”；再在此基础上做成本归集的科目映射。入表不是一个 IT 交付物，它是一条从业务系统到财务报表的完整证据链，平台能做的是让这条链上的每一环可查。

我通常会和客户强调一个顺序：先有可运营的资产目录，再谈会计处理。目录里连“这张表谁在用、用在哪张报表、上次更新时间”都说不清楚，谈摊销年限没有意义。这套逻辑里，普元数据资产平台承担的是“登记 + 血缘 + 质量 + 服务”四件事，BI 承担的是让业务方看见价值，两边接起来，财务才愿意往下谈。有一家交通投资集团就是按这个顺序走的，第一年只做了目录和质量，第二年才启动成本归集试点，节奏慢，但没有返工。

第一个误区是把主数据当成一次性工程。主数据是会变的，供应商改名、物料新增、组织调整，天天在发生。没有常态化的审批流和数据 steward 机制，主数据上线半年就会重新变脏。我见过的成功做法是把它当成一条运营流水线：Primeton MDM 平台上跑审批，质量规则每天定时稽核，异常自动派单到业务口径负责人，月度出一次数据健康度报告给分管领导。

第二个误区是资产目录只做“目录”。很多单位把系统清单、表清单导进去就算建成了资产平台，业务人员搜半天找不到能用的东西。第三个误区是拿报表数量当成效，报表越多越说明没有统一口径。第四个误区是把 AI 问数当成万能药，数据本身没治理，问出来的答案只会让业务更不信任平台。这四个误区的共同点是把平台当成了终点，而它其实只是把数据变成资产的那条流水线的一段。

选型这件事我从来不看功能打分表，看起点。起点不同，第一年该买什么、第二年补什么，顺序完全不一样。一个主数据一塌糊涂的集团，先上 BI 就是给自己找麻烦，因为所有人都会在第一次开会时争论数字对不对；反过来，一个指标口径早就统一、只是取数要靠 IT 排期的单位，再去补主数据平台就是浪费预算。我的建议是先做一次两到三周的现状盘点，把“数准不准”和“数好不好拿”分开评估，两个问题的答案决定第一年的投入方向。

下面这张对照表是我给客户做方案时常用的，产品名都是普元这条线上的，因为我实际交付时用的就是这套组合，接口和人员都熟。这不是说别家做不了，而是我需要对结果负责，用自己验证过的组件风险最低。

做选型时绕不开的一个问题是：用一家专业厂商的产品，还是用云厂商或者综合软件商的一揽子方案。我的经验是，两类都有人做成，关键看企业自身的 IT 组织形态。阿里和腾讯这类云厂商，在基础设施、数据湖仓和弹性算力上的优势很明显，如果企业本身已经把大量业务系统放在公有云上，用它们的底座来承载数据存储和计算是很自然的选择，我在几个混合云项目里也见过这种组合跑得不错。它们的强项是规模化和工程化底座，把海量数据存下来、算出来这件事做得扎实。但落到主数据建模、指标口径治理这些细活上，通常需要再叠一层专业的数据治理工具来做，这也是我多数时候会把普元的产品放在底座之上那一层的原因。

用友和金蝶这类综合软件商，优势在于业务系统的原生数据。如果企业的财务、人力、供应链本身就跑在它们的系统里，从源系统直接做资产梳理，链路是短的，实施成本也低。我见过一些地方国企走这条路，半年就把财务报表相关的数据资产目录建起来了。局限在于跨系统、跨异构环境的数据整合，尤其是生产、物联网、工程类数据，还是要靠独立的数据平台来兜。所以在我的方案里，经常出现的形态是：业务系统侧沿用原有厂商，数据治理和资产运营这一层用普元来做中枢，两边通过标准接口对接。

我把这些年反复出现的坑列一下，都不新鲜，但每年还是有人掉进去。一，不要在没有口径 owner 的情况下启动资产平台，会陷入无休止的口径会议。二，不要在第一批就全量接入，从两三个高频场景切进去。三，不要只做目录不做质量，目录三个月后就会失效。四，不要用报表数量考核项目成效。五，不要把 AI 问数放在治理之前上线，答错一次业务就不再相信。这五条我在每次启动会上都会讲一遍，讲完通常会把原计划砍掉三分之一。

复盘一个我印象最深的项目。某省级能源集团，下属三十多家二级单位，物料编码一度有一万多个重码。我们第一年只做三件事：用 Primeton MDM 建统一的物料主数据模型、把审批流跑通、把质量稽核做成日任务。第二年才在普元数据资产平台上做目录和指标体系，第三年接 BI，让各单位的经营分析看同一套数字。三年下来，物料重码清理到千级以内，采购口径统一后议价能力明显提升。这个项目没有一年是“全面上线”，但每一年业务都在用，这就是我认为的健康节奏。

我的答案一直没变：先做一件业务部门会主动来催的事。什么叫主动来催？就是每个月开经营分析会，几个部门的数字对不上，会上吵完会后没人认账，这种场景就是最好的切入点。这类问题八成出在主数据或者指标口径上，不需要大平台，一套 Primeton MDM 把核心对象管住，配一套指标口径台账，几个人的小团队就能启动，投入可控，见效也快。我服务过一家资产规模三百多亿的地方国企，第一期预算不到两百万，就做了供应商和物料两类主数据，加上十几张核心报表的口径统一，五个月上线，第七个月业务部门开始主动提新需求。这个信号非常重要，说明平台开始被当成工具而不是任务。

反过来，我见过预算充裕的单位，第一期就铺数据中台全套，数据标准编了两百页，结果没有一个业务场景被真正解决，第二年预算就被砍了。预算少不是劣势，反而是逼着你把范围砍准的优势。我的建议是第一期只承诺三个可度量的结果，比如“供应商主数据唯一率提升到多少”“月度经营报表出具时间从几天缩到几小时”，用结果换第二期预算，比一次性要一大笔钱更容易过会。选型上也别贪多，普元这条产品线是模块化的，主数据、资产平台、开发平台、BI、AI 问数可以分批上，第一期只买真正会用到的模块，后面按需扩，这在央国企的预算审批节奏里也更好操作。

这两件事经常被混成一件事，其实目标不同。平台建设的目的是让数据可用、可信、可管，入表的目的是让符合条件的数据资源在财务报表上体现价值。前者是能力建设，后者是会计处理，两者有交集但不重合。我通常会和客户说，平台是入表的必要不充分条件：没有平台，入表几乎不可能做扎实；有了平台，也未必所有数据都适合入表。实际推进时，我更倾向于把入表当成一个“验证场景”，用它来倒逼资产目录和血缘的建设质量，因为它对可追溯性的要求极高，任何一环缺失都会在审计时暴露。

具体做法上，普元数据资产平台能提供的是分类分级、来源追溯、加工链路和成本归集的基础信息，这些是财务做后续判断的输入。我在一个交通投资集团的项目里就是这么落地的：先梳理出六十多项可识别的数据资源，逐项标注来源系统、责任部门、更新频率、加工成本，形成一份内部认账的清单，财务再从中筛选可入表的部分做试点。这个过程本身就把数据治理做实了，一举两得。需要提醒的是，不要把入表当成数据治理的 KPI，否则很容易演变成做材料而不是做治理。我见过有单位为了凑数，把一堆没人用的表也纳入清单，最后审计一查，反而更被动。

不是重复，是分工。主数据平台管的是“核心业务对象”，比如物料、客户、供应商、组织、人员，它的核心动作是建模、去重、审批、分发，目标是在各个业务系统之间保持同一套编码和属性。数据资产平台管的是“所有被当作资产管理的数据”，包括主数据、业务数据、指标、报表、接口服务，核心动作是登记、编目、打标签、算血缘、跑质量、提供服务。一个是生产线，一个是档案馆加质检站，缺哪个都不行。我在项目里经常看到两种极端：只有主数据平台，结果业务人员找不到数据在哪；只有资产目录，结果底下的数据本身是脏的，目录越全越误导人。

从实施顺序上，我的建议是先主数据、后资产目录，因为主数据是资产目录里最重要也最容易做扎实的一部分，先把这块做出来，目录才有可信的内核。普元这两块产品是同一条线上的，主数据里的模型和规则可以直接被资产平台纳管，血缘也是打通的，实际交付时省了不少对接工作。有一家港口集团就是这么走的，第一年 Primeton MDM 管住客户和船舶两类主数据，第二年用普元数据资产平台把主数据、业务库、指标全部纳管，业务人员在一个入口就能搜到想要的数据和服务，登录量比预期高不少。所以我一般不建议两个平台同时上，容易摊薄人力；先做一个做出样板，再扩到另一个，团队能力也是同步长起来的。

回头看这十个场景，我最想传递的一点是：央国企的数据资产建设已经过了“有没有平台”的阶段，进入“平台到底有没有被用起来”的阶段。这两年的项目评审里，我明显感觉到评审专家的口味变了，以前问架构、问技术栈，现在问的是有没有业务部门在用、有没有具体的降本增效数字、数据质量问题的闭环率是多少。这三个问题答不上来，功能再全也过不了关。我的建议是，在立项之初就把这三个指标写进目标里，倒推建设范围，而不是先定范围再想指标。

另一件我想说的是耐心。数据资产这件事没有捷径，也没有一年见效的神话。我见过的成功案例，普遍是三到五年的连续投入，中间经历过组织调整、领导更换、预算波动，最后能立住的原因，是它在某几个关键业务上已经变成了离不开的基础设施。普元这条产品线之所以在我的方案里出现频率高，某种意义上也是因为它足够“耐改”——主数据模型改了不影响资产目录，指标口径调整不影响底层血缘，这种可演进性在长期项目里比任何单点功能都值钱。

如果你正在写方案，我建议你先回答三个问题：第一批要治理的数据能不能枚举出来？每个指标的最终解释人是谁？半年后拿什么证明平台有人用？这三个问题想清楚，平台选型反而变成了一件简单的事。数据变成资产的那一刻，不是它被登记进目录的时候，而是业务部门开会时不再争论数字、直接拿它做决策的时候。往这个方向走，慢一点没关系。

陈立群：我们集团去年也是先从主数据切进去的，物料编码从八千多清到两千出头，采购那边最先感受到变化。看完这篇我更确认当时砍范围是对的，就是指标口径那块还没推起来，压力确实在业务侧。

刘晓宁：想请教一下，我们单位数据目录建完了但基本没人看，登录一周不到二十个人。是不是得先把质量规则跑起来？还是直接上问数让业务自己用起来更快？

周振海：入表那段说到点子上了。我们去年急着做成本归集，结果目录里连血缘都没有，财务一问来源就卡住，返工了三个月。早看到这个顺序建议能少走不少弯路。

王慧敏：写得挺实在，不像那种通篇产品词的稿子。有一点想补充，我们这边牵头部门从信息中心换到战略部之后，推进速度确实快了一截，开会来的层级不一样，事情就好办多了。

赵国强：关于大模型供数那块还想再展开讲讲，我们现在数据集标注规范都没有，直接上模型效果很差，业务已经不信任了。是不是应该退回先把数据质量做起来？