《教育信息化2.0行动计划》^[1], 提出分步实施教育政务数据的共享开放, 做到事项清单标准化、办事指南规范化、审查工作细则化和业务办理协同化, 实现“一张表管理”和“一站式服务”, 切实让百姓少跑腿、数据多跑路, 增强人民群众获得感.

网上办事大厅、服务流程平台在很多高校都已建设, 并发挥了实效^[2,3]. 例如复旦大学2015年上线的网上办事大厅, 通过服务“碎片化”、管理“平台化”、数据“集中化”, 再造业务流程、创新服务模式, 打造“一站式”在线服务. 浙江大学实施的网上办事大厅和与之配套的“三张清单”制度在高校的网上办事大厅建设方面具有很好示范作用.

在高校的“双一流”建设中, 面临着多校区办学, 资源被物理空间分隔的现实情况, 影响制约了高校网上服务办理和体验. 在已有的网上办事大厅相关方面的期刊文献中, 林华治等人^[4]在2012年提出基于BPM(Business Process Management)平台构建网上办事大厅的建设设想, 并且在浙江大学树人学院进行了探索. 王宣琳等人^[5]结合华南农业大学的实际案例提出了一个网上办事大厅的层次结构体系, 取得了实际成效. 丁洁^[6]提出了高职院校基于微服务架构的一站式办事大厅的建设系统架构, 实现公文发文申请办理. 王怡丹等人^[7]从网上办事大厅的背景、功能定位和实现策略等给出了建设网上办事大厅的思路和关键点. 范小春等人^[8]以金陵科技学院为例提出构建基于流程引擎的高校一站式网上服务体系. 张颖^[9]初步的提出设计基于大数据的“一站式”服务模型, 破解跨部门业务流程打通难题.

然而, 随着网上办事大厅的建设的深入, 面临流程服务如何与多校区的管理相适应的问题越发突出, 这些问题还有待进一步思考并形成共识:

(1) 网上办事大厅与业务系统的功能边界如何划分和定位, 未来需进行融合发展有效治理.

(2) 一体化背景下的多校区的服务流程应怎样设计, 符合校区办学和管理的需要.

本文围绕网上办事大厅的建设, 结合实际案例实践, 就如何服务一体化背景下的网上办事, 提出满足多校区一体化背景下服务大厅建设的平台化体系设计, 分析提炼了一体化服务设计模型、要素、步骤、用户交互服务模型设计和理念, 最后给出了实际服务建设运行效果.

1 多校区一体化办事服务平台需求 1.1 一体化办事服务的管理需求

多校区一体化办事服务平台要能够实现多校区资源要素整合, 提供资源要素的集中优化配置, 发挥资源集中优势, 为实现资源的集约利用、提升内部治理效能提供前提条件.

多校区一体化办事服务平台是管理职能和管理方式从管理为主向服务为主转变的需要, 从师生用户到多个不同职能部门进行事项审批办理, 转变为到师生用户到统一的事务办理大厅进行所有事项全过程办理.

多校区一体化办事服务平台是实现师生用户的一致性办事服务体验, 增强师生的信息化满意度和获得感的重要途径. 通过办事服务平台, 实现不同校区之间、不同部门之间的事务服务的线上联通, 消除部门之间、校区之间、线上和线下的阻隔. 让办事服务从单一型向全场景、全业务、全过程转变.

1.2 多校区一体化办事服务平台概述

多校区一体化办事服务平台基于工作流引擎平台进行构建是业内共识. 工作流建模技术主流包括11种, 陈广智等人进行了梳理和分类^[10]. 林佳等人^[11]提出传统的工作流的建模技术是面向过程的建模技术, 基于ECA (Event-Condition-Action)、业务流程建模语言(Business Process Execution Language, BPEL)、另一种工作流语言(Yet Another Workflow Language, YAWL)都是面向过程的建模技术, 同时列出了以对象和数据为中心的其他文献建模方法.

工作流即服务(workflow as a service)^[12]是一种能适应于云计算的工作流中间件技术, 可以获得更好的扩展弹性和利于共享, 实现工作流与面向服务架构的无缝融合. 文献[13]提出面向服务架构的基于JBPM(Java Business Process Management)和Spring MVC框架组合的工作流管理系统, 实现组织内各类信息统一集成平台.

多校区一体化办事服务平台以事项办理为主线, 融合线上和线下的两个场景, 面向师生用户提供各类校园事项服务. 其总体模型如图1所示, 线上的部分是服务事项的申请和办理, 参与者是需要办理事项的普通师生、服务事项办理的各类工作人员以及技术人员; 线下的部分包括位于不同校区的现场集中的服务大厅、自助打印设备、物流自助设备、现场用户咨询等, 参与者是现场服务办理和咨询人员. 融合办事大厅体系覆盖多校区、融合线上和线下、面向师生用户提供统一、全过程的办事服务.

