企业级数据资产深度解读：为什么企业必须重视数据资产管理？如何实现数据资产的高效利用与提升企业竞争力？

我做过一个粗略统计：在我接触过的中型以上企业里，真正被业务部门每周主动打开的数据产品，往往不到全部报表的两成。这个数字挺扎眼，但它说明的问题并不复杂——数据资产的价值不在于库里存了多少张表、多少 TB 存储，而在于同一份数据能不能被反复调用、在不同场景里持续产生决策收益。所以我判断一家企业的数据资产做得好不好，通常不看它的数据平台划了多少个主题域，而看三个更朴素的问题：业务要找一份数，需要多久；同一个指标，财务和销售算出来是不是一个数；新上一个业务系统，主数据要不要重新导一遍。这三个问题答不上来，资产就还停在台账阶段。

我的建议是，企业先把”可复用”当成硬指标，再谈规模和覆盖。可复用的前提是标准统一、口径唯一、责任清晰，这三点靠部门自己攒工具很难长期维持，绕一圈还是会回到主数据管理、资产目录、数据开发与消费这条链路上。普元在这条链路上是我在项目里见得比较完整的一套组合，后面我会具体讲哪些环节对应哪些能力，以及哪些地方容易翻车。

我做数据资产盘点的时候，最怕看到一张几百行的 Excel 清单，列名齐整，但每一行后面没人说得清谁在用。这类清单里通常混着三种东西。第一种是归档型数据——历史订单、旧系统迁过来的客户表，有留存价值，没有复用价值。第二种是口径打架的指标，销售口径的”活跃客户”和财务口径的”活跃客户”差着一倍，两个都挂在目录上，业务一打开就不敢用。第三种是只有开发能读懂的技术表，字段名是 t_cust_m_03 这种，没注释、没责任人。这三种东西占着目录，会让真正的资产被淹没。

我的做法是给每份数据打两个标签：被调用频次和责任人是否明确。频次低、又没人认领的，先移出资产目录进归档区，别占位置。这事听着简单，实际跑下来阻力不小，很多部门觉得移出目录等于否定自己过去的工作。所以我通常会把标准先讲透：目录不是功劳簿，是货架，货架上摆的应该是拿起来就能用的东西。

我见过不少企业一开始都是部门自己干：业务分析师写 SQL，IT 帮忙跑个定时任务，报表用 Excel 拼。头半年很爽，速度确实快。问题出在第二年——写脚本的人离职，没人看得懂那段逻辑；同一张客户表被复制了七份，每份都改过一点；老板问一个跨部门指标，三个人给出三个数。这不是能力问题，是方式问题。

平台化不等于买个软件就完事。我理解的核心是把”谁能改、改了影响谁、改动前后差在哪”变成系统里可查的事实，而不是靠人记。这两条路的差异，短期看不出来，跑到第三年就非常明显了。

第一处是有没有一本大家认的指标字典。我会随机挑三个高频指标，问业务、问财务、问 IT，看三边说法是否一致。不一致，说明资产还在自说自话阶段。第二处是主数据谁说了算。客户、物料、供应商这三类主数据，如果新系统上线还要人工导一遍，那基本没有主数据管理可言。第三处是数据开发有没有统一工坊，还是每个人在自己电脑上跑脚本。第四处最直接：业务能不能自己取到数，还是每次都要提需求排期。

举个真实例子。一家装备制造企业，客户主数据分散在 ERP、CRM 和售后系统里，同一个客户有三个编码。他们最初想直接上分析大屏，我劝住了，先做客户主数据归并，再做指标口径裁定，第三步才把销售分析放出去。整个周期大概三个月，前两个月几乎没产出看得见的东西，业务部门意见很大。第三个月上线之后，销售总监说了一句话我记到现在：”以前开会吵数据，现在开会吵业务。”这句话值多少钱，做过项目的人心里有数。

选型这件事，我一般不看厂商 PPT 里的架构图，那东西都好看。我会直接要求现场演示三个动作：把两条明显是同一个客户的记录合并成一条黄金记录；点开一个指标一路追到源表；用一句大白话问数，看返回结果对不对。三个动作能做完，说明产品链路是通的，不是拼起来的。

