“一窗通办”新型政务受理系统设计与实现

文｜ 滨州市大数据应用中心 姚志新；滨州市人力资源和社会保障局 姜伟；滨州市政务服务管理办公室 王河山；滨州市公安局 颜立强

一、引言

本文首先分析了传统政务服务模式和“一窗通办”政务受理系统的优缺点，指出构建“一窗通办”的核心和关键，即打破解决窗口收件与部门业务办理系统之间的数据壁垒，实现数据的互联互通。然后以滨州市政务服务中心为研究对象，在对中心业务现状和实际需求充分调研的基础上，进行了“一窗通办”政务受理系统的设计与建设，并在传统单事项多岗位受理的基础上跨前一步，实现了“ 一窗通办”，显著提升了群众的获得感和满意度。

二、研究背景及意义

1.传统“部门专窗”模式的缺陷

随着改革的不断深入，根据“三集中三到位”的要求，各地方政府均先后设立了政务服务中心，将辖区内原本分散在各部门窗口的审批事项、服务事项归集到了一起，初步实现了“一站式”部门专窗服务，在一定程度上缓解了群众办事难的情况。然而，在实践过程中，专窗服务模式依然暴露出不少问题。

（1）窗口排队时间差异化极大，不利于行政资源的合理配置

通常，行政服务中心的办事窗口数量均在几十甚至上百个。但由于事项热门程度不一，而特定事项只能在主管部门甚至主管部门的特定窗口才能办理。

（2）收办件信息无法直接流转，需要依赖二次录入

目前，各地区的政务服务中心，都已基本建有中心的收件平台。但由于大部分审批事项和服务事项，均需要依托部门自建业务系统完成审批流转，而中心的收件平台与各部门业务系统之间存在数据壁垒，中心的工作人员需要在部门业务系统中进行二次录入，极大的增加了工作量，也在一定程度上降低了政务服务的效率。

（3）各部门间存在信息孤岛，主题事项需要跑多次

调研发现，入驻政务服务中心的部门数量一般在20-30 个左右，基本涵盖了与企业办事、个人办事相关的各业务部门。但各业务部门之间的信息各自独立，没有实现数据和材料的共享与复用。

（4）中心无法沉淀有效数据，辅助决策能力不强

由于大部分办件都是依托各部门的业务系统，中心系统只负责登记收件，办件的节点、环节信息等数据，并不推送到中心系统中。缺乏这些必要的数据支撑，中心不能对这些数据进行综合运用和可视化分析，无法为社会公众提供更精准、智能、高效的政务服务。

2.“一窗通办”新型政务受理系统的优势

考虑到系统的共性，本文以滨州市政务服务中心为例，探讨中心的“一窗通办”政务受理系统以及智能数据交换平台的设计与实现。与传统的数据交换模式相比，“一窗通办”新型政务受理系统的智能数据交换具有以下特点和应用价值：

（1）数据接口服务化，能够高效快速打通应用边界

政府各部门之间的信息系统由于建设时间和承建单位的差异，互相孤立，存在较为严重的信息孤岛现象。数据交换渠道的不畅，极大地影响了政府部门对政务资源的利用率。

（2）无须开放源系统，确保数据的安全性

在传统数据交换模式中想要实现对现有各应用系统的数据提取，就需要开放数据字典、系统源代码等，存在数据安全方面的风险问题，这也是各部门特别顾虑的问题。而智能交换平台则基于表现层提取数据，完全屏蔽了应用系统业务逻辑层与数据层的差异性。仅以普通用户访问的形式即可实现数据获取，且完全遵循原系统的数据交互模式，确保了数据的安全性。

（3）解除开发商锁定，降低人力与沟通协调成本

传统模式的开发中，需要从在用的应用系统中获取数据，不可避免地存在多个归属责任部门/单位及相应的开发商之间协调沟通的困境。而智能数据交换技术，无需各系统提供深层次、复杂的配合，因此在协调、沟通方面人力成本与时间成本都大大降低，使原本令人头疼的多系统数据获取工作变得简单易行。

三、总体设计及关键技术

1.“一窗通办”政务受理流程设计

“一窗通办”政务服务模式，采用“综合窗口统一受理，后台分工协作”的新型业务模型，设立统一的窗口受理界面，并通过与人口库、法人库等基础数据库的信息共享和快速调用，能够为法人和个人提供统一的对外服务。

“一窗通办”政务受理，对于不同的办件类型有不同的业务流程，具体可分为即办件和承诺件。

（1）即办件

