University of Glasgow

HR Systems Development Project

User Requirements Specification
__________________________________________________________________________________

HR Systems Development Project

User Requirements Specification

CONTENTS

1 INTRODUCTION

1.1 Overview
1.2.1 Human Resources
1.2.2 Payroll
1.2.3 Faculty Offices
1.2 Scale
1.3 Current Systems

2 LOGICAL BUSINESS PROCESSES & HIGH LEVEL RESPONSIBILITIES

3 KEY REQUIREMENTS

3.1 Integration
3.2 Employee Status
3.3 Once only data entry
3.4 Web-enablement
3.5 Workflow capacity
3.6 Audit facilities

4 GENERAL REQUIREMENTS

4.1 Strategic Partnership

4.2 Ease of use
4.3 Access Control
4.4 Data Currency, Accuracy and Auditability
4.5 Management Information/Decision Support
4.6 Formal Reporting Requirements
4.7 Organisational Structure Standardisation of Codes

5 DETAILED FUNCTIONAL REQUIREMENTS

5.1 Recruitment
5.2 People Record Management
5.3 Employee Management
5.4 Establishment Management
5.5 HR Information
5.6 Training Employees
5.7 Payroll

6 INTERFACES

__________________________________________________________________________________

Approved Board 14.12.2000 ver 2

 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

1. INTRODUCTION

1.1 Overview

The University of Glasgow wishes to provide a modern, integrated, flexible administrative and
management information system to support its human resource needs. This document is a summary of
a detailed analysis of the processes operating in Human Resources and the Human Resources/Payroll
interface carried out by the project team. Findings regarding non-employees and the wider uses of HR
information in the University have also been included from the People Database project team. In keeping
with the business needs there has been consultation with stakeholders.

The purpose of this document is to define the scope of the user requirements. It is important to note that
this represents a broad range of desirable facilities, not all of which can necessarily be achieved. The
existence of an item in this document does not mean that it can be achieved, but that it has been
requested by users. The development priorities will be identified within the project plan.

1.2.1 Human Resources

The system will support the core activities of the human resources function and efficiently support the
processing of bulk activities. It is widely recognised that HR needs have not been met and considerable
improvement is required to support their role in the University. An important aspect of this is to align
responsibility, authority and ownership, and as such, practical responsibility for driving the joint
HR/Payroll system.

The University employs have circa 6,000 staff across a wide range of post types, for example Academic
& Related, Research, Professorial, Managerial, Administrative, Secretarial & Clerical, Technical and
Manual, each with their own salary scales and terms and conditions. The University merged with St
Andrews College in 1998 and the new Faculty of Education has a number of departments with staff on a
variety of terms and conditions.

1.2.2 Payroll

The Payroll section currently creates and amends employee records on the system as well as carrying
out payroll responsibilities. The payroll department is part of the Finance Office. Currently there are 10
payroll runs per month, and the payroll section are also responsible for paying over 1,100 pensioners.
Payroll as responsible for monitoring, controlling and paying expenses submitted on 1,000 forms each
month. There is a considerable number of regular ‘casual’ staff who are currently dealt with exclusively
by Payroll and this activity will be addressed by regularising the situation in compliance with employment
law, and changes necessary to systems and processes will take account of this. The payroll section also
acts as paying agents to some external companies.

Pensions are housed within the Payroll section. This is an administrative function which liases with
outside agencies. The payroll record provides their source of employee information and there is scope to
improve the information flow. This is a complex area with operation of University schemes such as
NASPS and USS in addition to other schemes such as NHS, Teaching and local government.

1.2.3 Faculty Offices and Senate Office

Faculty Offices appoint honorary staff and also deal with ‘affiliated individuals’ such as visiting
academics (departments may also fill this latter role.)There are a significant number of such individuals
associated with the University, of which a good part are in the Faculty of Medicine. Senate Office
oversees certain regulations regarding for example the use of honorary or emeritus titles. The records
are used by departments and different service areas across the University, including the Library,
Computing Service and for University publications. At present there is no authorised source and
information is fragmented and often not available. There are significant benefits to be gained across the
University by standardising and streamlining the information flows. Whilst it is intended that Faculty
Offices are responsible for creating such records, there may be some interim plans made in order to
achieve deadlines for business critical objectives. The procedures and processes will be established by
working with Faculty Offices and there will be central co-ordination before any roll out of responsibility.

