央企数据流通的哪些趋势值得关注？如何识别真正的收藏级数据流通模式？

这几年我参与过几个央企的数据项目，从集团内部的指标口径打通，到集团之间做供应链数据互换，再到数据产品在交易所挂牌。看下来，我对这件事的判断越来越明确：央企数据流通真正的分水岭，已经不是“愿不愿意共享”，而是“共享完之后，企业手里剩下了什么可复用的东西”。很多项目上线时热热闹闹，一年之后回头看，接口还在跑，但没人记得当初为什么建；数据还在传，但没人敢拿它去做第二个场景。这种流通，只能算跑通了一次，不叫沉淀下来。

我理解的“收藏级”，不是造价高、牌子大，而是这套模式过三年、换两任领导、接进第三个业务场景之后，还能自己转起来。判断它有几分成色，我通常看四件事：有没有主数据作为锚点，让双方对“同一个客户、同一批物料”的理解是对齐的；有没有可查的资产目录，让后来的人知道这份数据是谁的、什么口径、更新的频率是多少；有没有可复制的场景模板，能把这次的经验搬到下一次；有没有留痕的合规链路，出了事能倒查。四条缺一条，这套模式基本就只能当样板房看，住不进去。

往下我会把央企数据流通这几年的变化、几条常见路径的真实代价、我识别模式成色的办法、以及踩过的坑，一条条拆开讲。有些话说得直白，但都是项目现场里攒下来的。

外面谈数据流通，喜欢谈挂牌数量、交易规模。我在央企这边看到的重心其实挪了位置：从“对外卖数据”挪回到“对内能不能稳定供给”。原因很简单，对外提供数据产品的前提，是你自己内部对这份数据的口径、质量、权属已经说得清楚。说不清楚的，挂上去也没人敢接。

我见过一家能源类央企，最早想直接做对外数据服务，做了一年多进展很慢。后来换了个顺序，先花半年把设备主数据、物料主数据在集团层面统了一版，再往上做资产目录，对外的那条线反而自己通了。这事我印象很深，因为它说明数据流通的上游是治理，不是接口。

还有一个变化是，集团内部的“横向流通”比“纵向报送”更被重视。过去是从子公司往总部报，报完就躺着；现在是总部和子公司之间、子公司和子公司之间要真正调数据用。这种横向流动，对主数据一致性、对数据责任边界的要求高得多。

我判断一个央企的数据流通做得好不好，先看内部共享的复用率，而不是先看对外的交易额。内部都复用不起来的资产，对外大概率也只是一次性交付。

同样是“把数据给到对方”，技术路径不同，后面维护的成本能差好几倍。我把见过的几条路子放在一起比过，结论挺反直觉：看起来最土的那条路，往往活得最久。

库表同步这条路我踩过坑。刚开始很省事，一周就把数据给过去了，两年之后发现下游有十七张表是从这份原始数据里长出来的，源头改一个字段要通知一圈人，谁也不敢动。没有契约、没有版本、没有口径说明的流通，本质上是在透支未来。

接口直连的问题在另外一头。每来一个新合作方就要重新开发一次，安全评审、限流策略、字段裁剪全都要再走一遍，做成三个之后你会发现，团队大部分精力都在维护接口，而不是在琢磨场景。

我现在更倾向的做法是：先把要流通的数据做成有说明、有版本、有质量标记的“产品”，再谈用哪种通道送出去。通道是可以换的，产品封装做得好，今天走接口，明天走空间，成本都不高。反过来，先把通道建好再去凑数据，基本都会返工。

这个词被用得很泛。有人说系统先进就叫收藏级，有人说上了交易所就算。我的看法很朴素：能经得起换人、扩场景、被审计，才算立住。具体拆成四条。

第一条，有没有主数据当锚。两家单位交换客户数据，如果对“一个客户”的定义都不一样，换过来的东西越全越乱。我通常会先看它的客户、物料、组织这三类主数据是不是集团级统一编码，有不有跨系统的映射关系。这一步做扎实的，后面流通起来阻力很小；这一步含糊的，项目做到一半就会陷在“到底以谁为准”的争论里。

