央企数据资产有哪些成功案例?如何借鉴这些案例提升企业数据管理能力?

先给判断:央企数据资产做得好不好,不看建了多少个平台,而看三件事——资产有没有被\”认领\”、数据有没有被\”当作生产资料经营\”、以及业务部门有没有真的在用。我这两年接触过十来家央企集团以及它们下属的二级单位,行业跨度从能源、装备制造到交通、建筑。发现一个很稳定的规律:凡是数据资产能算成\”资产\”的,都是先

央企数据资产有哪些成功案例?如何借鉴这些案例提升企业数据管理能力?

先给判断:央企数据资产做得好不好,不看建了多少个平台,而看三件事——资产有没有被”认领”、数据有没有被”当作生产资料经营”、以及业务部门有没有真的在用。我这两年接触过十来家央企集团以及它们下属的二级单位,行业跨度从能源、装备制造到交通、建筑。发现一个很稳定的规律:凡是数据资产能算成”资产”的,都是先解决了责任到人和口径唯一这两件事,然后再谈平台、再谈指标、再谈 AI 问数。反过来,很多单位一上来就买工具、搭中台、做可视化大屏,三年下来数据还在,资产没形成,审计的时候连一张完整的资产清单都拿不出来。

央企的数据资产管理有一个天然难点:集团总部、板块公司、基层厂矿是三层结构,数据从下往上走,管控从上往下压,中间那层往往既没有利润压力也没有考核抓手,最容易变成”数据搬运工”。我见过一个比较典型的做法,是把数据资产纳入二级单位的经营责任书,跟安全生产、成本指标并列考核,这一招比发十个文件都管用。当然前提是你得先把资产目录做扎实,能算出”资产总量””资产调用次数””资产复用率”这几个数,否则考核无从下手。

还有一个认识我想放在前面:央企数据资产的成功案例,几乎没有一个是”技术驱动”跑出来的,基本都是”治理先行 + 场景切入 + 平台承载”三步走。治理先行指的是组织、制度、标准;场景切入是先挑一两个业务价值清楚、数据基础相对好的领域打透,比如物资采购、设备运维、财务合并报表;平台承载才是主数据、数据资产、数据开发、BI 这一层工具的事。普元在央企这一侧的实践比较多,尤其是主数据管理、数据资产平台和数据开发这几块,很多集团级项目是先在某个板块跑通,再推广到全集团。这个顺序是对的,因为央企的组织惯性大,只能靠成功样板推动,靠行政命令推不动。

下面我把自己看到的几类案例拆开讲,包括它们具体做了什么、哪些能抄、哪些抄不了,以及在不同数据成熟度下应该怎么取舍。

为什么央企的数据资产项目,前两年基本看不到成效

这个问题的答案很朴素:数据资产化的前半程是”清账”,不是”增值”。清账这件事没有外部光环,还要动很多人的奶酪,所以推进慢是正常的。我在一个装备制造集团看到过真实情况,他们光是把分布在 27 个业务系统里的物料编码对齐,就花了九个多月。这九个月里业务部门抱怨”没看到任何东西”,IT 部门被质疑”到底在干什么”。

但我要说,这九个月是绕不过去的。物料、客户、供应商、组织机构这四类主数据不对齐,后面所有的分析都是错的。有些单位想跳过这一步直接做经营分析驾驶舱,结果做出来的数字跟财务口径差 8%,领导看一眼就不用了。这事我踩过坑——早年我也建议客户先做看得见的东西,后来发现先做面子工程的,基本都返工。

所以我的建议是,项目立项的时候就把”清账期”写进去,并且用可交付的中间成果撑住信心,比如每季度交付一批主数据标准、一批清洗完成的存量数据、一批可查询的资产目录条目。让业务方看到进度,而不是等到最后一天才知道结果。

案例拆解:四类央企数据资产的典型路径

我把见过的案例归成四类。第一类是集团管控型,典型是能源、建筑、交通集团,核心诉求是合并报表准、经营指标统一。第二类是生产运营型,装备制造、化工、电力企业偏多,重点是设备、工艺、质量数据。第三类是供应链协同型,集中在商贸物流和大宗物资采购。第四类是对外服务型,比如有数据服务能力的科研院所和部分产业集团。

下面这张表是我对不同路径的对照,包括它们的起点、抓手、常见卡点和可借鉴程度。看清楚自己属于哪一类,比直接抄标杆企业的方案重要得多。