__________________________________________________________________________________

Page 1
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

1.3 Scale

At present there are circa 42 potential system users in the Human Resources Department, and 15 in the
Payroll department. There may be an extension of users to Faculty/Department level to support
elements of devolved input. Longer term, the intention is to widen access to the system on a web basis,
opening it up to managers/administrators and individual staff. Practically this will relate to approximately
4,500 staff who have access to the computer network. Some indications of activity are:

Total Current employees circa 6,000 Fees per month 1,500

Honorary staff circa 1,500 Pensioners(on payroll) over 1,000
Job vacancies pa circa 700
Job applications pa circa 25,000

1.4 Current Systems

Delphi is supplied by Midland Software Limited and is a joint HR/Payroll system. The major issue
surrounds the current use of the system opposed to what it is capable of delivering, which are two
distinct issues. The system was implemented as payroll driven and has met restricted HR needs. A key
pre-requisite to meet many of the needs by providing a stable development foundation is the
implementation of the core HR module and the Payroll Interface. (The definition of ‘core HR module’ is
made up of items marked ❇ in section 5.)

Recruitment is supported by a Microsoft Access database underpinning the work flows, standard
documentation, and providing some management information.

Information from the system is available on a read basis to Faculty and Department using the reporting
tool BiQuery. It is also exported to a variety of other systems which use the HR data, for example the
Research and Consultancy System that supports the person based Research Assessment Exercise and
the Identity Card System. This role will extend to provide the authorised source of HR information to any
University system that can make legitimate use of it, for example intranet development. Interfaces are
detailed in Section 6.

Locally in Departments and at Faculty level there are a number of databases and spreadsheets
recording staff and non-employee information. They often duplicate data held in central systems. During
consultation departmental data needs matched central human resource needs, and departments
indicated their willingness to cease holding and maintaining local systems if they were provided with
adequate central data. It is intended that as the project develops these links are maintained and
developed in the form of a user group and test areas.

__________________________________________________________________________________

Page 2
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

2. Logical Business Processes & High Level Responsibilities

The processes in the system can be shown logically as follows:

Human Resources
Processes

Recruitment People Record Employee Establishment HR Information Training Records Payroll

Management Administration Management

There are certain major process changes being primarily that the system will be run on a ‘human
resources driven’ basis. The main process responsibilities in each of the areas are detailed below (the
specific detail is listed in section 5.) It should be noted that a number of these activities are not carried
out at present and there are inherent resource implications to develop policy and process, as well as
system development and on-going administrative maintenance.

Recruitment
• HR will maintain recruitment records (where recruitment is managed by them).
• Faculty/Department authorised users will be able to have view access to relevant records.

People Record Management

• HR will create all University employee records on contract acceptance, with person to post and the
personal grade, scale point and allowances.
• HR will load additional roles and any related allowances
• Faculty Offices will create non-staff records for honorary staff and affiliated (longer term).
• Senate Office will define honorary grades.
• Court Office will define allowable ‘affiliated’ categories(eg emeritus professors or visiting
academics).
• Computing Service/ MIS / Library will access new employee records on contract acceptance.
• Departments/Individuals will have responsibilities for limited elements of personal data.

Employee Administration
• HR will create and maintain grade and spinal scales.
• HR will maintain employee administration records such as probation and promotion.
• HR will be responsible for attendance management records.

Establishment Management
• HR will create and maintain an post based system recording posts against line
management(Department) units. All contracts will be attached to posts. A derivative of this is
forecasting information for all types of funding.
• Finance Office will derive salary forecasts (functionality of sf out with the scope of this project).

Training Records
• Staff Development/Computing Service/TLS will create training records.

HR Information
• HR & Payroll will generate management information for internal and external purposes.
• Faculty/ Department will generate management information for their purposes through improved
reporting model and targeted training.

Payroll
• Payroll will pay employees and meet statutory requirements.
• Payroll will act as paying agents.
• Payroll will pay expenses and overtime on departmental authority.*
• Payroll will retain responsibility for creation and control of element codes.
• Payroll will attach temporary elements (mid-month calculations).
• Payroll will pay fees.
• Payroll will be responsible for Pensions administration.
*Longer term areas such as expenses/overtime will be devolved to Departments.