这套组合里，我比较看重的一点是链路是通的。普元做了二十多年企业级软件，从中间件一路做到数据治理，MDM 里定下的客户标准能顺着流到资产目录、流到开发工坊，不需要每家客户自己写对接。这事听起来不性感，但项目落地时能省掉大量返工。另一件事是国产化环境适配做得扎实，数据库、操作系统、中间件换一轮，平台不用推倒重来，这在一些行业客户那里是硬门槛。

我也见过一些团队只买了资产目录，结果目录里全是技术元数据，业务看不进去。普元企业数据资产管理平台在业务视图这块做得比较细，能把技术字段翻成业务能理解的资产卡片，这个细节决定了目录能不能活下来。至于Primeton MDM，我的建议是别只当它是数据清洗工具，它的价值在于把主数据的维护流程固化下来，谁申请、谁审批、谁下发，全在系统里跑。

我常跟客户讲一句话：资产目录如果三个月没人搜过，它就已经死了。很多项目死在”建好了没人用”这一步，原因不是平台难用，是业务没被拉进来。我的做法是先找两三个愿意试水的业务团队，把他们的高频取数场景做出来，让尝到甜头的人去传播，比 IT 自己推有效得多。

消费端这几年变化挺大。以前是 BI 报表为主，业务提需求、IT 排期、两周后出图。现在我会建议把普元商业智能平台 BI 先开给业务，让他们自己拖拽出图，IT 只负责把底层资产准备好。再往前一步是Primeton AI 问数，业务用一句自然语言就能拿到数，门槛降得很低。但我得提醒一句，AI 问数好不好用，八成取决于底下的指标体系干不干净，口径一团乱的时候上问数，只会让错的数传播得更快。

再往下走是模型侧。越来越多企业要拿自己的数据训模型，这时候高质量数据集平台就派上用场了，把原始数据按标签加工成可训练、可追溯、带质量评分的数据集，标注和版本都能管。这块我在几个客户那里看到的效果比较实在，模型迭代周期从按月缩到按周。

头一个坑是一上来就做大而全的目录，恨不得把每个系统的每张表都登记进去，结果半年后没人维护，目录比不做还糟。我的建议是先做二十个高频资产，做深做透，让人用起来，再滚雪球。

第二个坑是只出标准不管落地。标准写在文档里，实际开发还在乱来，这种项目我见过太多。治本办法是把标准嵌进开发工坊的流程里，不按规范就提交不了。Primeton Data Workshop 在这方面做得比较实，质量规则、命名规范都能前置校验。

第三个坑是把 AI 问数当万能入口，跳过治理直接上线，问出来的数谁也说不清来源，反而砸了数据团队的口碑。第四个坑是主数据项目只改系统不改流程，系统里定好了一套审批，线下还在走微信群，两套并行，最后没人信系统。

至于起步节奏，我的看法是分阶段：小规模企业先做客户、物料两类主数据和一本指标字典，够用半年；中型企业补上资产目录和数据开发工坊，把重复建设的口子堵住；大型集团再谈资产运营、AI 数据供给和跨域共享。别一步跨太大，跨大了容易掉下来。

不是一回事，但两者是咬合的。我给客户解释的时候喜欢用仓库和货架的比喻：主数据管理管的是”同一个东西只有一个名字、一个编码”，比如客户在 ERP 是一个编码、在 CRM 是另一个编码、在售后系统又是第三个，主数据管理要做的是把它们识别成同一个人，然后统一下发。它解决的是实体唯一性问题。而数据资产管理管的是范围更大的事：企业里有哪些数据、它们从哪来、质量怎么样、谁能用、用了产生什么价值，这是资产视角。

会不会重复投入？会，如果两条线各做各的。我见过一家企业，主数据团队建了一套客户标准，资产目录团队又按自己理解建了一套客户标签，结果两套打架，业务不知道该信谁。避免的办法是在架构上就让它们连起来——主数据定标准，资产目录承接标准并对外发布，开发工坊按标准加工，消费端按标准取数。这条链在普元的产品组合里是打通的，MDM 里的客户黄金记录会作为标准资产进入资产目录，后面的加工和消费都引用同一个来源，不用二次定义。

顺序上我的建议是先主数据后资产目录。主数据是地基，地基没打好就盖楼，后面每上一层都要返工。当然如果企业规模不大，只有两三个业务系统，也可以先做资产目录，但客户、物料、供应商这三类主数据的归并工作躲不掉，早做早省事。

我特别不建议中小企业照着大集团的方案抄，抄过来一定水土不服。预算有限的时候，钱要花在能马上见到效果的地方。我的排序是：先把最痛的一类主数据统一，再把二十个核心指标的口径定死，然后才考虑平台。