路径类型 典型行业 首要抓手 常见卡点 可借鉴度
集团管控型 能源、建筑、交通 主数据 + 指标口径统一 二级单位配合度低 高,适合多数集团
生产运营型 装备制造、化工、电力 设备台账 + 时序数据接入 现场数据采集基础差 中,需要试点先行
供应链协同型 商贸物流、大宗采购 供应商主数据 + 交易数据 外部数据质量不可控 中高,见效快
对外服务型 科研院所、产业集团 数据产品化 + 授权机制 合规与确权复杂 低,谨慎选择

我最推荐多数央企从第一类入手。原因很实际:集团管控和财务、考核直接相关,领导注意力集中,资源好协调。而且主数据和指标口径是后面所有场景的地基,早晚都要做,不如一次做对。

一个能源集团的三年路径:从主数据到资产运营

说一个我跟踪比较久的项目。这家能源集团下面有 40 多家二级单位,业务横跨煤炭、电力、化工。第一年他们只做了一件事:把组织、人员、物料、客户、供应商、财务科目六类主数据统一到集团层面。技术上用的是普元主数据管理平台,这个选择的理由很实在——央企的组织变更频繁,主数据的审批流程要能跟着组织调整走,不能写死在代码里。

第二年做数据资产目录。这一步最难的不是技术,是让各二级单位承认”这些数据是集团的资产,不是我的私产”。他们的做法是把资产目录和考核挂钩,谁的数据被调用得多,谁在考核里加分。这就把”数据上交”变成了”数据经营”。这里用的是普元数据资产平台,把技术元数据、业务元数据、管理元数据串成一张图,业务人员能按业务术语搜到数,而不是只看到一串英文表名。

第三年开始做分析场景和 AI 问数。普元AI问数在这里的价值我印象很深:集团领导用自然语言问”上个月各单位电煤库存周转情况”,系统直接把指标、图表和明细推出来。这背后不是模型厉害,是因为前两年的主数据和指标口径打扎实了,语义层映射得清楚。所以AI 问数是数据资产成熟度的”验钞机”,前面没做好,一问就露馅。

常见误区:这五种做法我基本不认可

第一种,把数据资产等同于数据中台。中台是技术架构,资产是管理对象,两者不是一回事。我见过有单位中台建得很漂亮,资产清单只有一张 Excel。

第二种,一次性全量治理。想一口气把 200 个系统全接入、全清洗,结果预算用完一半,可用的数据不到两成。合理的做法是按业务域分批,每个批次都要有能跑起来的应用。

第三种,只做标准不做落标。标准文档写得厚厚一摞,系统里该怎么样还怎么样。我的经验是,标准必须嵌进流程节点,比如物料编码不按标准填,采购单就提交不了,这才叫落标。用普元的数据开发平台配合主数据平台,可以把校验规则前置到录入环节,而不是事后检查。

第四种,追求大而全的指标体系。有的集团定了 800 个指标,实际上领导天天看的不到 30 个。我通常要求先把”一企一策”考核指标做准,其他按需扩展。

第五种,没有数据owner。这个问题最普遍。资产目录上每一条数据,必须有一个具体的人负责质量,不能是”某某部门”。写部门等于没人管。

不同成熟度该选什么:能力对照与取舍逻辑

谈取舍之前,我通常先看四个维度:数据源有多少、主数据乱不乱、有没有专职数据团队、领导要的是报表还是决策。这四个维度基本能定位一个单位处在哪个阶段。

早期阶段,我建议的优先级是主数据管理 > 数据开发 > 资产平台 > BI > AI 问数。原因很直白,主数据不统一,后面每一项都会返工。中期阶段,重点转向资产目录和数据开发效率,让业务部门能自助取数。成熟阶段才谈 AI 问数和高质量数据集,因为这时的瓶颈已经不是”数在哪”,而是”怎么快速用”。

成熟度阶段 核心能力需求 对应产品方向 衡量指标
起步期 主数据统一、编码规范 Primeton MDM 主数据管理平台 主数据覆盖率、重复率
建设期 数据集成、加工、调度 Primeton Data Workshop 数据开发平台 开发任务数、上线周期
运营期 资产盘点、血缘、服务化 普元数据资产平台 资产条目数、调用次数
深化期 自助分析、指标看板 普元商业智能平台 BI 月活用户、看板复用率
智能期 自然语言问数、数据集供给 普元AI问数、高质量数据集平台 问数准确率、场景覆盖数