对于即办件事项，申请人在综合窗口提出申请，窗口人员通过业务知识库，核对相关材料要件后当场办结，并将办理结果信息推送到部门业务系统。具体业务流程如图1所示。

（2）承诺件

承诺件是指根据政策文件要求，无法现场完成办理的事项。申请人在综合窗口提出申请后，窗口人员在统一受理平台中进行信息录入。通过智能数据交换，录入的信息流转到部门业务系统进行办理。在完成办理后，部门将办理结果信息推送到受理平台，并由平台将业务办结信息推送给公众。具体流程如图2所示。

2.总体框架设计

针对系统的所有功能和非功能需求，进行总体框架设计，系统自下而上分为基础设施层、数据层、平台层、应用层、访问层五个主要部分。图3为本系统的总体框架设计图。

基础设施层：主要包括电子政务网络、服务器和安全等硬件基础设施。

图1 即办件办理流程

图2 承诺件办理流程

图3 总体框架设计图

数据层：指中心自建的法人库、人员库、电子证照库等基础数据库。

平台层：通过数据接口服务平台对各类政务应用提供各种通用化的服务，既有效简化应用系统的设计和实现，避免了重复投资，又规范了各独立系统的建设，使之更容易进行集成和整合。

应用层：围绕政务服务中心“一窗通办”政务改革的总体目标，开发建设包括综合受理、查询反馈、智能提醒、窗口配置、绩效考评等功能模块的“一窗通办”政务受理系统，并通过数据接口服务平台实现与市、区各类异构系统的数据交互。

访问层：系统及与系统相关的用户对象包括企业法人、窗口人员、部门审批人员、中心管理人员等。

3.关键技术：智能数据交换平台

考虑到数据交换的必要性以及不同业务系统与中心数据对接的工作量极大，本系统中的智能数据交换平台，没有采用传统的Web Service 接口模式。而是基于DaaS（数据即服务）技术，无须侵入原系统，只需访问业务系统的表现层，即可重建出业务系统的数据接口。通过此技术，能够快速生成需要与“一窗通办”政务受理系统对接的信息系统的数据接口,从而在无需协调源系统开发商，不改变原部门业务系统工作人员办件习惯的前提下，通过对接口服务的调用，实现受理数据的分发和审批环节数据的获取等，实现跨部门跨系统的数据对接。

智能数据交换平台的数据接口生成后，提供给新应用调用时，不破坏原系统访问方式，对原系统而言，和真实的用户访问行为无差异。其主要由API 生成平台，API运行平台和API 管理平台三部分组成。总体逻辑架构如图4所示。

数据接口（API）生成平台：生成平台包含云仓库、云编译、云部署等主要功能，能够为每个项目组分配用户空间，各个用户空间之间互不影响，存储仓库、编译环境等都在用户空间中完成，编译后API 可以自动通过生成平台部署发布在云端测试环境，并完成云端测试、封装、打包。

数据接口（API）运行平台：运行平台为生成平台建模生成的API 资源包提供运行环境，同时提供配套服务，如安全机制、缓存机制、访问控制等。

数据接口（API）管理平台：管理平台负责API 运行时的监管服务，提供API运行生命周期管理功能，并可以对API 运行的健康状态进行监控，以便及时采用应对措施避免或者减少异常情况带来的损失。管理平台能够对用户访问进行控制，阻止恶意用户或者未授权用户访问。用户行为的审计和分析统计的工作也由管理平台来完成。

4.数据流向设计

平台的数据流向由接口分析生成、接口运行、接口管理依次进行。具体对于某个应用系统来说，先按照应用系统的访问方式访问应用系统，根据内存镜像分析捕获用户的操作行为。通过程序理解（包括内存变量分析、源代码分析、字节码分析、界面截图快照分析等），并综合网页DOM树分析，行为模式学习，特征分析提取，相应的数据流向分析，操作指向节点分析等，学习理解为可重放的API 模型配置。

数据接口可以通过数据接口管理平台自动部署上线，并进行运行周期管理，对用户进行授权管理、访问控制、监控运行及访问状态，审计数据接口访问情况，并可以将监控和审计状况生成数据报表等。整个数据流向如图5所示。

5.与传统技术对比分析

与传统对接技术相比，本系统中采用的智能数据交换方式，在灵活性、安全性等方面均有较大的优势。（1）与WEB Service 对接技术对比

图4 智能数据交换平台总体逻辑架构

图5 平台数据流向

