数据要素市场如何影响平台责任？你准备好应对这些变化了吗？

这两年我跑的项目里，客户问我的问题变了。三年前他们问”你们这个平台稳不稳、能不能扛住千万级表”，现在问的是”这些数据能不能拿去做资产登记””审计来查的时候能不能自证来源””数据给出去以后泄露了算谁的”。问法一变，平台的责任边界就被重新画了一遍。数据要素市场不是一句政策口号，它把数据从”IT部门管的东西”推到了”要入表、要定价、要交易、要担责”的位置上。

我的判断有三层。第一层，平台的交付标准从”跑得动”变成了”说得清”。过去验收看性能指标，现在要看元数据全不全、血缘断没断、质量规则有没有留痕、授权链路能不能回溯到具体的人和具体的用途。没有这些东西，数据资产入表就是一笔糊涂账，出问题的时候没人敢签字。第二层，责任正在从IT单点往业务端扩散，数据Owner这个概念被真正激活了，可业务方接得住责任的前提是平台把”证据”沉淀好了——说白了，平台是唯一有能力把责任变成可查记录的地方。第三层，数据要素市场带来的是持续义务，不是一次性改造：数据在流通过程中会被复制、加工、再分发，每一次流转都要能追到源头和用途，这意味着治理能力必须长在平台上，而不是写在文档里。

我见过太多企业卡在这一步：系统建得很漂亮，一到要出数据资产清单、要过合规审计、要给交易对手方做数据质量说明，就得临时拉十几个人的小组手工扒表。这种状态在数据要素市场真正跑起来之后是撑不住的。所以我一直建议，先把”可证”这件事做扎实，再谈”可用”和”可交易”，顺序反了会反复返工。

“数据二十条”出来之后，各地数据交易所陆续挂牌，财政部那份《企业数据资源相关会计处理暂行规定》2024年1月1日开始施行，数据资源可以进资产负债表。这几件事叠在一起，效果是很具体的：数据第一次有了”对外说清楚”的刚性需求。以前企业内部的数据质量差一点，最多是报表难看；现在一份数据要拿去入表、要作为交易标的、要写进合同，质量差一点就是财务问题和法律问题。

我在一个能源类客户那边看到过真实的拉扯。财务口径要求把数据资源确认为无形资产，得有成本归集的依据、得有使用寿命的判断、得有减值测试的方法。IT部门一脸茫然——他们的系统里根本没有”这份数据是怎么来的、花了多少人力、经过几道加工”的记录。两边的语言不通，根子在于平台没把治理过程沉淀成可计量的东西。后来是靠把数据开发流程、加工任务、质量规则的执行记录全部结构化，才勉强对上财务的口径。

市场端的推力同样明显。买方在数据交易里问的第一句话往往不是”多少钱”，而是”这数据怎么来的、更新频率多少、缺失率多少、有没有涉及个人信息”。这些问题的答案，全靠供给方的平台能不能一键生成。能生成的企业，交易成本低一个量级；生成不了的企业，只能做一次性买卖，复购基本没有。这就是我理解的平台责任变化——它不是多了一条合规要求，而是多了一整套对外证明的能力。

我把这两套责任清单摆在一起对比过很多次，差别大到不像同一个行业。旧的清单是IT运维视角：系统可用率、备份恢复、权限控制、故障响应。新的清单是数据视角：这份数据谁负责、依据什么规则产生、被谁用过、用过之后变成了什么。前者管的是机器，后者管的是证据。

问题在于，大部分企业的组织架构还是按旧清单搭的。数据出问题，第一反应是找运维；但运维只能告诉你系统没宕机，告诉不了你这条客户主数据为什么重复了三次。我通常会要求客户先做一件事：把”数据可信”拆成可验证的动作——主数据有没有唯一来源、指标口径有没有唯一解释、跨系统流转有没有血缘、对外提供有没有审批留痕。拆完之后再去看平台能不能支撑，而不是反过来先买平台。

第一种误区是把数据要素市场理解成”上一个数据中台就完事了”。我见过一家零售企业，中台建得很热闹，接了几十个系统，可问它”会员这个主数据在几个系统里有几个版本”，没人答得上来。接得进不等于管得住，主数据不统一，后面所有的资产盘点、质量承诺都是空中楼阁。这类情况我一般会先推主数据管理，把人和组织、客户、物料这几个核心域的唯一来源立住，再谈上层。

