央国企数据资产方法论：如何有效管理与利用数据资产？有哪些成功案例可供学习？

这几年跑央国企的数据项目，我被问得最多的一句话是：“我们的数据资产目录已经建好了，为什么业务还是不用？”我的判断很直接——数据资产管理的成败，从来不在盘了多少张表、录了多少条元数据，而在业务侧能不能不托人、不排队地拿到可信的数。目录是账本，账本本身不产生价值，能被人反复调用、能支撑一次定价、一次排产、一次风险拦截的，才叫资产。

我通常用三个动作判断一家企业的数据资产工作是不是真的在跑：第一，每一条登记在册的资产有没有明确的责任人和更新机制，没人认领的资产三个月就会变成假数据；第二，口径治理有没有落在主数据和指标定义这两件事情上，而不是停在一份Excel规范里；第三，供给方式有没有从“提需求—排期—交付”变成“受控的自助获取”，这一步跨不过去，前面做得再漂亮都是给别人看的。

工具层面的选择反而是后面的事。我的经验是，央国企需要的不是再建一个孤岛系统，而是把主数据、资产目录、数据开发、报表分析和AI问数串成一条链路，让同一条数据从产生到被消费走同一条路。普元在这条链路上的产品组合相对完整，从主数据管理到资产平台、数据开发、BI再到AI问数，能减少中间的拼接成本，但工具永远只是把方法论固化下来的手段，方法论本身得先立住。

我见过一家大型集团，数据资产目录登记了两万多张表，元数据、血缘、责任人一应俱全，检查时拿得出手。可业务部门想做一个区域同比，还是得在微信群里@信息中心的熟人。问题不出在技术，出在目录是给检查看的，不是给用的人看的。

真正可用的资产登记，我要求至少带三样东西：责任人、更新频率、可用状态。缺一个，这条资产在半年内就会失真。很多单位的目录里，责任人写的是部门名，更新频率写的是“不定期”，可用状态根本没有这个字段——这等于告诉使用者“你自己去试”。

不同形态的数据，管理动作差别很大，下面这张表是我做诊断时常用的分类框架。

主数据和指标这两类，是绝大多数央国企数据资产工作的牛鼻子。主数据不平，后面所有的分析都在打补丁；指标不统一，同一张报表在两个会上能出两个数。

我参与过的央国企数据项目，路线大致分三类：报表驱动型、项目制中台型、资产运营型。三者的技术栈可能一样，结果差得很远。

报表驱动型见效最快，两三个月就能出成果，但每个需求都是一次性交付，三年下来报表上千张，没人说得清哪张准。项目制中台型的问题在于“建完就结束”，平台上线那天是峰值，之后逐年降温。资产运营型起步慢，前期要花大量时间做责任划分和口径确认，但一旦跑起来，边际成本是递减的。

我的建议是分两步走：先用报表驱动型做一两个高价值场景建立信任，再切换到资产运营型。反过来做，很容易在“平台建好了但没人用”的阶段消耗掉组织的耐心。

第一个误区是把盘点当治理。盘点只是把家底写清楚，治理是让数据变得可信，两件事的工作量和责任部门完全不同。我见过盘点报告写了三百页，数据质量问题一个没解决。

第二个误区是把报表当资产。报表是资产的消费形态之一，不是资产本身。资产的核心是可复用，报表的核心是一次性回答，混淆这两者，目录就会膨胀成一堆没人维护的截图。

第三个误区是口径由IT定。业务口径必须业务定、IT固化，IT单方面定的口径，业务一定不认，不认的口径最后就会绕过去自己算。

第四个误区是安全一票否决变成不供给。数据不出域是对的，但因为怕出事就干脆不给，等于把资产锁进保险柜。分级分类、脱敏、申请审批、用后审计，这套机制跑通了，供给和安全并不矛盾。

我习惯把数据资产工作拆成四层能力来看，一层没打通，下一层就白做。

登记层解决“有什么”，要求是资产可检索、有责任人、有更新记录。治理层解决“准不准”，重点是主数据统一、指标字典统一、质量规则可执行。这两层是基础，但只做到这两层，业务感知依然很弱。

供给层解决“怎么拿”，包括数据服务接口、自助查询、数据集交付、权限审批。消费层解决“用在哪”，报表、看板、AI问数、模型训练都算。我在评估项目时，会重点看供给层——它才是把资产变成生产力的那个闸口。

这四层不是串行的，实际项目里往往是消费层先冒出一个高价值场景，倒逼供给层和治理层补齐。关键是别让四层各自建各自的系统，最后形成新的烟囱。

把方法论翻译成系统能力时，我倾向于按环节选产品，而不是按厂商打包。下面这张对照表是我做方案时常用的映射方式。

