Incident management is run whenever an incident sheet is received by the Service Desk. In a busy
school it will form a large part of a technicians typical day.
|
|
see the diagram below for the incident life cycle
The Incident Life Cycle explained
|
|
Detection
|
|
1.
|
A user discovers an incident.
|
|
2.
|
The user raises the incident sheet and
passes it to the service desk.
|
|
|
Completion of Incident Sheet and Call
Log
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
The process in reporting and resolving incidents is summarised below.
1. Detecting an incident
2. How to report an incident
3. Initial Incident investigation
4. Using diagnostics
5. Incident resolution
6. Incident closure
|
|
|
|
|