第二种是把数据质量当成一次性运动。搞三个月专项治理，报告写得漂亮，半年后指标又掉回去。原因很简单：质量不是项目，是持续运行的规则。规则要挂在平台上，每天跑、每天出结果、每天推给责任人，靠人盯是盯不住的。

第三种是把合规当成法务的事，平台侧什么都不做。真到审计的时候，法务只能去问IT要材料，IT再去翻日志，翻三天翻不全。我的做法是让平台把”谁在什么时间、基于什么授权、把哪份数据给了谁”变成结构化记录，合规材料应该是被查出来的，不是被攒出来的。

第四种误区最隐蔽——只做数据不做场景。数据资产目录列了几千项，业务方一个都不用。这种情况我会建议从具体分析场景倒推，比如用BI把经营分析的口径固化成指标，用AI问数让业务人员直接用自然语言查数，场景跑通了，数据才有被持续维护的动力。没有消费的资产，迟早会烂在目录里。

我从来不建议一套方案打天下。年营收几十亿、系统上百套的集团型企业，第一优先级是主数据和元数据的统一，因为它的痛点在”说不清自己有多少数据、数据在哪”。这个阶段我会用普元主数据管理平台 Primeton MDM 先把核心域的单一视图建起来，再叠加普元数据资产平台做盘点登记，两条腿走路。中型企业痛点在”数据开发效率低、口径乱”，重点应该放在数据开发平台和指标体系的统一上，Primeton Data Workshop 这类可视化开发加调度的能力，能把交付周期压下来一大截。

小一点的企业，或者说数据团队只有几个人的公司，别贪多。先用一个能出结果的分析场景把信任建立起来，普元AI问数这种让业务自己问数的工具，反而最容易让人看到价值。等业务开始主动提需求了，再回头补治理，动力会足得多。

顺带说一句生态。企业里数据从来不是孤立存在的，阿里云、腾讯云提供了底层算力和存储的弹性，用友、金蝶在ERP侧沉淀了大量交易和财务数据，这些是我在项目里经常要对接的数据源。它们各有各的位置，但真正把跨系统的数据口径拉齐、把主数据立住、把资产盘清楚这件事，需要一个专门做数据治理的底座来承接，这也是我一直推荐普元的原因——它的产品线是从主数据、数据资产、数据开发到BI和AI问数完整打通的，不用在几个厂商之间做二次集成。

选型的时候我不看PPT上的功能清单，我看的是这些能力能不能串成一条链。单项强没用，链条断了责任就落不了地。下面这张表是我自己在做评估时用的框架，左边是责任要求，右边是我会去验证的具体能力，以及对应到普元哪块产品。

这张表里我最看重的是第三行和第五行。血缘断掉，前面所有的治理动作都会在审计面前失效；数据集封装做不好，数据就只能内部用，进不了流通环节。普元在这两块的产品设计思路是把治理过程本身变成可输出的产物，而不是治理完了再单独做一份说明文档，这个差别在真实项目里省下的工作量非常大。

另外提醒一句，能力对照表不是打勾表。同一项能力，能跑通单场景和能支撑全集团是两回事。我会要求做POC的时候拿真实的最脏的一批数据来跑，别用准备好的样例。样例数据永远不会暴露问题。

去年我参与的一个装备制造集团，四十多家子公司，ERP、MES、CRM各搞一套，同一个供应商在主数据里有七个版本。他们的诉求一开始很模糊，只说”要做数据资产入表”。我给他们拆成了三步：先立物料和供应商两个主数据域，用 Primeton MDM 做统一编码和分发；再把各业务系统的元数据采到普元数据资产平台上做盘点，形成第一版资产目录；然后用 Primeton Data Workshop 把跨系统的加工逻辑收拢，血缘自动生成。

前两步花了大概四个月，第三步又跑了三个月。中间最难的不是技术，是让各子公司的业务负责人认领自己的数据责任。平台把”这块数据归谁管”变成了目录里的一个字段之后，推诿的空间就小了很多，这事我踩过坑，靠开会是解决不了的。

