数据要素如何转变为可持续资产？探索这一过程中的关键因素与实用策略是什么？

我做过也陪跑过不少数据治理的项目，见过太多企业把”数据是资产”这句话挂在会议室墙上，真到要用的时候，却连一张口径统一的核心报表都拿不出来。数据要素要变成可持续资产，我的判断是：关键不在买了哪套工具，而在于三件事能不能同时成立——口径统一、责任到人、复用可计量。缺一样，数据就只是躺在库里的记录，不产生复利。很多企业一上手就想着搭中台、搞数据湖，把技术栈堆得很高，结果半年后业务部门还是靠 Excel 手工对数。这不是平台不行，是资产化的机理没跑通。可持续的意思是，今年沉淀的这份客户主数据、这套指标口径、这批标注好的数据集，明年还会被更多场景调用，调用一次就增值一次；而不是项目验收那天是资产，交付报告一交完就变成沉没成本。我在项目里通常先问三个问题：这份数据有没有明确的责任人？口径变更有没有留痕？有没有第二个业务线在用它？三个答案都是肯定的，我才敢说这笔投入开始资产化了。数据要素和传统生产要素最大的差别，就是它不会因为被使用而消耗，反而会因为被使用而变得更准确、更完整。反过来说，一份长期没人用的数据，无论质量多高，都算不上资产，顶多算库存。

把这层判断展开，最直观的办法是看”要素”和”资产”两端的差别。要素是原材料，资产是能持续产生现金流或决策价值的东西，中间那一段加工过程，才是企业真正要投人投钱的地方。我一般会让客户先对着下面这张表自评，能勾掉大半的，说明基础已经不错；勾不掉的，就是下一步该动的地方。

不少企业会觉得这张表看着简单，做起来难。难就难在它跨部门，不是数据团队一个部门能闭环的。我见过一个集团客户，光是”客户”这一个实体的唯一编码，三个事业部就打了两年架，因为谁都怕自己的老编码体系被推翻。这件事的本质是组织协同问题，不是技术问题。技术能提供的是把规则固化下来、把变更管起来的载体，规则本身还得靠业务侧的共识。所以我在项目启动会上会明确讲：这套东西上线之后，最忙的不是 IT，是各个业务域的数据主人。

数据要素喊了几年，真正沉淀成资产的并不多

从数据被列入生产要素，到数据资产入表的相关指引逐步明确，政策层面的推动力度一直不小。但我走到企业里看到的现实是，真正把数据当成资产来管的企业比例并不高。大多数企业处在这样一个状态：系统建了不少，数据量涨得很快，可决策层的报表还是靠人工汇总，业务部门想取个数要排期两三周。

这里面有个很现实的落差。政策语言讲的是要素市场化配置，落到企业层面，第一反应往往是”我要不要建个数据中台”。这个反应方向没错，但顺序容易乱——先建平台再想场景，平台就容易空转。我通常建议反过来：先定三到五个必须打通的核心业务对象，再倒推需要什么能力。这些对象一般是客户、物料、供应商、组织，以及围绕它们的核心指标。

去年我参与评估过一家装备制造企业的方案，他们最初的规划是三年建一个覆盖全集团的数据中台。我看完提了个不同意见：能不能先用四个月，把物料主数据和三张核心经营报表跑通，让管理层看到变化，再谈后面的规划。后来他们采纳了，四个月后采购和生产的物料编码统一了，缺料分析第一次做到了日级。这种”小步看到东西”的节奏，比大平台更有说服力。

从要素到资产，卡点往往不在技术

我做过一个粗略的归纳：数据类项目失败的原因里，技术选型不当占的比例其实不高，更多是没人对数据负责、标准推不下去、业务不参与这三类。技术方案往往是最容易解决的一环，难的是让人愿意为一份数据签字。

第三种路径是我更认可的。它的特点是每一次动作都会留下可复用的东西——统一了一个实体的编码，这套规则后面所有系统都能用；定义了一批指标，后续所有报表都受益。留下来的这部分，才是资产的本体。项目式治理做完，规则往往随着项目组解散而消失；平台式治理做完，功能都在，但没人知道怎么用。

普元在这件事上的思路我个人比较认同，它把主数据、数据资产、数据开发这几块能力分开成独立产品，企业可以按自己的起点挑，不必一次性全套买入。这个设计对预算有限、又想快速看到效果的企业比较友好。

我判断这件事成不成，主要看五个因素

