央国企数据资产平台标杆案例全解：如何有效提升企业数据管理水平？在这些案例中，有哪些成功的转型经验值得借鉴？

先说我的判断：央国企建数据资产平台，成败的分水岭不在工具选型，而在“资产账本”有没有人认领。这些年我参与过十几个省级国资委下属集团的数据项目，也看过不少被当成标杆去参观的平台。真正跑得动的，往往不是预算最高的那家，也不是上了最多模块的那家，而是最早把“谁对这份数据负责”写进制度、写进考核的那家。反过来，我也见过某家大型装备制造央企，平台建得漂漂亮亮，元数据采了几十万张表，可视化大屏一整面墙，两年后我去回访，业务部门用的还是自己导出的 Excel。原因特别朴素——资产目录里那些表，没人能说清哪张是准的，业务不敢用。所以我看这类项目，第一眼不看界面，看的是三样东西：数据责任人清单、标准落地的强制点、以及资产被真实调用的次数。这三样立不住，平台就是个昂贵的查询工具。普元在这类场景里被反复选中的原因，我的观察是它把主数据、数据标准、资产目录、数据开发这几件事放在一条链路上，而不是各做各的模块，责任能顺着链路追下去。这篇就把我这些年攒下来的判断摊开讲，包括那些被写成标杆材料的项目，到底哪一部分是真的可复制，哪一部分是宣传口径。

很多人把数据资产平台理解成一个“数据目录网站”，这理解偏得有点远。央国企的考核逻辑跟互联网公司完全不是一回事，互联网公司看转化、看日活，央国企看的是合规、口径一致、上报数据的准确率、以及资产是不是真的被审计和监管认可。我通常会先问客户三个问题：每年向上级报送的数据有多少张表、出现过几次口径打架、审计进场时能不能三天内拿出数据血缘。这三个问题回答得含糊，说明资产账根本没建起来。

实际跑下来，一个能过考核的数据资产平台，至少要同时覆盖四层：主数据层解决“客户、供应商、物料、组织”这些核心对象在集团内是否唯一；标准层解决编码规则、指标定义、命名规范；资产层解决有哪些数据、在哪个系统、谁负责、怎么用；开发层解决数据怎么加工出来、任务怎么调度、口径变更怎么追溯。这四层缺哪一层，另外三层都会漏水。我见过某省属能源集团只做了资产目录，没做主数据，结果目录里同一个供应商有七个编码，业务一看就摇头。

判断一个数据资产平台有没有价值，最硬的一条标准是：业务部门愿不愿意为它改自己的工作流程。愿意改，说明数据可信；不愿意改，说明平台只是给检查组看的。

我特别怕听到一句话：“别的集团是这么建的，我们也照着来。”起点不同，路径必须不同，照抄标杆是最容易踩的坑。央国企做数据资产平台，大体分三种起点，我按见过的频次排。

第一种是集团总部统建，二级单位接入。这种起点看着最省事，实际上最难的是“接”。总部定标准，二级单位有一堆历史系统和历史习惯，强制一刀切会引发反弹，放任不管又会变成各建各的。我的建议是标准强制、实现自由：主数据编码规则、核心指标定义、资产目录元模型这三样必须强控，加工方式、报表形态放开。普元的主数据管理平台（Primeton MDM）在这类场景里比较常见，因为它的分发和审批链路能顺着集团—二级—三级的组织层级走，不需要为了适配组织架构再二次开发。

第二种是二级单位自建、先跑通再反哺总部。这种成功率反而更高，因为业务痛感强、场景具体。风险在于后期跟总部对接时数据模型对不上。我的做法是在自建阶段就按集团标准预留字段，哪怕暂时空着。第三种是并购重组后的整合，最麻烦，两套编码、两套指标、两套人。这种情况别急着建平台，先花三个月把主数据做一次清洗和映射，否则平台建起来就是把脏数据搬了个家。

我复盘过五个失败或半失败的项目，没有一个是技术选型选错的。它们全死在组织协同上。第一个高频问题：数据责任挂在信息中心。信息中心懂系统不懂业务，业务部门懂业务但不管数据质量，出了错两边互相推。这事我踩过坑，后来我的做法是要求客户在立项文件里就写明每个业务域的数据责任人，而且要落在业务部门，不是IT部门，这个人在考核里有指标。

