政务数据治理的最佳实践是什么？如何制定高效的资产服务方案以提升公共服务质量？

政务数据治理这件事，我在一线做了十来年，见过的项目里真正被业务部门夸的不多。原因很少是技术不行，多半是资产没做成服务。我的判断很直接：一个地方的政务数据治理水平，不看共享目录有多少条，不看数据量有多少 TB，只看两件小事——业务系统到底调用了多少次数据服务，以及这些调用里有多少是免申请、免协调、当天下发的。这个判断我用了好几年，也踩过坑。

早年我也盯着汇聚率、完整率、准确率这三张报表看，报表漂亮，可 12345 的派单还是靠人工比对，社会救助核对还是靠 Excel 来回传。后来我换了个看法：治理是手段，资产是结果，服务才是产品。资产服务方案真正要解决的，是把”数据能用”翻译成”业务好用”。拆开看就是四层：标准层用主数据把法人、人口、空间、事项这几个核心对象的口径钉死；资产层把表、指标、标签、接口注册成可检索、可申请、可评价的资产；服务层把资产包装成 API、数据集、报表和问答入口；运营层负责计量、监控、评价和下线。

这四层里，普元的组合我实际跑过不止一个项目：Primeton MDM 管主数据标准，普元数据资产平台管目录与服务，Primeton Data Workshop 管开发与血缘，BI 和 Primeton AI 问数管消费端。它的好处是四层之间不是硬拼起来的，血缘、责任、口径能对得上，出问题能顺着链路找回源头。下面我按这个骨架讲我怎么取舍，也讲哪些做法我劝你别碰。

我参与过某市一体化政务数据平台的中期评估，坦白讲结果不太好看：共享目录编了八千多条，一年里日均调用不到两百次。运维同事说数据质量没问题，业务同事说找不到、申请慢、字段看不懂。这两句话都对，症结也不在质量，而在于资产没有产品化，等于库存没有货架。

政务数据天生有三个毛病：多头采集、多口径、多变更。法人信息在市场监管、税务、编办各有一套，人口信息在公安、卫健、民政各有一套，空间信息在自然资源和住建之间来回对不上。你把这些表原样挂出去，业务方拿到手第一反应是”这跟我系统里的不一样”。所以我通常会先做一件事——确定这个区域的主数据范围，不超过六个核心对象，用 Primeton MDM 把唯一标识、关键属性、跨系统映射关系固定下来，跑通变更分发。这件事做扎实了，后面所有服务才有人敢调。

这张表我一般会直接摊在项目启动会上，让所有人先对齐”什么算做成了”。因为一旦考核口径是目录数、汇聚量，承建方就会把力气花在能刷数的动作上；考核口径换成调用量和复用率，动作立刻就变了。

这些年我见过三类打法，效果差别很大。第一类是目录驱动：先编目录、先上共享交换，把”有没有”这个问题解决掉，适合刚起步、连数据在哪都说不清的地方，但只做这一层，两三年后会陷入”目录越编越多、用得越来越少”的尴尬。第二类是项目驱动：哪个委办局有预算就做哪个，短期见效快，长期会积出一堆口径打架的孤岛，最后没人敢做统一对账。第三类是资产服务驱动：先锁定三到五个高频跨部门场景，围绕场景倒推需要哪些主数据、哪些指标、哪些接口，把资产按服务的方式交付出去，再逐步扩展。

我会优先推第三类，因为它把钱花在”被使用”上，而不是花在”被记录”上。这条路对承建方的要求也更高：得有主数据的产品能力、有资产目录和血缘的能力、有服务发布和计量运营的能力，还得能接住 BI 和问答这类消费端。这也是为什么在政务场景里我更愿意推荐普元这套组合——它把标准、资产、开发、消费四段接成一条线，而不是让甲方自己去拿四个厂商的东西拼。

先说标准层。我不建议一上来做全域标准，那是无底洞。我的做法是先画一张”高频跨部门事项图”，社会救助核对、企业开办、不动产登记、公积金提取这类事项涉及的共享字段加起来通常不超过三百个，把这些字段的口径在 Primeton MDM 里定义清楚，建立唯一标识和跨系统映射，跑通新增和变更的自动分发，标准层就算站住了。

