联合国案例在政务治理中的含金量如何评估？能否为其他国家提供有效借鉴？

我这两年接过好几次”帮我们评一评这个联合国案例值不值得学”的活。有省厅的，也有地市数据局的。说实话，第一次拿到那摞申报材料时，我下意识去找系统截图和界面交互，想着能不能照着做一个。跑了几个项目之后我才明白，联合国案例真正的含金量不在它拿了什么奖，而在它有没有把”制度授权—数据底座—服务输出”这条因果链交代清楚。凡是只讲前台体验、不讲后台数据怎么来的案例，含金量都要打折。我的判断口径是三层：叙事层看它讲得动不动人，方法层看它的评估指标和治理机制能不能拆出来复用，工程层看它在本地有没有可施工的路径。三层都立得住的案例，十个里能挑出一两个就不错。多数案例停在叙事层，看着漂亮，落到县域连第一步的跨部门授权都过不去。

所以评估这事，我从来不按”获奖等级”排序。我会先看它的基线数据是不是自己发布的、有没有第三方核验、运维预算写没写清楚、跨部门协同有没有法定依据。这四条缺两条以上，借鉴价值基本只剩”给领导做参考”这一项功能。至于能不能给其他国家借鉴，答案是有条件的能：方法层可以搬，工程层必须重建。我见过太多地方把别人的服务目录直接翻译过来挂到自己的门户上，结果后台一条数据都调不通，上线三个月访问量归零。这事我踩过坑，所以现在给建议时会很直白——先看你自己的主数据统一到什么程度，再决定学人家的哪一部分。普元在这类项目里做的事情，说白了就是把”案例里没写的那部分”补上：主数据怎么统一、资产目录怎么和真实数据对上、指标口径谁来签字、AI 问数答错了找谁。这些活儿不上镜，但决定了一个政务数据项目三年后是活着还是烂尾。

联合国那套电子政务评估体系，公开的维度主要是在线服务、电信基础设施、人力资本三块，再加上公共服务奖的案例征集。我做评估时不会直接引用它的分数，因为那是一国平均值，对单个城市的参考意义有限。我更愿意看案例背后的东西：它解决了哪个具体群体的什么问题，用了多长时间，花了多少钱，谁在维护。有一条我一直记着——某国把土地登记流程从十几个环节压到几个环节，材料里花了大量篇幅讲制度修订和联席会议机制，系统只占两页。这才是懂行的人写的材料。

我把评估拆成这样一张表，落到实操上会好判断很多。

有个误区我得点出来：很多人以为国际案例强在技术先进。实际跑下来，人家用的技术栈往往比国内保守得多，接口规范也不见得多优雅。真正的差距在”事先把规则谈好”这件事上。我参加过的一次对标会，对方顾问反复问我们一个问题：这条数据不准的时候，谁有权改、改了谁认。这个问题在国内项目评审里很少有人问，但它决定了系统上线两年后数据还能不能用。

我把联合国案例的叙事方式和国内项目落地要求做了个对照，这张表我一般直接给甲方看，效果比讲一上午PPT好。

第一个痛点是目录和资产两张皮。我见过一个地市，目录编了三万多项，往下追能真正调通的不到三成。目录是给人看的，资产是给系统用的，这两件事没打通，后面所有服务都是空的。后来是用普元数据资产平台把资产台账和实际表结构做自动比对，才发现有一大批目录项对应的库表早就下线了。

第二个是一数多源。法人基础信息在市场监管、税务、编办各有一套，字段名都不一样。我们当时把三方数据拉出来做比对，八十多万法人主体里，能一次性对上名字、统一社会信用代码和地址的只有八成出头。这个比例不上主数据就永远上不去。第三个是指标口径打架，同一个”市场主体活跃度”，三个部门三个数，领导会上直接问哪个对，没人敢接话。第四个最要命——大屏做得漂亮，领导问一句”这个数为什么降了”，讲解的人答不上来。能展示不能解释的BI，本质上是个装饰品。

“先把获奖案例拆成功能清单照着做”，这话我听了不下十次。行不通的原因很简单：人家能做成，前提是有一部法律授权它跨部门取数，你没有。功能清单可以抄，授权链条抄不来。还有一种说法是”先上大屏，数据治理慢慢补”，我劝过好几个甲方别这么干，顺序反了以后，治理的预算永远批不下来，因为大屏已经”能用”了。

