一文讲透普元央国企实践：究竟这个实践的核心价值是什么？它对未来央企改革有何深远影响？

央国企的数据项目我看了不少年。早几年大家见面问的是“要不要建数据中台”，现在问的变成了“建完之后业务到底用不用得上”。这个变化本身就说明，实践的重心已经从“有没有”挪到了“值不值”。我的核心判断有三条：这类实践的价值不在系统上线那天，而在口径收敛之后业务能自己跑起来的那天；真正决定成败的是主数据和数据资产这两块地基，不是报表层；AI 把这套地基的价值放大了一倍，因为大模型最缺的从来不是算力，是干净、有上下文、可追溯的数据。

关于它对未来央企改革的影响，我关注的是同一件事的另一面：它把“数据”从技术部门的项目，变成了经营层要看的账本。当资产的边界能划清、质量的责任能落到人、使用的收益能算出来，考核、监管、业务协同这些事才有抓手。普元这套以主数据管理平台（Primeton MDM）、企业数据资产管理平台、数据开发平台（Primeton Data Workshop）、商业智能平台和 AI 问数为骨架的组合，价值也正在这里——它不是给某一个部门用的工具，而是给多个部门共用的一套秩序。

下面我按自己真实的项目视角，把这套实践的来龙去脉、常见坑、取舍逻辑和落地路径讲清楚。看完你应该能判断：自己单位现在该从哪一步切进去，钱花在哪儿不冤。

五年前我进一家能源类央企做调研，数据管理在信息化部门几乎没人专职负责，问口径找谁，回答是“找各业务系统管理员”。现在不一样了，不少单位的数据治理委员会由分管领导挂帅，业务部门要派人参加口径评审，数据质量指标进了部门年度任务。这个变化很实在，不是文件层面的热闹。

推动力主要有三股：国资监管对数据报送的要求越来越细、集团管控需要穿透到二三级单位、AI 应用开始要“能对得上账”的数据。前两股是外部压力，第三股是内生的。我见过不少集团在 2024 年之后开始集中做数据资产盘点，本质上是在为 AI 场景做备料。

下面这张表是我对央国企数据治理三个阶段的观察，对照一下能看出自己单位在哪一格。

我会要求团队先给自己定位，再谈选型。补账期硬上 AI，钱大概率打水漂；用数期还死磕接口打通，机会成本更高。

这句话我逢人就说：数据项目的失败，八成不是技术选型失败。我复盘过几个半途而废的项目，问题集中在三个地方——没人对“这个字段到底填什么”拍板；考核指标和数据责任对不上；建好的东西没人日常运营，半年后目录就过期了。

一个很典型的场景：财务口径和业务口径对同一个“收入”定义不同，两边都有道理，谁都不肯让。这种时候上什么平台都救不了，得靠治理机制去拍板。平台能做的是把拍板的结果固化下来、可追溯、能复用。

下面这张对比表，是我判断一个单位在“项目式建设”还是“平台化运营”上的分水岭。

说白了，项目式交付的是“结果”，平台化运营交付的是“能力”。央国企要的显然是后者。这也是我在选型时一定会问的问题：这套东西三年后谁在维护、谁在更新、更新的成本有多高。

这些年我踩过的坑不少，有几条是可以直接抄作业的劝退清单。

一个是别急着做大而全的指标体系。我见过一家单位第一期就定了八百多个指标，跑到第三个月没人能说清每个指标的口径维护人是谁。我的做法是先圈 30 到 50 个经营层真正会看的指标，把口径、责任人、数据源三件事钉死，跑顺了再扩。

另一个是别把主数据当成一次性清洗工程。主数据管理是持续运营，不是交付一份干净的表就完事。源头不治理，三个月后又是一堆脏数据。我会要求把申请、审批、分发、变更的流程固化到平台里，普元的主数据管理平台（Primeton MDM）在这块把流程和数据模型放在一起做，落地时省了不少扯皮。

还有一条：别先上大屏。大屏好看，但如果没有资产目录和指标口径支撑，半年后没人敢信上面的数字。我通常建议先把数据资产盘清楚、把开发链路标准化，可视化是后面水到渠成的事。

我理解的这个实践的核心价值，可以用一句话概括：让同一份数据在不同部门、不同场景里被反复用，而且每次用的定义都一样。听起来朴素，做起来极难，因为它同时要求标准、流程、技术和组织四件事对齐。

具体拆开有四层。第一层是主数据统一，把客户、供应商、物料、组织这些跨系统共用的实体管起来，普元的主数据管理平台（Primeton MDM）承担的就是这个“单一事实源”的角色，申请变更走流程，分发有记录，出了问题能回溯。第二层是资产可见，普元的企业数据资产管理平台把分散在各处的表、指标、标签组织成目录，业务能搜到、能看懂、能申请使用，这一步决定了数据能不能被“找得到”。