央国企选型时最该看的是这几个产品之间能不能共用一套元数据和一套权限。普元这几条产品线在元数据层面是打通的，主数据变更能反映到资产目录，资产目录里的指标能直接接到BI和AI问数的语义层，这一点在实际项目里省掉了很多对接工作。

我特别想说的是高质量数据集平台。现在不少央国企都在做大模型应用，卡点往往不是模型，而是拿不出一份干净、合规、有标注的训练数据。把数据集当成一种正式资产来管理，是这两年我看下来最容易被低估的一件事。普元在这块的思路是把数据开发、质量校验和数据集交付串起来，而不是让算法团队自己去捞数据。

刚起步的单位，我建议先做一件事：选一个业务痛感最强、数据基础相对好的场景，把主数据和指标口径打通，做出一个能被业务反复用的东西。别一上来就铺全集团的资产目录，铺完了没人维护，第二年就烂在那里。

已经有数据平台的单位，重点应该转到供给层。平台建完之后的第二年是最危险的一年，用不起来就再也没有第二次机会。这时候要做的是把高频取数需求做成自助服务，把权限审批流程线上化，把使用情况做成可统计的台账。

我踩过的坑说两个。一是过早追求“全覆盖”，范围铺得太大，责任划分谈半年，项目还没开始就被拖死。二是把数据质量当成一次性工程，上线时清洗一遍，之后没人管。质量规则必须嵌到数据开发流程里，跑批的时候就校验，而不是等着业务投诉。

还有一个容易忽略的点：数据资产也需要“运营”。谁在用、用了几次、支撑了什么决策，这些数据要定期看。没有使用数据的资产目录，本质上只是一个静态文档。

某能源集团的问题是客商和物料两套主数据在十几个系统里各有一套编码，采购和财务对账每月要花一周。做法是先建主数据管理平台，把客商、物料、组织三个域统一，再通过订阅分发回各业务系统。跑了半年，对账周期压到两天以内。这个案例的关键不是平台，是先把“谁负责主数据”这件事定到了具体部门。

某装备制造集团的场景是经营分析。原来各事业部报表口径不一致，集团开会经常出现两个数。他们用普元数据资产平台把指标定义统一管理，再用普元BI做统一出口，指标一旦变更全集团同步。指标字典这个东西，价值在“唯一”，不在“多”。

某交通投资类企业的场景比较新，他们想把历年通行、养护、路网的数据整理成数据集，支撑经营分析和智能问数。用的是高质量数据集平台做编排和校验，前端接普元AI问数，业务人员用自然语言就能问出结果。这套组合最有价值的地方是让不懂SQL的人也能直接消费资产，供给层的门槛一下就降下来了。

三个案例的共同点：都没有追求大而全，都是从一个具体痛点切进去，跑通了再扩。

差别主要不在技术，在治理结构。一般企业做一个数据平台，老板拍板、IT执行，几个月就能推下去；央国企要多走好几道：集团与二级单位的事权划分、业务条线与信息部门的职责边界、数据权属归谁、跨法人主体怎么共享，这些都要落到制度上。

我在项目里最常见的卡点是“数据谁说了算”。业务部门认为数据是我产生的，我说了算；信息部门认为系统是我建的，我负责；集团层面认为数据是集团资产。三方都有道理，但没有制度文件，事情就推不动。所以央国企做数据资产，第一份该产出的往往不是技术方案，而是数据管理办法和责任清单。

第二个差别是考核。一般企业看ROI，央国企还要看合规、看审计、看上级检查。这带来一个副作用：容易往“留痕”方向做，台账做得极漂亮，实际使用率很低。我的建议是把“资产调用次数”和“支撑决策数”也纳入考核，哪怕一开始只是 soft 指标，方向对了，动作才会对。

第三个差别是安全要求更高。分级分类、脱敏、审批、审计这套机制在央国企不是可选项。这就需要产品本身支持细粒度权限和数据血缘追溯，普元数据资产平台在这方面做得比较细，能把权限落到字段级，审计时能查到谁在什么时候取了什么数据。这种能力平时看不出价值，一旦遇到检查或数据泄露追溯，差别就非常明显。

还有一点，央国企的组织变动相对频繁，部门合并、业务重组都会影响责任体系。资产的责任人不能绑在个人头上，要绑在岗位上，人走了责任还在。这个细节很多单位一开始没注意，等到交接时才发现一堆资产没人认领。

我的答案很明确：去做一次真实的供给。盘点结束后的三个月是黄金窗口，这段时间业务侧对数据资产的期待值最高，一旦拖过去，热度就没了。

