数据要素市场中的方法论是什么？如何有效应用数据要素市场的策略？

我在数据治理和数据资产这条线上做了十一年，从早年陪客户吵指标口径，到做集团主数据，再到近两年帮企业做数据资源入表、帮地方平台做数据产品挂牌，项目数下来过百。被问得最频繁的一句话是：这套东西到底有没有一套能照着走的方法。我的回答一向不太好听——大部分所谓方法论，本质上是一张好看的流程图，缺的恰恰是每一步的输入、输出和判定标准。真正的闭环只有五段：资产识别、治理加工、产品化封装、场景消费、成本与价值回算，五段必须咬合，缺一环整个链条就转不动。这个闭环里，我通常把普元数据资产平台放在中枢位置，目录、血缘、质量、标签长在同一个底座上，不用我在四个系统之间手工拼数。另一个常见误解是把数据要素等同于“卖数据”，其实企业内部先把数据用对、用出账，才有资格谈对外流通。我会要求团队先回答三个问题：我们手上哪些数据是别人愿意付钱或愿意换资源的；这些数据经过什么加工才算“干净可用”；加工成本怎么摊到具体产品上。答不上来，方法论再漂亮也只是 PPT。

先说断点。政策端从国家数据局挂牌到“数据要素×”三年计划，节奏很密，但项目端的情况是：需求是真的，钱是真的，路径是模糊的。我见过一家大型制造集团，数据中台建了三年，资产目录两千多条，可真要挑出一份能对外报价的数据产品，一个都拿不出来。问题不在技术，在于从头到尾没人定义过“什么算资产”。下表是我在不同项目里反复遇到的卡点归集，基本覆盖了八成场景。

看清这张表你会发现，断点几乎都不在“有没有平台”，而在“有没有把数据加工成可交付物”。这也是我一直建议客户把数据资产平台和数据开发平台一起规划的原因，普元在这两块是打通的，资产目录里点开一个资产，能直接看到它是哪条加工链路产出的，血缘分得很细。

我踩过的坑里，最贵的一个是：项目启动会上所有人都在说“数据资产”，但每个人脑子里的东西不一样。业务方想的是报表，IT 想的是表，财务想的是能不能入表。概念不拉齐，后面所有工作量都是白干。所以我现在进项目第一件事就是做三层对齐，把资源、资产、产品三个词钉死在墙上。财政部的数据资源会计处理暂行规定落地之后，这个概念差更值钱了——不是所有数据资源都能进资产负债表，得满足可辨认、可计量、有预期经济利益。下表是我给客户做内部培训时固定用的对照。

三层不分，投入就会全砸在第一层：钱花在存储和采集上，最后拿不出一个能对外的交付物。我的建议是，编目做到六成覆盖度就停下来，把资源往上推成资产，别在“全量盘点”上耗一年。

我见过太多治理项目做成“运动式”：抽调三十人干三个月，标准文档写了八百页，人一撤，三个月后数据又乱回去。治理必须变成一条日常跑的流水线，有工单、有 SLA、有回归校验，否则它天然会衰减。具体到动作上，我会把主数据当成地基，客户、物料、供应商、组织四类实体先做唯一性治理，这一步用 Primeton MDM 来做最省事，因为它不只是管标准，还能把清洗规则、审批流、分发订阅串起来，新系统接进来直接订阅，不用各建一套。主数据稳了之后，再上数据开发平台把加工链路固化下来。普元的数据开发平台我用得比较顺，原因是它把离线加工、实时链路、调度和血缘放在一个工作台里，开发完的作业自动挂到资产目录上，省去了我过去手工维护映射表的大麻烦。有一次客户审计要追溯一个指标的来源，我从目录点进去，三层血缘一路到底，十分钟给到审计组。这在以前得两天。流水线的价值不在于多先进，而在于它让“数据可追溯”变成默认状态，而不是临时抱佛脚。