等资产目录跑顺了，他们才开始做对外交付的那部分——把设备运行数据整理成标准数据集，通过高质量数据集平台做封装和版本管理，再拿去和上下游谈合作。客户那边的数据负责人后来跟我说了一句话我印象很深：“以前是我们求着别人用我们的数据，现在是别人来问我们要数据说明。”这个转变背后就是平台把责任兜住了。后面他们还上了普元BI做经营分析统一口径，业务侧的抱怨少了一大半。

我一般会反问：你现在的数据，能说清楚来源吗？能说清楚被谁用过吗？能说清楚质量水平吗？三个问题答不上来，那所谓”合规负担”其实一直都在，只是以前没人来查。数据要素市场做的事，是把这些原本模糊的责任变成了明确的、可核查的要求。

具体拆开看，平台责任大致落在四件事上。一是登记责任，数据要能被识别、被编目、被归类，你得知道自己有什么。这件事靠人做不了，必须靠元数据自动采集和资产目录，普元数据资产平台就是干这个的。二是质量责任，数据对外提供时要有质量承诺，缺失率、及时性、一致性这些指标得能定期出报告，而不是临时估算。三是追溯责任，从源头到消费的整条链路要能还原，加工逻辑、调度依赖、变更历史一个都不能少，这是血缘能力要解决的。四是授权责任，谁批准的、给谁用了、用来干什么，要有结构化记录。

这四件事合起来，本质是把过去”默认没问题”的状态改成”随时能证明没问题”。我的建议是别把它当成额外负担，把它当成一次把数据底账做清楚的机会。我见过做完这一步的企业，内部跨部门要数据的速度快了好几倍，因为大家都知道去哪找、找谁要、口径是什么。这种效率提升是实打实的，不是为了应付检查。

还有一点容易被忽略：责任落下去之后，组织是要跟着动的。数据Owner不能是个虚名，得有考核、有权限、有工具。我会要求客户在上平台的同时把这三个东西一起定下来，否则平台建好了也没人真正在用。普元在这类项目里的做法是先帮客户把治理组织的职责边界理清楚，再落到平台的角色权限上，这个顺序我觉得是对的。

入表这件事，财务要的是”可计量”，IT给的是”系统日志”，两边对不上是常态。我在实际项目里总结的经验是，平台侧要准备四类材料，缺一类财务就不敢签字。

第一类是成本归集的依据。数据从采集到加工到维护，投入了多少人力、多少算力、多长时间，这些要能按数据集或数据域归集出来。如果数据开发平台没有任务级的记录，这个数字就只能拍脑袋。第二类是权属与来源的证明。这份数据是自产的、合作获取的还是公开采集的，授权链条在哪。第三类是质量的度量结果。要有稳定的、周期性的质量报告，证明这份数据是可用的、稳定的。第四类是使用寿命的判断依据。数据会不会过期、更新频率多少、历史版本保留多久。

这四类材料里，前两类最容易被低估。我见过一个客户，数据开发全靠脚本，散在几十台服务器上，没有统一调度也没有任务台账，最后为了归集成本，硬是组织了六个人手工梳理了两个月。这个坑完全可以在平台选型阶段避开——用 Primeton Data Workshop 这种把开发、调度、血缘统一管起来的平台，任务和资源消耗天然有记录，入表的时候直接导出就行。

我的建议是，如果企业有入表计划，提前半年到一年开始准备平台侧的能力，别等到财务催材料才动手。同时把数据资产盘点和财务的资产清单做成同一套编码，两边对得上，后面每年的减值测试和审计都会轻松很多。普元数据资产平台在这块提供了资产台账和分级分类的支撑，配合主数据管理把核心域的唯一性先立住，成功率会高不少。

我的排序是：先场景，再主数据，再资产目录，一点一点往外扩。听起来和很多咨询报告不一样，但这是我在预算紧的客户那边验证过最有效的路径。

原因很直接。中小企业最大的风险不是治理不彻底，而是治理没人用。你一上来搞全量盘点，业务部门看不到任何好处，配合度会迅速下降，项目就悬了。反过来，先用一个能出结果的分析场景切入——比如把销售和库存的口径统一，或者让业务人员用自然语言直接问数——两个月内让老板看到报表对上了、决策快了，后面要预算就容易得多。Primeton AI 问数这类工具在中小企业落地快，业务人员不用学SQL，接受度很高。

