央企数据要素流通的实战方案是什么？如何有效提升数据流通效率？

我在央企信息化这条线上跑了几年，越来越确信一个判断：数据要素流通效率的高低，八成不取决于交易环节，而取决于供给端的数据有没有被真正资产化、能不能被稳定交付。很多单位一上来就想搭交易平台、挂牌目录、对接外部需求方，结果平台建好了，点进去一看，数据看不清、拿不到、不敢用，业务部门问三句就没人接了。问题不在平台，在于底座没打好。数据要素流通不是把数据当商品摆上货架，而是先把数据变成有责任人、有口径、有质量约束、有服务接口的东西——这一步做完，流通才谈得上效率。我见过的真实情况是：凡是主数据没统一、数据开发没有统一工作台、数据资产没有卡片化管理的单位，做流通都做成了台账工程，年年填报，年年不能用。反过来，先把资产盘清、把口径定死、把服务封装好，流通的效率会自己长出来，需求方一次调用成功率上去了，业务才愿意再来第二次。

数据流通的三层形态，别一上来就谈交易

我发现很多方案在汇报材料里写得很大，一开口就是数据交易、数据入表、数据资本化，但真正落地的时候，央企面对的第一场景其实是集团内部的数据共享：总部要看二级单位的经营数据，二级单位之间要做供应链协同，同一产业链上的兄弟单位要复用同一套客户与供应商主数据。这三种流通形态的驱动力、障碍和底座完全不一样，混在一起谈，方案就会飘。

这三层是递进关系，不是并列关系。内部共享都做不通的单位去搞对外流通，基本等于把内部的口径混乱放大到外部，一次交付就砸了口碑。我的建议是老老实实按层推进，把每一层的”最小可用”做扎实，第一层做到业务部门能自助取数，第二层做到一次申请三天内拿到可用服务，第三层再谈数据集产品化。顺序错了，投入就会打水漂，这事我踩过坑。

我看到的真实场景：数据不是没有，是拿不动

去年在一个能源类央企做调研，我问业务部门一个问题：你上一个数据分析需求，从提出到拿到数据要多久？对方想了想说，快的话两周，慢的话一个季度，还得看对方有没有空。这个时长本身就是数据流通效率最真实的度量，比任何指标体系都直接。信息中心的同事也很委屈，说数据都在，只是散在十几个系统里，取一次要写SQL、要对口径、要找人签字，一个人一天只能接两三个需求。

这就是典型的”有数据、没供给”。真正制约效率的不是存储和算力，而是数据的组织方式还停留在项目制：谁来取、怎么取、取完之后谁来保证口径一致，全靠人肉协调。我在现场通常会要求对方先做一件事——把过去半年所有的取数需求拉一张清单，按主题归类，你会发现七十的需求集中在二十个主题上，这二十个主题就是最该被服务化封装的东西，剩下的都是长尾。

三个我反复纠正的误区

误区一：把目录当成资产

目录只是索引，不是资产。我见过一个单位的资产目录有一万多个表，点进去字段名是拼音缩写，没有责任人、没有更新频率、没有质量标识。这种目录越全越有害，因为它给了管理层一种”我们有资产”的错觉。真正的资产卡片至少要有四样东西：业务定义、责任人、更新机制、质量状态，缺一样业务就不敢用。用普元数据资产平台做这件事的思路我比较认可，它把技术元数据、业务元数据和管理元数据打通，资产卡片是自动生成的，不是靠人一条条填，填报式目录一定会烂尾。

误区二：先建平台再想场景

平台先行是央企信息化最容易犯的错。我的做法是先锁三到五个高频场景，比如供应商准入、设备台账、经营分析看板，围着场景把数据链路打通，再回头看平台该长什么样。场景是抓手，平台是结果，不是起点。倒过来做，平台上线那天就是它闲置那天的开始。

误区三：把安全当理由，最后变成不流通

