1. Accountability

  • OUCS is accountable to the Collegiate University in terms of delivering the agreed services (as defined by our SLDs) to the agreed budget. Control is exercised by the OUCS Management Sub-Committee, which is officially responsible for OUCS.

  • The OUCS Management Sub-Committee is made up of senior representatives from all the divisions, plus college representation. It is charged with reviewing OUCS's performance (in terms of meeting its targets), its financial performance, agreeing changes to/new services and then supporting the escalation of funding requests. The OUCS Management Sub-Committee meets once a term (with an optional meeting prior to Michaelmas Term). It reports directly to the PRAC ICTC sub-committee. In particular it monitors:
    • The Annual Reports from OUCS, incorporating various useful statistics on use of the various services (in effect a list of our KPIs).
    • Service Level Definitions of all the key services provided by OUCS.

OUCS reports up to the PRACT ICTC sub-committee, and ultimately to PRAC itself. It is also a member of the Academic Services and University Collections (ASUC) Group. This comprises the Oxford University Library Services, the Oxford University Computing Services, the Language Centre, the University Archives, and the University’s museums and Botanic Garden. Details of this group can be found on the web site: http://www.admin.ox.ac.uk/asuc/

2. What OUCS does

2.1. We reply to a few simple things

  1. Most of our activities can be reduced to simple things like - 'Can you fix it?', 'Can I have it?', 'Can you change it?', and 'How do I use it?'. The first may relate to a user's own machine, or a service OUCS is responsible for. The second to a product or service we have available. The third to a service we run but the user thinks it needs changing, or could even be a request for a new service. The fourth can be any request for information on how to do something. Using the terminology from the widely adopted Information Technology Infrastructure Library (ITIL) we would call these (respectively): incidents, service requests, feature requests, and information requests. OUCS goes beyond this, however. It is also charged with developing services, usually based on feature requests, but sometimes off its own initiative as a result of R&D projects. More importantly, it is seen as the main IT provider and a main source of expertise within the University so we are often called upon to assist other IT units.

  2. The main point of contact is our Help Centre. Every user contact is assigned a ticket and this is logged, until it is resolved and closed. The details of how the Help Centre operate are contained in the associated SLDs for all our User Support Services.

  3. In IT jargon we often talk about first-level support and second-level support (etc). First-level support is the initial point of contact and will often deal with straightforward problems. Second-level support concerns issues of a more complicated nature and may have to be escalated to specialists. The University IT support structure states that for general user requests your first-level support should be your local IT Officer and you should always contact them in the first instance. OUCS will provide first-level support for services it is tasked with running by the University, and this is usually dealt with by the Help Centre but will occasionally have to be escalated to second-level support depending on the nature of the query or service. In terms of 'incident requests' then ('Can you fix it?') these will be dealt with by the Help Centre possibly in collaboration with specific service teams. OUCS has chosen to implement ITIL in part, to best suit its service model.

  4. Where an issue is not easy to resolve, they are escalated up ('Problem Management') according to the steps outlined in 2.19 to 2.21 in our general SLD for OUCS. Again these are all tracked in our Request Tracker system, and tickets are only closed off when resolved. In the case of major outage of service OUCS will assemble its Incident Response Team which will enact a series of pre-designed disaster recovery and business continuity plans. All major incidents will be the subject of a comprehensive review once they are resolved.

  5. Service Requests or Feature Requests will come to OUCS through a variety of means. Many services have dedicated user groups (e.g. WebLearn) which bring to the fore ideas, but we also have a series of OUCS reps on faculty/department/divisional IT committees, informal links with some colleges, and sit on senior IT committees. We also monitor requests coming directly to our Help Centre, and regularly seek suggestions on improvements through our Suggestion Box. Initially these will be considered by our Innovation Team who will pass on minor service requests to the relevant sections. If the change is more substantial (a 'Feature Request') this will be escalated to our User Services Team (which also acts as a 'Change Advisory Board'). If it is approved it will then follow OUCS's light-touch project methodology. Any major projects that require funding or will have a substantial impact on servers would be considered by our Senior Managers' Group, and then escalated (if appropriate) to the OUCS Management Committee and PICT.

  6. The objective here is to have a continual service improvement system that is led by the needs of the users or advances in technology, that is agile enough to respond quickly to changes, but at the same time has sufficient checkpoints in place to safeguard against any major disruptions brought about by service changes.