(back to index)

GaSP - Organisational Hierarchy V2

Proposal Sponsor: 
Craig Middlemass

Overview

The Organisational Hierarchy plays a central role in co-ordinating the management information and transactional information across multiple University systems.

Around 26 University systems make use of the Organisational Hierarchy to:

  1. To associate an object to an Organisational Unit (e.g. This course is run by the School of Physics)
  2. To aggregate information for reporting purposes (e.g. rolling together all the school based staff to provide a college level summary)
  3. To authorise use based on people's associations (e.g. staff in schools have access to book rooms owned by the same school and their associated college. Removing the need to manage permissions for a large user base)

The existing Organisational Hierarchy system has been in operation since 2002 and is reaching the end of life.

The coding convention being used at present is running out of combinations to represent new Organisational Units, it is expected that the codes will run out in the next 2-3 years. Additionally the University has grown more complex and needs the ability to flex its structure and have multiple associations for non-traditional Organisational Units such as virtual research centre, which the current system cannot accommodate.

The vast majority of systems that reference the Organisational Units do not take this information automatically or directly from the source. Which can lead to miskeying and subsequent failures in joining information. This adds complexity to any change to coding convention or organisational structures as the systems will require work in order to accept any new coding convention and additionally ensure that they can handle any change to the structure which has been relatively fixed since 2002.

 

There is currently no workflow associated with the annual collection and approval of changes to the Organisational Units, meaning that the task is laborious and manually communicated. Ideally this would be improved in a replacement system, however, this is not critical to the project's success.

 

This project would seek to:

  1. Enhance or replace the existing Organisational Hierarchy system
  2. Ensure that systems that refer to Organisational Units can accommodate new coding conventions and structures
  3. Build connections from the new system to existing systems that use Organisational Units (identified in 2)
  4. Implement a coding convention change ensuring the consumers of Organisational Hierarchy data are not adversely affected

 

Objective 3 is optional for each of the systems that take Organisational Hierarchy data as at present this is manually updated for the majority of systems. It would be preferential and beneficial to have tighter integration between systems to avoid issues of changes not being applied consistently, allowing clearer reporting of data between source systems and having fore knowledge of impact on downstream systems before changes are instigated would reduce the support burden in applying the changes individually each year.

 

 

 

Other contributors: 
Lynda Hutchison, Julia Miflin
What would happen if the project did not take place?: 

If the coding convention is not updated, eventually there will be no new codes available to represent new Organisational Units. In reality this is likely to lead to local areas creating new pseudo codes to represent Organisational Units. It is likely that any new unit created externally to Organisational Hierarchy will introduce failures. Such as the issues seen in 2014/15 when EUCLID created Organisational Units prior to them being in IDM which caused a failure in Timetabling feeds that rolls up subject level information into school level information.

The existing Organisational Hierarchy has a number of rules hardcoded, such as no re-use of codes. Therefore it is not possible for GaSP to even re-use codes or manipulate the hierarchy as a workaround.

The existing constraint of the Organisational Hierarchy not being able to represent the more complex structures in the University is already leading to manual workarounds. A current example is the "Edinburgh Medical School". Ideally this would exists as a school above the deaneries. With the existing limitations of Organisational Hierarchy the "Edinburgh Medical School" has been created as a unit alongside the deaneries. The result of this being that any school level reporting needs to be adjusted to sum the results of the deaneries and the school to give a total school level view. Without new developments these workarounds will continue to occur.

Additional information: 

A full recommendation paper following a review between May and July 2015 is available on request. This has not been released publicly as some of the recommendations relate to procedural changes in local areas that do not have an agreed implementation schedule.

Although the mainstay of the paper focuses on the need to change the Organisational Hierarchy to reflect the true University structure and be augmented with virtual units, mapping information and key unit information (such as is this unit part of the legal structure of the University).

Implementation of any coding convention or Organisational Hierarchy Structure would need to be implemented in a single year. In order to ensure that all local systems refer to the same coding convention for cross reference and sharing of data. Given that this project is likely to take longer than a single year the development could be split as follows:

YearNameDescription
1Build onlyThe currently Organisational Hierarchy solution is inflexible and would not allow for any coding or structural changes. Building a new solution that mirrors the features of the existing Organisational Hierarchy with the ability to flex coding convention and structures would allow for a more flexible source system to be created.
2Implement system with existing hierarchyUsing the new Organisational Hierarchy system but mirroring existing structure, local systems could be integrated and updated to allow them to consume far more complex Organisational Structures and coding conventions but without actually enabling this type of change. Therefore having the ability in place but not enacting it until all downstream systems are capable of handing the change.
3Enact coding convention changeOnce all systems have been linked to the New Organisational Hierarchy System and are able to accommodate a new coding convention or structure, then these features can be enabled.

Taking this approach would protect downstream systems until the point at which they can handle a change to coding convention. At which point it can be enacted and all systems are updated automatically. Ensuring that no system is left behind and unable to share Organisational data.

Who does it affect?: 

The following diagram depicts the systems that use Organisational Hierarchy directly or inherit the data as result of recieving information with Organisational Units. Please note that numbers in brackets refer to the levels of the Organisational Hierarchy being used in these systems.

Why is it needed/What are the benefits?: 

Whenever the Organisational Hierarchy cannot fulfill the needs of the University, workarounds are put in place that lead to disjoin in information and integration between systems. The Organisational Hierarchy is an enabler for lots of processes:

  • Reporting across data sets (e.g.. joining Staff to Finance data in order to produce School/Support Group level costing)
  • Granting permissions based on association (e.g.. Timetabling automatic role allocation, removes the need to manage a 50,000 strong user base)
  • Interfacing information from one system to another with the correct associations (e.g.. sending student programme information to ensure correct allocation of income)

If no work is progressed on the Organisational Hierarchy it is likely the more workarounds will be introduced and data fall out of syncronisation across the University. This is echo'd in the the conclusion from the July 2015 review which states that there are a number of key things that we will need to do in the short and medium term which, if not addressed, will prove to be barriers to any long-term improvements to BIMI. And hamper the successful implementation of elements of other initiatives such as the Resource Allocation Model (RAM).

BI/MI requirement?: 

Reporting is an essential enabler of Organisational Hierarchy. There is a reporting Universe in existence, but it would be useful to prove how this can be joined to multiple datasets in order to provide, subject, department, school and college level reporting. Please note that this is not a mandatory requirement for the project.

External costs?: 

Implementation of a coding convention change will require each of the downstream systems to be updated to receive new codes and also migrate/transform records for the existing coding convention to a new one.

Given that some of these platforms are provided by third parties, it is likely that consultation or configuration from the suppliers will be required.

Fit with University strategy: 

Objective: “ensure that we have the information we need to support learning, teaching, research and effective decision-making”

 

The BI MI Initiative is about gaining access to quality information to improve decision making processes.  The three main ways to join data sets together are through individuals (students and staff), curriculum and Organisational Hierarchy.  Being able to join using Organisational Hierarchy allows far greater scope for combining data sets particularly where individuals or curriculum are not directly related.

Score for portfolio comparison: 

 

Programme Priority

 

Overall Priority

Please categorise proposal as 1/2/3

 

Programme Scoring

1.Alignment with University Strategic Plan/Business Objectives

6

2.Risk of not doing the project

4

3.Benefits relative to cost

0

4.Time to deliver tangible benefit

1

TOTAL SCORE

11
Planning Status: 
Withdrawn
Portfolio: 
USG
Planned Start: 
16/17
Multi-Year: 
Yes
Project Owner: 
USG
Procurement > £50K: 
No
Funding Source: 
Core Grant
IS Admin Tab
Estimation Reference: 

Due to time constraints and the fact that this was withdrawn by Student Services Programme Owner prior to the estimation meeting this was not able to be discussed with the business area in detail.

If all the downstream systems were all to be updated to accommodate any change in organisational hierarchy then this would be significantly higher than even the typical extra-large IS Applications project, with a high complexity in the number of different areas of the University that would be impacted, potentially concurrently. As such it is recommended that funding is sought in the University planning round for this as a specific initiative, with agreement and input from the relevant areas potentially impacted.

Impact on other service area: 

All of the connected systems would be impacted, though not necessarily at the same time as most of the feeds from the Organisational Hierarchy are manual. Changes to each of these would need to be co-ordinated, ideally through a single project encompassing the changes to each of these systems - this would need a high degree of co-ordination with each of the business areas impacted, considering their planning.

(back to index)