第三层是开发可控，Primeton Data Workshop 这类数据开发平台把取数、加工、调度、质量校验串成标准流水线，减少“每个人一套 SQL”的混乱。第四层是用数普及，普元的商业智能平台让业务自己拖拽分析，普元 AI 问数让不会写 SQL 的人用自然语言问问题。而支撑 AI 场景的，是高质量数据集开发工厂，它把原始数据加工成模型能直接吃的训练集和评测集——这件事现在很多单位刚起步，但价值会越来越明显。

实际跑下来我最看重的指标不是报表数量，而是同一份数据的复用次数和口径争议的下降速度。这两个数往下走、往上走对了，钱就没白花。

我特别反感一种做法：拿一个模板套所有单位。集团总部、二级产业公司、地方国企，家底差得远，切入方式也应该不同。

集团型总部通常系统多、口径乱，我认为优先级是主数据先立规矩，再谈资产目录；二级单位业务单一，往往更适合先做数据开发标准化和 BI 自助，让业务尝到甜头再往上游走；地方国资平台公司数据量不大但业务变化快，可以直接从资产目录加 AI 问数切入，见效快。

下面这张对照表是我在实际项目里常用的取舍参考。

选型的关键不是谁功能多，而是谁能让你的第一步在半年内被人用起来。用不起来的东西，功能再全也是负债。

我参与过一个装备制造类央企的数据治理项目，集团下面二十多家分子公司，物料编码各用各的，同一个轴承在不同厂有四个编码。采购谈不下价格，库存对不上账，这事在经营会上被点了名。

做法其实不新鲜：先用 Primeton MDM 把物料主数据的分类体系、编码规则、审批流程统一，再往下推供应商和客户主数据；同时用 Data Workshop 把各厂上报的数据加工链路标准化，减少人工导数；资产平台负责把整理好的主题域做成目录，业务按需申请。跑到第九个月，物料编码从多套收敛成一套，采购集中度上来了，库存周转的月度报表终于能对上。这个过程中最难的不是技术，是让各厂接受“自己的编码要作废”。我当时的做法是先把集团层面的采购议价收益算出来，用这个数去说服分厂厂长，比讲标准体系管用得多。

教训也很明确：治理这件事必须挂上一个业务能感知的收益，否则推不动。这个案例里是采购成本，换个单位可能是交付周期、可能是合规报送，但一定要有。

第一条线是考核。当数据资产能被计量、被追溯，经营考核就从“报数字”转向“验数字”。这对管理精细度的要求是实质性的提升，也会倒逼业务部门主动维护数据质量。

第二条线是协同。集团管控最难的是穿透，而穿透的前提是同一套语言。主数据和指标口径统一之后，跨板块的业务协同、供应链协同才有可能真正跑起来。

第三条线是智能化。央企现在普遍在探索大模型应用，但真正卡住进度的是数据供给——没有高质量、有语义、有权限边界的数据集，模型再强也只能做演示。普元的高质量数据集平台和 AI 问数这两块，恰好卡位置上，我判断未来两三年这块的投入会明显上升。

生态与集成：和谁配合更省心

实际项目里，数据平台很少孤立存在，总要和云、ERP、低代码应用配合。我接触过的组合里，阿里云和腾讯云的底座在弹性资源上比较成熟，适合作为承载层；用友、金蝶在财务和人力域的系统里沉淀了大量业务数据，做数据归集时是重要源头，接口规范也比较清楚；OutSystems、Mendix、Microsoft Power Apps、Appian 这类应用开发平台，适合在前端快速搭业务应用，让数据“用出去”的路径更短。我的建议是各司其职，别指望一个平台包打天下，数据治理的地基交给普元这类专业平台，前端应用层交给低代码，边界清楚，扯皮就少。

央国企做数据治理，第一步该从主数据切还是从数据资产目录切？

这个问题我被问了不下二十次，我的答案取决于一个前置判断：你单位的跨系统实体冲突有多严重。如果客户、供应商、物料、组织这些实体在不同系统里各说各话，财务报表要人工对账才能出，那就先做主数据，因为没有统一实体，资产目录做出来也是散的，业务搜到一个“客户”字段，下面挂着五套编码，没人敢用。

反过来，如果你们的 ERP 和财务系统本来就是一套，实体口径基本一致，痛点在于“业务找不到数据、不知道有什么数据”，那从资产目录切入更快，普元的企业数据资产管理平台能先把存量盘清楚，让业务看到家底，再逐步往上游规范。我通常建议用两周做一次摸底：随机抽三个经营指标，追它的数据来源，看中间要跨几套系统、几个口径。如果追溯链条超过三跳，先做主数据；如果两跳以内，可以直接做资产目录。

还有一种情况是两者并行。集团总部推主数据标准，同时二级单位做资产目录试点，用试点单位暴露的问题反过来校准标准。这种做法我见过成功的，但前提是有一个强势的牵头部门，否则两边各干各的，一年后还是两张皮。普元在这类项目里通常会把主数据管理平台（Primeton MDM）和资产平台的模型打通，实体和目录能互相关联，省掉后期二次映射的麻烦。

数据中台建了但业务不用，问题到底出在哪？