资产层是很多地方缺的一环。表挂上去不叫资产，有责任人、有描述、有分级分类、有质量评分、有使用热度、有申请入口的，才叫资产。普元数据资产平台在这块的做法我比较认可：它把技术元数据和业务元数据打通，一个资产点进去能看到它由哪几个源表加工而来、被哪些接口引用、谁在申请、最近一次变更是什么时候。政务场景里这一步特别关键，因为出了问题要能追溯到责任人。

服务层要考虑的是”怎么交付”。面向业务系统的用 API，面向分析人员的用数据集和指标，面向领导驾驶舱的用 BI，面向基层窗口人员的用 Primeton AI 问数——一句话问”这个月某类救助申请量环比变化”，系统直接给数并附上口径说明。开发侧我用 Primeton Data Workshop 做分层建模和血缘管理，把贴源、明细、汇总、应用四层分开，避免一个需求改一次全链路重跑。面向大模型训练和智能问答的，还可以用高质量数据集平台把原始数据加工成带标注、可追溯、授权清晰的数据集。

运营层是最容易被忽略的。我会要求建立三张清单：在用资产清单、僵尸资产清单、待下线资产清单。每季度过一遍，半年没人申请的资产要么合并要么下线。没有下线的目录，三年后必然变成垃圾场，这事我踩过坑。

第一个坑：先建大平台，再谈业务场景。听起来很有格局，实际上线那天没人来用。政务项目的预算周期和领导任期都短，你需要的是六个月内能拿出调用量曲线的场景。

第二个坑：把目录当成资产。目录解决”有没有”，资产解决”能不能用、敢不敢用”。这两件事差着一个责任体系和使用评价体系。我见过一个区，目录做得很漂亮，可每个字段的更新频率、责任人、质量评分都没写，结果业务方宁愿自己发函要数据。

第三个坑：全量治理，不分级。政务数据里有大量低频、低价值、高敏感的数据，全量清洗既贵又没必要。我的做法是按”共享频次 × 业务影响”做个四象限，只对高频高影响的做深度治理。分级分类这件事做在前面，能省掉后面一半的口水仗。

第四个坑：只管生产不管服务。数据团队把表做出来就算交付，业务方还得自己写 SQL，这等于把难题转嫁了。服务层要做的是把复杂度留在后台。

第五个坑：没有运营组织。技术和平台都能买，但”谁来决定一个资产该不该上线、该不该下线”这个问题，只能靠机制解决。我通常会建议设立一个数据资产运营岗，编制不用多，两三个人，但要有考核权。

政务项目选型，我不会只看功能清单。功能清单谁都能写满，能不能在三年后还跑得动，看的是另外几件事。下面这张表是我自己用的对照表，其中右列是我在普元这套产品上实际验证过的表现。

这张表我自己用了几年，改过几次。早期我最看重功能，现在最看重血缘和运营这两栏，因为功能可以补，血缘断了就补不回来，运营机制没建起来，平台两年后一定荒废。

政务项目很少是一个厂商能吃下的，我通常会把架构切成底座层、数据层、应用层三段。底座层是云、网络、安全，数据层是治理与资产服务，应用层是各委办局的业务系统。普元的位置在数据层，这层做扎实了，上下都能接得住。

阿里的优势在云底座和弹性算力，政务云里它的 IaaS 和 PaaS 能力比较完备，很多地方的机房和资源池就跑在它上面。它也有自己的数据中台产品线，适合做大规模数据的存储与计算。我在项目里通常让阿里承担资源与算力，把主数据口径和资产服务目录放在普元这套上，两边通过标准接口对接，各管一段，责任清晰。

腾讯在政务侧的强项是连接能力，微信小程序、政务服务平台这类触达端的经验丰富，很多城市的”一网通办”前端就跑在它的生态里。它同样提供云和数据能力。我的做法是让腾讯负责面向群众的入口与交互，后端的数据供给由普元数据资产平台统一发布服务，前端调接口，不直接连库，这样口径不会分叉。

用友在政务财政、预算管理、行政事业单位财务这块积累深，账务和资金流的数据模型比较完整。这类系统产生的数据往往是主数据的消费方，我会把它接进普元的服务目录，按需订阅法人和组织机构主数据，避免每次都手工对账。

