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:
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:
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.
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.
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:
Year | Name | Description |
---|---|---|
1 | Build only | The 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. |
2 | Implement system with existing hierarchy | Using 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. |
3 | Enact coding convention change | Once 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.
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.
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:
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).
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.
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.
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.
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 |