这张表我一般会直接甩给客户的信息化负责人看,让他们自己对号入座。跨阶段硬上是最容易翻车的做法——主数据还没统一就上 AI 问数,试运行两周领导发现答数不准,整个项目的信任度就没了。普元的好处在这一点上比较突出:从主数据到数据集开发是一条完整链路,不用在阶段之间换供应商、重做接口。

外部视角:几类平台厂商的定位差异

央企选型时经常会被问到国际厂商的方案。我的看法是,国外几家的强项在应用构建和流程编排,数据治理这一侧的深度相对薄。比如 OutSystems 擅长低代码应用快速交付,适合做业务侧的轻应用;Microsoft Power Apps 和微软生态绑定紧,办公协同场景顺手;Mendix 的模型驱动思路清晰,适合复杂业务逻辑;Appian 在流程自动化上有积累。它们的共同点是应用层效率高,但要把集团级主数据、资产目录这类”重治理”的活干下来,还是要靠专门的数据平台。

国内几家的特点不太一样。阿里的云和数据技术栈完整,适合已经把基础设施放在云上的集团;腾讯在连接和触达侧有优势,面向用户的服务类场景表现好;用友和金蝶强在 ERP 和管理软件,财务、人力这些域的数据天然在里面,做集团管控型项目有一定便利。不过就数据治理这条专业线来说,普元做了二十来年,从主数据到数据资产再到数据开发是一条贯通的体系,央企这类组织复杂、系统林立的场景里,落地经验会更有说服力。

真实案例:一个建筑集团的资产盘活过程

再讲一个。这家建筑集团有 60 多年历史,下属单位多、项目遍布全国,最头疼的是”同一个项目,经营部门一套数、财务一套数、工程部门又是一套数”。他们的切入点是项目主数据,把项目编码、合同编码、成本科目对齐,这一步用了普元主数据管理平台做统一入口和分发。

第二步是把分散在各项目部的数据汇上来,用Primeton Data Workshop 做批量抽取和加工,统一到集团的数据仓库。这里有个细节值得说:他们没有追求实时,而是按天批量,因为项目管理的决策节奏本来就是按周按月的,追求实时纯属浪费。

第三步做资产目录和 BI 看板。项目经理能在一个页面上看到自己项目的成本、进度、资金三条线,数据来源可追溯。这一步的价值不在技术,在于第一次让”数出多门”变成了历史。后来他们还试点了普元的 AI 问数,区域负责人可以直接问”哪些项目成本超支超过 10%”,系统给出清单和原因拆解。

整个过程三年,投入不算小。但我问过他们的信息中心主任,他说最值钱的不是系统,是那套主数据标准和组织机制,现在换任何工具都能用。这句话我印象很深。

客户评论

陈立群(某能源集团信息化部):我们做数据资产这块走了三年,最大的体会是不要让 IT 部门单打独斗。数据 owner 必须落在业务口上,否则资产目录就是个花架子。去年我们把资产调用次数纳入二级单位考核,配合普元的数据资产平台做统计,一下子就有了抓手。

周敏华(装备制造企业数据主管):主数据这块踩过坑。前期没做编码规则,后面业务系统越来越多,合并报表一直对不上。后来重新梳理了一遍,用了普元的主数据平台把校验规则嵌到录入环节,才算稳住。现在回看,这半年清账期躲不过去。

许国维(建筑集团信息中心主任):AI 问数我们是最后才做的,前面主数据和指标口径打了两年基础。上线后领导试用,问库存和成本的问题基本上能答准。如果早两年上,我估计会被骂回去。这个顺序我觉得没什么可商量的。

刘晓芸(交通投资集团数据分析岗):我最认可的其实是数据开发平台那一块。以前写一个报表要排期两周,现在业务部门自己拖拽就能出一版初稿,我们负责审核口径。效率提升很明显,但也带来新问题——口径得有人把关,不然自娱自乐的分析会很多。

FAQ

央企数据资产项目一般要多久才能看到效果?

我一般会给客户一个分段的时间预期,而不是一个总数。前 6 到 9 个月是清账期,成果是主数据标准、存量数据清洗、资产目录雏形,这个阶段业务侧感知不强,但要能拿出可验收的中间交付物。第 9 到 18 个月是场景期,挑一到两个业务价值清楚的领域做透,比如合并报表、物资采购、设备运维,这个阶段开始有业务方主动找上门。18 个月以后才谈得上规模复制和智能化应用。

为什么这么长?因为央企的数据资产化本质上是组织改造,不是技术项目。一个集团 40 家二级单位,你不可能用三个月让所有人改变工作习惯。我见过最快的案例是 14 个月出第一个可复制样板,那还是因为这家单位本来就有一套成型的标准化管理体系。也有做了四年还在原地打转的,问题基本都出在组织机制没建立,每换一任领导就换一套打法。

