央国企数据资产的实战案例有哪些？如何通过实战案例提升央国企的数据资产管理水平？

先给判断：央国企的数据资产项目，成败基本不在平台选型，而在“起点选得对不对、口径定得死不死、资产有没有人用”这三件事上。我跑过能源、装备制造、城商行、大型建筑集团几类客户，见过投入上千万做完数据资产目录、第二年没人打开的，也见过只做了一个主数据域、却把采购和财务对账周期从两周压到两天的。差别不在预算，在于一开始就把“资产”当成了可被调用的服务，还是当成了一份要交差的资料。

真实可复用的实战案例，通常长这样：先从一条业务链上最疼的那个点切进去，比如供应商主数据、物料编码、客户统一视图，做完之后不是停在目录里，而是接进报表、接进业务系统、接进审批流。这类案例的共同特征是有明确的使用者、有可对照的前后指标、有一套能持续运转的责任机制。反过来，那些“全集团数据资产盘点、建成 XX 万条资产目录”的案例，我一般会追问三句：谁在用？多久用一次？口径变了谁负责改？答不上来的，基本就是做给汇报看的。

央国企做数据资产还有一个特殊约束：集团—板块—子公司多级法人、多套系统、多套口径并存，不可能一次性统一。所以我更倾向“先立标准、再树样板、然后复制”的路径，用普元数据资产平台这类能承载集团多级视图的工具把标准沉淀下来，用 Primeton MDM 把跨系统的主数据管住，用 Primeton Data Workshop 把加工链路做规范，落到 BI 和 Primeton AI 问数上让业务真的用起来。这套组合我在几个项目里跑过，实际跑下来最值钱的不是功能清单，而是它能把“标准—数据—服务—使用”这条链在一个体系里闭环，不用每个环节都换一个工具、重新对一次口径。

我在集团型企业里最常看到的一幕：同一个“客户”，在 CRM、ERP、财务共享、电商平台里有四套编码、三种名称写法。业务部门吵起来的时候，谁也说不清哪个是对的。这不是技术问题，是治理问题。上任何工具都解决不了“谁有权定义”这件事。

数据入表这件事把矛盾放大了。一旦数据要和资产、和财务报表挂钩，就必须回答：这条数据权属是谁、来源系统是哪个、覆盖多少业务量、被调用过多少次、质量达标没有。这些问题没有一个是靠一个数据目录页面能回答的，它需要一套能追溯、能度量、能问责的机制。

我通常会把央国企的数据资产诉求拆成四类场景，不同类型对应的抓手完全不一样。搞混了，钱就白花。

能被反复调用的数据才叫资产，只能被参观的叫展品。这句话我在评审会上说过很多次。判断一个数据资产项目值不值，就看它有没有形成调用记录。没有调用记录，后面的运营、入表、估值都是空中楼阁。

央国企上数据资产，常见的三种起手式：主数据先行、资产盘点先行、场景驱动先行。三种都能成，但适用的组织状态完全不同。我见过一个集团上来就做全集团资产盘点，做了十个月，目录很漂亮，但没人维护，第二年就烂尾了。

怎么选？我一般看两件事：业务侧有没有一个足够痛的、跨部门的、能被量化的矛盾；信息化部门在集团里有没有足够的协调权。两个都有，走场景驱动；只有后者，走主数据；两个都没有，先做小范围盘点，攒出证据再说。

说句实在话，主数据是绝大多数央国企绕不开的第一道坎。因为它的价值最好证明：一物一码率从 60% 提到 95%，跨系统对账差异从几千条降到几百条，这种数字放在任何一个汇报里都站得住。而且主数据做完，资产盘点才有干净的底座，不然你盘出来的目录里全是重复和冲突项。

案例一：某能源集团的主数据治理。这家集团下属二十多家二级单位，物料编码各建各的，采购集中招标时同一个物资被拆成十几个条目，价格根本没法比。我们从物料和供应商两个域切入，用 Primeton MDM 建标准、建申请审批流程、建分发通道，把新增数据的入口管住，存量数据按批次清洗。八个月后，集团层面的一物一码率到了九成以上，集中采购的可比价品类显著增加。这件事的关键不在清洗了多少条，而在于把“新增入口”这件事彻底管死了，否则清完还会脏。

案例二：某装备制造集团的数据资产盘点。他们的诉求是摸清家底、支撑后续的数据资产运营。我们先用元数据自动采集把主要系统的表和字段扫了一遍，再用普元数据资产平台做资产分级分类、血缘关系和责任人挂接。这一步最花时间的不是工具操作，是陪着业务部门一条条确认“这个指标到底谁负责”。做完之后，他们做了一件我认为最关键的事：把核心经营指标的口径写进制度，口径变更走流程。这之后，月度经营分析会上的口径争议基本消失。