__________________________________________________________________________________

Page 3
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

3. KEY REQUIREMENTS

The following items are a combination of functional requirements and fundamental

policies/principles.

3.1 Integration

3.1.1 Between HR and payroll elements of the system, being driven by HR.

3.1.2 Between the non-employee and employee elements, with appropriate ‘firewalls’ in place to
ensure that only privileged users in HR can perform the following functions.

Can … Create Person Record of type Connect Connect

Employee Person to
to Payroll Paying Agent
/Fee Payroll
Employee Honorary Affiliated Fee/
Pay Agent

HR √ √ √ √

Payroll √ √

Faculty √ √

3.1.3 Between the solution and other systems interfaced to it (detailed in section 6.)

3.2 Employee Status

3.2.1 The system will clearly identify who holds employee status, and hence who does not, with
reference not only to honorary staff but in particular to casual employees.

3.3 Once only data entry

3.3.1 Data will not be duplicated where possible, and it will be captured as early as possible.
Redundant data will not be held.

3.4 Web-enablement

3.4.1 Two-way web interfaces are essential to facilitate the dissemination of data and to capture data.
These could be used to facilitate the dissemination of data(eg job vacancies) and to capture
data(eg line manager providing job details to HR via web interface into a database.)

3.4.2 The University wishes to use web enabled facilities to provide manager and self service
facilities for staff within the confines of access privileges granted.

3.5 Workflow capacity

3.5.1 To facilitate streamlining and automation of routine administrative processes, for example
completion of post release forms, and to enable task management /event driven processes.

3.6 Audit Facilities

3.6.1 The system will provide robust audit information, reports showing updates as distinct from
views are essential for control purposes.

4. GENERAL REQUIREMENTS

4.1 Strategic Partnership

__________________________________________________________________________________

Page 4
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

4.1.1 The users recognise the need for high level commitment and co-operation from the software
supplier.

4.2 Ease of use

The system must be user-friendly, in particular:

4.2.1 Package should be cosmetically consistent and provide a GUI interface, meeting the needs of
both frequent and occasional users. (for example, fast data entry for bulk users, guided screens
for occasional users).

4.2.2 History and tracking facilities, maintaining an audit trail.

4.2.3 Exporting data facilitates, mail merging, document creation, export of statistical snapshots,
export of data to create email and computer accounts for staff.

4.3 Access Control

4.3.1 Solution must allow read/write access privileges to be set for categories of users as well as for
tables, screens and system modules. This facility must allow compliance with Data Protection
legislation. The design of the establishment hierarchy is relevant and the design must be taken
into account to support future devolved input.

4.3.2 The system must support the sufficient firewalls and flexibility to allow the uses to carry out
tasks as highlighted in section 2.

4.3.3 For web enablement, it is preferable that access to the system is via the user’s standard login
to the university computer network.

4.4 Data Currency, Accuracy and Auditability

4.4.1 User configurable on-line error validation and trapping.

4.4.2 Archiving facilities to enhance system performance, removal of obsolete data and to comply
with Data Protection. It is understood that an informed policy must be developed to implement
such facilities.

4.4.3 Input and outputs from systems must stand up to the scrutiny of internal/external auditors.

4.5 Management Information/Decision Support

Management Information provides objective and comparative details that support general
operational processes, provide executive level information and facilitate the management of
change. Management information is critical to underpin the overall planning direction.

The University uses a standard reporting tool on all of its main administrative information
systems, BI Query. This may supply some of the following requirements.

4.5.1 Ability to extract, transform and load data from other University systems.

4.5.2 Data integration, consistency of names, definitions and codes.

4.5.3 Features to aid information processing and user understanding of the information, including
ability to analyse data in a subject-oriented way.

4.5.4 Ability to analyse data at various levels of details.

4.5.5 Ability to produce and analyse data ‘as at’ certain points in time.

4.5.6 Salary Forecasting (person to post data aspects, the forecasting functionality, ie producing an
actual forecast, is co-ordinated by the Finance Office and their development team).

4.6 Formal Reporting Requirements

__________________________________________________________________________________

Page 5
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

The University is required to produce individual and aggregate returns to the Higher Education
Statistical Agency. This is currently dealt with by an in-house developed module.