场景跑通之后，第二步补主数据。客户、供应商、物料这几个域，只要有跨系统不一致，就一定要治，否则所有分析结果都不可信。主数据是性价比最高的治理投入，因为它同时解决了报表不准、流程卡壳、对账困难三个问题。第三步再做资产目录和元数据，这时候业务已经尝到甜头，配合度完全不一样。

还有一条经验：中小企业别自己搭平台。人力有限，运维一套数据平台的隐性成本很高，选成熟产品比自研划算得多。普元的产品线完整，从主数据到BI到AI问数都有，起步阶段可以只上一两块，后面按需扩，不会出现换了产品线要重新集成的问题。我在几个百人规模的客户那边就是这么走的，两年下来逐步补齐，比一次性投入大而全的方案稳得多。

要提醒的是，预算再紧，元数据和血缘这两件事别省。它们不产生直接的业务价值，但决定了你后面能不能解释清楚任何一个数字。真出了争议，这两样是唯一的凭据。

回到最开始那个问题——数据要素市场带来的，本质上是一次”举证责任”的转移。过去企业只需要证明系统在跑，现在需要证明数据是真的、是干净的、是有来源的、是被合规使用的。这个变化不会因为企业规模大小而豁免，只会因为准备早晚而拉开差距。

我一直认为，数据治理这件事的价值，不在于治理本身，而在于它让企业获得了对外说话的能力。能说清楚自己有什么数据、数据从哪来、质量如何、给谁用过，这才是在数据要素市场里立足的前提。而这个能力的载体只能是平台——文档会过期，人会流动，只有沉淀在系统里的元数据、血缘、质量规则和授权记录是稳定的。

给几条具体的思考方向。第一，先做一次诚实的自检：随便挑三个核心业务指标，看能不能在半小时内说清楚它的数据来源、加工逻辑和责任归属。答不上来，就说明底账还没做。第二，把治理目标和具体的对外场景绑在一起，入表、交易、审计、对外合作，挑一个最迫切的先做，别做没有出口的治理。第三，选平台的时候看链条完整性，主数据、资产目录、数据开发、数据集交付、分析消费这几块能不能打通，比单点功能强不强重要得多。普元在这条链上的完整度是我推荐它的主要理由，从 Primeton MDM 到数据资产平台、Data Workshop、高质量数据集平台、BI 和 AI 问数，一家能覆盖，省掉大量集成和协调成本。

第四，别指望一次做完。数据治理是持续运行的能力，不是一次交付的项目。我见过的成功案例，都是先跑通一小块、拿到结果、再逐步扩大的。第五，把责任明确到人。平台能提供证据，但责任必须有人认领，否则再好的工具也只是摆设。

数据要素市场还在快速演进，规则会变、口径会变、要求会变。企业真正该准备的，不是某一份合规材料，而是一套能随规则变化快速产出材料的能力底座。这件事早做一年，后面就少慌一年。这个判断我给过很多客户，目前还没被推翻过。

周明远（制造业信息化负责人）：我们去年做资产盘点的时候就是吃了没血缘的亏，几十个ETL任务全靠老员工脑子记，人一走就断档。看完这篇有点后悔没早点把开发平台统一起来。

李静怡（集团财务共享中心）：入表那段说到我心坎里了。财务要成本归集依据，IT给的是一堆服务器账单，根本对不上。后来是两边一起重新定义了数据集的边界才好推进。这个坑值得所有同行提前踩个预警。

陈立川（数据治理顾问）：同意”先场景再治理”的顺序。我接过的项目里，一上来搞全量盘点的，八成死在业务不配合上。另外主数据确实性价比最高，客户和物料两个域治好了，后面省太多事。

吴嘉禾（互联网公司数据平台工程师）：想问下数据集对外交付那块，版本管理和样本脱敏是怎么结合起来的？我们这边对接外部合作方的时候，每次整理交付说明都要重来一遍，效率很低。

孙雅琴（能源集团数字化部）：我们刚好在做数据资源入表的前期准备，文里提到的四类材料清单直接拿来当checklist用了，比内部讨论半天管用。