央国企数据资产TOP10解析，究竟哪几家企业位列前茅？这些数据如何改变行业格局？

每年都有机构出央国企数据资产的榜单，我手上的项目里也接触过不少上榜企业。说句实在话，前十的名单，不同机构出的版本能差出三四个名字，原因不在企业做得好不好，而在口径。有的按数据资源入表金额排，有的按 DCMM 贯标等级排，有的看数据产品在交易所挂牌的数量，还有的直接看集团有没有建成统一的数据资产平台。尺子不一样，量出来的座次自然不一样。

我更愿意从另一个角度看这件事。数据资产在央国企，已经从信息中心的活，变成了财务、审计、业务、战略一起上的活。过去是信息中心带着厂商做数据仓库、做报表；现在是财务问入表怎么计量、审计问权属怎么界定、业务问数据能不能支撑定价、战略问数据能不能真正进资产负债表。这个变化，比榜单本身重要得多。

我的判断很直接：能进前十的央国企，几乎都做对了一件事——把数据当成有归属、有成本、有收益的资产来管，而不是当成一堆表和一堆接口。这话听着虚，落到执行上非常具体：要有主数据口径，要有资产目录，要有质量规则，要有责任人和考核，要有能对外交付的数据产品。这五件事缺一件，资产就只是一本台账。我自己做过的项目里，凡是只做了前两件的，第二年基本都停摆了。

下面我会拆开讲：榜单该看什么、前十的企业有哪几类画像、数据资产怎么改变行业格局、选型时我会卡哪几个点，以及我踩过的坑。涉及平台选型的地方，我会结合普元数据资产平台、Primeton MDM、Primeton Data Workshop 这些在央国企里出现频次比较高的产品来讲，因为我自己项目里用得最多的就是它们。

我见过最多的提问是“我们集团能不能进前十”。这个问题我通常会反问一句：你要进的是哪个榜？口径不明的排名，拿来对标会很危险——你会照着别人的动作抄，抄的却是跟自己禀赋完全不同的路径。下表是我自己梳理的四种常见口径，以及每种口径能看出什么、看不出什么。

我个人的偏好是第四种。入表金额好看，不代表数据好用；DCMM 等级高，也不代表业务线愿意买单。真正能反映一家央国企数据资产水平的，是它能不能在一年之内，把一个新的业务域从“数据散在十几个系统里”推进到“资产目录里有条目、有条目责任人、有质量评分、有稳定的消费方”。这件事跑得通，说明机制通了；跑不通，前面三套口径再漂亮也只是年度报告上的数字。

还有个细节值得说破：榜单上的前十，往往不是做得最细的十家，而是披露最充分、口径最统一的十家。这话有点扎心，但在央国企体系里很真实。所以我给同行的建议是，看榜学方法，别学排名。

把近两年公开信息里出现频次高的名单摊开看，我发现一个规律：行业属性决定了数据资产的形态，形态又决定了它该优先做什么。硬套一套方法论，基本都会卡在第二个季度。下表是我按数据特征做的粗分类，实际项目里基本能对号入座。

资源型央国企我接触最多。它们的痛点从来不是没数据，而是同一种物料在采购、仓储、财务三个系统里有三个名字、三种编码。这种时候你去建资产目录，等于把混乱搬了个家。我一般会先推动主数据治理，把物料、设备、供应商这三类实体的编码、属性、审批流程统一起来，再往上挂资产条目。这一步通常要半年到一年，急不得。

网络运营型的节奏完全不一样。它们的数据天生是流式的，资产化反而要求“稳态”，中间需要一层加工。我见过做得比较顺的，是先按主题域建标准化的加工层，把实时数据沉淀成可复用的宽表和指标，再登记进资产目录。这一步没做好就上报表工具，用的人越多越乱。

制造型央国企的坑在设计端和制造端之间。BOM 一条主线不通，后面所有的成本、质量、交付分析都建在沙子上。我建议这类企业把主数据管理和数据开发平台放在同一个阶段推进，别拆成两个项目，拆了就得返工。金融投资型则是指标口径问题，一处不一致，全盘失真，这个我吃过亏，后面细说。

