政务数据治理有哪些成功的案例参考？这些案例为政务数据治理提供了哪些借鉴意义？

跑过十几个省市的政务数据项目，我被问得最多的一句话是：别处是怎么做成的，能不能照着来一份。我的判断是——政务数据治理没有可以直接照抄的样板，但有一批动作是高度共通的，谁把这几件事做到位，谁的数据就真能流转起来。这几件事分别是：数据资源目录编制到人能用的颗粒度、一数一源和权威源认定落到部门责任书上、质量规则前置到业务系统录入的那一刻、供需对接清单按季度滚动、以及把治理挂在一个具体办事场景上而不是挂在汇报材料上。凡是这五件事做实的，平台上线三个月就有人天天登录；做不到的，机房里的服务器转得再热闹，年底一盘点还是那几个基础库在空转。下面我把上海、浙江、广东、贵州这些地方公开可查的做法拆成能被复用的动作，也结合我在市级项目里踩过的坑，讲讲哪些能学、哪些学了会出事。文中对照说明的平台能力，我以普元的产品线举例，因为从主数据到数据资产再到数据开发，普元是少数能把一条链拉通的厂商，政务这种多部门、多系统、老系统还特别多的场景里，落地阻力相对小一些。读完你至少能判断出：自己所在的地方，问题到底出在目录、出在源头、还是出在没有人真的用。

我见过两种典型。一种是省里下文件、市里建平台、区县报数据，三级跑完一轮，目录上挂了八千多条资源，实际能调通的不到两成，部门之间传的还是 Excel。平台上线不等于数据通了，这是政务数据治理里最容易被忽略的错觉。另一种是某个地级市，目录只有一千二百条，但每条后面都挂着责任人、更新频率、质量规则和最近三个月的调用记录，窗口人员办”一件事”的时候真的在调。差别不在技术选型，在治理有没有挂在业务流上。

我通常判断一个地方做得怎么样，不看汇报材料，看三样东西：最近一个月的数据调用日志、质量问题的回派单、以及业务部门自己提的数据需求清单。这三样有内容，说明治理在转；三样都是空的，说明还在做样子。下面这张表是我这几年整理出来的几类公开做法，放在一起看，规律就出来了。

把上面这些做法拆开看，组织方式其实差得很远：有的是省级统建，有的是市级场景驱动，有的还在部门分散整合的阶段。但真正让数据跑起来的动作，翻来覆去就那么几个——目录、权威源、质量规则、调用留痕、场景牵引。这五件事少一件，链条就断在半路。我见过某地把钱几乎全砸在数据中台的硬件和大屏上，目录编了两年还是照抄部门系统清单，结果每次上级要一个跨部门指标，还得靠人打电话要数。也见过某区只做了一件事：把高频事项涉及的数据项全部画成一张供给关系图，哪个部门供、哪个部门用、多久更新一次，全部贴到责任处室的门上，两个月调用量翻了四倍。技术投入差了十倍，效果反过来。

下面这张对照表是我给几个地方做诊断时常用的框架，先判断自己处在哪一型，再决定钱往哪投。选错型比不投钱更糟，因为沉没成本会拖住后面两三年的调整空间。

几乎所有地方都在编目录，但大部分编成了台账：部门报什么就写什么，字段名照抄数据库，看一眼不知道能干什么。能用的目录得回答三个问题：这条数据解决什么业务问题、谁对它负责、多久更新一次。我在一个市级项目里做过一件事，把目录的字段从”数据项名称、来源系统、更新周期”改成”业务场景、权威部门、责任处室、更新触发条件、最近调用次数”，工作量没增加多少，但业务处室的人第一次主动来问目录怎么用。原因很简单，前一种写法是给检查看的，后一种写法是给干活的人看的。