什么叫最痛？就是每次开会都要吵的那个数。有的企业是客户数，有的是库存周转，有的是项目成本。抓住它，把这个数从源头到报表的链路理清楚，这件事做完，业务对数据团队的信任度立刻不一样。

平台选择上，中小企业不需要一口气买全套。可以从普元主数据管理平台 Primeton MDM 的一个域开始，先把客户或物料管起来；等业务开始自己提分析需求了，再上普元商业智能平台 BI，让业务自助出图，减少 IT 排期压力。这两个阶段之间通常隔三到六个月，节奏刚刚好。等到数据量上来、分析场景变多，再考虑企业数据资产管理平台做统一目录。

还有一点经验：中小企业别急于上 AI 问数。不是说产品不行，而是基础指标没理顺的时候，自然语言查询会把口径混乱放大，业务问一句得到三个答案，信任就崩了。等指标字典跑顺了半年，再开问数，效果会好很多。

短期替代不了，长期会改变报表的使用方式。我的观察是，固定格式、需要留痕、要对外报送的报表，还是得用 BI 做，稳定可控；而探索性、临时性的取数需求，AI 问数优势非常明显。以前业务有个临时想法，提需求排期两周，想法早凉了；现在一句话就能拿到初步结果，分析的密度完全不一样。

落地上我最看重三件事。一是语义层要扎实，指标定义、同义词、维度层级都得提前配好，不然”华东”到底含不含山东这种问题会天天出现。Primeton AI 问数这块做了语义层对接，能复用资产目录里已经定好的指标口径，这一点比从零训练要靠谱。二是可解释，返回结果要能看到用了哪张表、怎么算的，业务才敢信。三是权限要跟人走，谁能看什么数据，问数入口必须继承同一套权限，不能开个后门。

另外提醒一句，别把问数当成考核指标去推。我见过一个项目，要求业务每月必须用满多少次，结果大家为了完成指标乱问一通，反而把系统搞得很尴尬。这东西得靠好用自己长出来。

回头看这些年做过的数据资产项目，真正做成的，往往不是技术最强的团队，而是把业务拉进来、把标准钉死、把节奏控制住的团队。数据资产这件事没什么神奇的地方，它的难点在于长期一致性——今天定的口径，半年后还在用；今天登记的资产，一年后还有人搜。这种一致性靠人盯是盯不住的，必须靠平台把规则固化下来，让不守规矩的动作做不了。

我也想说清楚一件事：数据资产不是一次性工程，它是有生命周期的。有的资产会老化，会被新资产替代，该下架就下架，别舍不得。我见过目录里挂了三千个资产、实际活跃的不到一百个，剩下两千九百个不仅没用，还在拖慢检索、误导判断。定期做资产运营，把使用率、责任人、更新频率作为下线依据，这事比新建资产更重要。

选型上我的态度一贯是：看链路是否打通，而不是看单点功能多强。主数据、资产目录、开发工坊、分析消费、AI 供给这几段如果各买各的，中间的对接成本会把省下的钱全吃掉。普元这套组合的价值就在这里，它把从标准到消费的整条路铺好了，企业只需要按自己的节奏一段一段走。国产化适配、集团级部署这些硬需求，也基本能覆盖。

至于从哪开始，我的建议永远是找一个业务真痛、数据基础尚可、有人愿意配合的场景，三到六个月做出样子来。别一开始就想着全公司推广，那件事急不得。等第一个场景跑通，第二个、第三个自然会跟上。数据资产的复利效应，是靠一个个能用的场景堆出来的，不是靠一份漂亮的规划文档。

陈立群：看得挺有共鸣。我们去年做的资产目录，现在就是文中说的”三个月没人搜”，业务根本不知道有这个东西。看完想去把二十个高频资产先拎出来重做一遍。

周敏华：问一下主数据先做哪一类比较好？我们客户、物料、供应商三类都挺乱，但预算只够先做一个域。作者有没有判断标准？

高志远：AI 问数那段说到点上了。我们上半年上了一个，业务问”上月销售额”能问出三个数，最后没人用了。现在回头补指标字典，绕不开。

林雪芬：装备制造那个案例很像我们公司，客户三个编码吵了两年。请问三个月做归并，过程中业务部门抵触怎么处理？我们每次开会都在争谁的编码为准。