高校人员身份数据治理研究与实践-中国教育和科研计算机网CERNET

资讯

校园信息化

技术

资源与应用

产品与装备

信息服务

首页 > 教育信息化 > 校园信息化 > 高等教育

高校人员身份数据治理研究与实践

2024-08-14 中国教育网络

　　党的二十大报告首次提出“推进教育数字化”，高校实施教育数字化转型战略既是教育教学适应社会发展的时代要求，也是教育改革和大学高质量发展的必然选择。数据作为新型生产要素，在高校数字化转型过程中发挥着重要作用，通过数据要素赋能高校各项事业发展，成为高校数字化转型的突破点。教育数字化转型落地实施终究离不开高质量的信息系统和高质量的数据。基于数据交换共享，通过数据流动将系统和业务串联起来，增强系统能力，提升用户体验，已经成为高校信息化建设的基本共识。在所有交换共享的数据中，人员数据最基础也最重要，没有高质量的人员数据，所有系统运转都会遇到不同的问题。

　　人员数据交换共享这一基本建设看起来简单，实际实施中却会遇到很多问题和困难。以多数高校都经历过的真实案例为例，新冠疫情期间，各高校及下设部门都要准确掌握组织所有人员的情况，包括在职教职工、在职学生、自聘人员等。由于人员类别多、记录人员信息的系统多、数据源头多，再加上数据维护准确性等问题，给准确掌握人员数据带来了很大难度和挑战，全国高校信息化建设者可能都对此深有体会。在疫情期间，上海财经大学网络与信息技术中心和业务部门投入很多精力梳理清楚人员准确情况，同时也意识到人员数据治理的重要性。2022年，上海财经大学一网通办服务平台项目建设对人员、部门和角色提出了更复杂的应用需求，网络与信息技术中心借此契机，采用数据中台理念规划设计并开发了独立的人员数据中心库来支撑下游应用。

　　本文从人员的业务管理、应用系统建设和人员数据模型三个方面，探讨如何构建高质量的人员数据中台，进而支撑业务系统建设，充分挖掘、释放人员数据价值。

对人员管理业务的思考

　　1.“人员”的定义应当被明确界定。此处的“人员”指和学校有业务交集且需要使用应用系统的所有人员，包括学校正式聘用人员、部门临时聘用人员、各类学生、附属单位人员以及校友等。

　　2.实行全员全生命周期管理。此处突出两个“全”，一是人员要全，和学校有业务交集的人员都应该纳入相应系统进行管理，逐步培养用户使用系统功能完成工作的习惯，促进采集、更新人员数据；二是全生命周期，及时、准确维护人员状态等基础信息，做到有始有终。目前最常见的问题是数据录入系统以后就不再维护，导致大量僵尸数据产生。人员管理部门是人员数据产生的主要源头部门，包括人事处、教务处、研究生院以及其他二级机构。

　　3.业务部门应该明确数据责权，及时、准确维护人员数据，保障数据质量，使用系统功能完成日常业务操作，避免业务和系统脱节，通过系统功能带动数据更新，始终保持数据最新状态。

对信息化建设主管部门的建议

　　1.统筹规划全校信息系统建设，减少产生人员数据的源头系统。源头系统越多，管理和使用数据的难度越大。另外，通过完善系统功能和线上办事流程来促进人员数据采集和更新，保证全员数据能够进入系统。

　　2.梳理、确认人员数据准确源头，包括人员的属性信息。同时，监管人员数据产生和使用过程，对于已经明确了源头的数据，不允许其他业务再另起炉灶产生新的数据源头，数据新增和更新都应在源头系统中维护，下游系统只能通过数据交换共享来使用。

　　3.掌握人员数据维护业务和源头系统数据结构，采集所有源头的人员数据，构建人员数据中台，形成全局唯一人员库。设计不同数据模型，通过数据交换共享支持下游系统不同需求场景的使用。

人员数据中台建设方案

　　系统架构

　　人员数据中台系统架构如图1所示，首先调研业务源系统，清楚掌握人员数据产生的准确源头系统、人员种类以及每个源系统人员的字段属性、字段类型和字段值等情况。调研过程更重要的是，要了解每个系统人员数据的数据库表关系、人员状态记录方式、人员变化更新机制等关键信息，比如人员部门关系、人员状态是用起始时间还是状态字段标识、人员属性变化是直接更新还是会保留历史等。不同业务以及不同的功能设计实现会导致源数据记录方式有很大差别，调研过程为模型设计及开发数据集成程序做好了准备。

图1 人员数据中台系统架构

　　人员中心库数据模型逻辑上设计为两层，即基础模型层和应用模型层。基础层模型和应用需求无关，主要是采集并以合理的方式存储所有人员数据和尽可能多的属性字段，为应用层模型提供足够的基座能力。应用层模型主要面向具体应用场景和需求，使用基础层的数据来组装实现。人员中心库数据通过数据交换共享方式为下游提供服务，常见方式包括数据推送、数据库授权、API和数据下载，使用人员数据的主要应用场景有统一身份认证、应用系统用户和人员、数据统计上报、日常业务查询等。