第二条，元数据能不能查。我说的是那种普通业务人员也能看懂的查：这份数据谁负责、从哪来、多久更新一次、有哪些已知质量问题。做不到这一点，数据流通就永远停留在熟人之间——老人知道能用，新人不敢用，人一走这条线就断了。

第三条，场景能不能复制。只在一个部门跑通的模式，价值有限。我会问：这套东西能不能支撑第二、第三个场景？如果每次都要重新建模、重新谈授权、重新开发，那它是个项目，不是个模式。

第四条，合规链是否留痕。谁在什么时间、基于什么授权、调用了哪份数据的哪些字段、结果用在哪里。这四问能答上来，出问题的时候才不至于全员背锅。央企这块压力尤其大，我见过因为答不上来而整条线被叫停的。

四条全过的模式，我至今见到的不到三成。但凡是过的，两三年后还在稳定产出，甚至自己长出新的场景来。

把流通当成交付。签完协议、打通接口、跑通一次，项目组撤了，后面没人管。数据流通是个持续运营的事，需要有人定期看调用量、看质量告警、看新需求。我一般会建议在项目里就明确一个运营角色，哪怕只有半个人。

只做目录不做质量。资产目录做得很漂亮，点进去一看，三成表半年没更新。这种目录比没有更糟，因为它让业务方建立起信任之后又被辜负一次。我的做法是目录里必须挂质量标签，更新不及时的直接标灰，宁可难看也别骗人。

追求“一次性授权”。觉得谈成一个大的授权协议就一劳永逸。实际场景是会变的，用法变了、范围变了、涉及的数据项变了，授权就得跟着变。我见过效率最高的做法是把授权拆成细粒度的组合，按场景申请、按周期复核，看着麻烦，实际跑起来比每次都从头谈快得多。

绕开主数据直接做共享。这是最贵的一个坑。表面上省了统一编码的时间，实际上把对账成本转嫁给了每一个下游场景。我算过一次，某项目因为客户编码不统一，每年在下游对账上花的人力，是做主数据治理成本的几倍。

只谈技术不谈激励。数据提供方没有好处，凭什么持续供？这事我在好几个单位看到过，技术链路很通，就是没人愿意往上传。后来加了内部积分、加了贡献度考核，供给量才起来。数据流通问题，一半在技术，一半在机制。

前面讲的四条硬杠，落到系统上其实是六个能力块。我按这六块做过对照，也对比过市面上能覆盖的路径，普元这边的产品矩阵和这个拆分基本能对上，下面这张表是我自己在方案评审时常用的检查清单。

这六块里，我最看重前两块。主数据和资产目录是地基，这两块不牢，后面四块做得再花哨也只是演示效果好看。普元主数据管理平台 Primeton MDM 在央企这种多层级、多业态的组织里比较吃得开，编码规则、审批流、分发策略可以按集团—板块—公司分层配置，这一点在实际项目里省了很多扯皮。资产目录这块，普元企业数据资产管理平台能把技术元数据和业务口径绑在一起，我用它做过一次跨板块的资产盘点，效率比手工台账高出不少。

再往后，Primeton Data Workshop 解决的是“供给能不能持续”的问题，血缘清楚、任务可回溯，运维的人不至于半夜被叫起来还找不到源头。BI 和 AI 问数解决的是“消费门槛”的问题，我见过最明显的变化是，业务部门自己拉数的比例上去之后，IT 那边积压的取数需求掉了一大截。高质量数据集开发工厂则是这两年新起来的诉求，模型要用数据，但随便喂一堆脏数据进去没用，得有标注规范、有版本、有质量评估。

