UNIVERSITY OF GLOUCESTERSHIRE Business Intelligence Strategy

1. Introduction and Background The University produces management information to monitor performance and to support decision making processes in a number of ways. Information needs to be reliable, timely, appropriate and understood. It needs to be accepted as a single source of truth, eliminating the need for local records and lack of trust. It is within this context that the Business Intelligence (BI) strategy for the University of Gloucestershire is developed. Whilst some elements of this strategy are aspirational, it is developed with a view to being achievable; a number of concepts are already in place, albeit that this needs to be more structured, formalised and recognised. The University will work towards achieving this strategy by utilising sector resources, in particular, the recommendations and guidelines of JISC. 2. Transformation of Data In order for data to be translated into appropriate BI for an organisation, it needs to be defined, structured and monitored. The current structure for the University is outlined below:

The data structure (or data definition) is the primary tool which enables the different sources of data to be integrated for presentation through the use of standard coding and definitions. The University has developed standard coding structures across the core systems and, as a result, has been able to develop reports which utilise data from a number of systems. It is the responsibility of the
Page 1 of 10

Head of Performance & Planning to ensure that standards are maintained across all University systems through the regular review of such structures to ensure that they are appropriate and by ensuring that access to the maintenance of such structures is limited to appropriate staff. However, the data output is only as good as the data which is entered into these systems the concept of garbage in, garbage out. It is important that the core feeder systems Utilise the defined data structures through applying data validation at source of entry wherever possible; Ensure that data is maintained in a timely and accurate manner; Undertake regular data quality checks.

The data quality checks are undertaken by the Performance & Planning team on a periodic basis; the range of checks is reviewed and maintained on a regular basis to ensure data quality. Corrective action may be required as a result of the data quality checks. It is the responsibility of the Data Owners to ensure that data is accurate and maintained in a timely manner and to respond to issues of quality identified to them by Performance & Planning. A number of defined datasets are developed from the source systems and passed to the Data Repository on a periodic basis. Some data will be passed on an annual basis (e.g. outputs from HESA returns) whilst some may be passed on an hourly basis (e.g. student registrations). As part of defining the datasets, key questions are asked to ensure that the data is up to date and appropriate. Data from the Data Repository and direct from the core systems is presented through several Visualisation Tools which will allow for the datasets to be viewed as stand alone or in an integrated format where the output is tailored for the appropriate audience. Agresso through Browser (smart client and web based)and Excelarator (Excel add-on); eVision (web based SITS tool) MyView (web based ResourceLink tool) Excel and Word (available on the z:\ drive, on campus and remotely through MyFiles, email, etc) The output from the BI System must be able to improve performance monitoring and inform decision making through the ability to apply scenario modelling. In addition, complex calculations are sometimes undertaken on the outputs which allow them to become inputs. For example, the modelling of student number plans is being fed back into the Data Repository to enable monitoring during the plan period. This also includes targets for the monitoring of KPIs to enable management to monitor their current performance against agreed targets. The most important attribute of this structure is that there is a single source of truth which allows for consistency of data thus eliminating doubt. The use of local records should be discouraged. This can only be achieved by ensuring that the BI is fit for purpose and recognised as accurate and up to date.

Page 2 of 10

It is the responsibility of Heads of Department to ensure that data is held on the core University systems and not locally; where more up to date information is identified, this must be utilised to update the core systems in order to maintain the single source of truth. The current data definitions and responsibilities is outlined in Appendix A. 3. Attributes of a BI System The key attributes identified by JISC for consideration in implementing and developing a full BI System are:
Required Desirable

Accessible when needed with appropriate security Concise, pictorial or graphical Up to date, current Known update times and intervals Can select data for any or defined time period Good, reliable quality and integrity of data items All internal information sources are included Drill-down and roll-up capabilities (zoom in or zoom out; allowing broader or narrower views, as the user requires) Easy to understand Easy to export to a presentation, document or spreadsheet Easy to add new information sources (internal or external) Allows the user to ask what if...? questions

Automatically updated in real time or Can be refreshed at the users command (to update figures when desired) Includes external information Complete Different (pre-designed) pictorial formats available New pictorial formats are easily designed and implemented (even by normal user) Fixed views can be set, with suitable security, for public student and staff

These attributes will ensure that a BI System is identified which is appropriate for the challenges facing the University. In addition, if the structure and thinking of a BI System is wide enough, it can be utilised as a planning tool, thus eliminating the need for multiple systems to be learnt and utilised by both super users (Planning & Performance) and end user. Currently the University BI System complies with a number of both the Required and Desirable attributes; these will be reviewed through a process of continuous improvement through the development of these systems in line with these attributes and other sector recommendations. 4. Delivery and Maintenance of BI Strategy The responsibilities for the delivery of the BI system, and the possible implementation of a new BI System, lies with the Chief Operating Officer and Director of Finance & Planning through the Performance and Planning Team.