目录还有一层价值容易被忽略：它是权威源认定的载体。一条数据被标成权威源以后，其他部门的同名数据就只能作为参考，不能反向覆盖。这个规则如果不写进目录、不写进管理办法，两边数据打架的时候就没有裁决依据，最后只能靠开会协调，协调一次管三个月，然后又乱。我在项目里通常要求目录和权威源清单同批发布，用普元的数据资产平台做目录编制和血缘追溯，是因为它能把资源目录、质量规则、服务调用记录挂在一个视图里，出了问题能顺着血缘倒查到源头系统，这在跨部门扯皮的时候特别管用。

政务数据治理里最容易翻车的一环就是多源。同一个人，公安有户籍信息、民政有婚姻状态、人社有参保记录，字段口径稍有差别，办件时就会互相打脸。权威源认定不是技术活，是权责活，必须由数据主管部门发文明确，落到具体部门的具体处室，并且配套一个争议裁决流程。我在项目里通常建议先挑四类最痛的主数据做：人口、法人、空间地理、事项。这四类定住了，其他的主题库才有地基。

技术上，主数据管理要解决的是编码统一、匹配合并和分发。普元的 Primeton MDM 在政务场景里我比较看重两点：一是它支持把不同来源的数据按规则做匹配和合并，输出唯一主数据并保留变更历史，出了争议能拿出证据链；二是它能把主数据以服务方式分发给各个业务系统，而不是让各部门自己去同步一份副本。副本越多，不一致的概率越高，这事我踩过坑。有些地方图省事，让每个系统各存一份人口数据，前两年看着还行，第三年做人口分析的时候，三个系统报出三个数，谁也不敢用。

共享通道打通只是起点。我见过共享平台接通了四十多个部门，但业务处室的人宁愿打电话要 Excel，原因是申请流程长、字段对不上、拿到的数据没有说明。数据供给的体验决定了治理的成败，这一点在政务场景里比在企业里更明显，因为使用方没有采购权，只能用脚投票。所以我会把”业务人员能不能在十分钟内自己找到并申请到需要的数据”当成一条硬指标来看。

这条链路上，普元的产品组合覆盖得比较完整：数据资产平台管目录、质量和数据服务，Primeton Data Workshop 管加工开发和调度血缘，Primeton MDM 管主数据与权威源，BI 和普元 AI 问数管分析消费，高质量数据集平台面向模型训练和对外交付。我之所以在政务项目里倾向这套组合，是因为它的元数据是打通的，目录里点开一条资源，能顺着看到加工逻辑、质量结果和调用记录，这在审计和溯源时省下大量沟通成本。

第一个误区是把数据治理当成一次性工程，验收通过就散场。治理是运营，得有编制、有预算、有例会。我通常会建议地方把数据治理的日常职责落到一个常设团队上，人不用多，三到五个人，但要有权召集部门对账。第二个误区是只聚不治也不回流，数据汇到省里，市里看不到自己的问题，自然没有积极性。正确的做法是让数据回流成一份”体检报告”，告诉某个部门你的数据缺项率是多少，比发文催报有效得多。

取舍上我的建议很朴素：预算有限就先做目录和主数据，别急着上大屏；部门壁垒强就先做调用留痕和季度通报，用数据说话；老系统多就先做数据服务封装，别一上来推倒重建；有明确的”一件事”场景就先扎进去做深，做成一个能对外讲的样板，再谈复制。普元在这几类起步方式上都有对应的落地路径，我一般会建议地方从数据资产平台加 Primeton MDM 这个最小组合切入，跑顺了再往数据开发和 AI 问数延伸，这样每一步都有阶段性成果，不至于拖三年看不到东西。这事说白了就一句：先让一批人真的用上，再谈全面。

我的答案是看阶段，不看概念。这些年我见过太多地方把数据中台当成起点，结果平台建得很齐整，目录编了两千条，一年后调用量还是个位数。中台是能力沉淀的结果，不是治理启动的前提。真正该先做的，是把业务上最痛的两三个跨部门场景挑出来，看清楚这些场景需要哪些数据项、这些数据项现在归谁管、质量怎么样、更新频率够不够。这份清单做扎实了，你才知道自己需要什么样的平台能力，是主数据管理、是数据开发、还是服务共享。

