面向服務一體化的網上辦事平臺①

張國寶,吳 凱,楊 莉

1(河海大學 網絡安全與信息化辦公室,南京 210008)

2(河海大學 計算機與信息學院,南京 210008)

《教育信息化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所示,線上的部分是服務事項的申請和辦理,參與者是需要辦理事項的普通師生、服務事項辦理的各類工作人員以及技術人員;線下的部分包括位于不同校區的現場集中的服務大廳、自助打印設備、物流自助設備、現場用戶咨詢等,參與者是現場服務辦理和咨詢人員.融合辦事大廳體系覆蓋多校區、融合線上和線下、面向師生用戶提供統一、全過程的辦事服務.

圖1 線上線下融合辦事大廳體系模型

2 一體化服務流程建模

定義1.面向一體化業務流程的工作流業務模型可以表示為一個四元組,Model=＜Data,Roles,Flow,Business＞,其中,Data 表示業務模型對應的數據集,Roles 表示業務對象涉及的相關人員角色集,Flow 表示業務模型對應的流程,Business 表示業務模型提供用戶的表單界面,通過抽象和封裝,實現一個工作流業務模型對應一個具體的網上服務流程.文獻[14]類似提出了一種面向服務的工作流設計模型,包括人員信息、服務信息、結構信息3 個要素.

2.1 統一數據模型Data

數據模型是信息通過線上進行流轉的基本對象單元,實現多校區一體化的設計首先要在數據模型上采用統一的數據標準,例如數據標準中的樓宇、教室、設備、學生、教職工、課程等,通過引入校區的數據標準屬性,實現基本的資源要素對象,關聯實現資源要素數據的多校區可識別.數據的校區屬性的引用表示如圖2.

圖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]提出一種基于工作流模式的流程語言來表示工作流的業務需求,實現工作流程建模的規范性.

圖3 工作流元素建模圖示

2.4 統一用戶表單Business

對某一個服務而言,用戶交互或操作時可見的是服務用戶的表單,即業務服務用戶操作界面.業務界面對應于某一具體業務服務,提供用戶填報必需數據、獲知服務內容、提交下一環節、打印、退回等操作功能,提供了一個“完整”的、與業務數據模型關聯的用戶側界面展示,用戶表單對應工作流模型中的不同環節節點,根據各節點對應的統一授權人員,可有權限進行表單中授權操作的字段和區域,實現用戶操作表單的權限控制,從而實現了業務服務在不同節點的用戶界面的“差異化”.

3 服務平臺的技術實現

3.1 分層體系設計

文獻[5]提出了一種“一站式網上辦事大廳的層次體系結構”,服務構建、服務封裝、數據管理和消息服務.文獻[6]提出微服務概念下的一站式辦事大廳系統設計架構.本文的服務平臺體系采用類似的分層體系設計,如圖4所示.平臺基于面向服務的分層體系設計,能夠實現較好的功能方面的擴展性.其中流程服務層就是實現一體化服務流程建模的主要功能組件層.

圖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 類三元組角色,其綁定不同分支節點實現節點審核和表單訪問的權限控制,通過不同校區管理員實現與線下場景的銜接,滿足多校區場景需求和不同申請用途的教室借用申請.

圖5 教室借用申請流程邏輯設計

教室借用申請服務是較為典型的包括多個校區的一體化使用,同時也涉及線上和線下相結合的業務,覆蓋面廣,使用較為頻繁.該服務的運行數據如下:共計服務13 719 次,服務次數界面和服務使用數據如圖6所示.其中2019年6月以來完成受理借用申請7298次,按照申請對象和活動用途分析如表1所示.

表1 教室借用服務申請分析

圖6 教室借用服務記錄和次數統計

6 總結

面向服務一體化網上辦事平臺,在分層的面向服務平臺架構(Service-Oriented Architecture,SOA)下,進行一體化建模和面向服務的交互設計,遵循敏捷化原則、服務閉環原則實現快速交付,滿足師生多校區、多業務系統的辦事服務的需要.特別是平臺能夠與業務系統服務規范融合,從而更好發揮網上辦事服務平臺的服務師生用戶功能,有助于提升師生對校園信息服務的滿意度和獲得感.