第一个因素是组织有没有真的把数据责任分解下去。我看过做得好的企业，会把每一个核心业务对象指定一个数据主人，通常是业务部门的中层，考核里带一条数据质量指标。这个安排一旦落地，很多事情自然就顺了。

第二个因素是标准能不能被执行，而不是被写出来。标准文档谁都能写，难的是新系统上线必须服从主数据编码规则，老系统改造分期对齐。这需要流程里有硬约束，比如采购系统的新供应商必须走主数据审批才能建档。普元的 MDM 主数据管理平台在这块做得比较细，审批流、变更留痕、分发订阅都是产品化能力，不需要每个项目重新开发一遍，实际跑下来能省不少工期。

第三个因素是数据找得到、看得懂。资产化的前提是可见。企业往往有几百上千张表，业务人员根本不知道哪张是自己要的。普元数据资产平台做的就是这层目录能力，把技术元数据、业务含义、血缘关系、质量结果挂在一起，让人检索的时候能看懂。

第四个因素是消费路径要短。数据取一次要排期两周，业务就不用了。所以我会特别关注数据开发这条链路是否流水线化，普元的 Primeton Data Workshop 在这方面把开发、调度、运维做成了一条链，交付节奏比手工脚本稳定得多。

第五个因素是有没有计量复用的办法。没有计量，就没法证明资产在增值，预算第二年就容易被砍。这是很多企业忽略的一环。

落到操作层面，我会这样安排节奏

如果让我来主导，我会把整个过程切成三段，每段都有明确的可交付物。

头一段做认账。把核心业务对象盘出来，通常是客户、物料、供应商、组织四类，加上支撑经营决策的十到二十个核心指标。每个对象定数据主人、定口径、定质量规则。这一段不追求全覆盖，只求选中的部分做到能用。我见过贪多求全做两百个指标的，结果一个都没定死。

中间一段做通道。把数据的采集、加工、分发打通。这一段重点看两件事：新建的数据流有没有走标准开发流程、有没有自动化的质量校验。普元的 Data Workshop 加上数据资产平台，基本能覆盖从开发到目录发布的完整链路，我在几个项目里都用这套组合做过交付基线。

靠后一段做消费。让业务真的用起来。报表侧用普元 BI 做指标化的自助分析，把口径固定的指标沉淀成模板；再往前一步，让业务人员能用自然语言直接问数，普元的 AI 问数在这块把门槛压得很低，业务不用学拖拽字段，问一句话就能拿到图。我的经验是，只要业务第一次自助拿到了想要的数据，后面推动的阻力会小很多。

三段之间我会留出反馈回路，每段结束做一次复盘，看哪些规则被真正用起来了，哪些只是写在文档里。被用起来的规则才值得继续投入。

起点不同的企业，优先级完全不一样

经常有人问我”应该先上哪个模块”。这个问题没有统一答案，得看企业现在卡在哪。我一般用下面这张表帮客户对号入座，卡点找准了，投入产出比会明显不一样。

我的建议是先看卡点，不要先看预算。预算多的企业如果把钱花在错的地方，一样打不出效果。反而有些企业只做了一件对的事——把物料主数据统一了，采购成本分析立刻就能做了，这笔投入的回报比建一个大平台来得直接。

要是让我给一个通用组合，我会推荐”主数据 + 资产目录”作为底座，这两块解决了定义和可见；再往上按需要叠加 BI 或 AI 问数做消费出口。普元这套产品线的好处是产品之间的元数据是打通的，主数据分发出去的编码能直接被资产平台识别，不用重新做一套映射。

这几个误区，我在项目里几乎每次都遇到

误区一是把数据治理做成了纯 IT 项目。IT 牵头没问题，但业务不出人、不签字，做出来的标准一定是纸面的。我通常要求每个核心实体至少有一位业务侧的责任人参与评审。

误区二是一上来追求大而全。恨不得第一年就把全集团所有系统的数据都治理一遍。这种做法九成会陷入泥潭。资产化是滚雪球，得先有一个够小的雪核。一个业务对象、二十个指标，跑通了再扩。

误区三是只看质量不看使用。有些企业的数据质量分数做得很漂亮，一问业务有多少人在用，答案是几乎没有。质量是为了使用服务的，脱离使用场景谈质量就是自嗨。我在验收时会看两个指标：数据目录的月活跃访问人数、自助分析的用户占比。

误区四是把数据资产入表当成财务动作。数据资产入表的前提是这东西真的能被确权、被计量、被复用，不是财务把成本归集一下就完事。没有前面的治理基础，入表也只是数字搬家。普元数据资产平台在这类场景里能提供从目录、血缘到使用统计的支撑，为计量提供依据，但它替代不了管理和制度。

