Home 
 1. Overview 
 What is Incident Management? 
 Why use Incident Management? 
 Who uses Incident Management? 
 How Incident Management works 
 What does Incident Management cost? 
 2. Implementation Guide 
 Define what needs to be done to implement Incident...  
  Prepare to implement Incident Management 
 The Incident Management implementation plan 
 Incident Management post implementation review 
 3. Operations Guide 
  Who carries out Incident Management? 
 DW1105 When does Incident Management occur? 
 How to operate Incident Management 
  Measuring the results of Incident Management 
 4. Toolkit 
 Incident Management downloads 
 Incident Management resources 
 5. Roles and responsibilities 
 Service Desk role in Incident Management 
 Technical support role in Incident Management 
 User role in Incident Management 
 6. Review 
 Recap of Incident Management  
 Checklist  
How Incident Management works
Incident process Steps in the incident life cycle
Incident Management is about understanding the incident life cycle and the actions to take at each stage.


Go back to Overview
Incident process

Input to the incident process
Input to the incident process
These are the usual methods of being informed of an incident :
    • incident details via incident sheet and Service Desk
    • configuration details from the Configuration Management database
    • output from problem management  and known errors
    • resolution details from other incidents
    • response to a request for change.

Technicians should be encouraged to complete an incident sheet when they detect a new incident.

see diagram below for service desk actions in the incident life cycle

graphic

Go back to Incident process
Output from the incident process
Output from the incident process
These are the usual outputs from the incident process:
    • Request for Change (RFC)
    • incident resolution
    • updated incident record and call log
    • methods for workarounds
    • resolved and closed incidents
    • communication to users
    • management information (reports)
    • input to the Problem Management process.

Go back to Incident process
Activities of the incident process
Activities of the incident process
    • incident detection and recording
    • initial support
    • investigation and diagnosis
    • resolution and recovery
    • incident closure
    • incident ownership, monitoring, tracking and communication.

Go back to Incident process
Roles and functions in the incident process
Roles and functions in the Incident Process
    • Service Desk to be the single point of contact between all roles in the incident process.
    • Service Desk to log, monitor and track the progress of the incident.
    • Technician support to diagnose and resolve the incident or implement a workaround.
    • Technician support to progress unresolved incidents through the problem management process.
    • Any additional first line support groups eg, configuration management or change management specialist to be consulted.
    • Second-line and third-line support groups, including specialist support groups and external suppliers to be consulted.
    • User to keep the service desk informed of any further changes to the state of the affected equipment (sometimes the  computer can start working again when different incidents are resolved).

Go back to Incident process
Steps in the incident life cycle

The Incident Life Cycle explained.
 
Detection
1.
A user discovers an incident.
 
Completion of Incident Sheet and Call Log
2.
The user completes the incident sheet and passes it to the service desk.
3.
The person manning the service desk (the single point of contact) checks that the details of the incident can be understood.
4.
The service desk then completes their part of the incident sheet and puts a summary of the incident in the call log.
 
Initial Investigation
5.
The service desk, with experience will know if the resolution to the problem can be found in the schools knowledge base or if a technician is to be contacted.  The schools knowledge base will be checked for a resolution .
6.
If the knowledge base provides a solution, then this should be tried before contacting a technician. This is where the system agreed by the school will be followed.
 
The options are
1. Someone in the school tries the resolution and a technician is not called.
2. The technician is contacted and given the resolution found in the knowledge base.
 
Request Technician support
7.
If a resolution has not been found, the technician will be contacted and provided with details from the incident sheet. Again the system agreed by the school will be followed.
 
The options are
1. to email, post or fax the sheet to the technician
2. Telephone the technician and discuss the incident and action taken so far.
3. Leave the incident sheet for collection by the technician at their next scheduled visit.
 
Diagnosis
8.
The technician runs through a checklist of actions to discover the cause of the incident. An incident diagnostics sheet is available for the technician.
9.
Once the initial checks are performed the technician needs to decide if the incident can be fixed at this stage. If the incident cannot be fixed it becomes a problem, and the problem management process should be started.
 
Incident Resolution
10.
Resolving an incident is NOT the same as fixing a problem. The aim is get a working system available ASAP. If a fix is not available at this stage, the technician must aim to provide a workaround. 
11.
When implementing a workaround, the technician may well use spare equipment and remove the computer that is exhibiting the errors. Or the technician may need to identify existing equipment that can be used instead of the affected equipment.
12.
Even when a workaround has been implanted, the problem management process should be invoked to try to understand why the incident occurred and to prevent further occurrences.
 
Closure
13.
If the incident has been resolved, the incident sheet and call log are updated.
14.
The incident sheet is filed in chronological order, using the date the incident was reported.
15.
If the incident has now become a problem, the call stays open in the call log. The incident sheet and call log are updated to show the action taken. The problem management process is then started.
Top