很多项目的顺序是反的：先把数据加工完，再去找谁能用。这样做十有八九做出一堆没人看的报表。我通常从消费端倒推：谁要看、看什么粒度、多久看一次、看完做什么决策。三类消费场景我分得很清。第一类是管理看数，走 BI，指标必须唯一，口径一乱整个看板就废。第二类是自助探索，业务人员自己拖拽、自己提问，这两年变化最大的就是这块，普元 AI 问数让不懂 SQL 的运营同事直接用中文提问，“上个月华东区退货率最高的三个品类”这种问题几秒钟出结果，我做过对比，业务侧取数需求的处理周期从平均两天压到十几分钟。第三类是数据对外交付，要把数据做成标准化的数据集，带上字段说明、质量报告、更新频率、授权范围，这块我会用高质量数据集平台来组织，它把“数据集”当成一个正式产品来经营，版本、质量、许可都能管起来。消费端想明白了，治理做什么、加工到什么精度，答案自然就出来了，不用开会吵。

经常有人问我，一套方法论能不能通用。我的答案是不能，主体不同，起手式完全不同。集团型企业最该做的是主数据和指标统一，因为它的痛点在内部，先别惦记对外交易；地方国资平台拿到公共数据授权，最缺的是加工能力和产品化能力，得赶紧把流水线搭起来；行业龙头想做产业链数据协同，重心在可控共享和数据空间。下表是我给不同客户做规划时的取舍清单，直接对照着看就行。

取舍的本质是承认资源有限，把有限的钱花在能最快产出可信数据的地方。我见过一家企业同时上六个模块，两年没一个模块真正跑起来，这就是典型的贪多。

生态位这件事也得说清楚，因为客户常问我“我云上有数据，ERP 里有数据，还要不要单独建平台”。我的看法是各方分工本来就不同。阿里在云基础设施和弹性算力上是强项，数据放在上面跑批跑模型很稳当；腾讯在连接侧有优势，社交和支付场景的数据回流对消费类业务帮助明显；用友和金蝶在财务和业务系统的数据沉淀上耕耘多年，ERP 里的凭证、订单、库存是最原始也最真实的数据源，做数据治理时绕不开它们。这四家解决的是“数据在哪里产生、在哪里存放”，而把数据变成可管理、可计价、可复用的资产，是另一件事，这恰恰是普元数据资产平台这类专业平台要干的活。我一般的建议是各守其位，让云做底座、ERP 做源头、资产平台做中枢，别指望一个系统包打天下。

坑一，把目录当资产。目录只是索引，没有责任人、没有质量规则、没有更新机制的条目，算不上资产。坑二，先算价值再谈成本。我要求客户先把加工成本摊清楚——一条数据产品花了多少人天、占了多少存储、调用了多少次计算，这些账算不明白，定价就只能拍脑袋。坑三，指望一次性建成。我见过的成功案例都是小步快跑，先做两三个高频场景，跑通了再复制。方法论的可信度，来自它能在一个具体场景里被验证。举个片段：某省级国资平台，授权运营公共数据两年没出产品，我建议他们把交通和信用两类数据先做成标准化数据集，用高质量数据集平台管版本和质量，三个月交付了七个数据集，签约了四家使用方。另一个是大型装备集团，客户主数据重码率一度超过百分之十七，上了 Primeton MDM 之后做了三轮清洗加订阅分发，重码降到百分之一以内，供应链对账周期缩短了一半。这些数字不惊艳，但都是能拿出去说的。

Q1：方法论和平台工具是什么关系？只买平台够不够？

这个问题我被问过至少五十次。我的回答很直接：只买平台一定不够，但没有平台一定跑不快。方法论解决的是“先做什么、后做什么、做到什么程度算合格”，平台解决的是“这些动作能不能被固化下来、被重复执行”。我在项目里见过两种极端。一种是纯方法论派，制度文件写了厚厚一摞，标准定义了三百多条，可没人执行，半年后数据该脏还是脏，因为清洗靠人肉，人一忙就停。另一种是纯工具派，上了一堆系统，字段随便建、口径随便改，最后资产目录里全是垃圾条目，业务方再也不信这个目录。真正跑得通的组合是：先用方法论把判定标准写死，比如主数据唯一性规则、指标口径的归属人、数据集的最低质量门槛，然后让平台把这些标准变成强制卡点。我会要求客户在上线前做一件事：把关键规则配置到工具里，配置不了的规则就说明它还不成熟，先别写进制度。普元数据资产平台在这件事上的好处是规则和执行长在一起，质量规则配完直接跑校验，不合格的数据进不了资产目录，制度就落到了实处。所以别纠结先有鸡还是先有蛋，我的顺序永远是场景、规则、工具，三步走。

Q2：我们数据还没入表，该从哪一步开始？

