Incident Management is a defined process for logging, recording and resolving incidents.

Examples of Incidents:

• Moodle not available / won’t load 
• PC not turning on 
• cannot log in to PC 
• application error message 
• eduroam not working 
• Hallnet not working.

The aim of Incident Management is to restore the service to the customer as quickly as possible. We will always aim to find a permanent solution, where this is not possible we will aim to put a workaround or temporary fix in place.

Incident reporting via our Single Point of Contact (SPOC)

Your Single Point of Contact: here at Oxford Brookes University is the IT Service Desk ( web portal with self service and Chat / Service Desk Point locations / 01865 48 (3311) telephone support). 

The role of the service desk is to manage your incident from start to finish, this involves initial triaging of the Incident, information gathering, first line fixes and communication with you. The diagram to the right visualises this process.

At any point during this process you may be asked to provide us with further information to help us diagnose your issue. In line with the Single Point of Contact approach to Incident Management, you will generally be contacted by the Service Desk to gather this information with you, though in some cases you may be contacted by a second or third line support technician if the Incident is time sensitive or if the second or third line technician needs to visit you to resolve the Incident.

First line / Service Desk support staff: these members of IT Services have a general knowledge of most of the services which we provide, sometimes they are able to fix common issues and give you a quick or instant fix.

Second line support staff: these members of IT Services have a specialist knowledge of a few of the services which we provide, when first line / Service desk staff cannot resolve your incident it will be escalated to this level of support.

Third line support staff: these members of IT Services have a specialist / technical knowledge of individual services, when second line support staff cannot resolve your incident it will be escalated to this level of support.

Problem Management is he tracking and recording of issues that are likely to affect / have already affected multiple users.The aim of this is to identify the root cause and either fixing or working around the issue, in order to restore service as quickly as possible.

Examples of Problems:

• nobody can print 
• Swindon campus users are unable to access the internet 
• a bug found in a system that left unchanged will affect many end users.

The aim of Problem Management is to improve overall availability of services by proactively and reactively identifying Problems. Problem records will store information such as proven workarounds and known errors (where the problem is tolerable and/or cannot easily or cost effectively be fixed), these can then be referenced by any new Incidents that are created against a particular service.

Problems and how they affect you

Generally you will not be aware of the Problem Management process, but we think it useful for you to be aware of its existence to give you a further understanding of how this fits in with the Incident Management process. There are three usual routes for the creation of a problem record:

• Proactive - we have identified an issue with a service that hasn’t yet been reported by an end use
• Semi-Proactive - one or two incidents have been created and the support engineer dealing with the incidents determines that it’s an issue with a service that could affect multiple users
• Reactive - multiple incidents are being created against a single service for the same issue.

In all of the cases outlined above, new incidents that are created against a service can reference the notes or workarounds on an open problem record.

Major Problems

When a major problem is identified, ie a problem that will affect a high number of users, the Major Problem Review Team will meet to discuss and/or monitor progress in fixing the problem so that normal service can be resumed as quickly as possible. Major problems are defined by their business criticality. For example; a scanner not working in an office that affects multiple users will have a lower business criticality than the Oxford Brookes Active Directory Server going offline because this will affect all computer users. (Active Directory is the service that checks your password when you log into a networked PC.)

Problem resolutions

When a problem is resolved (ie a fix has been identified and implemented on the service) the problem record is closed and any incidents that are attached to the problem are also automatically resolved. The closure notes from the problem record are copied to all incidents and users will receive a copy of these via email.

Request Fulfilment is the process that is used to allow end users to request access to, or the fulfilment of, a service. Each service offering included in Request Fulfilment will have it’s own defined workflow processes, such as authorisation, approvals and fulfilment tasks.
Examples of Request Fulfilment:

• a new role based email account 
• software installation 
• granting of administrator rights on a computer. 

The aim of Request Fulfilment is to optimise the processes for common requests. In some cases the processes are fully automated so that the only interaction from IT Services is to approve your request. Defining processes in this way helps us to provide all staff with a unified experience. In addition forms are designed to ask for all of the pertinent information to allow fulfilment of the service with minimal extended communication with the end user.

Making Requests
Requests are made via the Service Catalogue on our web portal. When you make a request the item workflow starts and in most cases will assign the first task in the workflow to the IT Services team that deal with that particular request. In most cases the requests are dealt with by multiple teams and so multiple tasks are created throughout the life of the workflow. Once all the tasks have been closed the workflow ends and closes your request.

Understanding Requests
When you create a request, you will receive a notification of your request number. You can use this number if you need to contact the Service Desk about the progress of your requests. You can also view the status of current requests, and your request history, in our web portal.

References starting REQ: this reference number is in relation to your request as a whole, think of this like your shopping basket, you may have requested multiple items. This reference number relates to all of the items which you have requested during a checkout.
References starting RITM: this reference number relates to a single requested item and sits within your shopping basket (the REQ). If you want to talk to us in person or on the phone about a request you have made this is the most useful reference number you can give to us.
References starting TASK: this reference number isn’t usually visible to you as these refer to records which are created by the requested item workflow. You may on occasion see reference numbers like this when our team are communicating with you but you do not need to worry about them.