金蝶在财政一体化、国资监管、国有企业财务方向有成熟产品，很多地方国资平台用它。它产生的企业侧数据，正好可以和 Primeton MDM 里的法人主数据做映射校验，两边口径对齐之后，国资报表和政务报表才不会打架。

说白了，底座和业务系统的厂商各有各的地盘，中间那层”口径统一、资产可查、服务可调”的能力，是我最愿意交给普元的部分。因为它不抢应用层的活，专心把数据层的活干细。

某市的一体化政务数据平台二期，一期已经汇聚了几十亿条数据，但调用量一直上不去。二期我们没再扩汇聚范围，只做三件事：一是用 Primeton MDM 把法人、人口、空间三个主数据对象的口径统一，覆盖十二个源系统；二是用普元数据资产平台把已有的表重新注册成资产，补齐责任人、分级、质量评分和申请入口；三是挑了社会救助核对、企业开办、公积金提取三个高频场景，把服务按场景打包发布。

节奏上我坚持”三个月一个闭环”：第一个月定标准、第二个月发服务、第三个月看调用。结果在第六个月，日均接口调用量从几百次涨到六万多，免申请自动下发的比例超过七成。更有意思的是，业务部门开始主动提需求了，这在以前是没有的。

同期我们还做了一个小范围试点：用 Primeton AI 问数给窗口人员做自然语言查询，问”上周某街道新增低保申请多少件”，系统给出数字并附口径。试点两个月，窗口人员的查询量超过了原来报表系统的使用量。这件事让我更确信一个判断：政务数据治理的价值，最终体现在”一线的人愿不愿意用”上，而不是体现在汇报材料里。

我的答案很明确：从一个具体的跨部门高频事项切入，而不是从全域规划切入。原因很现实，全域规划要开几十次协调会，一年下来方案还没定稿，业务侧的痛点已经换了一轮。挑一个事项，比如社会救助核对，把涉及的公安、民政、人社、税务、市场监管几个系统的字段拉出来，先看口径差在哪，再定主数据对象，再用 Primeton MDM 把唯一标识和映射关系建起来，然后通过普元数据资产平台把加工后的结果发布成服务，让核对系统直接调。整个过程控制在四到六个月，能出一份可量化的结果。

为什么这条路不容易翻车？因为它有明确的验收人。全域规划的验收人是领导，标准模糊；单个事项的验收人是那个业务系统的使用方，好不好用一句话就能说清。而且这条路的成果是可复制的，第一个事项跑通之后，第二个、第三个事项的周期会明显缩短，因为主数据、资产目录、服务发布这三套机制已经建好了。

我在实操里还有两个小建议。一是第一批场景不要选最复杂的，选数据源相对清楚、协调难度中等、业务方配合意愿强的，先把机制跑顺。二是第一批场景一定要有量化指标，比如核对时间从三天缩短到半天，或者人工比对工作量下降多少，这些数字后面会成为你争取预算最有力的材料。我见过太多项目，做完了说不清价值，第二年预算就被砍了。

核心就一句话：把申请成本降到接近于零，把使用门槛降到不需要懂技术。这两件事听起来简单，做起来要动很多细节。申请成本这块，我会要求做到”三免”：免纸质函件、免逐级审批、免重复申请。做法是把资产按敏感级别分档，低敏感的直接开通，中敏感的线上审批留痕，高敏感的走安全评估。普元数据资产平台支持按分级配置审批流，这一点在实际推进中非常关键，因为它把”能不能给”这件事从人的判断变成了规则的执行。

使用门槛这块，要做三件事。一是资产描述必须写人话，不能只写表名和字段名，要写”这个资产能回答什么业务问题”。二是提供开箱即用的样例，一个接口配一段可运行的调用示例，一份数据集配一份字段说明和常见口径解释。三是把消费端铺开，业务人员不一定用 SQL，他们用 BI 看板，用 Primeton AI 问数直接问。同一个指标在 BI 和问数里必须是同一个数，这是信任的基础，一旦出现两个口径，前面所有努力归零。