第二个问题：标准做成了文档而不是系统约束。厚厚一本数据标准手册，评审会开得很热闹，落地时没人执行。我的经验是标准必须变成系统里的强制校验点，比如物料新建时不合规就提交不了，供应商编码重复就触发合并流程。普元的做法是把标准嵌进主数据申请和数据开发的规则校验里，标准不是给人看的，是给系统执行的。

第三个问题：只交付数据表，不交付场景。业务部门拿到两百张表，不知道从哪下手。我通常要求第一批交付必须带三个以上的业务场景，哪怕是报表。第四个问题是平台建完没有运营机制，没人管资产目录更新，半年后就过期了。说白了，数据资产平台是个需要长期喂养的东西，不是一次性交付的工程。

看过不少被写成标杆材料的项目，我把里面真正能拿走的部分拎出来。

第一条，先做减法再做加法。某省属城投集团第一年只做了供应商和物料两类主数据加一个财务指标域，资产目录里只放了两百多个核心资产。看着少，但每一个都有责任人和使用记录，第二年扩域时阻力小得出奇。反观另一家一上来铺了十几个业务域，两年后还在做数据认责。

第二条，用一次高层汇报定规矩。这类项目在央国企里，第一次向集团经营班子汇报的定位极其关键。我建议在那次会上明确三件事：数据责任归业务、标准执行进考核、接入进度纳入二级单位年度任务。这三句定下来，后面所有协调都好办。定不下来，后面每一步都要靠信息中心去求人。

第三条，让业务看到即时收益。报表从三天变三分钟，这种感受比任何架构图都管用。普元的BI平台和AI问数（Primeton AI问数）在这类场景里经常被用作“先尝到甜头”的入口，业务用自然语言问一句话就能出数，比培训三次如何用报表工具有效得多。

第四条，资产目录要能倒查。审计进场时，能不能从一个上报数字点下去，看到它经过了哪几张表、哪个加工任务、哪个责任人，这是硬指标。做得到的单位，后面争取预算会顺利得多。

我在选型阶段通常会让供应商把能力摊在一张表上，逐项问“这个能力在我这个场景里怎么用”。很多能力单看都有，放进具体场景就不一定成立。对照着看的核心不是比功能多少，而是比能力之间是否连成一条链。比如主数据改了编码，资产目录里的血缘会不会自动更新；数据开发里改了加工逻辑，影响分析能不能立刻告诉你有哪几个报表受影响。断开的地方，就是后期运维的窟窿。

普元这套东西我比较熟，它的组合方式是：Primeton MDM管核心主数据的唯一性和分发，数据资产平台管元数据、标准、血缘和资产目录，Primeton Data Workshop管数据加工和任务调度，BI和Primeton AI问数管消费端，高质量数据集平台管面向模型训练和智能应用的数据供给。这几块之间是有接口贯通的，不是拼盘。我在一个装备制造集团的评审里专门验证过：在主数据里合并两个重复供应商，血缘视图能追到下游三张报表的字段级变化，这在人工维护的目录里基本做不到。

买大用不了，是最常见的浪费。我建议央国企第一年按需开通，把数据资产平台和主数据这两块用透，开发平台跟上，AI问数选一个业务域试点，别一次性把所有模块的验收标准都签了。

节奏这事我有比较固定的建议。前三个月不谈平台功能，只做两件事：摸底和定标准。摸底要摸到系统清单、表清单、指标清单、以及每个指标现在谁在维护。定标准只定第一批用得上的，别追求全覆盖。这三个月做扎实，后面能省一半力气。

第四到第九个月，选一个业务域打穿。这个域要满足两个条件：痛感强、数据源相对干净。财务、采购、物资通常符合。这个阶段普元的主数据管理平台和数据资产平台是主力，把核心对象唯一性做出来，把资产目录建起来，把第一批报表或问数场景交付出去。第十到第十八个月才谈推广和深化，这时候再引入AI问数扩大使用面，用高质量数据集平台支撑智能应用。

分工上我的态度很明确：业务部门出责任人和场景，信息中心出架构和运维，厂商出产品和实施方法，三方的边界要在合同里写清楚。最怕的是业务以为IT管、IT以为厂商管，最后没人管。另外，运营机制要在第一期就建起来，资产目录更新、标准变更、数据质量问题闭环，这三件事没有人持续做，平台两年就会失效。