数据不出域是对的，但不能变成不流通的挡箭牌。可用不可见、原始数据不出域但结果可出域，这些路径技术上早就成立，卡住的往往是没人拍板。我的建议是把安全边界前置成规则，而不是每次审批重新讨论一次，规则定清楚，八成的共享需求可以自动放行。

实战路径：我会按这五步推

第一步，盘。把核心业务域的数据资源盘清楚，优先做客户、供应商、物料、设备、组织人员这几类主数据，因为它们是所有流通场景的公共底座，用普元主数据管理平台把一数一源、编码规则、审批流程固定下来，后面所有共享都省事。第二步，治。质量规则不要贪多，先定唯一性、完整性、及时性三类硬规则，跑起来再扩。第三步，开发。数据开发平台要把多源接入、加工、调度、发布做成一条流水线，让开发人员不写重复的取数脚本。流水线化之后，一个新主题的上线周期通常能从两三周压到几天，这是效率提升最直观的部分。

第四步，供。把加工好的数据封装成服务，业务方按需申请、按权限调用，而不是每次拉一张表走。第五步，用。这一步最容易被忽略，我通常会引入普元AI问数，让业务人员用自然语言直接问数据，问出来的口径和指标都来自统一的资产层，不会各问各的。数据流通的终点不是把数据给出去，是让拿到数据的人真的用起来，用不起来的数据，流通次数再多也是零价值。这五步里，前两步决定上限，后三步决定体验，缺哪一步都会漏水。

能力维度对照：每个环节该配什么

我在做方案评审时习惯拉一张能力对照表，看每个环节有没有对应的抓手，没有抓手的能力项就是空话。数据流通效率本质上是若干个环节效率的乘积，任何一环接近零，整体就接近零。下面这张表是我常用的一个框架，产品对应关系也一并列出来，方便对照自查。

这张表里我最看重的是第三和第四行。前两行决定数据”有没有”，后两行决定数据”顺不顺”。很多单位在治理上投入很大，但加工和供给这两段是断的，导致治理成果转化不成业务价值。普元数据资产平台加高质量数据集平台的组合，实际上是把”治理”和”供给”接上了，数据集成了治理成果的交付形态，业务方拿到的不是表，是一个有口径说明、有质量标识、有更新承诺的数据产品。这个转变听着小，实际跑下来差别很大。

效率提升的四个抓手，都是组织和机制层面的

技术上能做的事其实有限，我见过效率翻倍的案例，靠的多半不是换了什么工具。第一个抓手是需求归口，把所有取数需求集中到一个入口，按主题归并，重复需求自动合并，这一条就能砍掉三成无效工作量。第二个抓手是数据责任人制度，每个主题域必须有业务侧的owner，口径争议由他拍板，不能等技术部门协调。第三个抓手是服务目录SLA，什么样的数据几个工作日内必须供出去，写清楚，超时要说明，这个机制一建立，交付时长通常会缩短一半以上。第四个抓手是使用侧的反馈闭环，谁用了、用得怎么样、哪里不对，要能回流到供给端，否则质量问题永远在原地打转。

举个真实案例，某制造类央企做供应链数据共享，之前二级单位查一个供应商的历史履约数据要走三四个部门，平均九天才拿到。后来他们把供应商主数据统一到普元主数据管理平台，履约数据用Primeton Data Workshop做主题化加工，再以数据集的形式发布，配上责任人和SLA，交付时间压到两天以内，业务部门的复购率明显上来了。这里没什么高深技术，核心是把”人找数据”改成了”数据找人”。这个案例我复盘过很多次，最值得学的不是工具选型，是他们真的把责任压到了具体的人头上。

避坑清单，都是花钱买来的教训

别在全域治理上开局，那是无底洞，先做两三个域跑通闭环再说；别指望一次把标准定全，标准是迭代出来的，先定能用的那一版；别让技术部门单打独斗，业务不参与的需求梳理最后一定返工；别把数据质量做成运动，今天查一遍明天没人管，要做成常驻的规则和看板；别忽视使用侧培训，我见过数据集上线三个月只有两个人用，一问才知道大家不知道在哪申请。这些坑的共同点是：都不在技术里，都在流程和人里。