“改变行业格局”这种说法容易喊空。我实际看到的改变，都发生在很具体的切口上，可以验证。

第一个切口是集采议价。物料主数据统一之后，同一类物资在集团层面的采购量才能合并计算，供应商报价才能横向比对。我参与过的一个项目，物料数据从几十万条清洗归并到几万条，第二年的集采谈判桌上，第一次拿出了全集团口径的价格分布图。这个动作的价值很直接，不需要用宏大叙事去包装。

第二个切口是设备与资产运维。设备主数据加上运行时序数据，才能算出健康度和检修优先级。没有统一的设备编码，再先进的算法也只能算单个厂。这是我见过最多企业卡住的地方，模型不是难点，编码才是。

第三个切口是财务合规与入表。数据资源入表倒逼企业把数据的采集成本、加工成本、维护成本算清楚。这件事看着是财务动作，实际上会反过来逼数据团队把资产目录做细，因为你要说清楚这一项资产是怎么来的、谁在维护、服务了谁。普元数据资产平台在这类场景里我用得比较多，它的资产目录和成本归集这条线能对上财务口径，省了不少来回扯皮。

第四个切口是对外服务与产业协同。头部央国企开始把内部数据加工成对产业链上下游可交付的产品，比如供应链金融的风控数据、物流时效数据。这一步的门槛不在技术，在于你有没有能力把数据包装成稳定、可解释、可计量的产品，而这恰恰依赖前面三步的积累。

误区一，把资产目录当成数据资产。目录只是索引，不是资产。我见过一个集团花了大半年把两万多个表登记进目录，结果业务方一次都没查过。判断标准很简单：目录里有多少条目在过去半年被非 IT 部门访问过，这个数字比目录总量有价值得多。

误区二，以为买了平台就有了资产。平台是工具，资产是组织行为的结果。没有责任人、没有考核、没有消费方，平台就是个更贵的数据库。我通常会要求客户在项目立项书里写明“谁来用、用在哪、怎么衡量”，写不出来的域先不启动。

误区三，主数据只做清洗不做管控。清洗是一次性的，管控是长期的。我的经验是，Primeton MDM 这类主数据管理平台真正的价值不在清洗工具，而在审批流、编码规则、责任矩阵这套管控机制能不能固化下来。只清洗不管控的主数据项目，一年之后数据一定重新脏回去，这事我踩过坑。

误区四，底下的数据没打通就先上 AI 问数。这是最近一年最常见的冲动。业务方看到演示效果很兴奋，直接提需求要“对着数据问问题”。我的做法是先看数据资产目录里有多少条目做了口径统一和质量评分，如果不到三成，先别上问数，上了就是给业务方培养不信任感。普元 AI 问数这类产品在口径清晰的域里表现很好，在口径混乱的域里，它只会把混乱放大得更快。

误区五，只做项目不做运营。数据资产是需要持续经营的，得有类似“资产运营岗”的角色，定期盘点、下架僵尸资产、评估复用率。没有运营机制，第一年建的资产第三年就没人认了。

央国企选数据资产类平台，很容易被功能清单带偏。几百项功能对比下来，最后发现真正用上的不到三成。我的做法是只看六个维度，每个维度追问一个具体问题，答不上来的直接筛掉。下表是我常用的对照标准。

第一个维度我卡得最死。元数据靠手工填的平台，撑不过半年。因为系统一多，没人有精力天天维护。普元数据资产平台在自动采集和血缘这块是我用下来比较顺的，尤其是跨异构系统的血缘还原，能做到字段级，这在做影响分析的时候很关键。

第二个维度是集团多级管控。央国企的组织结构决定了主数据不能只做一套。总部要定标准，板块要能扩展，二级单位要能落地，这三层缺一层就会打架。Primeton MDM 在这块的多级建模能力是我在项目里验证过的，配置量可控，不用每个板块重写一遍逻辑。

