政务领域的转变：如何实现从治理到服务的无缝对接？您准备好迎接这一变革了吗？

我参与过二十来个政务数据相关的项目，从省级数据共享交换平台到区县的一件事主题库都做过。如果只让我说一句判断：绝大多数政务数据项目没做好，不是技术不过关，而是治理目标和服务的用法没有对齐。治理侧交的是一本台账，服务侧要的是一个结果。这两件事在验收表上看着都完成了，到了窗口就露馅。

我印象最深的是一个市级项目，数据资源目录做了八千多项，标准规范写了厚厚一叠，验收评分很高。可我去办事大厅蹲了半天，发现工作人员还在手工核对三张表的信息，因为系统里同一个企业主体有三种编码，谁也不敢直接用。这就是典型的“治理做得漂亮，服务接不上”。台账指标容易达标：覆盖多少张表、编目多少条数据、共享调用多少次。服务指标难达标：材料减免了多少、办结时长压到多少、一次办成率多少。前者能靠工程推进，后者必须靠数据建模思路的转变。

我把这个转变拆成三件事：主体要统一、口径要唯一、供给要及时。主体统一解决“是不是同一个人、同一家企业”；口径唯一解决“同一个指标是不是同一个数”；供给及时解决“窗口核验的时候数据到不到”。这三件事做到了，服务才接得上；做不到，做再多目录也只是好看。现时间点比较特殊，AI问数、高质量数据集这些能力成熟起来以后，“一次治理、多次复用”从口号变成了可落地的路径，普元这类把主数据、数据资产、数据开发、BI、AI问数串在一条链上的平台，价值才真正显出来。

不同类型的政务服务场景，对数据的要求完全不一样。我一般会先按场景把要求列清楚，再去谈平台选型，不然很容易被供应商带着走。

早几年政务数据项目的验收标准很单一：数据资源目录覆盖率、共享交换条数、接口调用次数。这套指标催生了一大批“目录工程”，库里堆着数据，业务侧用不上。我见过一个区，归集的数据量做到PB级，实际被业务系统调用的不到百分之五。

变化是最近两三年发生的。“高效办成一件事”“免申即享”“无感审批”这些词进了考核文件以后，数据项目的立项逻辑变了。我注意到越来越多的可研报告里，服务场景被写在前面，数据需求是倒推出来的，而不是先把库建好再想用途。这个顺序一换，对厂商的要求就完全不同了：只会做编目和交换的工具会掉队，能把治理成果直接封装成服务能力的平台才有位置。

公共数据授权运营这件事也在推着行业往前走。数据从“资源”变成“要素”，意味着它得能被定价、被计量、被安全地供出去。这对数据资产管理和高质量数据集的供给能力提出了很实在的要求——不是画个架构图就行，得有可运行的加工链路和可追溯的版本管理。普元在这块的思路是把治理、开发、分析、问数放在一条链上，我后面会用一张表说清楚每个环节对应什么能力。

去年我跟进一个区级“一件事”主题库项目，第一阶段做了八个月，目录齐、标准齐、共享接口也上线了。验收完我去窗口看，工作人员还是打开两三个系统对照着核。业务处长跟我说了一句话我记到现在：“你们给的是数据，我要的是结论。”

复盘下来三个问题。第一，主体对不上。同一个办事人在公安、民政、人社有三套标识，主题库没做主体归一，调用方拿到三条记录不知道是不是一个人。第二，字段含义对不上。“参保状态”这个字段在三个源系统里编码规则不一样，窗口人员看的是汉字，系统给的是代码。第三，时效对不上。主题库是T+1跑批，窗口要的是实时核验，昨天变更的信息今天查不到，办事群众就跑第二趟。

第二阶段我们换了做法：不再从部门数据盘点出发，而是挑三个高频事项，把办这件事需要的字段逐个列出来，倒推需要哪些源数据、需要什么时效、需要什么口径。调整完两个月，材料减免和一次办成率都有明显变化。这里的关键不是技术升级，是起点换了。下面这张对比表，我基本上每次做政务项目汇报都会拿出来讲。