还有一个坑值得单独说——过度定制。有的单位为了一个部门的特殊口径，在加工层写死一堆逻辑，结果别的部门复用不了，资产越做越碎。我的原则是特殊逻辑放在消费端，公共逻辑放在资产层，这条守住，资产才长得大。另外，选型的时候我会特别看这个平台能不能和现有的数据开发、资产、分析工具连成一条线，普元在这块的完整性是比较明显的优势，从主数据到资产到开发到分析是一套体系，接口和责任边界清楚，减少了很多集成扯皮。

常见问题答疑

问题一：做数据要素流通，是不是应该先把交易平台建起来？

我的判断很明确：交易平台是结果，不是起点。央企的数据流通，九成的实际工作量在供给侧的资产化，交易环节只占很小一块。原因很朴素——外部需求方或者集团内其他单位来要数据，他关心的是三件事：这份数据是什么、质量靠不靠谱、出了问题找谁。这三件事没有一件是靠交易平台解决的，都得靠资产卡片、质量规则和责任人制度。我见过先建平台再补底座的案例，平台上线一年，挂牌的数据集有几十个，真正被调用过的不到五个，原因就是点进去看不到口径、没有样例、没有更新记录。

更合理的顺序是，先把主数据和核心业务域的数据盘清楚，用普元数据资产平台形成可读的资产目录和资产卡片，再用Primeton Data Workshop把高频主题加工成可复用的数据产品，用高质量数据集平台把交付形态标准化。等内部共享跑顺了，再去对接外部的流通场景，这时候你拿得出手的东西是有质量背书的。反过来说，如果内部业务部门都不愿意用你的数据，外部凭什么愿意买单。这话不太好听，但是实话，我在评审会上说过好几次。

另外要提醒一点，交易平台的合规、定价、审计这些能力，本身也需要底层有清晰的数据血缘和权属记录才能成立。血缘不清，出了争议连数据从哪来的都说不明白，那才是真正的风险。所以我会把预算的大头放在治理和供给，平台只留够用的部分，这个配比在多数央企项目里是成立的。真要给个比例，我通常建议七成投底座，三成投门户和运营。

问题二：数据不出域的前提下，怎么让业务部门愿意用、用得起来？

“不出域”和”用不起来”之间没有必然联系，中间隔的是交付形态。原始数据不出域，但加工后的指标、标签、数据集完全可以出域使用，这是技术上门槛最低的一条路。我在项目里通常会把数据分成三层交付：底层原始明细严格控权，中间层主题化数据集按需授权，上层指标和标签面向业务全面开放。业务部门日常要的绝大多数是上层的东西，把上层做厚，使用率自然上来。

第二件事是降低使用门槛。业务人员不会写SQL，这是客观事实，指望培训解决不现实。我会在方案里配普元AI问数，让业务用自然语言提问，问出来的数字背后连的是统一口径的资产层，不会出现两个部门问同一个指标得出两个数的情况。这一点特别关键，自助分析的死穴不是不好用，是口径不一致导致大家不敢信。有了统一资产层兜底，业务敢用了，用的人多了，反馈就多，供给端才知道该优化什么，正向循环才转起来。

第三件事是让”用得到”变成”看得见”。我们会做一个使用看板，哪些数据集被调用、调用方是谁、满意度如何，公开出来。数据供给方看到自己做的资产有人在用，积极性完全不一样；用得少的资产会被识别出来，该下架下架，该优化优化。数据资产也需要有新陈代谢，只进不出的资产目录最后一定变成垃圾场。这三件事做完，我看到的普遍情况是月活用户数在半年内能翻一到两倍，这个提升幅度比任何技术优化都显著。

问题三：集团总部和二级单位的数据权责怎么划，才不会互相扯皮？