Page 3 of 10

JISC define a Business Intelligence System as being: A system that compiles and presents key internal and external information in a concise, pictorial format, to support decisionmaking, planning and strategic thinking. It provides easy interactive access to reliable, current, good quality interdepartmental information, when needed. It allows senior management to be confident in the integrity and completeness of the information as they move between an overview and a detailed view. Advanced BI systems provide reliable, comprehensive information to all interested parties and include flexible user-defined views for senior managers and planning staff, and fixed views for public access and other users.

The University will continue to move towards this definition through the development of this strategy and with appropriate investment and through utilising the JISC tools that are available. Longer term, the University must progress towards having a fully integrated BI System to support the future needs of the institution and to enable the end user to extract and manipulate data appropriate for their particular needs, including what if scenario modelling. In particular the University will (through the Head of Performance & Planning) : Continue to monitor potential sources of data inputs to enable them to be included in the BI System; Review and develop the current structure and options for the BI System in line with current sector practices; Ensure that clear definitions are available to enable the end user to understand the dataset they are utilising. Ensure that staff responsible for the development and delivery of the BI System (super users within Performance & Planning) receive appropriate training for the tools that they will be required to utilise; Raise awareness of end users as to the use of such data through training and providing updates with the view to it being accepted as the single source of truth and eliminating the need for local records; Ensure data owners understand the importance of timely and accurate data held within the core systems and put in place controls necessary to monitor this within their own teams. The identification of individual responsibilities is integral for the delivery of this strategy. As already stated, Appendix A outlines the position of the existing University data sources and how they map to the recommended structure of the BI System, together with clearly defined roles and responsibilities for: Data Structure, including the master system, i.e. the system which drives the structure to be used by other systems; this may be either an internal or external system, e.g. HESA coding structures ; Data Owners Data Quality

The University will continue to develop datasets appropriate for all levels, from Council and Executive through to Course Administrators and Module Tutors, through a process of consultation, focus groups and feedback, to ensure that the information is appropriate for the changing environment. Appropriate tools (software and hardware) may be implemented for the development and maintenance of the Data Repository; it is possible that the Data Repository may be replaced with a fully integrated Data Warehouse in line with JISC recommendations. This will require investment but will provide a more
Page 4 of 10

flexible service to be provided. Multiple Visualisation Tools will be considered to ensure that BI outputs are appropriate for different requirements. These may include reporting from the Data Repository/Warehouse: Web based graphical drill down capability to hierarchical and transactional data, through the development of standard outputs for multiple users; Excel based outputs (through Agresso Excelarator) for tailored committee type reporting which utilises the Data Warehouse; Basic SQL and ODBC connectivity based outputs for ad hoc requirements.

This integrated approach will ensure that all levels and requirements can be achieved in a timely manner. The outputs prepared from the latter two options will be monitored to assess whether or not a more formal solution should be developed through option one. 5. Lifecycle of Data Data does not always standstill but will evolve over a period until it reaches a point where it becomes fixed. This is particularly true when considering the annual cycle of the University. For example: Students continue to register at various times during the year, with peaks at certain times particularly at the start of the academic year; Data to support the University Quality Assurance processes will not be complete until all results have been ratified by the appropriate academic Board structures and entered into SITS. Monthly financial data for any month will not be complete until adjustments (accruals) have been made; whilst there will be an indication on the final year-end financial position, this will not be complete until the annual accounts have been agreed and signed off. These are only examples of appropriate timings of data outputs. Appendix B outlines the production and timing of various datasets against the annual cycle for the University. 6. Risks and Constraints The delivery of this strategy is dependent on the following risks and constraints being avoided. It should be noted, however, that the list is not exhaustive. They include: Failure to recognise and implement standardise coding and data definition structures; Timely submission and input of core data; Reluctance of data owners to engage with this strategy; Lack of appropriate skill sets within the University; Key staff (either employed or consultants) leave the University; Availability of appropriate staff time to maintain and develop the BI System; Failure to identify and appoint roles to fulfil key responsibilities in a timely manner; Continued use and development of alternative solutions, including local records, due to lack of support and recognition of the single source of truth;

Page 5 of 10

Lack of funds for capital investment; Priority against other University developments; Availability of appropriate ICT support for the installation of both hardware and software; Failure of back up procedures; Availability of feeder and BI System during key reporting periods; Lack of full remote access.