针对孤岛式Web 系统，StanfordUniversity和MIT 学者在顶级学术会议CHI 上提出Webzeitgeist，在代理上部署浏览器内核来渲染Web 网页，再用爬虫抓取进行离线分析，这种方式难以做到实时、动态和可定制，效率较低，扩展性差，数据语义可能不完整、不一致，目前该技术不具备商用性。

针对孤岛化移动App，Google 的App Indexing 和Facebook 的App Links，都需要开发者主动将应用内数据以某种格式暴露出来，工程量大、可行性差。

（2）与网络爬虫技术对比

与网络爬虫技术对比，智能数据交换技术具备以下优势：

实时性：智能数据对接平台可通过接口实时获取数据，而爬虫技术普遍采用定期获取数据，不能保障数据实时性。

开放性：智能数据对接平台不需要用户提供数据库或者让原系统方提供接口，只需要通过原系统的访问方式就能获取内网和外网中BS、AS、CS、flash 等不同类型系统中的业务数据。而爬虫技术一旦遇到需要账号的系统就很难获取到业务数据，也不支持AS、CS、flash 等类型的业务数据。

可交互性：智能数据对接平台所开采的数据以程序接口的方式进行供给，从而使程序化的系统集成、数据处理和展现成为可能。不仅可以进行读，而且也可以进行实时地写入。而爬虫技术无法完成写入等交互操作。

完整性：即便原始系统结构复杂、数据经过加密、数据动态生成，或是数据存在于不同账号或多个不同系统中，智能数据对接平台也能完整地获取对应系统所能呈现的全部业务数据。而爬虫技术一旦遇到复杂的系统，获取的数据就极有可能不是完整的业务数据并且有可能获取的数据是错误的。

（3）与导库（ETL）技术对比

与导库技术对比，智能数据交换技术具备以下优势：

数据导库技术很难实现高效、高质、低风险、低成本的信息孤岛数据开放共享。

导库技术需要提供数据库的权限，这点对于数据拥有者还是源系统开发商来说都是很难协调的，尤其是对于垂直系统，下级单位更是无法获得数据库的权限。

导库技术需要技术人员对源系统数据库的流程、字典等情况要非常熟悉，对项目实施周期影响较大。

导库技术起到的是底层数据的获取，但是无法做到业务的交互和写入，比如A系统的数据写进到B 系统中，或者将A 和B 系统的数据写入到C 系统中。

四、建设成效及未来展望

1.建设成效

2018年8 月，滨州市政务服务中心正式启用，进驻的54 个部门、394 项事项按事项类别划分为商事服务、不动产登记、投资建设项目等10 个服务板块，并按链式办理流程科学设置206 个服务窗口。在功能区设置和设备配置上也较原审批中心有了极大提升，实现了事项办理的“一厅办”“一窗办”“一网办”“一链办”。运行一年来，市政务服务中心共接待办事群众81.4 万人次，办件26.39 万件；日均接待2230 人次，日均办件723 件。

（1）削峰填谷，高频事项“立等可办”

通过“前台统一受理、后台分类审批、统一证照管理、统一区域出件”的“一窗通办”服务模式，滨州市政务服务中心对窗口资源进行了合理配置，与传统模式相比，高频事项的等待时间可缩短一半以上，真正实现了“立等可办”。

（2）部门协同，主题事项“一链办理”

目前，滨州市已在企业商事登记领域、个人公积金提取、个人过户（电、暖、气、有线电视综合受理）等方面，进行了业务流程和材料的多情形精细化拆分梳理，实现了主题事项的跨部门协同“一链办理”。如公积金提取业务，通过优化流程，12 项分类中的11 项情形可“一次办结”，一次办结率91.67%，办件量占比达99.74%。

（3）可管可控，政务数据“全息监管”

依托智能数据交换平台，滨州市政务服务中心可自动获取国家级、省级统建业务系统中的节点信息和环节信息，并通过可视化展示，辅助领导和管理人员对事项进行全生命周期的监管，及时督查督办，不断提升政务服务能级。通过对各窗口办件时长、等待时长、办件数量等进行综合分析，不断优化窗口设置，综合服务效率提高62.5%。

2.未来展望

由于“一窗通办”政务受理系统目前尚处于起步摸索阶段，在试运行期间发现了一些考虑不周的地方。诸如，在推广“一窗式”改革时，缺乏与一线窗口人员足够的沟通，在收件时对行政审查要点的梳理不够精细化；在业务知识库的检索方面未能实现语义逻辑关联查找，削弱了知识库的辅助作用等。上述这些问题的发现，为系统今后的升级拓展方向提供了借鉴和参考。