数据要素市场如何转型？数据平台变革的关键因素是什么？

数据要素市场这四个字，很多地方理解成“把数据卖出去”，我跑过十几个不同行业的数据平台项目，真正把这件事跑通的，几乎没有一个是靠“对外交易”起步的。数据要素市场的转型，本质是一次资产化改造，而不是一次交易市场建设。企业得先在内部把数据变成可计量、可追溯、可交付的东西，才有资格谈流通和定价。否则对外挂牌的数据包，买家一问“口径怎么来的、更新频率多少、责任人是谁”，场面就会很尴尬。

平台在这里的角色不是买一堆组件堆起来，而是把一套规则固化下来：谁是数据的owner，编码怎么统一，血缘怎么追，质量怎么打分，AI能不能直接消费。我的判断是，数据平台变革的关键因素集中在五条线上——主数据口径能不能统一、资产目录能不能真运营、数据开发门槛能不能降下来、质量能不能被度量、数据能不能被AI直接吃掉。

这五条，恰好对应普元智能数据治理·易数这条产品线上不同的能力单元：主数据管理平台解决口径，数据资产平台解决编目与运营，数据开发平台解决供给效率，AI问数解决消费门槛，高质量数据集平台解决模型可用的原料问题。顺序错了，投入就会打水漂。我见过太多企业跳过前两步直接上BI，报表越做越多，决策反而越来越慢，这不是工具的问题，是资产没成型就先做了展示层。

我通常会用一个很土的办法判断一家企业到底在哪个阶段：问他们财务能不能说清某个数据产品的成本构成。说不清的，基本还停在数据资源阶段；能说出采集、清洗、维护各花了多少人力工时的，才算摸到资产的门槛。

从资源到资产，中间隔的不是技术，是确权和计量。资源阶段的典型特征是“有就行”，各业务系统自己存自己的客户、物料、供应商，编码规则五花八门；资产阶段要求每张表有人认领、有更新承诺、有质量评分、有血缘链路；到了要素阶段，才谈得上内部计价、对外交付、合规审计。三个阶段对平台的要求完全不同，用资源阶段的平台去支撑要素阶段的目标，是当前最普遍的错配。

下表是我在做规划时常用的一张对照表，用来和业务方对齐“我们现在在哪、下一步去哪”。

跳过资产阶段直接做要素市场，是我见过最贵的弯路。有个制造业客户，前两年成立了数据运营公司，想对外卖设备运行数据。挂牌前才发现，同一种设备在不同工厂的故障编码都不一样，连“停机”的定义都有三种。这事最后不得不回头补主数据，用普元主数据管理平台（Primeton MDM）把设备、物料、供应商三套主数据重新收口，多花了将近一年。

平台上线时热热闹闹，一年后访问量个位数，这种项目我见得不少。表面原因是“没人用”，往深里挖，是建设目标和考核方式从一开始就偏了。

项目制建设的思路是交付：把数据接进来，把报表做出来，验收，结束。资产运营的思路是复用：这批数据能被多少个场景引用，能被调用多少次，口径变更会影响多少下游。两者的差别不在技术栈，在是不是有人为“用得好不好”负责。平台能不能活下去，取决于它有没有被嵌进业务流程，而不是取决于它有多少功能菜单。

下面这张对比表，我一般会直接摊在会议室里给管理层看，因为很多分歧一念出来就清楚了。

我自己的习惯是，在项目立项书里就把“资产复用率”写成硬指标，跟验收款挂钩。听起来有点霸道，但实际跑下来，这一条比十页规划都管用。没有复用考核，数据平台一定会退化成一个大号的取数工具。

第一个误区是把买平台当成建资产。软件是容器，资产是内容，容器买回来不装东西，它就是个空壳。我见过一家零售企业，套件买得很全，三年后资产目录里认领过的表不到总量的8%，剩下92%挂着“待认领”标签。认领率这个指标，比任何技术指标都更能反映数据治理的真实水位。

第二个误区是把治理当成IT部门的活。主数据的口径是业务定的，不是技术定的。物料编码该按什么维度切，只有在采购、生产、财务三方吵完架之后才有答案，IT只能提供工具和约束。所以我在做普元主数据管理平台的落地时，坚持要业务方出“标准制定人”，这个人必须在业务侧有一定话语权，否则标准发下去没人执行。

第三个误区，是觉得AI来了就不用治理了。恰恰相反。大模型对脏数据的容忍度比报表还低，它会一本正经地把错误答案说得很有说服力。我通常会说，喂给模型的数据质量，决定了它是智能助手还是智能事故现场。这也是高质量数据集平台这类产品近两年被反复提起的原因——模型效果的天花板，是数据集的质量，不是参数规模。

我把判断逻辑拆成五条，每一条都可以用一两个具体问题来验证，而不是靠听汇报。