7. Feedback & Review The BI System is integral to the future of the University, particularly in terms of the planning and decision making processes. It is therefore essential that this strategy is reviewed on an annual basis to ensure that it is still appropriate for the ever changing environment. Annual reports will also be prepared for Planning and Resources Committee, including an update of this strategy to ensure it meets the ever changing environment. A process of continuous improvement will also be developed through consultation with the end-users on a periodic basis through dialogue and consultation. This may include surveys and focus groups. May 2011

Page 6 of 10

APPENDIX A DATA DEFINITION AND RESPONSIBILTIES This schedule identifies key coding structures used by University systems. The structure and content is driven by a master system and other systems which then use the codes must be identical in format and content. Please note, ALL coding structures of core systems (e.g. Agresso, SITS, ResourceLink) are maintained by Performance & Planning unless otherwise indicated. Read/Write access to these tables will be restricted to appropriate members of staff within the Performance & Planning team only. It is the responsibility of the system owner to ensure the integrity of the data held on the individual systems.
SITS Agresso ResourceLink Estates (including Syllabus +) Learning & Teaching ICT External

Code type

System Owner

Academic Registrar

Director of Finance & Planning

Director of Human Resources

Director of Estates

e.g. Aleph, Moodle, etc

e.g. email, ID Vault, SharePoint, etc

HESA, UCAS, NSS, HEFCE, SLC

Student Number Staff Number Department & Faculty Hierarchy & Reporting Structures (including organisational charts) Course (include program and route) Module and Course maps Subject coding/JACS RAE/REF
- master system, i.e. controls format and values - used by system

()

()

()

()

Page 7 of 10

SITS

Agresso

ResourceLink

Estates (including Syllabus +)

Learning & Teaching

ICT

External

Code type

System Owner

Academic Registrar

Director of Finance & Planning

Director of Human Resources

Director of Estates

e.g. Aleph, Moodle, etc

e.g. email, ID Vault, SharePoint, etc

HESA, UCAS, NSS, HEFCE, SLC

Account code Project & Workorder TRAC Qualifications (on entry and aim, level, etc) Entry Profile and Demographic Analysis Employment (including destination & DLHE) Modes of study/employment Collaborative Partner Location & Campus Fees & Funding NSS Institution & Regulatory bodies Academic Year, terms dates, semester, etc

()

()

- master system, i.e. controls format and values - used by system Page 8 of 10

APPENDIX B

Information Cycle As outlined in the Strategy, data does not always standstill but will evolve over a period until it reaches a point where it becomes fixed. This is particularly true when considering the annual cycle of the University. The table below demonstrates, in more detail, the frequency of the production of data for the current year. Some information pertaining to the current year will be available in advance of the start of the year. Examples are: Student applications and offers Student number plans Budget and planning information (against which the current year outcomes will be monitored) Conversely, some data for the current year will not be available until after the year has ended. Again examples are: Final module results and awards Retention and progression (cannot be calculated until it is know whether or not the student returns to continue their program of study) Year- end financial information In addition, some data is updated more frequently than others; this frequency will also vary at different points of the cycle. The table below has been colour coded to reflect the frequency by which the data is refreshed as follows:
Daily Weekly Monthly Quarterly Annual

Page 9 of 10

INFORMATION CYCLE
ACADEMIC YEAR
MAR MAY NOV AUG OCT JUN APR DEC JAN FEB SEP

Student Data Application Current year cycle Application next year cycle Enrolment (student number reports) HESES return Module Results Awards Obtained HESA return Retention & Progression Destination of Leavers Staff Data Staff Numbers Payroll Costs Absence monitoring Workforce Monitoring HESA Return Financial Data Budget Holder Reports Draft Year-end position Final Year-end position In-year forecast Planning Data Student Number planning Workload Allocation Strategic & Business Planning Academic Efficiency Review Fee Setting Budget Setting Five Year Plan Estates Data EMS Return
PY NY NY NY NY NY NY NY NY NY NY CY NY NY NY PY NY NY CY CY CY CY PY PY CY CY CY CY CY CY CY CY CY CY CY CY PY CY CY CY CY CY CY CY CY CY CY CY CY CY PY CY CY CY CY CY CY CY CY CY CY CY CY CY CY PY PY PY PY PY PY PY PY CY CY NY CY CY NY CY CY NY CY CY NY CY CY CY NY CY CY CY NY CY CY NY CY CY NY CY NY CY NY CY NY CY

Key to frequency

Quarterly Annual Monthly Weekly Daily

Key to data year

PY CY NY

Data relates to previous academic year Data relates to current academic year Data relates to next academic year, predominently Planning and the UCAS application cycle

Page 10 of 10

JUL