北京大学人事系统：教工资源“大管家”

2013-09-10欧阳荣彬王倩宜

中国教育网络 2013年4期

文/欧阳荣彬王倩宜

建设目标

人事系统是北京大学电子校务建设中的重要应用之一。旧的人事系统是1 9 9 6年由北京大学计算中心开发的，主要是对学校正式职工从入校到减离全过程的信息进行管理。旧人事系统自运行以来，在一定程度上提高了管理部门的工作效率，并且为学校其他部门和应用提供了大量的人员数据。

然而，随着人事自身管理需求的不断变化，在北京大学电子校务整体建设的大环境下，旧人事系统逐渐显现出诸多不足，主要表现在以下几个方面：

1. 功能不够完善，管理效率不高

近年，人事工作日渐规范，管理流程日渐完善，影响日渐扩大，涉及到的部门和人员也越来越多。而旧人事系统对于新增或变化的各项人事工作支持力度不够，甚至完全不支持，导致很多工作还需要人工完成，工作效率不高，给工作人员和教职员工带来了很多不便。

2. 业务流程无法适应新需求，不利于协同工作

随着人事制度、医疗制度、保险制度的改革，旧系统中有些功能模块已不能适应新需求，业务流程无法满足多个部门科室之间的协同运作。

3. 信息交换和共享困难

日常工作中，人事部经常需要向国家的上级部门及校内其他部门提供教职员工的人事信息，同时也需要从其他部门获取关于教职员工的教学、科研等信息。旧人事系统对其考虑不足，很多信息交换工作只能依靠纸质或者E-ma i l来手动完成，无法保证信息的及时性、准确性和一致性。

4. 缺乏高效自动化的对外公共数据服务

人事部管理并维护着全校所有教职员工的大量信息，经常向各院系人事工作人员和教职员工个人提供一些人事信息查询服务。目前，由于旧人事系统基于C/S架构，对外的数据查询服务都必须由人事部相关工作人员完成，这种方式无疑给工作人员和教职员工都带来了很大不便。

为加强学校人事工作的信息化、规范化、制度化建设，北京大学计算中心联合人事部于2 0 0 7年秋开始建设了新一代的北京大学人事综合信息管理系统。系统以人事管理业务工作为核心，覆盖人事业务的主要工作范畴，面向全校提供实时人事信息服务，同时具有技术先进性和应用灵活性，并且达到如下的具体建设目标：

1. 满足人事管理的基本业务运作，安全、可用、可扩展，能快速适应未来的新需求。

2. 协同工作，提高管理效率。完善和规范化业务流程，支持和上级管理部门、校级其他部门、下级各院系部门及人事部内部各科室之间的协同运作，提高工作效率。

3. 实现人事信息共享。梳理和规范化数据流程，实现各部门及应用系统之间进行安全便捷的数据交换与共享。

4. 合理的多级管理。合理采用部门、院系和教职工个人多级管理模式，既减轻人事部的工作负担，也给院系工作人员和教职工个人带来便利。

5. 为广大教职工提供人事相关的信息服务。

6. 辅助各级管理与决策支持。为各级领导提供决策所需的人事数据，为正确决策提供有力的辅助支持。

新型技术架构和功能特点

技术选型

传统B S模式的管理信息系统是一个多页面系统，用户与系统服务的交互是同步式的。用户每一次提交请求都需要提交整个页面，同时必须等待系统处理完毕且重新载入一个新的页面之后，用户才能继续操作。这不但降低了用户与系统的交互性，同时由于大量冗余数据的传输，浪费了网络带宽，降低了系统性能。

图1 基于互联网应用的管理信息系统逻辑架构

We b 2.0环境下的新型管理信息系统首先应该是积极应用数据库技术和网络技术的互联网应用系统，而且应该是“富互联网应用”（R i c h I n t e r n e t A p p l i c a t i o n s，简称R I A）。它既不是C S的“胖客户端”模式，也不是传统B S的“瘦客户端”模式，应该是“富客户端”模式，如图1所示。富客户端模式的R I A架构是在瘦客户端模式的三层架构基础上，应用A j a x技术，丰富客户端用户界面的展示，增强用户与系统服务之间的交互。介于用户界面与We b服务器之间的A j a x引擎负责异步交互的数据转换，将用户触发的J a v a S c r i p t事件转换成H T T P请求发送至We b服务器；同时将We b服务器反馈回来的X ML数据转换成用户界面所需的H T ML和C S S数据。

R I A架构的最大特征是异步式交互。完成这一步骤的主要对象是X ML H t t p R e q u e s t，该请求对象具有同步和异步两种模式，只要在通过X ML H t t p R e q u e s t发送请求的时候将其设置成异步模式，并且设置回调函数，如此即可以完成异步式交互。A j a x引擎集成了X ML H t t p R e q u e s t对象，并且默认是异步模式。

正是由于异步式交互的引入，R I A架构抛弃原来瘦客户端模式的多页面形式，即不需要每次用户与系统服务交互完成之后都重新载入一个新的页面，而是吸收原来桌面应用的用户交互方面的优势，采用单页面形式。单页面形式并不是指整个应用系统就只是一个页面，而是指将原来多个页面的内容集中在一个页面中丰富地向用户展示，同时每次用户与系统服务之间的交互完成之后，只是更新页面中的一部分内容，而且这种更新是异步式的，用户不需要等待上一个交互完成之后就可以继续下一个交互——如果这两个交互之间没有逻辑上的先后关系。

在异步式交互过程中传输的数据只是一些关键和必要的数据，因此系统服务接口部分的处理需要对数据进行转换。除了接收A j a x引擎发送的请求关键数据之外，还需要将系统服务处理结果以X ML形式反馈给客户端，除X ML以外，J S O N（J a v a S c r i p t O b j e c t N o t a t i o n）也是一种被广泛使用的数据格式。