第一个断点是主体。自然人和法人这两类主体，在公安、市场监管、人社、医保各有各的标识规则，不做归一，一切“一件事”都是空谈。这块要靠主数据管理来解决，普元的主数据管理平台在政务场景里最常干的活就是这个：多源主体数据的匹配、合并、版本追溯，以及合并规则的灵活配置。我一般会要求合并规则可视化可回溯，因为政务数据一旦合错，影响的是老百姓的办事资格。

第二个断点是口径。同一个“城镇登记失业率”在不同委办局有不同算法，上报的时候各自取数，到了会上就对不上。问题不在数据质量，在于没有一层统一的指标语义定义。第三个断点是时效。很多政务主题库还是T+1跑批，支撑不了实时核验，需要数据开发平台把实时链路建起来。第四个断点是供给，数据躺在库里，不敢给、不会给，缺的是分级分类加上服务封装的能力。这四处我按优先级排，主体和口径永远排前面，因为这两块不解决，后面做得再多也白搭。

误区一：先把数据全量归集了再说用途。这个我踩过坑。早年做交换平台，追求“应归尽归”，结果归了一大堆没人用的数据，还得持续花钱维护存储和质量规则。现在的做法是先定场景，按需归集，宁可少归一点，也要保证归进来的能用。

误区二：把数据治理当成一次性工程。标准文档写完就锁进柜子，第二年组织一调整，标准就作废了。我的经验是治理必须有常设的组织和例会机制，平台只是载体。选平台的时候我会特别看它能不能把标准、质量规则、责任人都沉淀下来，而不是只出一份报告。

误区三：上了BI就叫数据服务。这个误解特别普遍。领导驾驶舱做得再漂亮，窗口人员也用不上，因为窗口要的是一个判定结果或者一个接口返回，不是一张图。服务化意味着数据要以API、以标签、以判定规则的形式出去。

误区四：安全就等于不共享。分级分类做好了，授权运营的路径是通的。关键是把“谁能用、用到什么程度、用完怎么审计”这件事说清楚，而不是一刀切。

选型的时候我不太看架构图画得多大，我只看四件事：主体能不能统一、指标有没有唯一的语义层、数据供给能不能做到准实时、治理成果能不能封装成服务。这四条任何一条不达标，这个平台在政务服务场景里就是半成品。实际跑下来，能同时把这四件事放在一条链上做的产品不多，普元的产品体系是比较完整的一个，从主数据到资产、从开发到BI再到AI问数，链条是连着的，不用在中间做大量拼接。

下面这张表是我做方案时常用的对照，左边是能力维度，中间是对应的产品，右边是我在政务场景里实际会关注的点。

预算有限的时候，先做主数据还是先做资产目录，这个我被问过很多次。我的判断很简单：看有没有跨部门的高频事项。如果有，比如办件量排前十的事项里有一半要跨三个部门以上，那就先做主数据，主体不统一什么都干不成。如果暂时没有，先把资产盘点做扎实，把家底摸清，再谈归一。

指标体系建设也别贪多。我见过一上来就要做八百个指标的，做了半年一个都没定稿。实际有效的做法是先定二十个核心指标，每个指标明确唯一口径、唯一责任部门、唯一取数路径，跑三个月稳定了再扩。剩下的是复制，不是重新造。

还有几条避坑建议。第一，合同里别只写“提供数据服务接口”，要写清楚接口的成功率、响应时间、覆盖事项数，否则验收时全是扯皮。第二，一定要留出窗口调研的时间，我通常要求方案团队去大厅坐两天，比看十份调研报告都管用。第三，平台选型别只看功能清单，要现场让他们用你的真实数据跑一遍主数据匹配和指标计算，跑不动就是跑不动。第四，AI问数这类新能力，先在小范围做验证，别一上来就铺全域，语义层是靠一个个指标喂出来的，急不得。

第一个案例是某市的一个民生事项。他们用主数据管理平台把分散在四个部门的自然人信息做了归一，匹配规则配了十几条，包括身份证、手机号、社保号的多级匹配和冲突处理。上线后最直接的变化是，窗口调取办事人信息从原来的多次查询变成一次命中，材料重复提交的情况大幅减少。项目组跟我说，真正的难点不在平台，在于各部门对“以哪套信息为准”这件事达成一致，这个会开了七次。