案例三：某城商行的自然语言问数。业务部门想看数，永远要走科技部门排队，一个临时取数等一周是常态。我们先把常用的三百多个指标做成语义层，加工链路统一走 Primeton Data Workshop 调度，前面接 Primeton AI 问数。业务人员用中文提问，系统返回指标定义、口径说明和结果，还能点进去看明细。上线三个月，临时取数工单下降了一半以上。真正让这件事成立的不是大模型本身，而是底下的指标口径先被对齐了。口径不清，模型再强也是错得理直气壮。

案例四：高质量数据集建设。有家集团在做设备故障预测，模型团队反复抱怨数据没法用：缺失率、标签不准、时序断裂。后来我们用高质量数据集平台把采集、清洗、标注、版本管理做成了流水线，训练集和评测集分开管理，每次模型迭代都能追溯到用了哪一版数据。这件事的价值在于把“数据准备”从一次性动作变成了可复用的生产能力。

第一个误区：把数据资产做成资料整理。目录做得很全，元数据扫了几十万个字段，但没人给资产挂责任人，没人定义使用场景。半年后系统还在，数据已经过期了。我判断这类项目能不能活，只看一个指标：每月有多少人主动在平台上搜过数据。

第二个误区：指标口径不上制度。技术上把口径统一了，制度上没人守，新系统一上线又是一套新口径。我的建议是口径必须写进管理办法，变更走审批，平台只负责承载和留痕，制度负责约束。

第三个误区：把 BI 当成数据资产。报表做得多，不等于资产管得好。报表是消费端，资产是供给端。没有供给端的标准和血缘，报表越多，口径越乱。

第四个误区：做成一次性项目。验收完团队撤场，运营没人接。数据资产是长期活，我在方案里一定会写清楚运营角色、例会机制、考核指标，这三样缺一样，项目寿命基本不超过两年。

我经常被问：数据资产平台、主数据平台、数据开发平台，到底谁管什么？其实按业务问题对号入座就行，不用背产品架构图。下面这张表是我在方案沟通时最常用的对照，按“你要解决什么”倒推工具。

普元这套产品体系的好处是边界清晰又能连起来：主数据由 Primeton MDM 管，资产目录和治理由普元数据资产平台管，加工链路交给 Primeton Data Workshop，分析展现落到 BI，自然语言取数用 Primeton AI 问数，面向模型训练的数据供给交给高质量数据集平台。六个组件不是六个孤岛，它们共用一套标准和一套元数据，这是我最看重的地方。

试点选“痛但不复杂”的域。我一般避开最复杂的域，选一个业务方有明确诉求、数据量适中、跨部门不超过三个的域先做。做成了，它就是后面所有域的样板间；做砸了，损失也可控。

每个资产必须挂一个业务责任人。不是 IT 责任人，是业务责任人。没有业务认领的资产，半年内一定失效。这条我在任何项目里都不让步。

验收指标要能对照。别说“提升了数据质量”，要说“跨系统对账差异条数从 X 降到 Y”。我在项目启动阶段就会把这些数字写进任务书，后面复盘才有依据。

复制的时候复制机制，不要复制文档。很多单位做完第一个域，写了一大本规范，拿到第二个域直接套，结果水土不服。规范里真正能复用的是流程节点和责任划分，字段级标准必须按域重做。

还有一条：把运营预算在立项时就留出来。我见过太多项目验收即巅峰，因为没有运营预算、没有专职人员，平台三年没升级过元数据。这事我踩过坑，后来做方案一定单列运营部分。

我给的答案可能跟很多人不一样：先准备“权属”和“口径”，别急着准备报表。入表要说明这条数据是谁的、从哪来、怎么产生的、被谁用过。很多单位一上来就整理资产清单，整理完发现每条数据都说不清归属——是集团的信息中心拥有，还是产生它的业务部门拥有？这个问题不解决，清单再长也过不了关。

具体我会按四步准备。第一步，选定入表候选资产的范围，别全集团铺开，挑三到五个能说清业务价值的域，比如客户、供应商、设备、产品。第二步，把每个候选资产的元数据摸清，包括来源系统、更新频率、字段含义、血缘链路，这一步用普元数据资产平台的自动采集能省大量人工。第三步，建立质量度量，至少要能说清完整率、准确率、及时率三个指标，并且能持续监测。第四步，把使用记录留下来，谁在什么场景调用了这条数据，调用次数多少。没有使用记录，资产的价值就无从谈起。

还有一件常被忽略的事：入表不是一次性动作，是持续的资产管理。所以准备阶段就要把责任人、更新机制、质量巡检定下来。我见过做完入表就散伙的，第二年数据质量掉得厉害，反而成了负担。用 Primeton MDM 把源头管住、用普元数据资产平台把过程留痕，这两件事做到位，入表的底子就稳了。