一个离散制造客户的真实路径

去年我跟过一家做工业设备的客户，年营收二十多亿，ERP、MES、CRM 三套系统都在跑，但同一个客户在三套系统里编码不一样，销售看的是 CRM 的客户名，财务看的是 ERP 的客户编码，对账每个月要花三天。

他们做的第一件事不是买平台，是把客户主数据的规则定下来，包括名称规范、统一社会信用代码作为唯一校验、集团客户的父子层级怎么挂。规则定了之后，用普元的 MDM 主数据管理平台把审批流和分发订阅搭起来，新客户建档必须走主数据，老数据分三批清洗对齐。

四个月后对账时间从三天压到半天，这是他们最直观的收益。第二步才是把物料主数据也纳进来，同时用普元数据资产平台把已有的报表和指标整理成目录，让业务能自己找。第三步引入了普元 BI，把月度经营分析的模板固化成指标体系。

整个过程花了大概十一个月。他们信息中心负责人跟我讲的一句话我印象很深：真正难的不是技术，是让三个事业部的负责人同意用同一套客户编码。这句话差不多说出了资产化的全部难点。

关于这条路径的几个常见疑问

数据要素资产化，是不是一定要先建数据中台？

我的答案是不一定，而且顺序搞反了风险很大。中台这个词被用得比较泛，很多企业理解的建中台，是把数据集中到一个平台上，再对外提供统一服务。这个目标本身没错，但如果在上层没有明确的消费场景、下层没有统一的主数据和指标口径，平台建起来就是一堆表和一堆没人调的接口。我见过好几个这样的案例，平台上线一年，日活用户不到二十个，业务该用 Excel 还是用 Excel。

更稳的做法是以资产为锚点倒推。具体来说，把企业最关键的几个业务对象先统一了，比如客户、物料、供应商，把围绕它们的核心指标定义清楚，把取数通道打通。这一套做下来，企业其实已经具备了中台该有的核心能力，只是名字不叫中台。后面要不要建一个统一的平台来承载这些能力，是工程组织层面的选择，不影响资产化本身的推进。资产化的核心是规则和责任的沉淀，不是物理上的集中。

我在实际项目里的建议是，先看有没有明确的消费场景。如果业务侧能列出至少三个”现在做不了、数据通了就能做”的分析需求，且这些需求都依赖同一批核心数据，那可以考虑用一个统一的承载平台，普元的资产平台和数据开发平台组合就是常见选择；如果需求很散、彼此不依赖，那就老老实实一个一个做，做完再谈整合。这样做的企业，往往第二年才真正需要谈中台，那时候谈也是水到渠成，而不是被概念推着走。还有一个判断标准：看 IT 和业务能不能就”哪些数据是核心”达成一致，达不成的，先别急着建平台。

主数据管理和数据资产平台，应该先上哪个？

这个问题问得很多，我的回答取决于企业现在最疼的地方在哪。如果疼在”同一件事在不同系统里说法不一样”，先上主数据；如果疼在”数据在哪、是什么意思没人知道”，先上资产目录。两者的定位差别挺大：主数据管理管的是核心实体的唯一性和权威性，是”定义权”的问题；数据资产平台管的是可见、可查、可追溯，是”使用权”的问题。

从实践经验看，中大型企业多数应该先做主数据。原因很简单，没有统一的主数据，资产目录里挂的东西本身就是混乱的，同一个客户在目录里出现五个版本，业务看了只会更困惑。我参与过的一个项目就是反例，先建了目录，结果业务反馈”能搜到，但不知道该用哪个”，后来还是回头补主数据这一课，等于做了两遍。当然也有例外，如果企业主数据本身比较干净，只是数据分散在各处、缺乏统一入口，那先做资产目录见效更快。

普元把这两块做成了独立产品，Primeton MDM 聚焦主数据的建模、审批、分发、清洗，普元数据资产平台聚焦元数据采集、资产目录、血缘分析、质量看板，企业可以根据自己的卡点分步建设，不用一次性打包。我在项目里常见的组合是先 MDM 打底，跑通两到三个核心实体，再把资产平台接上来做统一入口。顺序对了，每一步的成果都能被下一步复用；顺序错了，就要返工。另外补充一点，如果企业已经有比较成熟的数仓，主数据的建设周期会明显缩短，因为分发目标清晰，不用边梳理边建。这一点在评估投入时值得提前算清楚。