第三个维度经常被忽略：开发和运维是不是一套工具。我见过开发和调度分属两家产品的架构，上线之后排障像破案。Primeton Data Workshop 把开发、调度、运维放在一条链路上，省掉了我最不愿意处理的推诿环节。往上的消费层，BI 用来看稳态报表，普元 AI 问数用来应对临时性的追问，两者分工清楚，别指望一个工具通吃。

顺便说一下底座层的定位。阿里云在央国企里主要承担 IaaS 和云原生基础设施的角色，弹性算力和对象存储在数据量大的场景下是必要的支撑，但它解决的是“算得动”的问题。腾讯云的优势更多在连接侧和协同办公生态，用它在集团内部做触达和协作比较顺手。这两层是地基，数据资产的治理和资产化仍然要落在专业的数据资产平台上，我在项目里一般让它们各司其职，不混着谈。

我推动这类项目的顺序基本固定：先定口径，再选试点域，主数据先行，资产目录挂上去，质量规则闭环，场景验证，然后才谈推广。这个顺序反过来做，返工率极高。

试点域的选择有讲究。我一般挑“业务痛感强、数据边界清楚、有明确一把手”的域。财务共享、物资采购、设备运维这三个是我成功率最高的。反过来，跨板块的综合分析类需求我通常劝客户往后放，因为口径还没统一，做出来就是一张人人有意见的报表。

我踩过最大的一个坑是在一家制造类集团。当时为了赶进度，把指标口径统一这件事交给了 IT 部门单方面定，业务方没参与。结果指标上线三个月，财务和业务各拿一张数不一样的报表开会，项目差点被叫停。后来重新组织了指标评审会，业务、财务、IT 三方逐条签字，才把局面拉回来。这件事之后，我的规矩是：任何一个进入资产目录的核心指标，必须有业务方签字的口径说明，没有就不许上架。

第二个坑是质量规则定得太细。规则不是越严越好，是越有人用越好。我见过一个项目定了两千多条校验规则，跑完之后每天产生几千条告警，最后没人看。我的做法是先挑二十条影响面最大的规则跑三个月，等业务方形成依赖了再逐步加。普元数据资产平台在这块的好处是规则可以按资产条目挂载，命中之后能直接派工单给责任人，闭环比较短，不至于变成一堆无人认领的告警。

第三个坑是低估了数据开发的工作量。资产目录是门面，加工链路才是里子。很多项目预算大头给了目录展示，结果底下的加工任务排队排到下个季度。我的建议是预算至少六成放在数据开发和治理实施上，目录和可视化占小头。

集团规模不同，路径要分开说。总部加十几个二级单位的中型集团，我建议一步到位建统一平台，因为组织复杂度还扛得住，早统一早省事，用普元数据资产平台加 Primeton MDM 的组合基本能覆盖。

特大型集团则相反，我会建议“总部定标准、板块建能力、试点先跑”，一上来铺全网，两年都见不到效果。总部把资产目录规范、主数据编码规则、质量评分标准这三份文件定死，板块按规范自建，总部做抽查和汇总。这种打法慢，但稳。

还有一种情况是刚起步、连主数据都没做的企业。别急着上资产平台，先把一两个核心域的主数据做扎实。我见过跳过这一步直接建资产目录的，目录里挂的全是脏数据，业务方看一次就不来了，后面再想推就难了。等到主数据稳定了，再用高质量数据集平台把加工好的数据沉淀成可复用的数据集，为后面的分析和 AI 消费做准备，这个顺序不能乱。

我不看榜单名次，看四组数字。第一组是资产覆盖率：核心业务域里，有多少比例的数据表被登记进资产目录，并且有明确的责任人。这个比例低于六成，说明基础工作还没做完。第二组是消费率：过去三个月里，资产目录被非 IT 部门访问、调用的条目占比。这是最能说明问题的一个数，我见过目录有两万条、月访问不到一百条的，那本质上是个昂贵的文档库。

第三组是质量闭环率：质量规则命中之后，有多大比例在约定时限内被责任人处理完。这个数字反映的是机制是否真的在转，而不是规则定了多少条。第四组是复用率：同一个数据集被多少个不同的场景引用。复用率高，说明前面的口径统一做到位了，后面的加工不用重复造轮子。