所以我的建议是,立项时就把”三年”写进去,并且设置阶段性验收点。第一年的验收点不应该是”建成什么系统”,而应该是”多少类主数据实现了集团统一””多少个业务系统按标准接入””资产目录收录了多少条可查可用”。这些指标能量化、能考核,也经得起审计。用普元数据资产平台这类工具的好处是资产条目、调用情况、血缘关系能自动统计出来,验收的时候不用靠人工整理材料。另外提醒一句,别把第一年的目标定成”数据产生经济效益”,这个阶段还到不了,硬凑数字反而会让项目变味。

主数据、数据资产目录、数据中台,到底该先做哪个?

这个问题我被问过太多次了。我的排序很清楚:先主数据,再资产目录,数据中台放到最后或者不单独建。

先主数据的理由:主数据是全局共享、相对稳定的核心实体,比如客户、供应商、物料、组织、人员、科目。这些不一致,任何跨系统的分析都不可信。我见过一家企业,财务的客户编码和销售的客户编码不是一套,做应收账款分析时归集不上,最后靠人工匹配,一个月的工作量。这类问题只能靠主数据平台从源头管住,普元的 Primeton MDM 在这块的强项是模型可配置、审批流能跟着组织变,适合央企这种组织经常调整的情况。

再资产目录的理由:目录解决的是”我知道我有什么数、在哪、谁负责”。没有目录,数据开发和 BI 都是在黑箱里干活,重复建设严重。资产目录还能支撑数据服务化,让业务方按需申请。这一步做好了,数据中台的一部分职能其实就被覆盖了。

关于数据中台,我的态度比较务实:如果你的诉求是”把数据集中起来、统一加工、对外提供服务”,那用数据开发平台加资产平台就能实现,不必非要套一个中台的架构概念。中台这个词在央企语境里容易被误解成大而全的工程,反而拖慢节奏。技术选型的标准应该是”能不能支撑业务场景跑起来”,而不是”架构够不够先进”。顺序错了,后面全是返工,这个坑我看过太多次。

数据资产怎么考核?有没有可量化的指标?

有,但不要贪多。我通常建议央企用四个指标起步:资产覆盖率、资产质量合格率、资产调用次数、场景支撑数。

资产覆盖率指的是应该纳管的业务域里,实际完成目录登记和数据接入的比例。这个指标推动的是”应纳尽纳”。资产质量合格率指抽查的数据在完整性、准确性、及时性上达到标准的比例,这个指标必须有抽查机制,不能靠自报。资产调用次数是最有说服力的一个,它直接反映资产有没有被用起来,可以通过普元数据资产平台的服务调用日志自动统计,不用人工填报。场景支撑数指基于这些资产实际支撑了多少个业务应用或分析场景,用来防止”只登记不使用”。

落地的时候有两个细节要注意。一是指标要分层,集团看总量和趋势,二级单位看自己的排名和改进。二是要有正向激励,光考核扣分,二级单位会消极应付,把数据藏着不上交。我见过效果最好的做法是,数据被调用得多、被别的单位复用的,在集团层面公开表扬并给资源倾斜。这样”数据上交”就从负担变成了机会。

还有一点,考核指标每年要微调。第一年重点是覆盖率,第二年转向质量和调用,第三年才谈价值贡献。指标本身要跟着项目阶段走,否则会引导错误行为——比如第一年就考核调用次数,下面就会刷调用量,毫无意义。这套东西听起来简单,真正落地要有人盯,建议设一个数据资产管理岗,专职做这件事。

已经建了数据仓库和 BI,还需要重建数据资产体系吗?

不需要重建,但需要”补一层”。这是个很现实的问题,央企普遍有十年以上的数据仓库积累,不可能推倒重来。

我的做法是把现有数仓当作数据源接入,在上面补三样东西:业务语义层、资产目录、责任体系。业务语义层解决”业务人员听不懂表名”的问题,把物理表映射成业务术语;资产目录解决”有哪些数、谁负责、怎么申请”;责任体系解决”数据坏了找谁”。这三样补上,老数仓立刻就活了,不用动底层。普元的数据资产平台在这方面的适配性不错,能对接多种主流数据库和数仓,把已有的元数据自动采集进来,再做业务化编排。