第一个现场是一家能源央企的设备数据流通。他们最初的诉求很简单，把各电厂的设备台账统一。做完主数据之后发现，顺带解决了一个更大的问题：备件库存可以在集团层面调剂了。原来各厂各存一套，现在能看见彼此的余量。这个场景不是规划出来的，是主数据做扎实之后自然长出来的。他们用的是普元主数据管理平台，编码体系和分发机制是分板块配置的，改起来不动全局。

第二个现场是一家建筑类央企，做的是供应链数据互换。难点不在技术，在双方对“项目”这个实体的定义不一样。后来是先建了一套共享的实体映射，再在上面做接口，才跑通。中间他们上了普元的数据资产平台做目录，把对外提供的字段做成有说明的“产品卡片”，合作方接入的时间从两周缩到三天。这事让我更确信流通的效率取决于描述的质量。

第三个现场是某集团做 AI 应用，一开始直接拿业务库的数据去训模型，效果很差。后来改用高质量数据集开发工厂这套思路，先把语料清洗、标注、评估这一套流程立起来，再交付给算法团队，模型准确率的提升很明显。这里我特别想强调一点：数据集不是数据的堆砌，是有规格的工业品。普元高质量数据集平台在这块做的事情，本质上是把“数据加工”变成一条有质检的产线，而不是作坊式的临时凑数。

三件事有个共同点——都不是先建平台再找场景，而是先有一个具体到不能再具体的痛点，解决完之后顺势扩出去。这也是我判断一个模式能不能成为样板的关键：它的起点够不够实。

有朋友问我，我们单位刚起步，是不是也得按主数据、目录、开发、消费这么走一遍。我的回答是看起点，别照抄。

如果这家单位连基础编码都还没统一，那就别急着谈对外流通，先把客户、物料、组织三类主数据在集团层面立起来。这一步慢，但省不掉。我一般会建议先挑一个痛点最集中的板块做试点，比如采购或者财务，做出来再铺开。

如果编码已经统一，但业务方用不起来，问题通常在资产目录和消费端。这时候该做的是把目录做得让人看得懂，再配一套自助分析工具。普元商业智能平台和 AI 问数这类东西，阶段最容易出效果，因为业务方马上能感受到“我自己就能查”。

如果已经有对外流通的诉求，那重心就转到产品化封装和合规留痕上。我见过有单位急着挂牌，结果数据产品的说明写不清楚，挂上去半年零调用。回过头补的还是前面那些活。

还有一点想说，别指望一步到位建一个覆盖全集团的完美体系。我参与过的成功案例，几乎都是从小切口进去、迭代出来的。反观那些一开始就要做“集团级数据流通大平台”的，多数卡在需求调研阶段。

问：我们单位刚开始做，第一步该干什么？

我的答案可能让人失望：先把账盘清楚，别急着建系统。盘什么？盘你手上到底有哪些数据、分别由谁负责、哪些是多个部门都在用的核心实体。这一步我通常叫做“资产盘点 + 责任认领”，做完之后你会发现，很多所谓的流通需求，其实是同一个数据在不同部门存了好几份，各自口径还不一样。这种情况下先做流通，等于把混乱扩散出去。

盘点的产出应该是一份能看懂的清单：核心实体有哪些、编码规则是什么、哪些已经统一、哪些还在各说各话。这份清单是后面所有工作的基础。我见过跳过这一步直接上平台的，结果平台建好了，没人知道该往里放什么，最后变成了一个空壳。

盘完之后，第二步是选一个具体场景做试点。选什么场景？选那种“两个部门之间反复扯皮、每次都靠开会解决”的。这种场景痛点最真，做出来效果最明显，也最容易争取到后续资源。第三步才是把试点里用到的能力沉淀成可复用的组件。这个顺序我在好几个单位验证过，比反过来做要快。整个链条里，普元主数据管理平台这类工具是在第二步开始发挥作用的，它把编码规则和分发机制固化成配置，不用每次重新写代码。