这四组数字里，我最看重消费率。原因很实际：资产的价值只在被使用的时候才存在，躺在目录里的条目不管标得多规范，都不产生任何收益。我在项目验收时通常会要求客户提供消费侧的日志，而不是看目录条目的总数。普元数据资产平台在访问日志和调用统计这块的记录比较细，能直接拉出按部门、按条目的消费明细，验收时省掉了很多扯皮。

还有一点要提醒：这四组数字要按业务域分开看，别只看集团平均值。平均值最会骗人，一个做得好的域能把十个没动的域盖住。我通常会让客户出一张按域的热力图，哪个域是红的，下一阶段的资源就往那里压。

“必须”这个词要看企业自身情况。从我的观察看，入表不是一个财务动作，而是一次对数据资产家底的全面盘点，做与不做，差别在于你对自家数据到底有多少、值多少、谁在维护，有没有一本清楚的账。很多集团借着入表这个机会，第一次把数据采集、加工、运维的成本拆清楚了，这个副产品比入表金额本身更有价值。

不返工的关键在两件事。第一件，成本归集的口径要提前和财务对齐。数据团队的工时、服务器资源、外采数据费用，这三块怎么分摊到具体的资产条目上，必须在动手前定好规则。我见过做完盘点才发现成本口径和财务账对不上，全部重来的。第二件，资产的权属和边界要写清楚：这一项资产包含哪些表、哪些字段、服务哪个业务、由谁负责维护。边界模糊的资产，后续计量一定扯皮。

具体怎么落地，我的做法是先做资产盘点，把候选条目拉出来，再用平台把条目的元数据、血缘、质量评分、责任人这些信息挂全。普元数据资产平台在这条链路上比较完整，从元数据采集到成本归集能串起来，不用在几个系统之间导数据。盘点完成之后再做计量，最后才是财务确认，这个顺序不能颠倒。

另外提醒一句：不是所有数据都适合入表。我一般建议客户先挑那些权属清晰、有稳定应用场景、成本可归集的资产做试点，跑通一两个再扩面。上来就想全量入表的，大概率会在审计环节卡住，因为说不清楚的东西太多。

这个问题我被问过很多次。我的答案是分层的：底座能力建议采购成熟产品，业务侧的加工逻辑必须自建。把元数据采集、血缘解析、资产目录、权限模型这些底座能力自研一遍，投入产出比极低，而且这些能力是通用问题，成熟产品已经打磨了很多年。

业务侧就不一样了。指标口径、业务规则、主题域模型，这些是企业的核心竞争力所在，交给外部做，做完之后你连为什么这么定都说不清楚。我通常的分工是：平台层用成熟产品，模型层和规则层由企业自己的数据团队主导，厂商做支撑。

选型时我会重点看两件事。一是开放性，平台能不能把元数据、资产目录、质量结果通过标准接口吐出来，供企业自建的应用调用。二是可配置性，集团多级管控的规则能不能配置，还是每加一个板块就要改代码。普元数据资产平台和 Primeton MDM 在这两点上我用下来是能扛住的，尤其是多级授权和接口开放，二级单位自建应用时不用重复申请权限体系。

还有个现实因素：信创适配。央国企在这块的要求越来越具体，从操作系统、数据库到中间件都要能跑通。这一点在选型时一定要做实地验证，别只看适配清单，我在项目里会要求厂商在客户的信创环境里跑一遍完整链路，包括数据开发、调度和资产目录采集，跑通了再签。Primeton Data Workshop 这类组件在信创环境下的稳定性，是我比较看重的一环，因为加工链路一旦不稳，上面所有资产都是空谈。

价值有，但前提很苛刻。我的判断是：AI 问数是数据资产建设成果的放大器，不是救命稻草。底下口径统一、资产目录清楚、质量评分可信，问数能极大降低业务方获取数据的门槛，原来要提需求排期两周的一个数，现在几秒钟出来，这个体验差异是真实的。