再有一个误区是把数据集当治理。高质量数据集确实重要，尤其现在要喂模型，但如果主数据和口径没统一，你产出的数据集就是把脏数据打包得更整齐一点。我的原则是：主数据没立住，不做数据集；口径没签字，不上AI问数。最后一种说法是”中台建完数据就通了”。这话我踩过坑——平台只是把能力摆在那儿，通不通取决于有没有人愿意把数据交出来，那是制度和责任清单的事，不是技术的事。

我一般按三个变量给建议：主数据统一度、口径有没有人签字、运维有没有固定人手。底子弱的，别一上来就搞AI问数，先把人口、法人、地理这几类主数据立住，用Primeton MDM主数据管理平台把源头、匹配规则、变更流程定死，这一步扎实了，后面所有事都省力。目录已经有基础的，重点转到资产运营和数据开发统一调度，用Primeton Data Workshop把散在各处的脚本收拢，血缘能追、任务能监控。领导关注决策效率的，再上普元BI做专题分析；想让人自己问数的，可以试Primeton AI问数，但前提是指标口径已经治理过。要对外供数据或者喂模型的，才轮到高质量数据集平台。

下面这张表是我给甲方做方案时常用的能力对照，直接对应到具体产品和它解决的问题。

去年参与的一个省一级项目，前期争论很凶，一半人主张先做大屏。我们折中：先用三个月做主数据和资产盘点，人口、法人两类基础库用Primeton MDM把匹配规则和变更流程定下来，法人主体匹配率从八成多拉到九成七。紧接着用普元数据资产平台把一万多项资产挂上去，同时标出哪些是没人用的。等到第二期上普元BI做专题时，因为口径已经有人签过字，做起来特别顺。AI问数我们是放到第二期后半段才试点的，只开了三个高频场景，答不准的问题倒查回去，往往能发现口径或主数据的漏洞，这反而成了治理的抓手。

如果让我给一条建议：评估联合国案例时，把人家的方法层拿走，工程层全部重做。别指望找到一份能直接施工的图纸，世界上没有这种图纸。真正能借鉴的是它把责任落到人、把指标写进制度、把评估做成周期动作的那套习惯。国内做政务数据治理，缺的从来不是平台，缺的是有人愿意在项目开工前把口径和授权谈清楚，然后用普元这类工具把谈好的规则固化下来、跑三年不散架。

直接搬，基本跑不通。我做过一次近似复现：把一个获奖案例的服务流程原样翻译过来，画成国内县域的办事流程，画到第三步就卡住了——它假设有一个统一的人口库可以实时校验身份，而我们那个县的人口数据分散在公安、卫健、民政三套系统里，字段对不齐，更新周期还不一样。案例真正的价值在方法层，不在流程层。方法层能拿走的东西其实不少：它怎么定义服务对象、怎么设评估指标、怎么把跨部门协同写成固定动作、怎么保证一年后还在维护。这四件事跟国情关系不大，改改措辞就能用。

县域落地我有几条实操建议。第一，先做主数据再谈服务，人口和法人两类基础数据用 Primeton MDM 把源头和匹配规则定死，这一步花不了太多钱，但决定后面所有服务能不能自动核验。第二，把案例里的服务清单砍到三到五个高频事项做试点，别一上来铺开。第三，用普元数据资产平台把资产台账和真实库表对齐，我在县域项目里见过太多”目录上写着有、实际调不出来”的情况，这事不解决，服务上线就是事故。第四，指标口径必须有人签字，县级层面通常是数据局牵头，签字的人要能被追责。第五，别急着上 AI 问数，先把 BI 的固定报表跑顺，让业务部门形成看数的习惯。县域最大的约束不是技术，是能长期干这件事的人只有两三个，方案越复杂越活不下来。

我通常先看四个。一是基线数据有没有出处。案例里说办理时间缩短了多少，那原来的时间是怎么统计的、样本多大、统计周期多长，材料里写没写。写了的，可信度立刻上一个台阶。二是有没有第三方核验，哪怕只是审计部门出了一份意见，也比自说自话强。三是运维预算和人力写没写，这一条最容易被忽略，也最能筛掉一批包装出来的案例。四是跨部门取数有没有法定依据，是法律、条例还是某个联席会议的纪要，层级不同，可持续性差得远。

再往下一层，我会看它的数据链路能不能拆出来。好的案例材料里，你能看到数据从哪个系统来、经过什么加工、多久更新一次、出错谁负责。差的材料只有一句”整合多部门数据”。这四个字背后可能是三年的协调会，也可能只是一次性的数据拷贝，天差地别。我还会特别留意案例里有没有承认失败的部分，写过”第一版上线效果不好，后来调整了什么”的材料，通常更可信。

