OSF Service Support

Incident Management
Process
[Version 1.1]
Incident Management Process
Table of Contents
About this document 2
hapter 1. Incident Process !
1.1.Primary goal 3
1.2.Process Definition: 3
1.3.Objectives - Provide a consistent process to track incidents tat ens!res: 3
1.4.Definitions 3
"#$#"# C!stomer 3
"#$#%# Impact 3
"#$#3# Incident $
"#$#$# Incident &epository$
"#$#'# Priority $
"#$#(# &esponse $
"#$#)# &esol!tion $
"#$#*# +ervice ,greement $
"#$#-# +ervice .evel ,greement $
"#$#"/# +ervice .evel Target $
"#$#""# +everity '
1.5.Incident +cope '
"#'#"# 01cl!sions '
1.6.Inp!ts and O!tp!ts '
1.7.Metrics '
hapter 2. "o#es and "esponsibi#ities$
2.1.O+2 I+D +ervice Desk (
2.2.+ervice Provider 3ro!p (
hapter !. Incident ategori%ation& 'arget 'imes& Prioriti%ation& and (sca#ation )
3.1.Categori4ation )
3.2.Priority Determination )
3.3.Target Times *
hapter *. Process F#o+ ,
4.1.Incident Management Process 2lo5 +teps "/
hapter -. Incident (sca#ation12
5.1.2!nctional 0scalation "%
5.2.0scalation 6otifications: "%
5.3.Incident 0scalation Process: "3
5.4.Incident 0scalation Process +teps: "$
hapter $. "AI hart 1-
hapter ). "eports and Meetings 1$
7.1.&eports "(
)#"#"# +ervice Interr!ptions "(
%$)3$%*"3#doc Page " of "-
Incident Management Process
)#"#%# Metrics "(
)#"#3# Meetings "(
hapter .. Incident Po#ic/ 1)
About this document
Tis doc!ment describes te Incident Process# Te Process provides a consistent metod for everyone to
follo5 5en ,gencies report iss!es regarding services from te Office of +tate 2inance Information +ervices
Division 7O+2 I+D8#
0ho shou#d use this document1
Tis doc!ment so!ld be !sed by:
O+2 I+D personnel responsible for te restoration of services
O+2 I+D personnel involved in te operation and management of Incident Process
Summar/ o2 changes
Tis section records te istory of significant canges to tis doc!ment# Only te most significant canges
are described ere#
Version 3ate Author 3escription o2 change
"#/ Initial version
9ere significant canges are made to tis doc!ment: te version n!mber 5ill be incremented by "#/#
9ere canges are made for clarity and reading ease only and no cange is made to te meaning or
intention of tis doc!ment: te version n!mber 5ill be increased by /#"#
%$)3$%*"3#doc Page % of "-
Incident Management Process
hapter 1. Incident Process
1.1. Primar/ goa#
Te primary goal of te Incident Management process is to restore normal service operation as ;!ickly as
possible and minimi4e te adverse impact on b!siness operations: t!s ens!ring tat te best possible
levels of service ;!ality and availability are maintained# <6ormal service operation= is defined ere as service
operation 5itin +., limits#
1.2. Process 3e2inition4
Incident Management incl!des any event 5ic disr!pts: or 5ic co!ld disr!pt: a service# Tis incl!des
events 5ic are comm!nicated directly by !sers or O+2 staff tro!g te +ervice Desk or tro!g an
interface from 0vent Management to Incident Management tools#
1.!. Ob5ectives 6 Provide a consistent process to trac7
incidents that ensures4
Incidents are properly logged
Incidents are properly ro!ted
Incident stat!s is acc!rately reported
>!e!e of !nresolved incidents is visible and reported
Incidents are properly prioriti4ed and andled in te appropriate se;!ence
&esol!tion provided meets te re;!irements of te +., for te c!stomer
1.*. 3e2initions
1.*.1. ustomer
, c!stomer is someone 5o b!ys goods or +ervices# Te C!stomer of an IT +ervice Provider is te person
!tili4ing te service p!rcased by te c!stomer=s organi4ation# Te term C!stomers is also sometimes
informally !sed to mean ?sers: for e1ample @tis is a C!stomer foc!sed Organi4ation@#
1.*.2. Impact
Impact is determined by o5 many personnel or f!nctions are affected# Tere are tree grades of impact:
3 - .o5 A One or t5o personnel# +ervice is degraded b!t still operating 5itin +., specifications
% - Medi!m A M!ltiple personnel in one pysical location# +ervice is degraded and still f!nctional b!t
not operating 5itin +., specifications# It appears te ca!se of te incident falls across m!ltiple
service provider gro!ps
" - Big A ,ll !sers of a specific service# Personnel from m!ltiple agencies are affected# P!blic facing
service is !navailable
Te impact of an incident 5ill be !sed in determining te priority for resol!tion#
%$)3$%*"3#doc Page 3 of "-
Incident Management Process
1.*.!. Incident
,n incident is an !nplanned interr!ption to an IT +ervice or red!ction in te >!ality of an IT +ervice# 2ail!re
of any Item: soft5are or ard5are: !sed in te s!pport of a system tat as not yet affected service is also
an Incident# 2or e1ample: te fail!re of one component of a red!ndant ig availability config!ration is an
incident even to!g it does not interr!pt service#
,n incident occ!rs 5en te operational stat!s of a prod!ction item canges from 5orking to failing or abo!t
to fail: res!lting in a condition in 5ic te item is not f!nctioning as it 5as designed or implemented# Te
resol!tion for an incident involves implementing a repair to restore te item to its original state#
, design fla5 does not create an incident# If te prod!ct is 5orking as designed: even to!g te design is
not correct: te correction needs to take te form of a service re;!est to modify te design# Te service
re;!est may be e1pedited based !pon te need: b!t it is still a modification: not a repair#
1.*.*. Incident "epositor/
Te Incident &epository is a database containing relevant information abo!t all Incidents 5eter tey ave
been resolved or not# 3eneral stat!s information along 5it notes related to activity so!ld also be
maintained in a format tat s!pports standardi4ed reporting# ,t O+2 I+D: te incident repository is contained
5itin People+oft C&M#
1.*.-. Priorit/
Priority is determined by !tili4ing a combination of te incident=s impact and severity# 2or a f!ll e1planation of
te determination of priority refer to te paragrap titled Priority Determination#
1.*.$. "esponse
Time elapsed bet5een te time te incident is reported and te time it is assigned to an individ!al for
resol!tion#
1.*.). "eso#ution
+ervice is restored to a point 5ere te c!stomer can perform teir job# In some cases: tis may only be a
5ork aro!nd sol!tion !ntil te root ca!se of te incident is identified and corrected#
1.*... Service Agreement
, +ervice ,greement is a general agreement o!tlining services to be provided: as 5ell as costs of services
and o5 tey are to be billed# , service agreement may be initiated bet5een O+2CI+D and anoter agency
or a non-state government entity# , service agreement is disting!ised from a +ervice .evel ,greement in
tat tere are no ongoing service level targets identified in a +ervice ,greement#
1.*.,. Service 8eve# Agreement
Often referred to as te +.,: te +ervice .evel ,greement is te agreement bet5een O+2 I+D and te
c!stomer o!tlining services to be provided: and operational s!pport levels as 5ell as costs of services and
o5 tey are to be billed#
1.*.19. Service 8eve# 'arget
+ervice .evel Target is a commitment tat is doc!mented in a +ervice .evel ,greement# +ervice .evel
Targets are based on +ervice .evel &e;!irements: and are needed to ens!re tat te IT +ervice contin!es
to meet te original +ervice .evel &e;!irements#
%$)3$%*"3#doc Page $ of "-
Incident Management Process
1.*.11. Severit/
+everity is determined by o5 m!c te !ser is restricted from performing teir 5ork# Tere are tree
grades of severity:
3 - .o5 - Iss!e prevents te !ser from performing a portion of teir d!ties#
% - Medi!m - Iss!e prevents te !ser from performing critical time sensitive f!nctions
" - Big - +ervice or major portion of a service is !navailable
Te severity of an incident 5ill be !sed in determining te priority for resol!tion#
1.-. Incident Scope
Te Incident process applies to all specific incidents in s!pport of larger services already provided by O+2#
1.-.1. (:c#usions
&e;!est f!lfilment: i#e#: +ervice &e;!ests and +ervice Catalog &e;!ests are not andled by tis process#
&oot ca!se analysis of original ca!se of incident is not andled by tis process# &efer to Problem
Management# Te need for restoration of normal service s!persedes te need to find te root ca!se of te
incident# Te process is considered complete once normal service is restored#
1.$. Inputs and Outputs
Input From
Incident 7verbal or 5ritten8 C!stomer
Categori4ation Tables 2!nctional 3ro!ps
,ssignment &!les 2!nctional 3ro!ps
Output 'o
+tandard notification to te c!stomer 5en case is
closed
C!stomer#
1.). Metrics
%$)3$%*"3#doc Page ' of "-
Metric Purpose
Process tracking metrics
D of incidents by type: stat!s: and c!stomer A see
detail !nder "eports and Meetings
To determine if incidents are being processed in
reasonable time frame: fre;!ency of specific types of
incidents: and determine 5ere bottlenecks e1ist#
Incident Management Process
hapter 2. "o#es and "esponsibi#ities
&esponsibilities may be delegated: b!t escalation does not remove responsibility from te individ!al
acco!ntable for a specific action#
2.1. OSF IS3 Service 3es7
O5ns all reported incidents
0ns!re tat all incidents received by te +ervice Desk are recorded in C&M
Identify nat!re of incidents based !pon reported symptoms and categori4ation r!les s!pplied by
provider gro!ps
Prioriti4e incidents based !pon impact to te !sers and +., g!idelines
&esponsible for incident clos!re
Delegates responsibility by assigning incidents to te appropriate provider gro!p for resol!tion based
!pon te categori4ation r!les
Performs post-resol!tion c!stomer revie5 to ens!re tat all 5ork services are f!nctioning properly
and all incident doc!mentation is complete
Prepare reports so5ing statistics of Incidents resolved C !nresolved
2.2. Service Provider ;roup
Composed of tecnical and f!nctional staff involved in s!pporting services
Correct te iss!e or provide a 5ork aro!nd to te c!stomer tat 5ill provide f!nctionality tat
appro1imates normal service as closely as possible#
If an incident reocc!rs or is likely to reocc!r: notify problem management so tat root ca!se analysis
can be performed and a standard 5ork aro!nd can be deployed
%$)3$%*"3#doc Page ( of "-
Incident Management Process
hapter !. Incident ategori%ation& 'arget 'imes&
Prioriti%ation& and (sca#ation
In order to ade;!ately determine if +.,=s are met: it 5ill be necessary to correctly categori4e and prioriti4e
incidents ;!ickly#
!.1. ategori%ation
Te goals of proper categori4ation are:
Identify +ervice impacted and appropriate +., and escalation timelines
Indicate 5at s!pport gro!ps need to be involved
Provide meaningf!l metrics on system reliability
2or eac incident te specific service 7as listed in te p!blised +ervice Catalog8 5ill be identified# It is
critical to establis 5it te !ser te specific area of te service being provided# 2or e1ample: if it=s
People+oft: is it 2inancial: B!man &eso!rces: or anoter areaE If it=s People+oft 2inancials: is it for
3eneral .edger: ,cco!nts Payable: etc#E Identifying te service properly establises te appropriate +ervice
.evel ,greement and relevant +ervice .evel Targets#
In addition: te severity and impact of te incident need to also be establised# ,ll incidents are important to
te !ser: b!t incidents tat affect large gro!ps of personnel or mission critical f!nctions need to be
addressed before tose affecting " or % people#
Does te incident ca!se a 5ork stoppage for te !ser or do tey ave oter means of performing teir jobE
,n e1ample 5o!ld be a broken link on a 5eb page is an incident b!t if tere is anoter navigation pat to te
desired page: te incident=s severity 5o!ld be lo5 beca!se te !ser can still perform te needed f!nction#
Te incident may create a 5ork stoppage for only one person b!t te impact is far greater beca!se it is a
critical f!nction# ,n e1ample of tis scenario 5o!ld be te person processing payroll aving an iss!e 5ic
prevents te payroll from processing# Te impact affects many more personnel tan j!st te !ser#
!.2. Priorit/ 3etermination
Te priority given to an incident tat 5ill determine o5 ;!ickly it is sced!led for resol!tion 5ill be set
depending !pon a combination of te incident severity and impact#
Incident Priority +everity
3 - .o5
Iss!e prevents te
!ser from performing a
portion of teir d!ties#
% - Medi!m
Iss!e prevents te
!ser from
performing critical
time sensitive
f!nctions
" - Big
+ervice or
major portion
of a service is
!navailable
I
m
p
a
c
t
3

-

.
o
5
One or t5o
personnel
Degraded
+ervice .evels
b!t still
processing
5itin +.,
constraints
3 - .o5 3 - .o5 % - Medi!m
%$)3$%*"3#doc Page ) of "-
Incident Management Process
%