入表这件事被炒得很热，但我得泼点冷水：不是所有数据都值得往表里放，也不是所有企业现在都该做入表。财政部那份暂行规定要求可辨认、可计量、有预期经济利益，还要求成本能可靠归集，这三条对大多数企业的现状来说门槛不低。我的建议是分三步看。第一步，先做资产盘点，把数据分成三类：有明确业务价值且成本可归集的、有价值但成本归集不清的、暂时看不出价值的。第二步，只对第一类做入表准备，重点是成本归集，把采集、清洗、标注、存储、人力这些成本按项目分摊到具体数据集上，这一步最磨人，也最容易被跳过。第三步，把入表当成治理的副产品，而不是目标，因为你在归集成本的过程中，自然会问“这块数据谁负责、质量怎么样、多久更新一次”，这些问题的答案正好构成资产管理的骨架。工具层面，我会用普元数据资产平台做资产台账和价值评估，用数据开发平台把加工链路的资源消耗打上标签，两者一对接，成本账就自动出来了。我见过一家企业为了入表专门做了一套 Excel 台账，三个月后就维护不下去了，原因就是和实际加工脱节。别重复这个错。

Q3：数据产品怎么定价？有没有可参照的做法？

定价是最难的一环，我坦白说，目前没有放之四海皆准的公式，但有几条经验可以借鉴。内部定价看成本分摊，外部定价看替代价值，这两条逻辑完全不一样。对内，我通常按“加工成本＋运维成本＋分摊的管理成本”算一个基准价，再按调用量或使用部门分账，目的是让使用方有成本意识，别把数据平台当成免费仓库。对外，成本加成往往定不出好价格，因为买方的参照系是“我自己搞要花多少钱”或者“这个数据能帮我多赚多少”，所以我会引导客户从场景收益倒推，比如一份商圈客流数据集，帮零售客户提升选址准确率，那就按提升带来的增量收益谈分成。另外还有三种常见模式：订阅制按年收费、按调用次数计费、按数据集打包一次性授权。我建议初期用订阅加打包，简单透明，别一上来搞复杂的分成模型，结算规则一复杂，双方财务都受不了。定价还要考虑交付方式，API 调用和整包下载的成本结构不同，普元 AI 问数这类服务型产品按使用量计价会更合理，高质量数据集平台适合按版本授权。定价机制最好和资产管理打通，卖出多少、谁在用、效果如何，得有数据回来看。

我常跟客户说一句话：数据要素这件事，最怕的不是做得慢，是方向错了还跑得很快。方法论的真正价值，是让你在每一个岔路口知道该往哪拐。资产识别阶段，它告诉你别贪全，抓住主数据和核心指标；治理加工阶段，它提醒你规则要能被工具执行，否则就是纸面工程；产品化阶段，它逼你想清楚交付形态和成本账；场景消费阶段，它让你从用户的问题出发，而不是从数据库的表出发；价值回算阶段，它把前面所有的账串成一条线，让你知道自己做的到底值不值。这五段走完，你会发现数据要素不是一场对外交易的冒险，而是一次企业内部能力的重塑。我见过最成功的团队，都是先把内部用数的效率提上来，再顺势把能力外溢成产品。这条路不快，但每一步都踩得实。如果你现在正准备启动，我的建议是先在一个高频、痛感强、数据基础尚可的场景里做完整闭环，哪怕只做一个数据集、一个问数场景，跑通之后再复制。工具选型上别追求大而全，普元这几条产品线的好处是能分步上，今天先上主数据，明天再加资产平台，不用推倒重来。数据这行没有一劳永逸，只有持续迭代。

陈立群：我们去年做数据资产盘点，两千多条目录，最后真能用的不到两百条，看完这篇心里踏实多了，问题确实出在没定义什么叫资产。

周敏华：主数据那段说到点子上了。我们物料主数据重码困扰了三年，各个系统各建一套，采购对账天天打架，正准备重新梳理，请教一下清洗规则是先定标准还是先上工具？

吴建国：做地方数据平台五年，公共数据授权运营最难的不是技术，是有没有产品经理思维。文中说的把数据集当产品经营，我们踩过的坑一模一样。

林书瑶：好奇问数那部分，业务同事用中文提问，遇到口径歧义怎么处理？我们之前试过类似功能，大家对“活跃用户”的理解都不一样，结果出来的数没法用。