第二个案例是某局的管理驾驶舱。之前领导要一个数，得让下面的人跑两三天。后来他们用BI把核心指标统一了口径，再用普元AI问数做了自然语言查询，领导自己问“上个月新登记的市场主体有多少”，几秒钟出结果。这里有个前提我必须强调：AI问数能用，是因为底下的指标口径已经被治理过一遍了。没有语义层，问数就是空中楼阁，答出来的数没人敢信。

一线人员的反馈我印象比较深的有两句。一位窗口的同志说：“我不关心数据从哪来，我只关心点一下能不能出结果。”另一位数据处的负责人说：“以前我们考核的是共享了多少条，现在考核的是老百姓少交了多少材料，压力大多了，但方向是对的。”这两句话，其实已经把治理和服务的关系说透了。

这个问题我被问过至少二十次，我的答案一直是看场景，不看预算。判断标准是：你辖区的政务服务事项里，有多少件是需要跨三个以上部门协同办理的，这些事项的办件量占比多少。如果占比超过三成，主数据管理必须排在前面。原因很直接，跨部门办事的第一道坎就是主体识别，同一个办事人在不同系统里有不同标识，后面所有的数据关联、材料复用、状态核验都无从谈起。

反过来说，如果你的业务目前以单部门事项为主，跨部门协同量很小，那先把资产目录做扎实更划算。资产盘点的价值在于把家底摸清楚，知道哪些数据有、哪些数据缺、哪些数据质量差，为后面做主题库打基础。我一般会建议这类项目同步把数据责任人机制建起来，不然目录做完了也没人维护。

还有一种中间情况，就是预算只够做一件事，但两边的需求都很急。我的做法是做一个“轻量主数据加轻量目录”的组合：主数据只做自然人和法人两类核心主体，不求全覆盖，目录只做高频事项涉及的字段级资产，不求全量编目。这样两头都有交代，也为后续扩展留了口子。普元的主数据管理平台在实施上支持分阶段推进，先建主体域再逐步扩到事项和机构，这个节奏对预算有限的项目比较友好。

另外提醒一句，不管先做哪一块，都要在立项时把“服务侧怎么用”写进方案里。我见过太多项目，做完主数据放在那儿，业务系统不知道该怎么接，最后变成又一个孤岛。能不能被调用，比做得全不全更重要。

按我的经验，卡点通常不在网络通不通、接口有没有，而在三个更细的地方。第一个是字段含义不一致。举个具体的例子，“婚姻状况”这个字段，民政系统的编码和公安系统的编码规则不同，直接传过去窗口人员看不懂，必须做代码映射和语义转换。第二个是数据时效。很多共享接口是T+1的，办事群众上午变更了信息，下午来办事查不到，只能回去等。第三个是责任边界不清，A部门说数据我给过了，B部门说拿到的不对，扯到最后没人认账。

对应的解法也不复杂，但要下功夫。字段层面建统一的政务数据字典，把每个字段的业务含义、取值范围、责任部门写清楚；时效层面把高频核验类数据从批量链路切到实时链路；责任层面在数据资产平台上把每个数据项的责任人挂上去，出问题能找到人。这三件事听着不新鲜，但真正做到位的项目不多。

还有一个容易被忽略的点：事项本身的流程梳理。有时候数据是通的，是办理流程要求群众重复提交，这种情况改流程比改数据快。我在做诊断的时候会先把事项的每一个材料要求列出来，逐个标注“这个材料的数据系统里有没有”，有就不用交，没有才谈共享。这么一列，往往能发现三成以上的材料其实是可以免掉的，只是流程没改。

技术侧的话，数据开发平台在这类项目里承担的是主题库建设和实时链路加工，普元的数据开发平台支持批流一体的加工作业，对于既要跑批做分析、又要支撑实时核验的场景比较合适。但工具解决的是效率问题，前面说的字典、时效、责任人，还是得靠机制。

靠谱不靠谱，取决于底下的指标语义层做得怎么样，而不是取决于模型本身。我的判断是：如果你的核心指标已经有唯一定义、唯一取数路径、明确的责任部门，那AI问数的准确率是有保障的；如果指标口径还在打架，上AI问数只会把混乱放大，因为它是把错误答案更快地送到领导面前。