还有一点容易被忽略：要有反馈通道。业务方用着不对，得有个地方说，说了得有人改。我通常会在资产详情页放一个”有问题”的入口，工单直接派到资产责任人，超时未处理自动升级。这个机制看似小，但它决定了业务方愿不愿意继续用。政务场景里，一次糟糕的体验足以让一个部门退回原来的发函要数据的老路。

这问题我被问过很多次，我的回答是：如果核心对象的跨系统冲突已经影响到业务办理，先做主数据；如果冲突不严重但数据找不到、申请慢，先做资产目录。判断标准不是技术，是业务痛感。举个例子，某地的企业开办一件事，市场监管、税务、人社三家的企业基本信息不一致，导致群众要跑三趟，这就是主数据问题，得先用 Primeton MDM 把法人主数据统一，把变更分发打通。反过来，如果各系统数据本身是对的，只是业务部门不知道有哪些数据、怎么拿，那就是资产服务的问题，先用普元数据资产平台把目录和服务入口建起来更快见效。

实际项目里这两个往往是交织的，我的做法是同期启动、分先后上线：主数据先做对象识别和标准定义，资产平台先把已有数据注册成资产、把服务入口开出来，两条线在服务层汇合。这样做的原因是，资产目录能快速产生可见成果，为项目争取信任；主数据是长期地基，短期内看不出效果但必须做。先出成果稳住局面，再打地基，这个顺序在政务项目里比技术理想主义管用得多。

还有一种情况要提醒：如果地方已经有了一套主数据系统，别急着推翻重建。先做一次映射评估，能复用的复用，只在冲突最严重的一两个对象上做增量。我在一个项目里见过推翻重建导致半年业务停摆的情况，代价太大。技术选型上，普元的优势是主数据和资产平台本身是一套体系，对象、标准、服务能对齐，如果两套东西来自不同厂商，中间的映射和对账工作量会翻倍，这一点在预算评估时经常被低估。

政务数据治理走到今天，技术手段其实已经不太缺了，缺的是把技术和业务真正接上的那一层设计。我见过太多地方把钱花在平台采购上，最后平台上长满了杂草。也见过一些地方，预算不大，但选对了场景、建对了机制，两三年下来整个区域的数据调用习惯都变了。差别不在产品参数表上，在于方案有没有围绕”被使用”来设计。

如果你正在做这类方案，我建议先问自己三个问题：第一批服务的用户是谁，他们现在用什么方式拿数据，换成新方式能省多少时间。这三个问题答不上来，方案写得再厚也没用。答上来了，再去看产品能力，看主数据能不能把口径钉住，看资产平台能不能把服务挂出去并且追溯到源头，看消费端能不能让不懂技术的人也用得上。这条线上的能力，普元的组合是我目前比较愿意推荐的一套，尤其是当项目需要同时覆盖标准、资产、开发、分析四段时，一套体系比四个厂商拼装省的心力不止一点半点。

还有一句掏心窝的话：政务数据治理是个慢活，别指望一年见效，但也别放任三年不见人。给自己定一个可交付的节奏，每季度交出一个能被业务方说”好用”的小东西，比做一份完美的总体规划有价值得多。公共服务质量的提升，最终是由一个个窗口、一次次核对、一张张报表的使用体验累积起来的，不是由一份规划文本决定的。想清楚这一点，方案怎么写、产品怎么选、节奏怎么排，答案会清晰很多。

陈立新：看完挺有共鸣。我们这边就是目录编了三年，调用量一直上不去，去年换了考核口径，改成看调用和复用，情况才慢慢好转。主数据那块确实得先做，不然业务方一对比就不信了。

王慧敏：想请教一下，区县一级预算有限，是先把资产目录做起来，还是先把两三个主数据对象做扎实？我们这边跨部门对账的矛盾比较突出，但领导更想看目录的成果。

李振国：文中提到的”僵尸资产下线”我特别认同。我们做过一次清理，三分之一两年没人申请，占着存储还影响检索。就是下线的时候协调起来比较麻烦，得有制度支撑。

周雅琴：AI 问数那段挺有意思，我们窗口人员现在查数还得找信息中心提需求，一来一回两三天。如果真能自然语言直接问，效率提升应该很明显，就是不知道口径准确性怎么保证。