-

M
e
d
i
!
m
M!ltiple
personnel in one
pysical location
Degraded
+ervice .evels
b!t not
processing
5itin +.,
constraints or
able to perform
only minim!m
level of service
It appears ca!se
of incident falls
across m!ltiple
f!nctional areas
% - Medi!m % - Medi!m " - Big
"

-

B
i
g

,ll !sers of a
specific service
Personnel from
m!ltiple
agencies are
affected
P!blic facing
service is
!navailable
,ny item listed
in te Crisis
&esponse tables
" - Big " - Big " - Big
!.!. 'arget 'imes
Incident s!pport for e1isting services is provided %$ o!rs per day: ) days per 5eek: and 3(' days per year#
2ollo5ing are te c!rrent targets for response and resol!tion for incidents based !pon priority#
Priority Target
&esponse &esolve
3 - .o5 -/F - %$ o!rs -/F - ) daysG
% - Medi!m -/F - % o!rs -/F - $ o!rs
" - Big -'F - "' min!tes -/F - % o!rs
%$)3$%*"3#doc Page * of "-
Incident 3overnance Process
hapter * Process F#o+
Te follo5ing is te standard incident management process flo5 o!tlined in ITI. +ervice Operation b!t represented as a s5im lane cart 5it associated roles 5itin O+2
I+D#