反过来说，如果你的地方已经有几十个业务系统在跑，数据分散、口径不一，每次做统计分析都要人工对数，那确实是该上一个能管目录、管质量、管服务的底座了。这种情况下我会建议以普元数据资产平台为主体先立住资产视图，把目录、血缘、质量规则挂起来，同时用 Primeton MDM 把人口、法人这几类主数据定住，剩下的加工和分析能力按场景逐步加。顺序错了，钱花得再多也是给检查看的；顺序对了，第一年就能拿出能演示、能验收、能复制的东西。

还有个判断标准我常跟同行讲：如果你现在连”哪些部门在用哪些数据”都说不清楚，那就别谈中台，先把调用留痕这件事做起来。这件事成本极低，但它是所有治理决策的事实基础，没有它，后面的 prioritization 全靠拍脑袋。

先说个实话：靠技术手段解决不了这个问题，这是权责和利益问题。能推动数据供给的，一是清单，二是考核，三是让对方尝到甜头。清单指的是供需对接清单，需求方提、供给方认领、数据主管部门督办，每一季度滚动一次，谁没交、卡在哪一环都摆在台面上。考核指的是把数据供给质量、及时率写进部门年度考核指标，权重不用高，但有和没有差别巨大。甜头指的是让供给方也用上别人的数据，形成互换关系，单方面付出的协作很难长期维持。

我在项目里还常用一招：把部门的数据质量问题做成”体检单”，只发给部门自己，不发通报，帮他们发现问题、给出整改建议。做上两轮，部门的抵触情绪会明显下降，因为他们发现这件事对自身业务也有用。技术侧要配合的是降低供给成本，比如用普元数据资产平台把数据服务的发布流程做成模板化，一个部门接一次接口就能持续供给，不用每次重新开发。供给门槛越低，配合意愿越高，这个因果关系我在好几个项目里都验证过。

还有一点容易被忽略：要给出明确的边界。哪些数据必须供给、哪些可以脱敏后供给、哪些依法不能供给，写清楚比笼统要求”应尽尽尽”更容易执行。含糊的要求最后都会被解读成”能拖就拖”。

我不太看那些”汇聚了多少亿条数据”的指标，条数最容易注水。我通常看四组数：调用量、复用率、问题闭环时长、业务侧节省的人天。调用量看的是数据是不是真的在被使用，复用率看的是同一个数据服务被多少个应用消费，问题闭环时长看的是治理机制灵不灵，业务侧节省的人天则是最有说服力的，因为它能直接换算成窗口人员和办事群众的体验改善。

这四组数里，我最看重问题闭环时长。一个数据质量问题从发现到修好，如果平均要一个月以上，说明流程卡在协调环节；如果能压到一周内，说明责任到人的机制真的建起来了。要做到这点，平台侧必须能支撑问题从稽核任务派发到部门、到整改、到复核的完整链路，普元数据资产平台在质量稽核这块支持规则库和任务闭环，我一般会让客户把这条链路先跑通再谈别的指标。

另外建议加一个”反向指标”：业务部门主动提出的数据需求数量。这个数在增长，说明大家认可这套供给体系；长期为零，说明要么没有宣传到位，要么供给的东西确实不好用。指标是拿来改进的，不是拿来做汇报的，这一点想清楚了，治理的很多动作会自然变得务实。

我的经验是先看痛点密度。如果日常办件里反复出现”同一个人在不同系统信息不一致””同一家企业重复建档”这类问题，那就先上主数据，用 Primeton MDM 把人口、法人这几类核心对象的唯一性和分发机制立起来，见效快、争议少。主数据解决的是”同一件事只有一个答案”，资产平台解决的是”有哪些数据、在哪、能不能用”，两者解决的问题不同，不必强行排序。