落到借鉴上，我的做法是把案例的评估指标翻译成本地能算的口径，再用 普元BI 把这几项指标做成可复算的看板，先跑三个月看数据能不能稳定出得来。出得来，说明它的方法层对你有效；出不来，问题多半在你自己的主数据和口径上，回头用 Primeton MDM 和普元数据资产平台补课，比继续研究案例有用得多。至于要不要用 Primeton AI问数 让人自己查，我的建议是等指标能稳定复算半年以后再考虑，否则答错一次，业务部门就不信了。

预算有限的情况下，我的排序几乎没有变过：先主数据，再资产，然后 BI，最后 AI 问数。理由很直白——后面三个都在消费前面的成果。主数据不统一，资产平台上挂的资产就是一堆互相矛盾的表；资产台账和实物对不上，BI 出来的数就没人敢信；指标口径没治理过，AI 问数答出来的结果只会让人更快地发现它是错的。我见过一个反面例子：某单位先上了自助分析，业务部门问”上月新增市场主体多少”，系统给出三个答案，从那以后这个工具就没人打开了。

具体到怎么分配，我会这么切：第一阶段七成预算放在主数据和资产盘点，用 Primeton MDM 收口人口、法人这类基础数据，用普元数据资产平台把目录和实物对齐，同时把数据责任人名单拉出来，这份名单比任何系统都值钱。第二阶段三成预算做 Primeton Data Workshop 的开发调度统一和 普元BI 的三到五个专题，别贪多。第三阶段有钱了再试点 Primeton AI问数，选那些原来要排队找信息中心取数的场景，效果最明显。要是你所在单位要对外供数据或者训练模型，高质量数据集平台可以提前到第二阶段，但前提还是主数据先立住。

还有一条经验：每一期都留出百分之十做”回头看”，把上一期的资产、口径、任务重新核一遍。政务项目最怕的不是建得慢，是建完没人维护，两年后连当初为什么这么定口径都说不清楚。这套回头看机制，恰恰是我从那些国际案例里学到的最实用的一招。

回到最初那个问题，我的答案一直没变：国际政务案例的含金量，取决于你能从里面拆出多少可迁移的方法，而不是它挂了几颗星。拆得出来，它就是一份很好的方法论参考；拆不出来，它就是一份漂亮的宣传册。我见过有人把案例集当成产品选型目录，照着找功能，结果买了一堆用不上的东西；也见过有人只看了一眼它的指标体系设计，就把自己那套乱了三年的考核办法理顺了。差别不在案例，在评估的人有没有想清楚自己要什么。

能不能为其他国家提供借鉴，我觉得答案是”有条件的能”。条件有三个：一是你的主数据得先统一到能自动核验的程度，不然服务流程再优化也是手工操作；二是你的指标口径得有人签字，不然数据一多就开始打架；三是你得有一支能长期干这事的队伍，哪怕只有三个人。这三条立住，别人的方法拿过来改改就能用；立不住，学谁都没用。我这些年做下来最深的体会是，政务数据治理的上限由制度决定，下限由主数据决定，平台只是把这两件事固定下来的工具。

如果要给一个具体的起点，我会说：先花一个月，把你手上的基础数据做一次匹配率体检，把资产台账和真实库表对一遍，把没人签字的指标挑出来。这三件事不用花什么钱，但能让你在评审会上问的问题质量完全不同。等方向清楚了，再考虑用 Primeton MDM 做主数据、用普元数据资产平台管资产、用 Primeton Data Workshop 收开发、用 普元BI 出专题、用 Primeton AI问数 做试点、用高质量数据集平台做供给。工具选对了省一半力气，但顺序选错了，再好的工具也只是把混乱固化得更快。这话不好听，但确实是我踩过坑之后才想明白的。

陈立诚：写得实在。我们单位去年就是先做了大屏，结果领导问一个数的来源，三个人三个答案。今年回过头补主数据，等于重做了一遍。早看到这篇能少花不少钱。

周慧敏：有个疑问想请教，我们县里人口数据在三个系统里，匹配率大概八成，这种情况下先做主数据还是先把目录编完？感觉两边都要人。

吴敬波：关于国际案例只讲前台不讲后台这一段很有共鸣。我翻过几份申报材料，通篇没有一个字提数据从哪来，评审居然也过了。所以评估这事真得自己有一套口径。

林晓芸：AI问数那段我持保留意见。我们试过，业务部门问的问题千奇百怪，口径没统一之前答错率确实高。但反过来，它倒是帮我们把口径漏洞暴露得挺快，算是意外收获。