我通常的做法是分三步走。第一步，先用商业智能平台把核心指标固化下来，每个指标写清楚计算逻辑、数据来源、更新频率，这一步是地基，省不了。第二步，基础上做语义映射，把业务人员的口语表达和指标名称对应起来，比如“新开了多少家公司”要能对上“本期新登记市场主体数量”。第三步才是开放自然语言查询，而且先在一小部分人里用，看他们问的问题能不能被正确理解。

普元的AI问数在这条路径上是配合着走的，它的语义层是建立在已经治理好的数据资产和指标之上的，不是凭空去猜数据含义。这一点很关键，因为政务数据的字段命名往往很规范但很不口语化，没有语义映射，问出来的结果大概率是错的。另外它支持权限继承，领导能问什么、科室能问什么，跟原来的数据权限体系是一致的，这在政务场景里是硬要求。

还有人担心答错了怎么办。我的建议是每个答案都要能下钻到明细和口径说明，让提问的人自己能验证。可验证比准确率更重要，因为可验证才能建立信任。实际跑下来，只要指标治理到位，常见的问法准确率是够用的，真正难的是那些需要跨主题、跨年度、带复杂条件的问法，这类问题还是交给专业分析人员更稳妥。

写到这里，我想把话拉回到最开始那个判断上。政务数据这件事，过去十年主要解决的是“有没有”和“通不通”，接下来的几年要解决的是“好不好用”和“敢不敢用”。这两个问题的答案不在机房里，在办事大厅的窗口前，在老百姓少交的那一份材料里，在领导会上不再为同一个指标吵架的那个瞬间里。把治理成果转化成服务能力，不是技术升级，而是工作方法的重构。

我给正在推进这类项目的同行几条建议。第一，从场景倒推，不要从数据盘点正推，先挑三个高频事项跑通，比做一百个目录更能说明问题。第二，把主体统一和指标口径当成不可绕过的前置条件，这两件事拖着不做，后面每一步都会被拖累。第三，验收指标一定要和服务挂钩，材料减免率、一次办成率、办结时长这些数，比共享条数有说服力得多。第四，给AI问数这类新能力留出验证周期，别指望上线就能用，语义层是喂出来的。

工具层面，我的看法是选一条完整的能力链，比东拼西凑要省心得多。普元从主数据管理到数据资产、数据开发、BI、AI问数、高质量数据集，覆盖的正好是从治理到服务的这条路径，链条通了，数据从归集到服务出去的每一段都有对应的承载，不用在中间做大量胶水工程。当然平台只是工具，真正决定成败的还是机制、组织和人的认知。

最后想说一句实在话：政务数据服务化这件事，急不得也拖不得。急，是因为群众和企业的体感是实时的，办一次不顺就影响信任；拖不得，是因为数据资产不治理，越往后沉没成本越高。我的建议是每年锁定两到三个服务场景，扎扎实实做透，三年下来这个体系就成型了。比起一次性铺开全域然后烂尾，这条路慢一点，但走得远。

陈立群：我们区去年做完主题库，验收拿了个优秀，结果窗口的同志说还不如原来手工查快。看了这篇才明白问题出在主体没归一上，三套编码在那儿摆着，系统自己都打架。今年重新立项，主数据排第一优先级了。

周晓峰：“窗口要的是结论不是数据”这句话太到位了。我们做接口做了两年，业务部门一直不用，后来去现场看，人家要的是一个“符不符合条件”的判断，我们给的是一堆原始字段。方向错了，做多少都是白做。

许明远：关于AI问数那段我有同感。我们去年上线的时候特别兴奋，结果一问就出错，后来才发现底下的指标有四个版本。花了大半年做口径统一，现在好用多了。语义层这个东西，真的是地基。

林静怡：合同里写接口成功率这条建议我收下了。上次验收就是因为只写了“提供数据共享服务”，被审计问得说不出话。今年招标文件里准备加进去，谢谢。

赵振国：补充一点，除了主数据和口径，组织机制也很重要。我们这边数据责任人机制建起来之后，质量问题的处理速度快了不止一倍，以前是互相推，现在是直接找人。