Before identifying your needs, consider what you want to achieve.
- This is an opportunity to re-evaluate the way you have, to date, approached and fixed incidents.
- Rethink the processes and activities of what currently happens. Do your technical staff always
try to do Problem Management before Incident Management?
- Understand the difference between incident management and problem management. See What
is Incident Management?
- Technical staff will always try to solve the cause of the problem. Their way of thinking needs to
change so they approach it with Incident Management before Problem Management.
- Choose which areas to improve and which processes to remove.
- You need to sell the idea to the other staff, so make it appeal to yourself first.
|
|
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
|
|
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.
|
|
|
Incident management is a defined process for logging, recording and resolving incidents.
The aim of Incident Management is to restore the service to the user as quickly as possible, often
through a workaround or temporary fixes, rather than through trying to find a permanent solution.
Difference between Incident Management and Problem Management
- The aim of Incident Management is to restore the service to the user as quickly as possible,
often through a workaround, rather than through trying to find a permanent solution.
- Problem Management differs from Incident Management in that its main goal is the detection of
the underlying causes of an incident and the best resolution and prevention.
- In many situations the goals of Problem Management can be in direct conflict with the goals of
Incident Management.
- Deciding on which approach to take requires careful consideration. A sensible approach would
be to restore the service as quickly as possible, but ensuring that all details are recorded, to
enable Problem Management to continue once a workaround has been implemented.
- This does however, require discipline as the thought that the incident is fixed may prevail, but if
the resolution to the problem is not found, the incident may well appear again.
Incident vs problem
An incident is where an error occurs or something doesn't work the way it is expected. It is any
event which is not part of the standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service.
This is often referred to as a fault, error, it doesn't work! , a problem, but the term used with FITS is
'incident'.
A problem can be
- the occurrence of the same incident many times
- an incident that impacts many users
- the result of network diagnostics revealing systems not operating the expected way.
Therefore a problem can exist without having immediate impact on the users.
Incidents are usually more visible and the impact on the user is more immediate.
|
|
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 such as configuration management or change
management specialist to be consulted.
- Second-and third-line support groups, including specialist support groups and external
suppliers.
- 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)
|
|
The Service Desk responsibilities include:
- Checking the user has completed the incident sheet.
- Actioning the incident sheet.
- Logging the incident in the call log.
- Performing the initial incident diagnostics.
- Requesting technician support when required.
- Ownership of the call, monitoring, tracking and communication.
- Updating records (call log, incident sheet) with the resolution.
- Closure of Incidents.
- Filing of incident sheet and incident diagnostics sheets.
- Progressing any follow up action (for example follow through into Problem Management.
|
|
The Techncians role in incident management must still have the same focus - aim to restore the
service
The technician will keep the service desk informed at all stages.
Technician support to diagnose and resolve the incident or implement a workaround
- Receive details of the incident from the service desk with a completed incident sheet.
- Perform diagnostics and use the incident diagnostics sheet to record action taken.
- Update the incident sheet and the diagnostics sheet.
- Resolve the incident with use of workarounds if required.
Technician support to progress unresolved incidents through the problem management process
- Detection of possible problems (before incidents are detected) and action through
problem management.
- Escalation of an incident into problem management; workarounds should always be
implemented first to reduce the time pressure ton resolve the problem.
Additional first line support groups such as configuration management or change management
specialist to be consulted
- More specialised technician within the school.
- Contact with 3rd party support provider
- Internet based support groups
- Technician in another school or focus group, TSAS forums etc.
Second-and third-line support groups, including specialist support groups and external supplier
- Specialist software support groups eg, operating systems, applications etc.
- Specialist hardware support groups eg, manufacturers of printers, PCs,
- Specialist suppliers eg, whiteboard, projector, digital systems suppliers
|
|
1. A user discovers an incident.
2. The user tries to repeat the conditions that caused the incident to see if the incident recurs.
3. The user completes the incident sheet and passes it to the Service Desk
4. It is important that the user includes information about the incident or request
- What did they expect to happen for example; the printer to print a document?
- What exactly did happen for example, the printer power light was on, but a blank page
printed?
- What did they check for example, that there was paper in the printer?
- To their knowledge, when did the equipment or software last work?
- Is the user aware that this equipment or software has had the same problems previously?
- Is there anything further to add that might help with resolving the incident?
It would help the technician if the user were available to discuss the incident. However careful
completion of the incident sheet should avoid the necessity for this.
The user needs to notify the service desk if the incident appears to 'resolve itself' before a
technician's visit.
The user is notified when the call is closed and informed of the resolution that was implemented.
|
|
|
|
|