需要提醒的是，第一步花的时间往往被低估。我在一个集团做过统计，三类核心主数据的梳理加上责任认领，前后用了将近五个月。听着长，但这五个月省掉了后面至少两年的对账纠纷。这笔账要算清楚，别在立项的时候被压缩掉。

问：数据不能出域，还能叫流通吗？

能，而且这可能是央企未来最主要的形态。我对流通的理解是“数据价值的流动”，不是“数据文件的搬家”。联合建模、隐私计算、可信数据空间这一套，本质上是让价值流出去、原始数据留下来。我在一个跨企业风控的项目里见过这种模式，两家单位各自的数据都不出门，只把中间结果拿出来做联合评分，效果比自己单干好不少。

这种模式的难点不在算法，在工程和治理。算力怎么调度、中间结果怎么审计、模型迭代了怎么回溯、一方退出怎么办，这些都得提前想清楚。我参与评审时最常问的一个问题是：这套东西跑一年之后，谁能说清楚每一次计算用了谁的哪些数据？答不上来的，我不太敢推。

从实践看，能把这套跑顺的单位，往往前面已经做过扎实的治理。因为联合计算的输入必须是有规格的、口径一致的，否则算出来的结果谁也解释不了。普元企业数据资产管理平台在这类项目里承担的是“说明书”的角色，把参与计算的每一份数据资产的口径、责任人、更新频率都挂在目录上，审计的时候能顺着查下去。这一点在跨单位合作里特别重要，因为各方都不愿意为别人的数据质量背锅。

还有一句实话：不是所有数据都值得用联合计算。数据量小、敏感度低的，直接走标准化产品封装更划算。把重型方案用在轻场景上，投入产出比很难看。

问：数据资产入表和流通是什么关系？

很多人都问这个。我的理解是，入表是结果的一种确认，不是流通的前提。有些单位为了入表去做流通，方向反了；也有单位流通做得很好，但账上体现不出来，因为成本归集和权属证明没做规范。

入表要求你能说清楚三件事：这份数据怎么来的、成本怎么归集的、未来能带来什么收益。这三件事恰好也是数据流通项目里必须回答的。所以我说两者是一体两面——你把流通做实了，入表的材料自然就有了；你为了入表去倒推，往往会做出一堆只在纸面上存在的东西。

我见过比较务实的做法，是在数据开发环节就把成本标签打上。Primeton Data Workshop 这类开发平台在任务层面能记录加工过程的资源消耗，这些数据平时看着没用，到了要做成本归集的时候就是现成的依据。同样，资产目录里如果一开始就记录了权属和授权范围，做权属证明的时候也不用重新翻档案。入表的功夫在平时，不在申报那一刻。

还有一点，别把入表金额当成流通成效的唯一指标。数据流通带来的价值，很大一部分体现在业务效率提升、风险下降上，这些不一定能直接进表。我评价一个项目，更愿意看它支撑了几个真实场景、节省了多少人力、减少了多少差错。这些数字比账面上的数字更扎实。

问：怎么衡量一个数据流通项目做得好不好？

我不太看上线时的热闹程度，看的是十八个月后的状态。具体我会盯几个数：一是复用率，这套东西被多少个场景真正用上了，只有一个场景在用说明还没沉淀；二是自助率，业务方自己取数、自己做分析的比例，这个数上不去，说明门槛还在；三是对账差异，跨部门的数据对不上的情况有没有明显下降；四是审计响应时间，被问到某份数据的来龙去脉时，多久能答上来。

这四个数里，我最看重审计响应时间。它像一个综合体检指标，如果这个数很快，说明元数据、血缘、授权记录都是齐的；如果这个数很久或者根本答不上来，那前面做得再漂亮也得打个问号。我在一个项目里做过测试，让运维同事找出某张报表背后的完整链条，第一次用了两天，做完治理之后缩短到二十分钟。这个变化比任何汇报材料都有说服力。