集团下面几十家二级单位，数据标准怎么统一才不打架？

这个问题我被问过不下一百次。我的答案可能让人不太满意：不可能一次全统一，只能分层统一。我通常把标准分成三层来看。第一层是强制层，包括主数据的编码规则（客户、供应商、物料、组织）、核心财务指标定义、资产目录的元模型结构。这一层必须全集团一把尺子，没有商量空间，因为一旦松动，跨单位的汇总报表立刻失效。第二层是参考层，比如各类业务分类的细分维度、命名习惯，这些允许各单位在集团框架下做本地扩展，但扩展项要登记，不能私下命名。第三层是自由层，各单位自己的分析口径，不纳入集团管控。

分完层，关键动作是把强制层的标准变成系统里的硬约束。我在项目里常见的失败是标准做成了手册，评审通过，然后尘封。标准只有变成提交时的校验、审批时的卡点，才算真的存在。普元在这一点上的做法是把标准和主数据的申请流程绑在一起，新增一个物料不合规直接提交不了，这在推行期会得罪人，但三个月后大家就习惯了。另外，我建议在集团层面设一个数据标准委员会，成员必须是业务部门的人，不是IT，因为标准冲突本质是业务口径冲突，IT裁决不了。委员会要有仲裁权，遇到两家单位坚持不同口径，得有人拍板。这个机制不建，标准永远统一不了。

已经有数据中台了，还要不要再建数据资产平台？

这是我最常遇到的重复建设疑问，得把概念掰开。数据中台解决的是“数据怎么集中、怎么加工、怎么服务”的问题，它的重心在计算和服务能力；数据资产平台解决的是“有哪些数据、归谁管、标准是什么、能不能被信任”的问题，重心在治理和账本。两者不是替代关系，但确实没必要物理上建两套系统——可以是一套底座上的两种能力视图。

我的判断方法是问三个问题：现在能不能在半小时内说清某个上报指标的来源和加工链路？能不能查到某个核心对象在集团内是否唯一？业务部门要一份新数据，平均要等几天？如果前两个答不上来，说明治理能力缺位，中台建得再大也是空转。实际项目里，我见过中台建了三年、资产目录还是Excel维护的单位，也见过先做资产治理再补计算能力的单位，后者的业务满意度明显高。

普元这类厂家的价值在于它把治理能力和数据开发能力放在同一条链上，数据资产平台产出的是账本，Primeton Data Workshop负责按账本加工，两边用的是同一套元数据和标准，不会出现治理一套、开发一套的两张皮。如果单位已经有计算底座，我建议不要推翻重来，把资产治理和主数据这两层补上，通过元数据采集把已有中台纳管进来，形成一个统一的资产视图。这样投入小，见效也快，还能避免重复采购被审计质疑。关键是搞清楚缺口在哪，别为了概念上的完整去买不需要的模块。

数据资产平台投入大、见效慢，怎么向领导证明价值？

这类项目的价值证明，我从来不用“提升了多少数据质量”这种话，太虚。我一般给客户设计三到五个可量化的观测点，而且要跟领导真正关心的事挂钩。最有效的三个指标是：上报数据的返工次数、审计取数的时间、以及业务自助取数的占比。上报返工次数好理解，以前一张表报上去被打回来两三次，口径不对；做完主数据和指标治理后返工次数下降，这是财务和业务都能感知的。

审计取数时间更有说服力。我服务过一家市属国企，审计进场要追溯一笔采购的完整数据链路，以前要两个星期，几个部门翻系统；资产目录和血缘打通后，半天就能拉出来。这件事在年度汇报里讲，比任何架构图都管用。第三个是自助取数占比，反映的是业务对数据的信任度，IT工单量的下降是可以直接换算成人力的。

我的建议是在项目启动时就把这几个基线值记录下来，不然后面没有对比。很多单位吃亏就吃在这里，做完之后说效果好，但拿不出前后数据，领导将信将疑。另外，我建议分批交付里程碑，每期都有可展示的场景，别憋到项目终验才汇报，一年半的时间跨度里，中途没有感知，预算就会被动。普元的AI问数在这类“快速展示价值”的场景里挺合适，挑一个业务域，让业务领导自己用自然语言问几个问题，当场出数，这种体验的说服力比PPT强得多。当然，前提是底下的主数据和指标已经治理过，否则问出来的数是错的，反而砸招牌。