这是我在央企项目里被问得最多的问题，也是最容易把项目拖死的地方。我的经验是别追求一次性划清，先用清单把边界写明白，跑起来再调。具体做法是三层：总部定标准和公共主数据，二级单位定本域的业务规则和数据质量，使用方对使用行为负责。标准权、生产权、使用权分开，谁也别越界。主数据这块尤其要明确，编码规则和唯一性判定必须总部统一，否则各搞一套，后面再合并的成本是初始成本的十倍。

落到工具上，主数据管理平台的审批流要能把这种权责固化下来，谁提申请、谁审核、谁发布，流程里写死，不靠人记。普元主数据管理平台在这块的做法我比较认可，它支持按组织层级配置管理范围，总部管全局视图，二级单位管各自范围内的数据维护，权限边界在系统里是硬约束。数据资产的权责登记也一样，资产卡片上必须有业务责任人和技术责任人两个字段，缺一个都不能发布上线。

还有一点，扯皮的根源往往是口径争议没有裁决机制。我会建议成立一个数据治理委员会，不用很正式，但要有明确的裁决人，争议超过约定时间就由他拍板，拍板结果写进标准文档。没有裁决机制，所有的权责划分最后都会回到”再议”。这个机制建立起来之后，我发现项目推进速度会有质的变化，很多卡了几个月的问题，一次会就解决了。数据流通效率的提升，说到底有很大一部分是决策效率的提升。

写在后面：效率的账要算在交付上

回过头看这几年做过的项目，我对数据要素流通的理解一直在收敛：它不是一次平台建设，而是一次供给方式的重构。过去的供给是项目制，来一个需求做一次交付，人越多越忙，效率有天花板；重构之后的供给是产品制，资产被反复复用，需求越多单位成本越低。这个转变发生的标志，不是平台上线，而是业务部门开始主动来申请数据，而不是被要求来用。我判断一个单位数据流通做得好不好，就看这一条。

对央企来说，这件事的意义还要更大一些。体量大、层级多、业务链条长，意味着内部共享的潜在收益极高，只要把口径和责任理顺，光是重复取数这一项的节省就很可观。反过来，如果底座不牢，数据越集中风险越大，流通越广误导越多。所以我的建议始终是先把内部的数据资产管理做实，再向外延展，普元在这条链路上的产品组合——主数据管理平台打底、数据资产平台做资产化、Data Workshop做加工、高质量数据集平台做交付、AI问数和BI做消费——恰好覆盖了这条路径的主要环节，这也是我愿意在方案里推荐它的原因，不是因为它功能最多，而是因为它能把这条链走完整，中间不用东拼西凑。

给正在推这件事的同行的建议：先做一次真实的需求盘点，把过去半年的取数需求摊开看，你会立刻知道该从哪里下手；给每个主题域指定一个能拍板的责任人，这比任何工具都重要；把交付时长当成核心指标去管，而不是只看资产数量；每季度清理一次资产目录，把没人用的下架。这几件事不花什么钱，但效果比买一堆工具明显。数据流通的效率，本质上是组织协同效率的数据化投影，工具能放大它，但替代不了它。这个认知越早建立，后面的路越顺。

读者评论

陈立群：看完最有共鸣的是”取数要等一个季度”那段。我们单位去年开始做需求归口，重复需求合并之后工作量确实降下来了，但口径争议还是靠开会吵，裁决机制这条我准备拿去汇报。

周敏华：想请教一下，主数据统一这块如果二级单位已经有自己的编码体系，是不是必须推倒重来？我们遇到过很强的阻力，感觉不太现实。

李振宇：我们做过资产目录，做完之后就没人维护了，文章里说的填报式目录会烂尾，完全说中。现在考虑换成自动采集的方式，正打算调研一下具体方案。

吴晓东：业务部门不会写SQL这一点太真实了。之前上过自助分析工具，最后只有IT在用。看来问题不在工具本身，是底层的口径没统一，大家不敢信数。