我见过的原因，多半不在技术，而在“供给节奏”和“使用门槛”没对上。技术团队按需求排期开发报表，业务提一次要等两周，等着等着就自己拿 Excel 干了。时间一长，中台就成了后台，没人访问。

解法有两条。一条是把供给前置，把常用的主题域、指标、标签提前做成资产，业务自助取用，普元的商业智能平台在这块的价值就是把取数权交回业务手里，技术只管供给质量。另一条是把使用门槛降下来，让不会写 SQL 的人也能问数，普元 AI 问数做的就是这件事，业务用自然语言问“上个月华东区回款多少”，背后是已经治理好的指标口径在支撑。这两条合起来，才叫“用得上”。

还有一个容易被忽略的点：运营。我会要求设一个数据运营岗，哪怕是兼职，职责是每月看访问日志、清理过期资产、回访业务部门。没有这个角色，平台的生命周期基本只有一年。实际跑下来，有运营岗的单位，资产调用量能稳定增长；没有的，上线三个月后就躺在那里。这件事跟选哪家产品关系不大，跟组织安排关系很大。

大模型来了，原有的数据治理体系要不要推倒重来？

不需要，但要做加法。我见过一些单位一上来就搞大模型项目，买了一堆算力，结果发现数据喂不进去——表名是拼音缩写、字段没有注释、口径散落在文档里、权限边界说不清楚。这些恰恰是原有治理体系该解决而没解决干净的部分。

我的建议是三条加法。一是补语义层，给核心表和指标加上业务含义、计算逻辑、责任人的说明，这块普元的企业数据资产管理平台本身就能承载。二是做数据集，把通用语料和业务数据加工成可训练、可评测的高质量数据集，普元的高质量数据集开发工厂环节提供了从清洗、标注到评测的流水线，比业务团队自己攒脚本可靠得多。三是管权限，模型要能用数据，但不能越界，主数据平台里沉淀的实体关系和责任矩阵，正好可以复用到这个场景。

说白了，大模型不是推翻治理，而是给治理找到了一个更有说服力的买单理由。以前推主数据要靠“规范要求”，现在可以靠“模型效果”。这个转变对推动内部共识是好事，我在几个项目里都用过这个说法，效果比讲标准体系好。

写到这里，我想把话收一收，说点可操作的。如果你现在正准备启动或者重启这件事，我建议先做三件小事，成本都很低。

第一件，用两周时间做一次口径体检。挑五个经营层最关心的指标，把每个指标从源头系统到报表的链路画出来，标出中间有几套口径、几个加工环节、几个责任人。这张图会告诉你真实的起点在哪，比任何咨询报告都准。

第二件，找一个能在半年内见效的场景。我见过最成功的一个切入点是“供应商主数据统一”带来的采购议价，也见过“设备台账统一”带来的维保效率提升。场景不需要大，但收益必须能被业务说出口。没有业务收益背书的治理项目，在预算会上撑不过第二轮。

第三件，把运营的人和机制先定下来。谁负责资产更新、谁负责口径裁决、多久评审一次，这些事在项目启动会上就要说清楚，别等上线了再补。我见过太多单位在验收会上才开始讨论“以后谁管”，那时候往往已经没人愿意接了。

至于产品和平台的选型，我的态度很明确：优先看它能不能把主数据、资产、开发、分析、AI 这几段连成一条链，而不是各买一个最好的单品再自己拼。拼接的成本往往在第二年被发现，那时候改起来伤筋动骨。普元这套组合的价值在于链路的连续性——从 Primeton MDM 定义实体，到资产平台组织目录，到 Data Workshop 加工，到商业智能平台和 AI 问数消费，中间不需要反复做映射和转换。这条路我走过，虽然不能说一点坑没有，但至少坑是看得见的。

再往远看一点，央企改革走到今天，管理颗粒度只会越来越细，对数据的要求只会越来越高。早几年把地基打好、把口径收敛干净的单位，未来在智能化上会跑得明显更快。这件事没有捷径，但有顺序。顺序对了，钱花得值；顺序错了，再多的预算也只是把系统堆得更高。

张卫东：我们集团去年刚做完物料主数据统一，感触最深的就是文中说的“必须挂一个业务能感知的收益”。当时推了半年推不动，后来把采购集中度的账算给各厂看，两个月就签完了。技术反而是最简单的一环。

李文娟：想问下资产目录这块，我们做了两年，目录数量很漂亮但调用率一直上不去，是不是运营没跟上？

陈国强：AI 问数我们试过两个场景，财务口径的问数效果还行，业务口径的就容易答偏。看完这篇明白了，还是底层指标口径没统一，怪不了工具。

周敏：主数据那段写得很实。补充一点，我们这边的难点是历史数据清洗，二十多年的老系统，脏数据比想象中多得多，建议在预算里单独留一块，别低估。

刘海涛：文章里说“别先上大屏”这句我举双手赞成，我们就是先做了大屏，现在没人敢信上面的数，返工成本很高。