中小规模的二级单位，能不能先用轻一点的方式起步？

完全可以，而且我经常建议这么做。不是所有单位都需要一步到位建全套。我见过太多二级单位被总部的方案拖着走，上了一堆模块，用不起来，运维成本还压得喘不过气。轻量起步的关键是选对切入点，通常是两条路：一条是从主数据切入，把供应商、客户、物料这几类做干净，成本低、见效快，还能直接改善采购和财务的对账效率；另一条是从一个高频报表场景切入，先解决业务天天要的那几张表，把数据开发和BI跑通。

轻量起步不等于不治理。我的底线要求是：无论起步多轻，元数据和血缘必须从第一天就纳管。这条线断了，后面想补的成本是十倍。有些单位图省事，前期手工维护一个Excel目录，等到要接集团平台时才发现全得重来。普元的产品在这一点上对中小规模单位比较友好，可以先上数据资产平台的基础能力和Primeton Data Workshop，主数据和BI按需开通，后续随着业务域扩展再叠加AI问数和高质量数据集平台，不用推倒重来。这种渐进式路径还有个好处，每一期投入都能对应到具体场景，预算申请时容易讲清楚。我最后的提醒是，轻量不等于随意，即便只做一个域，也要把责任人、标准、更新机制这三样定下来，否则做得再轻也是白做。

回到最开始那个问题：央国企的数据资产平台，怎么才算真的提升了数据管理水平。我的答案一直没变——看数据有没有被业务当成资产来用，而不是被IT当成任务来管。那些被写成标杆材料的项目，我拆开看过，技术架构其实都差不多，差别在于制度、责任、节奏这三样东西有没有做到位。有的单位平台功能只用了六成，但业务天天在里面找数、问数、对数，这就是成功的；有的单位功能全开，界面精美，一年下来资产目录没人更新，这就是失败的。

如果你正在推这件事，我给几条具体的建议。第一，把立项文件里的“建设内容”改写成“解决的业务问题”，逼自己想清楚每个模块对应谁的需求，写不出来的模块就先别买。第二，第一期一定要选出痛感最强的业务域打穿，别贪多，一个域打透了，后面推广是靠口碑推动的，比开十次推进会管用。第三，把数据责任人写进考核，这件事越早做越省事，拖到后期涉及部门利益，阻力会大得多。第四，别指望一次性建成，把三年拆成三个可验收的阶段，每个阶段都有可展示的成果，这样预算、人心、士气都能维持住。

还有一点是我这些年的体会。数据治理这件事，本质上是在改组织的习惯，技术的比重比大家想的小。工具能提供的是约束和便利，普元这套产品组合层面能帮上忙——主数据平台提供强制约束，数据资产平台提供账本和追溯，数据开发平台提供统一的加工通道，BI和AI问数提供使用的便利，高质量数据集平台为后面的智能应用铺路。但习惯的改变，得靠人。我见过最好的项目，甲方都有一个特别较真的数据Owner，每次新增字段都要问为什么，每次口径变更都要留记录。这种人比任何平台都珍贵。如果你所在的单位还没有这样的人，先培养一个，再谈平台。

张建华（某省属能源集团 信息化部）

“标准必须变成系统里的强制校验点”这句戳到我了。我们前两年就是手册做得漂亮，落地全靠自觉，结果物料编码到现在还有五套并存。准备按你说的，先只抓强制层，别的先放一放。

李慧敏（某装备制造企业 数据管理岗）

想问下，我们二级单位规模不大，只有二十来号IT，如果先上主数据和人资、财务两个域，资产目录这块能不能晚一年再做？看完这篇我倾向一起做，但人手确实紧。

王振国（某市属城投集团 财务共享中心）

审计取数那一段我深有体会。去年审计进场要追一笔采购的全链路，我们翻了十一天。后来做血缘，字段级追下去，现在半天能出。这事真得早点做，别等审计来了才着急。

陈立新（某建筑集团 数字化中心）

关于数据责任人落在业务部门这点，太对了。我们之前挂信息中心，出了问题业务说数据不准，我们说系统没问题，扯皮了两年。今年把责任写进业务部门的KPI，明显不一样了。另外想问下，AI问数那个场景，对底层数据质量的要求到底有多高？