Relevant data should be identified and processed as far as possible automatically, with only
additional data specific to the returns added. The systems must be sufficiently flexible to
accommodate changes that HESA make from time to time to coding and validation.

Other reports are required and details are provided in section 5. In most cases, reporting needs
will be met by an improvement in the quality of the data and availability of additional data.

4.7 Organisational Structure Standardisation of Codes

Central University systems hold information about organisational structure, eg Departments

and Faculties. There is no formal mechanism for ensuring that the same hierarchical structure
is represented, or that the same codes are used to communicate and identify organisational
structure units throughout the central administrative systems. This requires to be proactively
managed and supported by development to the underlying organisational structure system
(noted in interfaces section 6). The HR system is be a key interface to this facility, as would
Student System, Finance, Physical Resources, Research & Contracts.

__________________________________________________________________________________

Page 6
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5. DETAILED FUNCTIONAL REQUIREMENTS

5.1 Recruitment

Recruitment of staff is guided by the University Recruitment and Selection policy. HR provides a full
recruitment and selection service, dealing with the majority of all recruitment. There is a limited element
of devolution where departments are responsible for dealing some aspects of the recruitment process
for certain types of posts, eg research. Posts can be funded in different ways and this determines one of
two routes for approval involving the local management, Finance Office and HR.

At present the recruitment module is Microsoft Access. An integrated module is required with the
following functionality.

5.1.1 Ability to create an authorised vacancy with auditable mechanism showing authority to recruit to
it.

5.1.2 Link to the salary forecasting mechanism to enable the post to forecast the authorised vacancy.

5.1.3 Automatic generation of a unique identifier for each new authorised vacancy.

5.1.4 Recording of advertisements medium per post, adverts may be for single or multiple vacancies.
Posts may be re-advertised. Cost of adverts. Advertising mediums used

5.1.5 Application recording features.

5.1.6 Shortlisting features.

5.1.7 Management of the interview process.

5.1.8 Mail merging facilities providing auto-generation of standard letters.

5.1.9 Recording of placement history (post offered/decline/rejection).

5.1.10 Analysis of applications covering monitoring and reporting of equal opportunities data,
nationality/work permit flags against applicants, or returns from use of advertising media.

5.1.11 Interface to the main HR system module so that

• Contract offer takes offered spinal point and start date into the salary forecast for that post.
• Contract acceptance by the successful applicant will trigger the new employee record and
unique identifier at the time acceptance received.
• A current member of staff being appointed to a new post will be correctly identified as
current staff and their identifier will be retained.

5.1.12 As part of the new employee record, entry to person, contract details, equal opportunities,
HESA and post information will be forced to create a complete HR record.

5.1.13 As part of web enablement/workflow aspects

• collection of job details from line managers via workflow directly into a recruitment
database, then once authorised by HR, publication direct to a web-site automatically
updated from core recruitment system.
• provide the ability to hold job descriptions associated with a vacancy as part of the
database. This would allow the data to be re-used, for other recruitment or to refer to job
spec at the appointee’s appraisal.
• The submission of a vacancy would be aligned with workflow to deal with the authority to
release a post on-line ie automated post release forms.

__________________________________________________________________________________

Page 7
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

From this point onwards items marked ❇ form part of the core HR module referred to in the
project plans.

5.2 People Record Management

The University requires accurate and up to date records of staff and other individuals to be able to
automate routine administrative actions where possible. One of the major objectives is to ensure this
information forms the ‘spine’ used across the institution. Contractual administration is a large element of
the routine work carried out jointly between line management departments and HR.

5.2.1❇ Ability to uniquely identify individuals.

5.2.2❇ Automatic generation of a unique identifier for each individual and the ability to re-instate
people returning to the University against the same ID. Unique identifiers are not re-used.

5.2.3❇ Ability to store records of people who are not employees, for example, honorary titles,
secondments from other organisations. Following on from 3.2, these individuals will be clearly
identified as not holding employee status.

5.2.4❇ Facilities to store contact details for a person, covering internal location, home address, email,
telephone etc. (Interfaces required to relevant central systems to eliminate data duplication and
reflect ownership, eg records producing on-line directory.)

5.2.5❇ Facilities to store staff competencies (eg qualifications and professional associations).