2 一体化服务流程建模

定义1. 面向一体化业务流程的工作流业务模型可以表示为一个四元组, Model=<Data, Roles, Flow, Business>, 其中, Data表示业务模型对应的数据集, Roles表示业务对象涉及的相关人员角色集, Flow表示业务模型对应的流程, Business表示业务模型提供用户的表单界面, 通过抽象和封装, 实现一个工作流业务模型对应一个具体的网上服务流程. 文献[14]类似提出了一种面向服务的工作流设计模型, 包括人员信息、服务信息、结构信息3个要素.

2.1 统一数据模型Data

数据模型是信息通过线上进行流转的基本对象单元, 实现多校区一体化的设计首先要在数据模型上采用统一的数据标准, 例如数据标准中的楼宇、教室、设备、学生、教职工、课程等, 通过引入校区的数据标准属性, 实现基本的资源要素对象, 关联实现资源要素数据的多校区可识别. 数据的校区属性的引用表示如图2.

2.2 统一人员权限Roles

人员角色集Roles是对应关联流程模型各环节的人员岗位分组; 即Roles={Posti, i=1 to n}每个角色集可以被看作一个权限三元组Triple, Triple=<U人员、D部门、P岗位>, 表示哪个部门的哪些人具有该岗位的权限, 通过权限三元组实现岗位和流程节点的绑定, 从而实现人员访问的授权, 在人员角色集的三元组权限中覆盖多校区属性, 从而支持跨校区的权限融合. 其中权限三元组OccupyTriple的结构定义如下:

OccupyTriple:{

"account": {string}, // not null, 账号

"postCode": {string}, // not null, 岗位编码

"deptCode": {string}, // not null, 人员部门编码

"userCode": {string}, // nullable, 人员身份

"timestamp": {long},

"disabled": {boolean}

}

2.3 统一流程设计Flow

BPMN (Business Process Model and Notation)是通用的工作流建模语言, 模型驱动是工作流建模的主要方法之一. 文献[15]定义BPMN2.0模型对象为一个四元组<活动, 网关, 事件, 流向>, 本文参考其采用通用工作流语言BPMN进行流程设计建模, 其主要元素事件、活动、网关、流向的图例表示及教室申请的流图举例如图3所示. 文献[16]描述面向服务工作流过程模型为活动、流和消息的集合. 文献[17]通过模型驱动方法实现云环境下BPMN规范、转换和执行的工作流模型弹性. 文献[18]提出一种基于工作流模式的流程语言来表示工作流的业务需求, 实现工作流程建模的规范性.

2.4 统一用户表单Business

对某一个服务而言, 用户交互或操作时可见的是服务用户的表单, 即业务服务用户操作界面. 业务界面对应于某一具体业务服务, 提供用户填报必需数据、获知服务内容、提交下一环节、打印、退回等操作功能, 提供了一个“完整”的、与业务数据模型关联的用户侧界面展示, 用户表单对应工作流模型中的不同环节节点, 根据各节点对应的统一授权人员, 可有权限进行表单中授权操作的字段和区域, 实现用户操作表单的权限控制, 从而实现了业务服务在不同节点的用户界面的“差异化”.

3 服务平台的技术实现 3.1 分层体系设计

文献[5]提出了一种“一站式网上办事大厅的层次体系结构”, 服务构建、服务封装、数据管理和消息服务. 文献[6]提出微服务概念下的一站式办事大厅系统设计架构. 本文的服务平台体系采用类似的分层体系设计, 如图4所示. 平台基于面向服务的分层体系设计, 能够实现较好的功能方面的扩展性. 其中流程服务层就是实现一体化服务流程建模的主要功能组件层.

用户层: 用户访问服务的场景, 包括用户使用的终端设备, 以及具体使用手机端的APP、微信、手机浏览器等, 还包括线下的自助打印、物流设备等.

服务展示层: 服务平台的用户界面, 提供用户方便的服务的检索、分类查找, 服务办理进度以及待办事项的查阅.

流程服务层: 构建服务平台的各个组件包括工作流设计组件、三元组角色权限控制、服务的表单编辑器、服务字段数据绑定、服务业务数据模型.

数据持久化层: 包括平台本地化的存储数据和集成共享数据的接口数据.

3.2 平台部署环境

服务平台的部署环境基于虚拟化云资源构建, 部署Linux CentOS6 和Windows 2008服务器环境, 配置2台数据库MySQL节点、1台流程引擎节点、1台消息节点、1台服务API节点、1台授权配置节点、1台办事服务平台节点.

4 服务的用户交互设计 4.1 面向用户服务设计要素

面向用户的服务设计, 应当突出服务用户的功能属性, 一般而言可以有4部分组成, 即服务名称、服务描述(办理指南)、服务办理、服务评价.