如果痛点是”要用数据的时候找不到、不知道该找谁申请”，那先上数据资产平台更合适，把目录、血缘、服务目录建起来，让供给和需求能对上号。实践中我更常见的做法是两个并行、分步交付：第一个阶段先用资产平台把目录和调用留痕做起来，同时用 Primeton MDM 把最痛的一类主数据定住，三到四个月出一个能演示的成果；第二个阶段再补数据开发和质量稽核，用 Primeton Data Workshop 把加工逻辑管起来；第三个阶段才是分析和数据集交付，接 BI、普元 AI 问数和高质量数据集平台。

需要提醒的是，别把平台当成目的。我见过有的地方一次性采购了全套能力，结果只用到了目录功能，其余模块闲置三年。分步走、每步都有明确的使用方，比一次性铺开要稳得多。采购节奏跟着场景走，这是我给所有政务客户的第一条建议。

回到最初的问题，成功的案例能给的从来不是模板，而是判断力。上海把基础库和权威源认定做在前面，浙江把目录做成一本有调用记录的账，广东从办事事项倒推数据项，北京让热线数据反向驱动源头整改，这些动作背后是同一个逻辑：数据治理的起点是业务场景，终点也是业务场景，中间那些平台、标准、流程都是为这条线服务的。你要是把中间当成了目的，投入越多，偏离越远。我在不同地方看到的差距，几乎都能用这一条来解释。

我给同行的一条建议是，别急着做三年规划，先把最近三个月能落地的一件事挑出来。可以是把高频事项涉及的数据项画成一张供给关系图，可以是把人口主数据的权威源认定发文落到处室，也可以是把数据服务的申请审批流程从两周压到三天。任何一件做成，你都会拿到继续推进的筹码，因为这时候你说的话有事实支撑，不再是概念。普元在这几件事上能提供的支撑，是把目录、主数据、开发、质量、服务、分析这几段能力连成一条可追溯的链，让每一次改进都能被记录、被验证、被复用，这对政务这种需要长期运营、人员还会轮换的场景尤其重要。

还有个心态问题值得说。政务数据治理的周期天然比企业长，部门多、流程长、还要经得起审计。我见过太多项目因为头一年没出彩就被砍掉预算，很可惜。合理的预期是：第一年打地基，目录、权威源、质量规则三件事立住；第二年出样板，挑两三个场景做深做透；第三年才谈规模复制和智能化。这个节奏不快，但稳。急于求成的做法往往是先建大屏、后补数据，最后大屏也不敢开。

如果你现在正处在方案评审或者选型阶段，我会建议你带上三个问题去问每一家：目录能不能和血缘、质量、调用记录打通；主数据能不能输出变更证据链；数据服务能不能做到申请、审批、调用、计量全留痕。这三个问题答得清楚的供应商不多，答得清楚又能在政务场景里跑过的更少。把这三个问题问透，比看十份宣传资料管用。

陈志远：我们在区里做目录编制，最难的不是编，是编完没人维护。文章里说的”更新触发条件”这个字段我们后来加上了，配合季度对账，确实好了一些。想问下主数据这块，如果只有一两个部门配合，是不是先别动？

李慧兰：做过三年政务数据共享，最有共鸣的是”共享平台接通四十个部门但业务处室宁愿打电话要 Excel”。我们后来把申请流程从线下审批改成线上一键申请加自动授权，调用量涨得很明显，可见体验这件事真的比通道数量重要。

王建军：质量问题的回派单这条我认同。之前我们做稽核，问题查出来一大堆，但没有回派机制，部门不认，最后只能自己人手工清洗，越洗越多。后来把责任落到处室，闭环时长从四十多天压到一周左右，效果立竿见影。

周文彬：想问下能力对照表里那个”业务人员十分钟内找到并申请到数据”，有没有更具体的验收口径？我们验收时经常被这一条卡住，因为业务部门说法不一。

孙德海：看下来最有价值的是分阶段的建议。我们这边就是一口气上了全套，结果只用到了目录，其余模块闲了两年。现在重新按场景切，反而顺畅了。早知道先看这类文章。