5.2.6❇ Creation, amendment and termination of contracts of employment. This includes, for example:
• contract start and end dates, contract review dates and associated codes, and date driven
automation where appropriate.
• grade, department(establishment unit) and funding code(including % splits), validation
against finance system at input, and start and end dates on these items.
• ability to record line manager/ grant holder.

5.2.7❇ Ability to record details of more than one contract at a time(concurrently) and consecutively.

5.2.8❇ Automatic calculation of Full Time Equivalents.

5.2.9❇ Automatic generation of a full history of personal, contractual and salary details for all
employees.

5.2.10❇ Facilities to flag that an employee has left the University, and to store exit data including reason
for leaving and destination. Information implications of any on-going relationship to the
University are met, eg to Pensions section.

5.2.11❇ Interface to payroll to ensure new and amended personal and contractual details are available
and action either is automated or notification is passed by automated work flows.

5.2.12❇ Ability to hold data specific to HEIs, in particular HESA data.

5.2.13❇ Ability to hold equal opportunities data.

5.2.14❇ Ability to hold work permit data.

5.2.15❇ Ability to hold information about additional roles in the organisation, for example head of
department. (Including management of clinical honorary contract details, eg the Trust the
contract is held with and start/end dates.)

5.2.16❇ Ability to store membership details for committees.

5.2.17❇ Ability to hold pre-employment medical information

5.2.18 Web-based access for employees to view and amend selected personal details on-line.

5.2.19 Web-based access for managers(or nominated administrators) to view and update selected
details of staff working for them. Ability to report on this information.

__________________________________________________________________________________

Page 8
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5.3 Employee Administration

The University has a variety of conditions of service. These cover issues such as entitlement to pay,
holiday, occupational sick/maternity pay, pension rights etc. These tended to be held solely on paper
records, however the terms and conditions of service drive or in some cases, trigger other system based
activity.

Much of this information is recorded manually at present and is often not available in an easily
accessible format to line managers.

5.3.1❇ Record different sets of conditions of service.

5.3.2❇ Match the conditions of service to a contract and set defaults for some fields accordingly (eg
pay award, increment due date, notice period). From that, ability to determine individual
contractual entitlements based on personal service record.

5.3.3 Employee attendance management facilities, covering for example:

• Management of actual hours worked including a range of fixed and flexible working
patterns.
• Various types of leave, eg maternity, parental, careers, study, secondments, public
service, annual leave
• Sickness absence

5.3.4 Management of statutory obligations, determination of occupational sick pay entitlement and
compliance with Absence Management Policy in relation to both frequent and long term
absence and the identification of absences which form a pattern.

5.3.5 Ability to hold data about pension eligibly, particularly with respect to casual staff and the
introduction of stakeholder pensions.

5.3.5❇ Ability to hold data to support employee probation.

5.3.6❇ Ability to hold data to support the employee appraisal process.

5.3.7❇ Ability to hold data on employee disciplinary and grievance issues.

5.3.8❇ Ability to hold data that supports the promotion process from application to decision.

5.3.9❇ Ability to support multiple pay scales, and grades.

__________________________________________________________________________________

Page 9
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5.4 Establishment Management

The University needs to plan and manage its staffing for a variety of strategic and operational purposes.

To date posts have been used for the purposes of tracking authorisation to release, salary forecasting
and budgetary control as oppose to providing detailed HR establishment information. From this practice
post data is maintained only for the purpose of general funds salary forecasting. The salary forecasting
facility has been developed in-house, with the post data being an add-on to the system. There is a need
to provide comprehensive post information regardless of funding, and also from a financial control
perspective to provide forecasting for all posts regardless of funding.

From an HR perspective there is a clear need to record posts against establishment units, line
management, which differ from Financial costs centres. Financial cost information will be available from
the cost centre information attached to the post.

It must be stressed that this is not an establishment in terms of a set number of post to a department as
the staffing fte is dependant on that Faculty/Resource Unit’s cash-limited budget and external funds. It is
only that the method of recording posts is by department of line management which can be different
from the financial ledger costing structure.

Organisational hierarchy is provided by an interfacing system and this requires to be developed to record
and maintain a true picture of the hierarchy including sub-Departmental units as required.

5.4.1❇ Maintain a full historical record of a posts and their incumbents on an establishment unit basis,
coping with multiple employees in a single post and that one employee may hold multiple posts.