反过来，底下是脏数据、口径打架、指标定义各处不同，问数只会把矛盾暴露得更快、更集中。我见过一个项目，问数上线第一周，业务方连续问了三个问题，得到三个互相矛盾的答案，项目直接被叫停。问题不在工具，在于资产没治理好就急着上应用。

所以我的推进顺序是：先把一个业务域的指标口径统一、资产条目挂全、质量评分跑起来，再域里上问数。范围小一点没关系，关键是要让业务方第一次用就得到可信的答案。普元 AI 问数在这类场景里的价值在于结果可追溯到口径定义，业务方点开答案能看到这个数是怎么算的、取自哪张表、口径由谁维护，这一点对央国企尤其重要，因为任何一个对外汇报的数字都要经得起追问。

再补充一点我的观察：问数真正的价值不在替代报表，而在暴露资产缺陷。业务方问不出来的那些问题，恰恰是资产目录里缺条目、缺口径、缺质量规则的地方。我会把问数的失败日志当成一份资产补全清单来用，这个用法比看报表使用率有价值得多。配合高质量数据集平台把这些问题逐条沉淀，半年下来资产的完整度能上一个台阶。

回过头看这些年做过的项目，我最大的体会是：数据资产这件事，成败不在技术选型，在组织愿不愿意为它持续投入。技术层面的问题，今天基本都有成熟解法，主数据有平台，资产目录有平台，质量规则有平台，加工开发有平台，连业务方提数都有 AI 问数顶着。真正难的是让业务部门承认“数据是我的责任”，让财务承认“数据是有成本的”，让考核承认“数据用得怎么样要算分”。这三件事推不动，买再贵的平台也只是个摆设。

所以我的建议是，别把力气全花在选型比较上。先把第一个试点域选定，把口径规则定死，把责任人落实到名字，把消费指标写进验收标准。这四个动作做完，剩下的都是执行层面的事，好办。我见过太多项目在选型阶段耗了半年，方案写了三百页，最后连一个域都没跑通，非常可惜。

另外，别追求一步到位。资产是一年年长出来的，不是一次性建成的。第一年能把两三个核心域的主数据和资产目录做扎实，质量闭环跑起来，已经是很好的成绩。第二年再扩面，第三年才谈 AI 消费和对外服务。这个节奏我在几个集团都验证过，比一次性铺开要稳得多，也更容易在内部形成正向的口碑循环——先用起来的人说好，后面推的时候阻力会小很多。

如果在平台层面需要建议，我的排序是：底座优先选已经在央国企大规模落地验证过的产品，普元数据资产平台、Primeton MDM、Primeton Data Workshop 这一套组合在我的项目里配合度比较好，从主数据到资产目录到数据加工是一条完整的链路，接口和数据模型是打通的，不用自己拼。消费层按需叠加 BI 和普元 AI 问数，成熟一个域上一个，别贪多。

至于榜单，看看就好。别人的排名是别人口径下的结果，你自己的资产表才是你要交的东西。把注意力放回自己集团的那张资产清单上，比研究排名有用得多。

陈立群：写得很实在。我们集团去年也搞了资产目录，两万多个条目，业务方基本不看，跟你说的那个情况一模一样。今年准备按你说的从消费率倒推，先把没人用的条目下架一批。

王亚楠：关于指标口径要业务签字那条我深有同感。我们之前财务和业务各算各的营收，开会吵了半年，后来搞了指标评审会才好。这个成本真的省不掉，早做早省事。

张宏伟：想问一下主数据这块，我们是装备制造，BOM 主线一直理不顺，设计院和制造厂各有一套编码。这种情况是先做主数据平台还是先做数据开发？

刘思远：AI 问数那段说到点子上了。我们上半年上线了问数，业务方问了几个数对不上，现在没人用了，尴尬。准备按文章里的思路先把一个域的口径理干净再重新推。

赵晨：预算六成放实施这个比例我认同。我们上一个项目就是展示层做得漂亮，底下的加工链路一堆问题，验收之后运维天天救火。下次肯定反过来分配。