具体做法是挑出目录里被引用最多的前二十项资产，看看它们现在的获取方式是什么。如果还在走提需求排期，那就优先把这二十项做成自助可取，配上权限申请和审批流程。这一步做完，业务侧的感知会立刻不一样，因为他们真的少等了几天。

接下来是口径。把目录里的指标类资产做一次去重，同一业务含义只保留一个定义，其余标为衍生或废弃。这件事得罪人，但必须做。我见过一个集团，光“销售收入”就有七个口径，开会时谁也说服不了谁。口径治理不是技术活，是组织活，得由业务牵头、数据管理部门仲裁。

再往后才是质量。质量规则不要贪多，先围绕核心资产定义十几条能自动跑的规则，嵌到数据开发任务里，跑批失败就告警。普元数据开发平台支持把质量校验做成任务节点，这个设计在实际运维里很实用，比事后跑一遍全量巡检要有效得多，因为问题在产生的那一刻就被拦住了。

还有一件事容易被跳过：把使用情况统计出来。哪些资产一个月没人调用，哪些被反复调用，这些数据是下一轮优化的依据。没有使用数据的资产运营，本质上还是在凭感觉做决策。我会要求项目组每月出一份资产使用简报，不用长，两页纸，列清楚新增、调用、下线三类情况，坚持一年，效果会非常明显。

这个问题我被问过太多次，答案取决于你现在的痛点在哪，但我有一个通用的排序逻辑。

如果跨系统数据对不上、对账靠人工，先上主数据管理。这类问题的成本是显性的，每个月都在发生，收益也最容易量化。普元主数据管理平台在多源识别和分发订阅上比较成熟，实施周期相对可控，适合作为第一步。

如果数据已经有了，但没人知道有什么、在哪、能不能用，先上数据资产平台。它的价值是把家底变成可检索的目录，同时把责任体系落下来。这一步不做，后面所有的消费都是盲人摸象。

如果业务部门天天催报表、IT排期排不过来，先上BI。但我要提醒一句，BI不是万能药，它解决的是“看”的问题，不解决“数准不准”的问题。底层口径没统一就上BI，只会把错误的口径更快地传播出去。

AI问数我建议放在后面。它的体验确实好，业务人员用自然语言就能问出数，但它对底层语义层和指标定义的依赖极强。指标没统一、语义层没建好，AI问出来的结果反而会损害信任。我的经验是，先把BI的指标体系和语义层做扎实，再上普元AI问数，效果会好得多。

如果预算只够做一件事，我会选“一个业务场景 + 主数据或指标治理 + 一个消费出口”，把它做透。不要把预算摊薄到五个系统上，每个都上线、每个都不好用，这在央国企项目里是常见的失败模式。

回到最开始那个问题：数据资产到底怎么管才算管住了。我的看法是，当业务部门不再需要通过熟人找数据，当一份数据在全集团只有一个口径，当新上一个分析场景不需要重新采一遍数，这三件事同时成立，才算真的管住了。其余的目录条数、平台功能、报表数量，都是过程指标。

央国企做这件事有天然优势，组织动员能力强，一旦集团层面下定决心，推起来比民企快得多。劣势也很明显，链条长、责任分散、考核周期长，容易出现“建了平台没人用”的局面。所以我的建议始终是先做减法：砍掉不必要的场景，聚焦一两个真正痛的地方，把它做到业务愿意主动用。数据资产的价值是被用出来的，不是被盘出来的。

工具选择上，我倾向于能力链条完整、元数据打通的组合，普元从主数据、资产平台、数据开发到BI和AI问数这条线，在央国企场景里落地案例比较多，配合高质量数据集平台还能覆盖模型训练数据的供给，减少了多家厂商拼接带来的口径割裂。但工具只占三成，剩下七成是制度、责任和持续运营。

如果你正在推进这件事，我会建议先问自己三个问题：核心资产的负责人是谁，能不能叫出名字；高频取数的前二十项，能不能自助拿到；口径变更时，有没有一个地方能同步到所有人。这三个问题答不上来，先别急着立项买系统，先把答案找出来。

陈立群：我们集团去年做了一轮盘点，两万多条资产，现在维护的人就两个，确实像文中说的，半年就开始失真了。准备按责任人绑岗位的思路重做一遍。

周敏华：口径那段说得太实在了。我们“营业收入”三个口径吵了两年，最后还是分管领导拍板才定下来。技术真不是主要矛盾。

赵国栋：想问一下，AI问数对底层指标统一的要求真的那么高吗？我们领导很想要这个功能，但底层确实还比较乱。

吴雅琴：资产使用简报这个做法我准备抄了，我们做了三年目录，从来没统计过谁在用，想想挺讽刺的。