　　数据模型

　　按照不同数据主题和应用场景会存在多种数据模型，下面分别介绍一套基础层和应用层比较重要也比较通用的数据模型及在上海财经大学的应用实例。

　　1.人员基础模型

　　人员基础模型主要用来解决组织下所有人员基本信息的合理存储，描述全局人员结构及详细情况，形成全局人员唯一视图，数据包含不同系统中的所有人员。模型按照人员源系统来规划设计，每一类来源的人员设计一个模型，这样源系统的升级迭代只影响基于该系统的数据模型，比如基于人事系统设计教职工和自聘人员模型，基于教务系统设计学生模型，基于留学生系统设计留学生模型。模型设计一定要参照源系统的人员属性字段以及源系统数据库结构，切不可凭空设计。人员基础模型主要从人员属性考虑，将尽量多的人员基本属性存储在一个宽表中方便使用。

　　人员基础模型如图2所示，模型由一个主表及不同类别人员子表组成，子表可以根据不同的人员数据源进行扩展。主表支撑需要所有人员数据的应用场景，如快速查询、分析所有人员情况；子表支撑专题应用，如查询不同类别人员的详细情况。主表和子表字段属性可以有重复，也建议重复存储，使用起来更加方便实用，但是要注意保证相同属性字段的计算逻辑一致。该模型不解决一人多部门情况，所以只存储人员主部门；人员状态非常重要，反映人员的生命周期和数据有效性。该模型主要支持统一身份认证、业务系统用户同步以及人员详情查询和上报统计等应用场景。

图2 人员基础模型

　　2.人员部门和角色模型

　　人员部门和角色是业务系统非常基础、非常关键的支撑数据。现实中，由于一人跨多个部门兼职，以多种身份角色承担不同工作，再加上业务系统基础数据不完善，使得人员部门和角色模型及数据情况比想象中复杂很多。上海财经大学一网通办服务平台在设计之初，要求支持人员多部门、多角色切换，需要有人员多部门、多角色数据模型支持。学校根据人员类型和身份设置了7种基础角色，分别为R001校领导、R002学院领导、R003部门领导、R004教师、R005职员、R006本科生、R007研究生，人员中心库基于该应用需求设计了通用数据模型，如图3所示。

图3 人员部门和角色模型

　　人员和部门、人员和角色属于1∶N关系，因此部门和角色无法合并到人员基本信息模型，需要使用单独模型来表示。这两个模型应用场景比较单一，只能单独使用，不能关联使用，关联以后会产生错误数据，如图4所示。

图4 人员部门和人员角色关联数据实例

　　经过分析发现，高校人员的角色与部门存在非常紧密的关系，身份角色只有在对应的部门下才有意义。比如，校长同时有校领导和教师两种角色，这两种角色只有对应到具体的部门，一条数据解读起来才具有正确的业务含义。学院领导角色一定是某个学院的领导，而不是所有承担工作部门的学院领导。因此，衍生出了第三种模型，将人员的部门和角色合并在一个模型中，支撑对用户权限要求更加精细和精准的应用场景，图5是该人员的正确部门、角色数据。

图5 人员部门角色数据实例

　　该模型已经作为学校应用系统建设的基础用户、角色数据被共享使用，一般会先同步到应用系统作为基础角色，应用系统再根据自身业务需求补充其他角色，一起支持系统功能。模型的基座能力特别依赖基础数据，基础数据不准确、不全面，模型的能力将大打折扣。现实中，很多人员相关的基础数据并没有记录在系统中，有些数据维护不及时。因此，一定要转变观念、规范业务管理、完善系统功能，将基础数据落实到业务系统中。

结束语

　　数据治理已经成为当前高校信息化建设的一项重要内容，很多高校已经实施并取得一定应用成效，但是精细化的人员治理在思想认识和实际行动上还缺乏足够的重视，导致人员数据作为最基础、最关键的数据资源，在实际应用中并不顺畅。此外，数据治理、业务治理、信息系统建设三者相辅相成，应该紧密结合而不能割裂开来独自建设，否则数据治理只能浮于数据表面，治标不治本，不能从根本上解决一些问题。

　　上海财经大学针对疫情期间使用人员数据的痛点，结合学校一网通办服务平台建设对人员数据的需求，借鉴数据中台理念建设了人员中心库，设计了通用的人员基础信息模型和人员部门角色模型，通过复杂的数据处理程序完成模型实现，并且在一网通办服务平台和其他业务系统进行了数据交换使用，应用效果显著。有了人员中心库，业务系统建设不需要再投入精力采集、处理人员数据，重点变为对接数据，结合应用需求灵活使用数据。

　　来源：《中国教育网络》2023年6月刊

　　作者：高亮（上海财经大学网络与信息技术中心）

　　责编：项阳

　　特别声明：本站注明稿件来源为其他媒体的文/图等稿件均为转载稿，本站转载出于非商业性的教育和科研之目的，并不意味着赞同其观点或证实其内容的真实性。如转载稿涉及版权等问题，请作者在两周内速来电或来函联系。