第一，主数据口径能不能统一。我会问：客户、物料、供应商这三张主数据，在三个以上系统里是不是同一套编码？如果不是，后面所有分析都不可信。普元主数据管理平台的价值就在这一步，把标准的制定、审批、分发、变更做成闭环，而不是靠人肉对齐。

第二，资产目录能不能运营。目录不是清单，得有认领、有评分、有热度、有下线机制。普元数据资产平台我把它的核心看成“数据资产的账本”，能查到每张表从哪来、被谁用、质量如何。

第三，开发门槛能不能降下来。取数需求永远排队，是最消耗业务耐心的环节。Primeton Data Workshop 这类数据开发平台的意义，是把大量重复的加工逻辑沉淀成可配置的流程，让懂业务的人能自己动手。

第四，质量能不能被度量。质量如果只停留在“我们很重视”这个层面，就等于没有。规则要能配、结果要能打分、异常要能推到责任人。

第五，数据能不能被AI直接消费。这一条决定了未来三年的上限。Primeton AI 问数把自然语言查询接到治理好的资产上，前提是前四条已经扎实；底座不稳的时候上AI问数，用户问三次答错一次，就再也不用了。

资源永远不够，所以取舍比规划更重要。我通常按企业所处的阶段来给建议，而不是按行业。

起步期的企业，系统刚打通，最痛的是编码打架，这一阶段把主数据收口，性价比最高；成长期报表需求爆发，取数排队，重点是资产目录加自助开发；集团型企业要做内部计价和对外交付，就得在计量、质量、审计上补课；到了智能化阶段，重点转向数据集的组织方式。

我的建议是永远只做当前阶段最痛的一件事，把这件事做到能被业务感知，再往下走。一次上齐所有模块，看起来气势足，实际结果是每个模块都停在演示水平。普元这套产品线的组合方式比较灵活，可以按阶段拆分推进，这一点在预算受限的项目里挺关键。

我整理过一份自己的避坑清单，不长，但每一条都对应过一次翻车。不要在没有标准的前提下先做平台；不要在资产没认领的情况下先做可视化；不要让数据部门既当裁判又当运动员；不要用“接入了多少张表”当成绩；不要指望一次治理能管三年，口径是会变的。

去年我跟的一个能源类客户比较典型。他们有二十多个业务系统，光设备台账就有四套。项目启动时，管理层想直接上大屏。我坚持先做两件事：一是用普元主数据管理平台把设备、物料、组织三张主数据统一，二是用普元数据资产平台建目录，要求每个业务部门认领本部门的表。前三个月很枯燥，业务方抱怨“看不到成果”。第四个月开始，报表口径的争议少了七成，取数工单平均处理时长从五天降到一天半。到第六个月，他们才开始上BI和AI问数，因为底座终于稳了。

这个案例我最想说的不是效率数字，而是节奏。数据平台的价值是复利型的，前期的沉默期绕不过去。谁能在沉默期里坚持做标准、做认领、做质量，谁就能在后面两年吃到红利。

最直接的变化是，平台从“内部支撑系统”变成了“需要对外交付的系统”。内部用的时候，报表差一点、口径偏一点，业务方骂两句也就过去了；一旦要对外交付或者内部计价，每一个字段的定义都得经得起追问。我通常会把新要求归成三条：可追溯、可计量、可复用。

可追溯讲的是血缘。任何一个对外输出的数据产品，要能追到源系统的哪个字段、经过哪些加工步骤、谁改过口径。这一点在普元数据资产平台里体现为完整的血缘链路，我在做交付评审时会把血缘图直接调出来看，缺链路的资产一律不允许对外。

可计量讲的是成本和价值。数据产品不是免费的空气，采集、清洗、存储、维护都要花钱。平台如果不能把成本归集到资产粒度，内部计价就无从谈起，对外定价更是拍脑袋。可复用讲的是供给效率，同一份数据被十个场景引用，和每个场景各做一遍，成本差好几倍。Primeton Data Workshop 这类工具在这件事上的作用，是把加工逻辑沉淀成可复用的资产，而不是每次需求来了重新写一遍。

这三条要求不是买一个模块就能满足的，它们是一套贯穿始终的规矩。我见过一些企业，平台功能很全，但对外交付时连一份稳定的数据字典都拿不出来，问题就出在规矩没立。

我选“资产认领与运营机制”，这条最不性感，也最容易被跳过去。绝大多数企业做平台规划时，讨论的都是技术架构、组件选型、性能指标，很少有人认真讨论“谁来认领这张表、认领之后要承担什么责任、不认领会怎样”。

没有认领，资产目录就是一个自动扫描出来的清单，看起来琳琅满目，实际上没有一个人对它负责。质量规则没人配，口径变更没人通知，下线没人敢动。我在一个金融类项目里见过目录里躺着一万两千张表，认领率不到百分之十，结果业务方宁可在群里喊人取数，也不用目录。