5.4.2❇ Recognise generic and individual posts. (Multiple person posts eg cleaners.)

5.4.3❇ Ability to recognise special requirements for a post, eg police or social services check required
and to trigger actions in the requirement process.

5.4.4❇ Ability to handle posts of temporary, permanent and fixed term duration, and of full time, part
time, casual and part year attendance patterns.

5.4.5❇ Ability to record grade, department and funding code(including % splits) for the post, and
funding start and end date for each source of funding.

5.4.6❇ Ability to hold data supplied about funding from the Financial Ledger about cost centres;
detailing internal and external/restricted funds; automating the mappings to the HESA Staff
return funding types; and validation of input.

5.4.7❇ Ability to forecast a vacancy based on the default post information if it vacant.

5.4.8❇ Organisation structure representation including ability to hold past, current and planned
versions of different levels of the organisation.

5.4.9❇ Salary forecasting functionality, taking into account employers on-costs, incremental
progression, pay awards, future changes in costs and forecasting for vacancies, ability to
identify core posts. (Development of the forecasting functionality itself, eg modelling is out with
scope of the project.)

5.4.10 An internal advisory group in investigating a number of recommendations in light of the Bett
Report. The administrative arrangements required to implement the policy, and supporting
system requirements, will become clearer once the needs have been defined by the advisory
group and considered by HR.

5.4.11 The University may be interested in facilities to support job evaluation.

__________________________________________________________________________________

Page 10
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5.5 HR Information

The HESA returns are managed on the Delphi system. Other statistics are generated by HR using
BiQuery which is the University standard reporting tool for central information systems. Information is
often manipulated further on spreadsheets. A web-based version of this reporting tool is being
evaluated by MIS.

At the moment production of information is often hampered by inadequate data, but the other sections
reflect the data required. The production of the following major reports is required:

5.5.1❇ HESA Annual Staff Individual Return

5.5.2❇ HESA Annual Staff Aggregate Return

5.5.3❇ Office for National Statistics Quarterly return

5.5.4❇ UCEA Annual survey of senior and middle management remuneration

Internal management information required:

5.5.5❇ Automated production of routine reports and statistics.

5.5.6❇ Facility to produce people lists in a variety of formats for export to interfacing systems and
inclusion in University publications.

5.5.7❇ Flexible ad-hoc reporting.

5.5.8❇ Inclusion of number, percentages and graphical presentation of data.

5.5.9❇ Facility to compare different periods of time or snapshots, for example to identify if recruitment
is increasing or decreasing.

5.5.10❇ Mortgage request information, returns to Department of Social Security etc. Whilst these are
routine requests about different members of staff there is a very high volume of requests met
by both HR and payroll.

5.5.11❇ The reporting tool is available to privileged staff in departments and faculties. Training is
voluntary at present and this will be targeted. Standard reports will be provided and
Departmental/Faculty users will assist in the development of these.

5.5.12 The reporting tool can run batch queries.

__________________________________________________________________________________

Page 11
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5.6 Training Employees

Training is provided by the Staff Development Service, Training Services (in HR), the Computing Service
and the Teaching and Learning Service. Facilities to record this information, and allow the addition of
details of training provided out with the University are required. At present, training is self/manager
selection and standalone access databases are used to record the information

5.6.1 Facilities to support the organisation of training and delivery of seminars including recording of
course and seminar details and resource requirements

5.6.2 Web based on-line booking for training course by line managers and individual employees.

5.6.3 Recording of attendance at training courses including automated update of training

/development history in employee record.

5.6.4 Facilities to support the evaluation and monitoring of training.

5.6.5 Facilities to produce statistical data on courses attended and courses that are still outstanding.

5.6.7 Ability for employee/manager to add record of non-University training course to their record via
the web interface.

5.6.8 In future, training will be linked to meeting objectives and performance management. Facilities
may be required to assist with confidential information management of this.

__________________________________________________________________________________

Page 12
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

5.7 Payroll

This section details the Payroll sections’ main responsibilities after HR assume responsibility for driving
the system. The underlying principle is that processes HR drive are automated where currently manual.
There is a large knowledge base that must be transferred from Payroll to Personnel.

5.7.1 Maintenance and control of on-line computerised payroll records for

• Statutory payments and deductions:
Tax, National insurance, Working family tax credit, Student Loans, Arrestments,
SSP/SMP