服务名称是在服务发布平台上显示该服务的准确名字, 一般是以“xx服务申请”、“xx办理”等用户直观明了的名称; 服务描述(办理指南)是指该服务使用时的注意事项、发布部门、咨询电话以及服务受理材料等需要用户办理前知晓的内容, 通过办理指南文字加以说明; 服务办理过程即服务的具体使用方式和内容呈现, 如在线提交申请的表单页面及后续步骤. 服务评价是服务完成后用户可以对服务进行评价反馈, 可以依据服务评价进行服务质量比较和服务完善. 通过设计可以规范化面向用户的服务属性, 也可便于后续的服务评估.

4.2 服务的分类维度

为了提升用户获取和使用服务的办理体验, 可以对服务进行多维度的分类, 方便用户检索平台上已经发布的服务, 一般而言, 分类维度有: 服务类别、服务场景、服务对象、服务部门等. 具体内容是:

服务类别, 按照校园业务领域进行服务分类, 可划分为人事服务、财务服务、资产服务、教务服务等; 服务场景, 按照服务的办理方式进行分类, 可划分为查询类、申请类、自助打印类、预约类、咨询类等; 服务对象, 按照服务面向校园的各类人员进行服务对象的划分, 可划分为教职工、学生、留学生、访客等; 服务部门, 是服务的归属或责任业务部门也是服务的受理部门, 一般有人事处、教务处、后勤处、网信办等; 一般而言, 服务维度可以根据实际需要设计, 可以是上述一个或几个维度的组合. 以上服务划分维度是面向用户的服务设计要素的延伸, 主要目的是为了用户获取服务更加方便, 平台进行服务的管理更加高效, 也能够有利于服务的优化和迭代.

4.3 服务的一体化设计原则

服务的一体化设计, 是指以服务的闭环为特征、以服务用户的满意度为目标进行服务设计的原则. 闭环设计原则主要考虑3个方面因素,

线上线下闭环原则: 线上与线下是一个服务的两个部分, 因办理服务不同而有所区别. 服务的闭环思想即实现服务的全过程完成, 通过线上服务与线下的物流信息衔接、自助服务衔接、物理位置设备衔接, 既能从线上跟踪线下, 又能从线下追溯到线上, 实现服务的全过程跟踪和闭环设计, 服务外再无可办.

服务敏捷交付原则: 服务敏捷交付包括敏捷化服务设计、规范化服务实施. 可以快速满足业务服务场景, 并且最小化影响或调整现有系统, 从而实现快速支撑业务需求的目的. 一体化服务流程模型是包括上述4个方面即数据、权限、流程、表单的一体化建模. 通过一体化建模能够快速构建和设计业务服务流程. 设计过程可参考文献[19], 一个服务流程的敏捷化开发步骤可以分为如下6个步骤, 即服务流程提出、服务流程设计、服务流程评估、服务流程实施、服务流程优化、服务流程交付.

服务规范融合原则: 基于校园存在多异构业务系统及服务不规范的情况, 服务规范融合是解决这一问题的有效途径. 一方面是办事服务平台依据规范化服务维度进行服务的管理和发布, 二是对业务系统的服务进行统一规范的服务集成和服务封装后, 在统一的服务平台上为用户提供使用, 平台融合异构的用户服务, 提供较为一致的服务使用体验.

5 应用成效与分析

论文依托项目案例部署一体化办事服务平台, 已完成了39个在线服务流程(包括教室借用申请服务)的运行上线. 以教室借用申请服务为例, 通过一体化数据建模和表单设计, 实现覆盖不同使用场景的申请表, 包括申请人基本信息、申请人类型、申请用途、申请使用时间段(通过课表数据接口获取空闲教室信息), 申请流程的逻辑如图5所示, 如图中背景填充矩形表示有9类三元组角色, 其绑定不同分支节点实现节点审核和表单访问的权限控制, 通过不同校区管理员实现与线下场景的衔接, 满足多校区场景需求和不同申请用途的教室借用申请.

教室借用申请服务是较为典型的包括多个校区的一体化使用, 同时也涉及线上和线下相结合的业务, 覆盖面广, 使用较为频繁. 该服务的运行数据如下: 共计服务13719次, 服务次数界面和服务使用数据如图6所示. 其中2019年6月以来完成受理借用申请7298次, 按照申请对象和活动用途分析如表1所示.

6 总结

面向服务一体化网上办事平台, 在分层的面向服务平台架构(Service-Oriented Architecture, SOA)下, 进行一体化建模和面向服务的交互设计, 遵循敏捷化原则、服务闭环原则实现快速交付, 满足师生多校区、多业务系统的办事服务的需要. 特别是平台能够与业务系统服务规范融合, 从而更好发挥网上办事服务平台的服务师生用户功能, 有助于提升师生对校园信息服务的满意度和获得感.