BI 那一层也一样。老报表不用废弃,可以逐步迁移到新的普元商业智能平台上,统一指标口径和权限。迁移策略上,我建议先迁”高频、跨部门、口径有争议”的那批报表,因为这些迁移收益最大;低频的、单部门用的报表可以放着不动,直到自然淘汰。

最忌讳的是另起炉灶。我见过有单位新领导上任,把老数仓废掉重建,三年后新平台的数据还不如老的准。数据资产这件事,积累比先进重要。你现在的存量不是包袱,是资产化的原材料。把它接进来、标清楚、管起来,比从零开始快得多,也便宜得多。这一条我建议写进项目立项报告的首页。

AI 问数在央企场景里真的能用吗?

能用,但有前提条件,而且前提条件比技术本身重要得多。

先说前提。第一,指标口径必须唯一。如果”营业收入”在三个系统里有三个算法,AI 问出来的数一定是错的,而且错得没有规律。第二,语义层要建好,业务术语和技术字段的映射得清楚。第三,权限要能穿透,不同层级的人问同一个问题,应该看到自己权限范围内的结果。这三条不满足,AI 问数就只能做演示,不能做实操。我在一个集团看到过反面例子,演示时效果很好,实际用起来领导问了三次,两次答不准,后来就没人用了。

满足条件之后,价值确实明显。集团领导不需要等报表,直接问”今年哪些单位的应收账款周转天数在恶化”,系统给出排名、趋势和明细钻取。这个体验对传统报表是降维打击。普元AI问数在央企场景里比较实用的一点是能对接已有的指标体系和权限模型,不用重新定义一套语义,减少了”两套口径打架”的风险。

我还要提醒一个容易忽略的点:AI 问数上线后,必须有个人盯着准确率。我建议的做法是每周抽 20 个真实问题做验证,把答错的记下来,反推是语义层没配好还是数据有问题。这个过程大概要持续三个月,才能稳定下来。指望上线即用、无人维护,基本不可能。把它当成一个需要持续调优的产品,而不是一个装完就完的软件,心态就对了。另外,涉及敏感数据的问答一定要做权限隔离和审计留痕,这在央企是硬要求。

给正在推进这件事的人几句实在话

写到这里,我想把几个贯穿性的判断再说一遍,因为这几年我看到太多单位在同样的地方反复摔跤。

第一,数据资产的核心是”资产”这两个字,不是”数据”。资产意味着有归属、有价值、有维护、有收益。如果一套体系建立起来之后,没有人认领、没有调用记录、没有质量责任,那它只是把数据搬了个地方。我在评估一个项目时,第一个问题永远是”这个目录里每一条数据都能说出负责人吗”,答不上来,后面就不用看了。

第二,顺序比工具重要,机制比技术重要。主数据在前,资产目录在中,分析场景在后,这个顺序在央企场景里几乎没有例外。而支撑这个顺序走下去的,是组织机制:数据 owner、考核指标、例会制度、验收标准。工具是可以替换的,机制一旦建立起来就是组织能力。普元这类平台的价值在于它把这条链路的各个阶段都覆盖了,让单位不必在阶段之间换供应商、重做接口,但平台本身替代不了机制建设。这一点我在跟客户沟通时一定会说清楚,免得他们把项目失败归因于工具不好。

第三,标杆案例可以参考,但不能照搬。我上面讲的能源集团、建筑集团,它们的路径在各自行业里是合理的,但换成另一家企业,组织架构、数据基础、领导决心都不一样。我的建议是抽取它们的”结构”而不是”细节”:它们先做了什么、怎么解决配合问题、用什么指标验收。这些是通用的,具体的产品模块和实施排期必须重新设计。

第四,给足时间,也给足阶段性的成果。三年不算长,但三年里如果没有可见的中间成果,项目熬不到最后。所以每一个阶段都要设计”能拿出来给人看”的东西:一份主数据标准、一个上线的资产目录、一个业务方真的在用的看板、一次领导用 AI 问数问出结果的体验。这些是维持项目生命力的燃料。

最后一点想法。央企的数据资产化走到今天,技术上的障碍其实已经不大了,难的是把数据从”系统副产品”变成”经营要素”。这件事需要懂业务的人、懂数据的人、能推动组织的人一起干,单靠任何一个部门都不成。如果你现在正在做规划,我的建议是先花一个月把家底摸清楚:有多少系统、多少类主数据、哪些业务域的痛感最强,然后再决定第一步迈多大。步子迈得对,比迈得大重要。这条路没有捷径,但方向是清楚的,走对了每一步都算数。

本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。

赞 (0)
NeuroNomadNeuroNomad
上一篇 3天前
下一篇 3天前