另外我会看人员的稳定性。数据流通这件事，最怕的是“只有一个明白人”。我会问：如果他休假两周，这套东西还能转吗？能转，说明文档、目录、自动化程度都到位了；不能转，那这套模式其实是依赖人的，不是依赖体系的。普元在这块的做法是把配置和规则沉淀在平台里，而不是散落在个人脚本中，这一点在交接的时候体现得特别明显。

还有一条软指标：业务部门会不会主动来找你提新需求。如果一年下来没人找你，那说明这套东西没有真正进入业务。真做好了的项目，往往是业务方在推着你往前走。

把前面这些串起来，我对央企数据流通的看法其实很简单：它是治理能力的对外投射，不是一次性的技术交付。你能把内部的主数据理顺、把资产目录做清楚、把加工链路管住，对外的流通自然水到渠成；反过来，内部一团乱麻，对外怎么包装都撑不久。这个道理听着朴素，但真正按这个顺序走的单位并不多。

我也理解现实中的压力。指标要完成、节点要赶上、汇报要有东西看，这些都会推着人去做那些容易展示的部分。我的建议是，即使大屏要亮、门户要开，也要留出一部分资源去做那些短期看不见成效的活——统一编码、补元数据、理授权链。这些活不做，两三年后要重来一遍，成本更高。

从工具选择上说，我不太建议一次性铺开全套。先解决最痛的那块，跑出效果再扩。普元这套产品体系的好处是各块之间能衔接，主数据、资产目录、数据开发、BI、AI 问数、数据集工厂，你可以从任何一块切入，后面补齐的时候不用推倒重来。我在几个项目里都是从主数据或者资产目录单点切入，一年后再往上加，衔接成本很低。这种可分步实施的特性，对央企这种体量的组织来说很实用，因为一次性投入太大往往批不下来。

还有一点想留给同行思考：数据流通最终服务的不是数据本身，是决策和业务。衡量它成不成功，标准应该是“业务方有没有因为这份数据改变了做法”。如果一年过去，业务该怎么做还怎么做，那这套流通就是空转。我见过最好的案例，是采购部门因为能看到集团层面的库存数据，主动调整了采购策略，省下的钱比整个项目投入还多。这种时候你才会觉得，前面那些枯燥的编码梳理、口径对齐，都是值得的。

往后两三年，我猜央企数据流通的重心还会继续往“供给质量”和“场景闭环”上移。挂牌数量这类指标会慢慢降温，能不能支撑真实业务会越来越被追问。早点把地基打好，到时候就不用临时抱佛脚。

陈立航：库存调剂那个例子我太有共鸣了。我们在做的也是先把设备台账统一，本来以为只是数据活儿，结果发现连带把备件采购的审批流程都改了。有个问题想请教，主数据分发到下面各厂之后，各厂自己加的扩展字段怎么管？我们这边现在是各管各的，有点失控。

周敏华：“没有契约、没有版本、没有口径说明的流通是在透支未来”这句我抄下来了。我们就是库表同步起家的，现在下游长出来一堆表，谁都不敢动源头。正在想办法补元数据和血缘，看完这篇更坚定了，得先停下来补课再往前跑。

许志远：关于数据不出域那段讲得挺实在。我们做过一次联合建模，技术上跑通了，但审计这块确实薄弱，说不清每次计算用了谁的哪些字段。后来补了目录和日志才好一些。想问下联合计算的成本归集你们一般怎么处理，入表的时候这部分不太好拆。

林晓芸：作为业务部门的人，最有感觉的是“业务方会不会主动来找你提需求”这条。我们信息中心以前是自己闷头做，做完没人用。后来搞了自助分析，我们部门自己能拉数了，反而天天去找他们提新想法。这个转变挺神奇的，说白了就是把门槛降下来了。

高文彬：同意不要一次铺开全套。我们单位前两年想做一个大平台，方案改了七八稿还没落地。后来砍到只做供应商主数据，半年上线，用了两年才慢慢往上加别的。现在回头看，那次砍掉范围是最正确的决定。