• Non-statutory payments and deductions:

Pension adjustments, Occupational Sick Pay adjustments, Unions, Other (Parking fee;
SRS fee; Languages at lunchtime; Class fees; GAYE)

5.7.2 Make payments to individuals, on receipt of authorisation from HR via electronic interface, by
• making record live for relevant pay period
• attaching relevant statutory and non-statutory information
• calculating adjustments for mid-month, backdated changes

5.7.3 Make temporary payments to employees, on authorisation from departments, using scanning
and automatic time recording systems
• overtime
• demonstrator / tutor claims
• casual employee claims

5.7.4 Control, monitor and pay employee expenses.

5.7.5 Process payments in capacity as paying agent for : Beatson Institute, GU Holdings, SRC,
Scholars

5.7.6 Payment of NASPS, LGPS, STSS, FSSU Supplementary and ex-gratia pensions

5.7.7 Provision of statements of pay

5.7.8 Calculation and payment of the University’s monthly PAYE tax and National Insurance
contribution liabilities

5.7.9 Year-end statutory returns to Inland Revenue (P11, P14,P35,P60)

5.7.10 Calculation of benefits in kind and preparation and submission of annual P11D

5.7.11 Calculation of PAYE settlement agreements

5.7.12 Control of Payroll bank and suspense account and bank reconciliations

5.7.13 Pension Contribution Control

5.7.14 Preparation of NASPS accounts to audit stage

5.7.15 Ensure all costs are interfaced to Financial system correctly and on time

5.7.16 National Statistics office monthly earnings

5.7.17 Provide payment information for Benefits Agency; Inland Revenue; Employees; Pension
scheme administrators

5.7.18 No new salary transactions will be generated within the Finance systems without being
recorded as required on the HR/Payroll system, for example percentage charges can be
recorded against grants at present on the financial ledger without showing the charged in
Hr/Payroll.

__________________________________________________________________________________

Page 13
 University of Glasgow
HR Systems Development Project
User Requirements Specification
__________________________________________________________________________________

6. INTERFACES

HR records interface in a variety of ways:

• Authorised source of information for a variety of other University systems. These systems cannot
change the data but add on relevant data to their own area, eg RAE data. This is not
comprehensive across the institution as other areas have links to individuals who may play no other
role, for example a paying member of the Library.
• Exporting data other systems to use functionality in them, eg to BACS or to record costs on the
financial ledger, the HESA return.
• Importing data for processing, for example from the time recording system.

Interface Description

BACS Net pay to bank accounts.

Computing Service Extract provided to the computing Service to support the creation and
maintenance of staff computer and email accounts.

Finance System Transfer Payroll costs to individual accounts on the general ledger
To provide validation and funding types of accounts
(New Agresso system currently being implemented)

Higher Education Electronic submission of annual returns.

Statistical Agency
Identity Card Database System providing staff, student and miscellaneous identity cards

Inland Revenue Magnetic tapes to IR. Paper back, Electronic Data Interchange with Tax
Office. Tax; year end returns information to/ from Inland Revenue proposed

MIS Registered Users XGQL database shows info about a person’s rights to access data in which
departments on which central information system. When a person leaves
privileges are removed.

Organisational Structure Central system that maps Departments into the Organisational Structure of
System Faculty, CAPU Division etc.

Pension Schemes Relevant information to/from on members; pensioners.

Physical Resources Extract about craftsmen to support job costing.

Plantime Time recording system about overtime and expenses incurred in Estates &
Buildings transferred into Delphi.

Research & Contracts Data extract with person and some contract details to support records for the
System RAE and publications.
Data extract of staff charged to account to support grant claims.
Salary Forecasting Forecast drawn from post/person information to produce financial forecasts.

Student System Information about staff to be linked to students supervised in post graduate
admissions system.

In Development/ Proposed
Library Extract of data for use in Innopac. (Currently the Library do not access the
data but will do once a unique staff identifier implemented.)
Payslips Proposal to send in electronic form to an external company to print the
payslips.
Room Bookings System Extract of data for use in room booking system.
(CMIS)
SCARF Signature Character and Recognition Form. Expenses and demonstrator &
tutor elements, amounts, account codes to Delphi.

__________________________________________________________________________________

Page 14