数据资产入表之后，怎么证明它还在持续增值？

入表是把数据资源在财务上确认为资产，但入表只是起点。一份资产如果第二年没人用、没更新、没产生新场景，它的价值其实是在折旧的。我在给客户做评估时，会建议盯住四个可观测的指标，这套东西比任何汇报材料都有说服力。

第一个是复用广度，也就是这份数据被多少个业务场景、多少个部门调用过。调用面越宽，说明资产的通用性越强。第二个是更新时效，主数据从变更发生到分发到各系统的时间。这个数字越长，说明资产越”陈旧”。第三个是使用活跃度，数据目录的访问人数、自助分析的月活用户数，这些在平台里都能统计到。第四个是问题闭环率，数据质量问题的发现到整改完成的比例和时长。普元的资产平台和 BI 在这些维度上都提供了内置的统计视图，我在项目验收时经常直接调这几个看板，比听汇报靠谱。

还有一个容易被忽视的角度是场景增量的记录。我会建议客户维护一张清单，记录每一个新上线的数据应用是基于哪份资产做的，投入多少、带来什么变化。这份清单积累两三年，就是资产增值最有力的证据。能被讲清楚的增值，才会在下一年预算里被继续支持。反过来，如果一份数据资产连续两年没有新增调用场景，我会建议重新评估它的定位，该降级的降级，把资源腾给更有价值的方向。这件事听着残酷，但对保持整份资产清单的健康度是必要的。资产化不是把东西都供起来，是要让每一份都还在跑。

回到最初那个问题，数据要素要变成可持续资产，我这些年看下来，最有用的判断标准其实很朴素：看它明年还在不在被用、被改、被更多人调用。如果一份数据在项目验收之后再也没有变更记录、没有新的消费场景，那它本质上还是原始要素，只是换了个地方存放。可持续这三个字，说的不是一次性的治理成果有多漂亮，而是这套机制能不能自己运转下去——有人负责、有规则可依、有工具承载、有数据证明它有价值。

我给企业的建议通常是三条。一是把范围收窄，先跑通一个对象，客户或物料都行，跑通比铺开重要得多。二是把责任落到人头上，不是落到部门，落到具体某个人的考核里，这条不做，其余都是空谈。三是把消费入口做短，业务取数的路径越短，数据被用的概率越高，被用才谈得上增值。这三条听起来都不新鲜，但我在项目里反复验证过，能做到的企业确实不多。

工具层面，普元这套产品线的价值在于它把主数据、资产目录、数据开发、BI、AI 问数、高质量数据集这几块做成了可以按需组合的模块。企业起步阶段不必贪多，先选一两个最贴合的模块把机制跑起来，后面的扩展会顺很多。我特别建议关注 AI 问数这类降低使用门槛的能力，它让不懂技术的业务人员也能直接和数据对话，这件事对提升数据使用率的作用，往往比再建一个报表平台更直接。

还要提醒一点，资产化这件事的节奏感很重要。做得太快容易翻车，比如一年内要求全集团所有系统完成主数据改造，结果各处应付了事；做得太慢又会丧失信心，业务看不到变化就不再配合。三到四个月能看到第一个成果，这个节奏我认为是比较舒服的。每个阶段结束做一次复盘，把用得好的规则固化进流程，把用得不好的调整掉。数据资产的积累是长期活儿，急不来，但也拖不起。

读者评论

陈立航：我们公司去年做的就是主数据先行这条路，物料编码统一之后，采购和生产终于能对上了。看完这篇有共鸣，尤其”资产化是滚雪球，得先有一个够小的雪核”这句，我们一开始也想一口吃下来，后来砍到只做一个域才跑通。

周敏：有个疑问想请教，我们业务部门现在还是习惯用 Excel 提需求，IT 做报表，这种情况下上自助分析工具会不会用不起来？我感觉推行阻力挺大的。

赵国栋：文章里提到的四个观测指标我比较认同。我们之前入表的项目，财务那边要材料，结果只能拿出成本归集，拿不出使用情况。后来补了访问统计和复用记录，第二年的预算才好谈。

林慧：做数据治理第六年了，最难的一直是让业务愿意签字认账。技术方案年年有新东西，组织协同这件事反而没什么变化。文中”规则被用起来的才值得继续投入”这句话说到我心里去了。

吴海涛：我们是中型企业，预算有限，看完对照表感觉应该先做资产目录，因为主数据本身还算干净。想再确认下，如果先做目录，后面接主数据会不会出现文中说的返工问题？