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

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

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

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

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

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

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

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

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

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

　　具备灵活的可扩展性

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

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

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

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

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