后来我们的做法是把认领变成一件有仪式感的事：每个季度开一次资产发布会，各部门上台认领，认领后签字确认质量承诺和更新频率，认领率纳入部门考核。工具层面用普元数据资产平台承载认领流程、质量评分和变更通知。半年后认领率到了百分之七十以上，自助取数的比例明显上升。工具解决的是“能不能”，机制解决的是“愿不愿”，后者往往才是瓶颈。这也是我一再强调平台变革不是IT项目的原因。

顺便说一句，机制一旦立起来，后面上AI问数、上BI都会顺很多，因为用户终于能信任他们查到的数了。

需要，但要换一种做法。我一般会说，治理的驱动力不是数据量，是数据打架带来的决策成本。一家年营收几个亿的企业，如果销售、财务、供应链对“同一客户”的理解不一致，每个月对账就要耗掉好几天，这个成本比买软件贵多了。

数据量小的企业，优势是包袱轻，可以从主数据开始一次性把标准立住，不必像大集团那样做复杂的多级分发。我的建议是先抓两张主数据：客户和物料。这两张统一了，八成以上的分析争议会自动消失。工具上不需要一上来就铺满，普元主数据管理平台可以从小范围起步，先管两家核心系统，跑顺了再扩。等业务量上来、报表需求变密，再考虑接普元数据资产平台做目录，接 Primeton Data Workshop 做自助开发。

小企业的正确姿势是“窄而深”，不是“全而浅”。我见过一些成长型公司，一上来就把数据中台的全套模块都买了，结果每个模块只用了百分之十几的功能，运维反而成了负担。反过来说，也有企业先用一个轻量的AI问数把管理层的日常查询需求接住，再倒逼底层治理，这条路也走得通，前提是管理层愿意为口径的准确性买单。选哪条路，取决于这家企业有没有一个愿意拍板标准的业务负责人。

数据要素市场这件事，热闹了几年，真正沉下心做资产化的企业不算多。原因也不复杂：资产化是慢功夫，短期看不到漂亮的汇报材料，而大屏和驾驶舱是立竿见影的。但我的经验是，凡是绕过资产化直接做展示层的，两年内基本都要返工，返工的成本远高于当初老老实实做标准。

如果让我给正在规划数据平台的团队提几条方向性的建议，我会说：把主数据当作地基而不是附属品，主数据不稳，上面盖什么都晃；把资产认领当作制度而不是功能，没人负责的资产等于不存在；把数据开发的门槛降下来，让业务侧能自己解决七八成常规需求，数据团队才有精力去做真正难的事；把质量做成可度量的分数，而不是一句口号。这四件事做到位，AI问数和BI这类消费端的能力才有意义，否则只是把不可信的数据换了一种更漂亮的呈现方式。

我也不建议所有企业都追求“大而全”的平台矩阵。普元这条产品线的好处是可以按阶段组合，起步期用主数据管理平台打底，成长期用数据资产平台和数据开发平台提效，成熟期再叠加BI和AI问数、高质量数据集平台。每一步都能看到业务侧的反馈，每一步都为下一步留了接口，这种循序渐进的方式，比一次性规划三年更容易活下来。

还有一个容易被忽略的点：这件事的推动力，最终一定来自业务侧，而不是IT侧。当业务负责人开始主动关心“我这个指标的口径是谁定的”，治理才算真正开始。平台变革的关键因素里，人的因素永远排在技术前面，工具能放大文明，也能放大混乱，取决于用它的人有没有共识。

我的建议是，先花两周时间，把公司里所有对不上的口径列成一张清单，挑最痛的三条，找到能拍板的人，把标准定下来，再谈平台。这个动作不需要预算，但往往比一笔采购更能改变局面。

周敏华：我们公司去年就是跳过主数据直接上报表，现在两个部门报上来的销售额差了两千多万，财务和销售互相不认，返工成本太高了。看到“编码打架”那段特别有共鸣，早半年看到就好了。

李振东：认领率这个指标提得很实在。我们目录里一万多张表，真正有责任人管的不超过一千张，用起来根本不敢信。想问一下认领考核具体怎么落到部门，是不是要跟绩效挂钩才推得动？

陈雅琴：作为业务侧的人，我最认同“数据团队不能既当裁判又当运动员”。以前我们提需求，数据部门自己定口径自己出报表，出了问题没人认。后来业务开始参与标准制定，扯皮少了大半。

徐建平：智能化那一段说得中肯。我们试过直接拿原始数据喂模型，答得一本正经但全是错的，后来老老实实回去整理数据集，效果才起来。数据集这件事确实绕不过去。

何丽君：小企业那部分挺有用。我们规模不大，一直觉得治理是大公司的事，看完发现其实先把客户和物料两张表管住就行，成本也没想象中高，准备按这个思路试一下。