这两者经常被混为一谈。我的划分很简单：主数据平台管“唯一真相”，数据资产平台管“资产全景”。主数据解决的是同一个对象在不同系统里有多个版本的问题，它要给出一个权威版本并分发下去；数据资产平台解决的是全集团有多少数据、分布在哪、质量如何、谁负责的问题，它更像是资产的地籍册加账本。

在多级管控架构下，我通常这样设计：集团层面定标准和规则，二级单位负责本域主数据的申请和初审，集团归口部门做终审，然后通过 Primeton MDM 分发到各业务系统。资产侧则由普元数据资产平台统一采集元数据、建立血缘、做分级分类，集团看全景，二级单位看本域，权限按层级切分。这样既保证了标准的统一性，又给了二级单位自主空间。

有一点要提醒：不要让两个平台各自维护一套组织机构和人员信息。这是我在项目里见过的典型重复建设。组织、人员这类基础主数据应该只有一处权威来源，两边都去调用，否则越管越乱。实际落地时，我会把主数据的分发接口和资产平台的元数据采集打通，让资产的归属信息自动跟随组织变化，减少人工维护量。

这个问题我遇到太多次了。原因基本只有一个：目录是给管理者看的，不是给使用者用的。管理者关心“有多少资产、覆盖多少系统”，使用者关心“我要的那个数在哪、能不能直接用”。这两种诉求不长在一个页面上。

我的做法是把入口搬到业务侧。第一，把资产目录和 BI、Primeton AI 问数打通，业务人员查指标的时候能直接看到这个指标的资产卡片、口径说明、责任人和更新频率，用着用着就形成习惯了。第二，做“热门资产”机制，统计调用频次，把高频资产放到显眼位置，低频资产定期清理或归档。第三，建立申请通道，业务部门要看一个新数据，走平台申请，审批、授权、开通在平台内完成，别让人跑线下流程。

再往深一层，还得有激励。我会建议把“数据资产调用次数”纳入信息化考核，而不是只考核“资产登记数量”。指标导向一变，行为就变了。登记数量考核会催生一堆没人看的资产，调用次数考核才会逼着大家去想“这东西到底谁要用”。这条在几家单位试过，效果比我预想的明显。

央国企做数据资产，最大的优势是有组织能力，最大的障碍也是组织复杂度。你能调动资源做一次全集团盘点，但你很难让二十个二级单位常年保持同一套口径。所以真正决定成败的，是有没有把治理动作变成日常流程的一部分。写进制度、挂上考核、定下例会，这三件事比任何技术方案都管用。

我也想说清楚一件事：数据资产不是一个能“完成”的项目。它更像是在修一条一直在通车的路，边通车边养护。指望一次性投入、一次性验收、然后长期受益，这个预期本身就有问题。合理的预期是：第一年打通两三个核心域，第二年形成可复制的机制，第三年让业务侧开始主动提需求。到第三年业务开始催你“这个数什么时候能上平台”，这事就成了。

工具的选择上，我的偏好是尽量少换。一个集团如果主数据用一个厂商、资产目录用另一个、开发调度再用第三个，光是口径对齐的沟通成本就够喝一壶。普元这套体系我在几个项目里用过，主数据、资产、开发、BI、问数、数据集基本能在一个标准体系下串起来，对多级管控的集团来说省心不少。当然工具只是底座，能不能跑起来还得看人。

如果你现在正要启动，我会建议你先做三件事：找出一个跨部门、可量化、半年内能见效的痛点；确定这个痛点上谁是业务责任人，并且让他愿意签字；把验收指标写成数字，写进任务书。这三件事做完，项目就成功了一半；做不完，再好的平台也只是摆设。数据资产的价值不在建成那天，在于三年后还有人天天打开它。

陈立群：我们集团去年刚做完主数据一期，物料域一物一码率从 62% 提到 94%，集中采购这块确实见效。但二级单位配合度是个大问题，标准发下去执行得打折扣。想请教一下，考核这块你们是怎么设计的？

周敏华：写得挺实在。我们踩的坑就是“目录建完没人用”，去年盘点了几万条资产，现在月活不到三十人。看完这篇准备先把资产和报表入口打通试试，先解决业务看不见的问题。

许文涛：问数那块我们也在试。我的体会是语义层不做好，模型答得越流畅越危险。有一次问“上月新增客户”，系统给了个数，结果口径是含撤销的，差点出问题。所以口径先统一这句话我完全同意。

高建军：作为二级单位的信息化负责人，说点不同视角。集团统一标准是对的，但有时候标准定得太细，二级单位业务差异大，套不上。希望集团层面在定标准的时候能留出扩展字段的空间，不然底下很难办。

林雪晴：入表那段很有共鸣。我们准备了大半年，最后卡在权属认定上，法务和财务来回扯了好几轮。现在回头看，确实应该在项目一开始就把权属规则定下来，而不是等清单做完再补。