%$)3$%*"3#doc Page - of "-
Incident 3overnance Process
*.1. Incident Management Process F#o+ Steps
"o#e Step 3escription
"e<uesting
ustomer

"
Incidents can be reported by te c!stomer or tecnical staff tro!g vario!s
means: i#e#: pone: email: or a self service 5eb interface# Incidents may
also be reported tro!g te !se of a!tomated tools performing 0vent
Management#
OSF IS3 Service
3es7
Incident identification
0or7 cannot begin on dea#ing +ith an incident unti# it is 7no+n that an
incident has occurred. As 2ar as possib#e& a## 7e/ components shou#d
be monitored so that 2ai#ures or potentia# 2ai#ures are detected ear#/ so
that the incident management process can be started <uic7#/.
Incident logging
,ll incidents m!st be f!lly logged and dateCtime stamped: regardless of
5eter tey are raised tro!g a +ervice Desk telepone call or 5eter
a!tomatically detected via an event alert# ,ll relevant information relating to
te nat!re of te incident m!st be logged so tat a f!ll istorical record is
maintained A and so tat if te incident as to be referred to oter s!pport
gro!p7s8: tey 5ill ave all relevant information at and to assist tem#
Incident categori4ation
,ll incidents 5ill relate to one of te p!blised services listed in te +ervice
Catalog# If te c!stomer is calling abo!t an iss!e tey ave tat is not
related to one of te services in te catalog: ten it is not an incident#
Is tis act!ally a +ervice &e;!est incorrectly categori4ed as an incidentE If
so: !pdate te case to reflect tat it is a +ervice &e;!est and follo5 te
appropriate +ervice &e;!est process#
Bas tis iss!e already been reported by otersE
If tis is anoter person reporting te same iss!e: relate te iss!e to te
cases already reported# More people reporting te same iss!e means te
impact of te iss!e is broader tan 5at migt ave been reported at first#
Te impact needs to be recorded base !pon c!rrent kno5ledge of te
impact#
Incident prioriti4ation
Hefore an incident priority can be set: te severity and impact need to be
assessed# +ee paragrap 3#% Incident Prioriti4ation# Once te severity and
impact are set: te priority can be derived !sing te prescriptive table#
Is tis a priority " 7major8 incidentE
If tis is a priority " incident meaning tat a service is !navailable in part or
5ole: all mid level and senior O+2 C I+D management so!ld be alerted to
make certain any reso!rces necessary to te resol!tion 5ill be immediately
made available#
Initial diagnosis
If te incident as been ro!ted via te +ervice Desk: te +ervice Desk
analyst m!st carry o!t initial diagnosis: !sing diagnostic scripts and kno5n
error information to try to discover te f!ll symptoms of te incident and to
determine e1actly 5at as gone 5rong# Te +ervice Desk representative
5ill !tili4e te collected information on te symptoms and !se tat
information to initiate a searc of te Ino5ledge Hase to find an appropriate
sol!tion# If possible: te +ervice Desk ,nalyst 5ill resolve te incident and
close te incident if te resol!tion is s!ccessf!l#
%$)3$%*"3#doc Page "/ of "-
Incident 3overnance Process
"o#e Step 3escription
J Is te necessary information in te Ino5ledge Hase to resolve te
incidentE If not: te case so!ld ten be assigned to te provider gro!p tat
s!pports te service#
If te necessary information to resolve te incident is not in te Ino5ledge
Hase: te incident m!st be immediately assigned to an appropriate provider
gro!p for f!rter s!pport# Te assignee 5ill ten researc te iss!e to
determine ca!se and remediation options#
,fter a possible resol!tion as been determined eiter from te Ino5ledge
Hase or tro!g researc: attempt te resol!tion#
Kerify 5it te c!stomer tat te resol!tion 5as satisfactory and te
c!stomer is able to perform teir 5ork# ,n incident resol!tion does not
re;!ire tat te !nderling ca!se of te incident as been corrected# Te
resol!tion only needs to make it possible for te c!stomer to be able to
contin!e teir 5ork#
OSF IS3 Service
3es7
If te c!stomer is satisfied 5it te resol!tion: proceed to clos!re: oter5ise
contin!e investigation and diagnosis#
Incident Clos!re
Te +ervice Desk so!ld ceck tat te incident is f!lly resolved and tat
te !sers are satisfied and 5illing to agree te incident can be closed# Te
+ervice Desk so!ld also ceck te follo5ing:
#osure categori%ation# Ceck and confirm tat te initial incident
categori4ation 5as correct or: 5ere te categori4ation s!bse;!ently t!rned
o!t to be incorrect: !pdate te record so tat a correct clos!re
categori4ation is recorded for te incident A seeking advice or g!idance from
te resolving gro!p7s8 as necessary#
=ser satis2action surve/# Carry o!t a !ser satisfaction call-back or e-mail
s!rvey for te agreed percentage of incidents#
Incident documentation# Case any o!tstanding details and ens!re tat
te Incident &ecord is f!lly doc!mented so tat a f!ll istoric record at a
s!fficient level of detail is complete#
Ongoing or recurring prob#em1 Determine 7in conj!nction 5it resolver
gro!ps8 5eter it is likely tat te incident co!ld rec!r and decide 5eter
any preventive action is necessary to avoid tis# In conj!nction 5it
Problem Management: raise a Problem &ecord in all s!c cases so tat
preventive action is initiated#
Forma# c#osure# 2ormally close te Incident &ecord#
J
%$)3$%*"3#doc Page "" of "-
Incident 3overnance Process
hapter -. Incident (sca#ation
,ccording to ITI. standards: alto!g assignment may cange: o5nersip of incidents al5ays resides 5it
te +ervice Desk# ,s a res!lt: te responsibility of ens!ring tat an incident is escalated 5en appropriate
also resides 5it te +ervice Desk#
Te +ervice Desk 5ill monitor all incidents: and escalate tem based on te follo5ing g!idelines:
Priority Time .imit before 0scalation
3 - .o5 3 b!siness days Manager
% - Medi!m $ o!rs Manager
If on-call contact cannot be reaced d!ring non-
b!siness o!rs
Manager
If neiter on-call contact or teir manager cannot be
reaced d!ring non-b!siness o!rs
+enior Mgt
$* o!rs +enior Mgt
" - Big Immediate Manager
Immediate +enior Mgt
-.1. Functiona# (sca#ation
O+2 I+D does not employ an official tiered s!pport system tat !tili4es escalation from one provider gro!p to
anoter# 9en te +ervice Desk receives notification of an incident: tey are to perform te initial
identification and diagnosis to classify te incident according to service category and prioriti4ation# If te
incident is a kno5n problem 5it a kno5n sol!tion: te +ervice Desk 5ill attempt a resol!tion# If it is not a
kno5n problem or if te attempted sol!tion fails: tey 5ill delegate responsibility for an incident to an
appropriate provider gro!p#
-.2. (sca#ation >oti2ications4
,ny time a case is escalated: notification 5ill occ!r to vario!s individ!als or gro!ps depending !pon te
priority of te incident# 2ollo5ing are basic g!idelines for notifications:
Te defa!lt mecanism for notification 5ill be by email !nless oter5ise specifically stated#
9enever escalation or notification by pone is indicated: all kno5n n!mbers for contact so!ld be
!tili4ed: leaving voice mail on eac !ntil person is contacted# Te master so!rce for on call
information 5ill be te on-call files located in te I:L2!nctionLOnCall folder#
+enior management notification 5ill incl!de CIO: CTO: and all f!nctional managers# 0scalation of a
case does not remove te assignment from an individ!al# It is !p to te manager of te provider
gro!p to make certain te rigt personnel are assigned# 9en additional personnel need to be
involved: tey may be added as interested parties#
,ny time a case is escalated: te case 5ill be !pdated to reflect te escalation and te follo5ing
notifications 5ill be performed by te +ervice Desk:
C!stomer 5ill receive a standard escalation email informing tem of te escalation#
Person to 5om case is c!rrently assigned 5ill be notified#
Manager of f!nctional gro!p to 5om case is c!rrently assigned 5ill be notified
%$)3$%*"3#doc Page "% of "-
Incident 3overnance Process
-.!. Incident (sca#ation Process4
%$)3$%*"3#doc Page "3 of "-
Incident 3overnance Process
-.*. Incident (sca#ation Process Steps4
,ll escalation process steps are performed by te +ervice Desk# +ome of te steps may be a!tomated#
Step 3escription
01amine all open incidents and determine actions based !pon incident
priority#
Is this a priorit/ 1 ?high priorit/@ incident1
If it is a ig priority incident: immediately notify O+2 C I+D mid level and
senior management personnel# +enior management personnel so!ld be
contacted by pone#
Monitor te stat!s of te priority " incident providing informational !pdates
to management at a minim!m of every $ o!rs#
Bas te incident been resolvedE If not contin!e to monitor#
If te incident as been resolved: notify O+2 C I+D mid level and senior
management of te resol!tion# +enior management so!ld be notified by
pone d!ring b!siness o!rs#
Is tis a priority % 7medi!m priority8 incidentE
If so: notify te manager of te provider gro!p performing te resol!tion#
6otification so!ld be by email#
Bas te incident occ!rred d!ring b!siness o!rs or off o!rsE If d!ring
b!siness o!rs: proceed to step "$#
If te incident occ!rred d!ring off o!rs: is te on call person availableE
If te on call person is not available: call te manager of te provider gro!p
assigned for resol!tion#
J Is te manager of te provider gro!p availableE
If neiter te provider gro!p on-call person or te manager of te provider
gro!p is available: notify senior management via email and pone#
Bas te time limit to resolve te incident elapsedE
If te time limit to resolve as elapsed: notify te manager of te provider
gro!p via email#
Contin!e to monitor te incident
J Bas te incident been resolvedE
J If te incident as been resolved notify te c!stomer and all personnel
previo!sly contacted of te resol!tion#
%$)3$%*"3#doc Page "$ of "-
Incident 3overnance Process
hapter $. "AI hart
Ob#igation "o#e 3escription
"esponsible &esponsible to perform te assigned task
Acco!ntable 7only " person8 ,cco!ntable to make certain 5ork is assigned and performed
ons!lted Cons!lted abo!t o5 to perform te task appropriately
Informed Informed abo!t key events regarding te task
Activit/ SP; Mgr SP; SM(As SP; 'eam
Service
3es7
OSF
Service
3es7 Mgr
"
&ecord Incident in C&M & ,
%
,ccept Information from C!stomer & & & & ,C&
3
$
'
)
*
-
"
/
(
"
"

%$)3$%*"3#doc Page "' of "-
Incident 3overnance Process
hapter ). "eports and Meetings
, critical component of s!ccess in meeting service level targets is for O+2 C I+D to old itself
acco!ntable for deviations from acceptable performance# Tis 5ill be accomplised by prod!cing
meaning reports tat can be !tili4ed to foc!s on areas tat need improvement# Te reports m!st ten
be !sed in coordinated activities aimed at improving te s!pport#
).1. "eports
).1.1. Service Interruptions
, report so5ing all incidents related to service interr!ptions 5ill be revie5ed 5eekly d!ring
te operational meeting# Te p!rpose is to discover o5 serio!s te incident 5as: 5at steps
are being taken to prevent reocc!rrence: and if root ca!se needs to be p!rs!ed#
).1.2. Metrics
Metrics reports so!ld generally be prod!ced montly 5it ;!arterly s!mmaries# Metrics to be
reported are:
Total n!mbers of Incidents 7as a control meas!re8
Hreakdo5n of incidents at eac stage 7e#g# logged: 5ork in progress: closed etc8
+i4e of c!rrent incident backlog
6!mber and percentage of major incidents
Mean elapsed time to acieve incident resol!tion or circ!mvention: broken do5n by impact
code
Percentage of incidents andled 5itin agreed response time as defined by +.,=s or I+D
standards
6!mber of incidents reopened and as a percentage of te total
6!mber and percentage of incidents incorrectly assigned
6!mber and percentage of incidents incorrectly categori4ed
Percentage of Incidents closed by te +ervice Desk 5ito!t reference to oter levels of
s!pport 7often referred to as <first point of contact=8
6!mber and percentage te of incidents processed per +ervice Desk agent
6!mber and percentage of incidents resolved remotely: 5ito!t te need for a visit
Hreakdo5n of incidents by time of day: to elp pinpoint peaks and ens!re matcing of
reso!rces#
).1.!. Meetings
Te >!ality ,ss!rance Manager 5ill cond!ct sessions 5it eac service provider gro!p to revie5
performance reports# Te goal of te sessions is to identify:
Processes tat are 5orking 5ell and need to be reinforced#
Patterns related to incidents 5ere s!pport failed to meet targets
&eocc!rring incidents 5ere te !nderlying problem needs to be identified and resol!tion
activities are p!rs!ed
Identification of 5ork aro!nd sol!tions tat need to be developed !ntil root ca!se can be
corrected
%$)3$%*"3#doc Page "( of "-
Incident 3overnance Process
hapter .. Incident Po#ic/
Te Incident process so!ld be follo5ed for all incidents covered by an e1isting service agreement:
regardless of 5eter te re;!est is event!ally managed as a project or tro!g te Incident process#
+!pport for or enancement of e1isting services identified in e1isting +ervice ,greements re;!ires an
Incident case to be opened#
If O+2 I+D already provides a service to a c!stomer: b!t tat c!stomer 5ants to significantly e1pand
tat service beyond te e1isting cost s!pport model in place: te re;!est so!ld be treated as a
+ervice Catalog &e;!est and for5arded to te O+2 +ervice Desk#
Incidents so!ld be prioriti4ed based !pon impact to te c!stomer and te availability of a 5orkaro!nd#
MIncident O5nersip remains 5it te +ervice DeskN &egardless of 5ere an incident is referred to
d!ring its life: o5nersip of te incident remains 5it te +ervice Desk at all times# Te +ervice Desk
remains responsible for tracking progress: keeping !sers informed and !ltimately for Incident Clos!re#O
A ITIL Service Operation
&!les for re-opening incidents - Despite all ade;!ate care: tere 5ill be occasions 5en incidents
rec!r even to!g tey ave been formally closed# If te incident rec!rs 5itin one 5orking day ten it
can be re-opened A b!t tat beyond tis point a ne5 incident m!st be raised: b!t linked to te previo!s
incident7s8#
9ork aro!nds so!ld be in conformance 5it O+2 I+D standards and policies#
%$)3$%*"3#doc Page ") of "-