基于A j a x的特性和用户对系统易用性的强烈要求，北京大学计算中心通过技术调研，决定应用新型的R I A架构建设新的人事系统，并且具体选取了E x t J S框架作为系统前台展示的技术平台，“北京大学人事综合信息管理系统”是北大电子校务环境中第一个应用R I A架构的系统。

新的技术架构的应用，以及友好的界面设计，极大地提升了用户的交互体验。

首先，系统在设计上尽量简化用户操作，提高界面的友好型，将不具有业务逻辑先后关系的操作合理有效地安排在同一个界面中，如此用户在日常工作中可以在一个界面中同时完成多项业务操作，不需要同时打开多个浏览器页面操作。

其次，充分应用R I A架构的异步交互特征，在设计中将不具有业务逻辑先后关系的操作合理有效地安排在同一个界面中，因此，每完成一步都不要等待页面刷新即可进行下一步的操作，如同操作桌面应用程序那般简便快捷。

再者，系统的用户界面在与后台交互的数据传输中，都是极其关键和必要的数据，尽量避免冗余的数据传输，较大提高了数据传输效率，使得用户的操作能够得到快速的响应，提升了用户的交互体验。

分层模型实现全方位协同工作

新的人事系统采用如图2所示的分层模型，各层独立完成相关功能，并与相邻层之间发生交互。

1. 业务层，系统主要是实现和完善人事部内部各办公室的业务，实现与各院系等二级部门的业务交互，实现和发布对广大师生提供的各种公共服务。业务层除了与交换层交互以外，还会直接与数据层进行交互，这些交互是不涉及到数据交换的交互业务，绝大多数是某办公室内部的单项业务。

2. 交换层，首先实现人事部内部各办公室业务流程之间的数据交换，其次为了完善人事部业务和对外服务，系统需要建立和完善与其他相关部门的数据交换和共享。同时由于一些在可以预见的一个阶段内必须使用的系统的存在，因此需要建设和实现本系统与这些系统的相关数据转换接口。

图2 分层模型

3. 数据层，主要是人事部门负责管理和维护的人员基本数据、人事部各办公室在业务处理流程中产生的人事业务数据和各类非结构化数据文档。

基于这样的分层模型，“北京大学人事综合信息管理系统”实现了多层级全方位的数据共享和协同工作。

首先是人事部内部各科室之间的协同工作。虽然不同科室之间能够实时共享数据库中人员信息，但是业务操作之间的协同工作则是通过系统设计采用请求和工作单的模式实现。例如，新聘教职工在规划调配科完成入校手续之后，直接可以在系统中向劳资科发送起薪请求，劳资科依据此请求和规划调配科更新的人员基本信息完成起薪操作。

其次是广大教职工、各院系和人事部之间的协同工作，这类协同工作通常情况下是通过设计合理的工作流完成。例如专业技术职务聘任工作，首先由教职工发起申请，院系进行初审，人事部审批、聘任并调整薪酬。

再者是校内不同业务部门之间的协同工作。前面两类协同工作都是人事系统内部的协同工作，而校内不同业务部门之间的协同工作则是不同应用系统之间的协同工作。由于不同的应用系统有可能是基于不同的技术平台建设，因此这类协同工作需要通过跨平台的服务接口（We b S e r v i c e）实现。例如，人事部于财务部之间有关薪酬发放的协同工作。

图3 薪酬管理子系统功能

最后是学校与其他管理部门的协同工作。这类协同工作如同前面第三类一样，也是应用系统之间的系统工作，但是从行政划分上，是北京大学与其他管理部门的数据共享和协同工作。例如有关博士后的进站和出站等管理工作，就涉及到北京大学和国家博士后管理办公室之间的协同工作。具备灵活的可扩展性

“北京大学人事综合信息管理系统”同时还具有灵活的可扩展性，这一点在薪酬管理子系统中体现得尤为明显。

薪酬管理子系统是人事综合信息系统中最复杂的核心子系统，其功能主要是对各类职工的工资、津贴和劳动报酬进行统一管理，该子系统与整个人事综合信息系统的多个子系统都有复杂接口。系统的设计目标是严格控制数据管理界限和权限，保证数据安全；提供灵活机动的设计，管理人员可以通过自行配置和修改满足不断变化的管理要求，易于维护。图3描述了薪酬管理子系统的功能模块，主要包括薪酬项目管理、工作请求管理、制单与审核管理、发放管理。

这种设计将薪酬项目定义和薪酬标准、薪酬项目和个人薪酬、个人薪酬项和发放异动区、个人薪酬标准和薪酬发放都区分开来。如此，任何一个环节的变化都能够独立完成，也都能够对关联的部分产生必要的影响。

例如，个人请假或者出境引起的薪酬变化只体现在发放异动中，个人的薪酬标准没有变化，而有了发放异动则自然会体现在最终的当月薪酬发放中，发放完成之后发放异动自动失效。如果不采用发放异动的设计，每次出现这样的情况都需要修改个人的薪酬项目值，在发放完成之后再恢复，如此过于繁琐且容易出现失误。

人事系统目前管理的薪酬项目超过1 1 0项，其中需要考勤的项目大约有1 0项，系统在计算考勤发放时直接依据个人是否有考勤项目和缺勤天数进行计算，而单位报考勤时无需关注哪个项目需要扣发，只是汇总缺勤天数即可。如果需要调整考勤项目的组成，劳资科业务操作员直接修改项目的定义即可，即便在此时单位也无需关注哪个项目进行了调整。如果不采用单独的项目定义，那么类似这样的调整，单位需要关注每一个人每一次的项目调整，无疑会增加用户的工作量，降低工作效率。