OSF Service Support

Incident Management
Process
[Version 1.1]
Incident Management Process
Table of Contents
About this document..................................................................................................................................... 1
Who should use this document?............................................................................................................ 1
Summary of changes............................................................................................................................. 1
Chapter 1. Incident Process..........................................................................................................................
1.1. Primary goal....................................................................................................................................
1.!. Process "efinition#..........................................................................................................................
1.. $b%ecti&es ' Pro&ide a consistent process to trac( incidents that ensures# ....................................
1.). "efinitions.......................................................................................................................................
1.*. Incident Scope................................................................................................................................ *
1.+. Inputs and $utputs ......................................................................................................................... *
1.,. Metrics............................................................................................................................................ *
Chapter !. -oles and -esponsibilities.......................................................................................................... +
!.1. $S. IS" Ser&ice "es(................................................................................................................... +
!.!. Ser&ice Pro&ider /roup................................................................................................................... +
Chapter . Incident Categori0ation1 Target Times1 Prioriti0ation1 and 2scalation..........................................,
.1. Categori0ation................................................................................................................................. ,
.!. Priority "etermination..................................................................................................................... ,
.. Target Times................................................................................................................................... 3
Chapter ) Process .lo4................................................................................................................................ 5
).1. Incident Management Process .lo4 Steps................................................................................... 16
Chapter *. Incident 2scalation.................................................................................................................... 1!
*.1. .unctional 2scalation.................................................................................................................... 1!
*.!. 2scalation 7otifications#................................................................................................................ 1!
*.. Incident 2scalation Process#......................................................................................................... 1
*.). Incident 2scalation Process Steps#............................................................................................... 1)
Chapter +. -ACI Chart................................................................................................................................ 1*
Chapter ,. -eports and Meetings............................................................................................................... 1+
,.1. -eports......................................................................................................................................... 1+
Chapter 3. Incident Policy........................................................................................................................... 1,
About this document
This document describes the Incident Process. The Process pro&ides a consistent method for e&eryone to
follo4 4hen Agencies report issues regarding ser&ices from the $ffice of State .inance Information Ser&ices
"i&ision 8$S. IS"9.
Who shoud use this document!
This document should be used by#
$S. IS" personnel responsible for the restoration of ser&ices
$S. IS" personnel in&ol&ed in the operation and management of Incident Process
Summar" o# changes
This section records the history of significant changes to this document. $nly the most significant changes
are described here.
!6,!++).doc Page 1 of 15
Incident Management Process
Version $ate Author $escription o# change
1.6 Initial &ersion
Where significant changes are made to this document1 the &ersion number 4ill be incremented by 1.6.
Where changes are made for clarity and reading ease only and no change is made to the meaning or
intention of this document1 the &ersion number 4ill be increased by 6.1.
!6,!++).doc Page ! of 15
Incident Management Process
%hapter 1. Incident Process
1.1. Primar" goa
The primary goal of the Incident Management process is to restore normal ser&ice operation as :uic(ly as
possible and minimi0e the ad&erse impact on business operations1 thus ensuring that the best possible
le&els of ser&ice :uality and a&ailability are maintained. ;7ormal ser&ice operation< is defined here as ser&ice
operation 4ithin S=A limits.
1.&. Process $e#inition'
Incident Management includes any e&ent 4hich disrupts1 or 4hich could disrupt1 a ser&ice. This includes
e&ents 4hich are communicated directly by users or $S. staff through the Ser&ice "es( or through an
interface from 2&ent Management to Incident Management tools.
1.(. Ob)ectives * Provide a consistent process to trac+
incidents that ensures'
Incidents are properly logged
Incidents are properly routed
Incident status is accurately reported
>ueue of unresol&ed incidents is &isible and reported
Incidents are properly prioriti0ed and handled in the appropriate se:uence
-esolution pro&ided meets the re:uirements of the S=A for the customer
1.,. $e#initions
1.,.1. %ustomer
A customer is someone 4ho buys goods or Ser&ices. The Customer of an IT Ser&ice Pro&ider is the person
utili0ing the ser&ice purchased by the customer<s organi0ation. The term Customers is also sometimes
informally used to mean ?sers1 for e@ample Athis is a Customer focused $rgani0ationA.
1.,.&. Impact
Impact is determined by ho4 many personnel or functions are affected. There are three grades of impact#
' =o4 B $ne or t4o personnel. Ser&ice is degraded but still operating 4ithin S=A specifications
! ' Medium B Multiple personnel in one physical location. Ser&ice is degraded and still functional but
not operating 4ithin S=A specifications. It appears the cause of the incident falls across multiple
ser&ice pro&ider groups
1 ' Cigh B All users of a specific ser&ice. Personnel from multiple agencies are affected. Public
facing ser&ice is una&ailable
The impact of an incident 4ill be used in determining the priority for resolution.
!6,!++).doc Page of 15
Incident Management Process
1.,.(. Incident
An incident is an unplanned interruption to an IT Ser&ice or reduction in the >uality of an IT Ser&ice. .ailure
of any Item1 soft4are or hard4are1 used in the support of a system that has not yet affected ser&ice is also
an Incident. .or e@ample1 the failure of one component of a redundant high a&ailability configuration is an
incident e&en though it does not interrupt ser&ice.
An incident occurs 4hen the operational status of a production item changes from 4or(ing to failing or about
to fail1 resulting in a condition in 4hich the item is not functioning as it 4as designed or implemented. The
resolution for an incident in&ol&es implementing a repair to restore the item to its original state.
A design fla4 does not create an incident. If the product is 4or(ing as designed1 e&en though the design is
not correct1 the correction needs to ta(e the form of a ser&ice re:uest to modify the design. The ser&ice
re:uest may be e@pedited based upon the need1 but it is still a modification1 not a repair.
1.,.,. Incident -epositor"
The Incident -epository is a database containing rele&ant information about all Incidents 4hether they ha&e
been resol&ed or not. /eneral status information along 4ith notes related to acti&ity should also be
maintained in a format that supports standardi0ed reporting. At $S. IS"1 the incident repository is
contained 4ithin PeopleSoft C-M.
1.,... Priorit"
Priority is determined by utili0ing a combination of the incident<s impact and se&erity. .or a full e@planation
of the determination of priority refer to the paragraph titled Priority "etermination.
1.,./. -esponse
Time elapsed bet4een the time the incident is reported and the time it is assigned to an indi&idual for
resolution.
1.,.0. -esoution
Ser&ice is restored to a point 4here the customer can perform their %ob. In some cases1 this may only be a
4or( around solution until the root cause of the incident is identified and corrected.
1.,.1. Service Agreement
A Ser&ice Agreement is a general agreement outlining ser&ices to be pro&ided1 as 4ell as costs of ser&ices
and ho4 they are to be billed. A ser&ice agreement may be initiated bet4een $S.DIS" and another agency
or a non'state go&ernment entity. A ser&ice agreement is distinguished from a Ser&ice =e&el Agreement in
that there are no ongoing ser&ice le&el targets identified in a Ser&ice Agreement.
1.,.2. Service 3eve Agreement
$ften referred to as the S=A1 the Ser&ice =e&el Agreement is the agreement bet4een $S. IS" and the
customer outlining ser&ices to be pro&ided1 and operational support le&els as 4ell as costs of ser&ices and
ho4 they are to be billed.
1.,.14. Service 3eve 5arget
Ser&ice =e&el Target is a commitment that is documented in a Ser&ice =e&el Agreement. Ser&ice =e&el
Targets are based on Ser&ice =e&el -e:uirements1 and are needed to ensure that the IT Ser&ice continues
to meet the original Ser&ice =e&el -e:uirements.
!6,!++).doc Page ) of 15
Incident Management Process
1.,.11. Severit"
Se&erity is determined by ho4 much the user is restricted from performing their 4or(. There are three
grades of se&erity#
' =o4 ' Issue pre&ents the user from performing a portion of their duties.
! ' Medium ' Issue pre&ents the user from performing critical time sensiti&e functions
1 ' Cigh ' Ser&ice or ma%or portion of a ser&ice is una&ailable
The se&erity of an incident 4ill be used in determining the priority for resolution.
1... Incident Scope
The Incident process applies to all specific incidents in support of larger ser&ices already pro&ided by $S..
1...1. 67cusions
-e:uest fulfilment1 i.e.1 Ser&ice -e:uests and Ser&ice Catalog -e:uests are not handled by this process.
-oot cause analysis of original cause of incident is not handled by this process. -efer to Problem
Management. The need for restoration of normal ser&ice supersedes the need to find the root cause of the
incident. The process is considered complete once normal ser&ice is restored.
1./. Inputs and Outputs
Input From
Incident 8&erbal or 4ritten9 Customer
Categori0ation Tables .unctional /roups
Assignment -ules .unctional /roups
Output 5o
Standard notification to the customer 4hen case is
closed
Customer.
1.0. Metrics
!6,!++).doc Page * of 15
Metric
Purpose
Process trac(ing metrics
E of incidents by type1 status1 and customer B see
detail under -eports and Meetings
To determine if incidents are being processed in
reasonable time frame1 fre:uency of specific types of
incidents1 and determine 4here bottlenec(s e@ist.
Incident Management Process
%hapter &. -oes and -esponsibiities
-esponsibilities may be delegated1 but escalation does not remo&e responsibility from the indi&idual
accountable for a specific action.
&.1. OSF IS$ Service $es+
$4ns all reported incidents
2nsure that all incidents recei&ed by the Ser&ice "es( are recorded in C-M
Identify nature of incidents based upon reported symptoms and categori0ation rules supplied by
pro&ider groups
Prioriti0e incidents based upon impact to the users and S=A guidelines
-esponsible for incident closure
"elegates responsibility by assigning incidents to the appropriate pro&ider group for resolution based
upon the categori0ation rules
Performs post'resolution customer re&ie4 to ensure that all 4or( ser&ices are functioning properly
and all incident documentation is complete
Prepare reports sho4ing statistics of Incidents resol&ed D unresol&ed
&.&. Service Provider 8roup
Composed of technical and functional staff in&ol&ed in supporting ser&ices
Correct the issue or pro&ide a 4or( around to the customer that 4ill pro&ide functionality that
appro@imates normal ser&ice as closely as possible.
If an incident reoccurs or is li(ely to reoccur1 notify problem management so that root cause analysis
can be performed and a standard 4or( around can be deployed
!6,!++).doc Page + of 15
Incident Management Process
%hapter (. Incident %ategori9ation: 5arget 5imes:
Prioriti9ation: and 6scaation
In order to ade:uately determine if S=A<s are met1 it 4ill be necessary to correctly categori0e and prioriti0e
incidents :uic(ly.
(.1. %ategori9ation
The goals of proper categori0ation are#
Identify Ser&ice impacted and appropriate S=A and escalation timelines
Indicate 4hat support groups need to be in&ol&ed
Pro&ide meaningful metrics on system reliability
.or each incident the specific ser&ice 8as listed in the published Ser&ice Catalog9 4ill be identified. It is
critical to establish 4ith the user the specific area of the ser&ice being pro&ided. .or e@ample1 if it<s
PeopleSoft1 is it .inancial1 Cuman -esources1 or another area? If it<s PeopleSoft .inancials1 is it for
/eneral =edger1 Accounts Payable1 etc.? Identifying the ser&ice properly establishes the appropriate
Ser&ice =e&el Agreement and rele&ant Ser&ice =e&el Targets.
In addition1 the se&erity and impact of the incident need to also be established. All incidents are important to
the user1 but incidents that affect large groups of personnel or mission critical functions need to be
addressed before those affecting 1 or ! people.
"oes the incident cause a 4or( stoppage for the user or do they ha&e other means of performing their %ob?
An e@ample 4ould be a bro(en lin( on a 4eb page is an incident but if there is another na&igation path to the
desired page1 the incident<s se&erity 4ould be lo4 because the user can still perform the needed function.
The incident may create a 4or( stoppage for only one person but the impact is far greater because it is a
critical function. An e@ample of this scenario 4ould be the person processing payroll ha&ing an issue 4hich
pre&ents the payroll from processing. The impact affects many more personnel than %ust the user.
(.&. Priorit" $etermination
The priority gi&en to an incident that 4ill determine ho4 :uic(ly it is scheduled for resolution 4ill be set
depending upon a combination of the incident se&erity and impact.
Incident Priority Se&erity
' =o4
Issue pre&ents the
user from performing a
portion of their duties.
! ' Medium
Issue pre&ents the
user from
performing critical
time sensiti&e
functions
1 ' Cigh
Ser&ice or
ma%or portion
of a ser&ice is
una&ailable
I
m
p
a
c
t

'

=
o
4
$ne or t4o
personnel
"egraded
Ser&ice =e&els
but still
processing
4ithin S=A
constraints
' =o4 ' =o4 ! ' Medium
!6,!++).doc Page , of 15
Incident Management Process
!

'

M
e
d
i
u
m
Multiple
personnel in one
physical location
"egraded
Ser&ice =e&els
but not
processing
4ithin S=A
constraints or
able to perform
only minimum
le&el of ser&ice
It appears cause
of incident falls
across multiple
functional areas
! ' Medium ! ' Medium 1 ' Cigh
1

'

C
i
g
h
All users of a
specific ser&ice
Personnel from
multiple
agencies are
affected
Public facing
ser&ice is
una&ailable
Any item listed
in the Crisis
-esponse tables
1 ' Cigh 1 ' Cigh 1 ' Cigh
(.(. 5arget 5imes
Incident support for e@isting ser&ices is pro&ided !) hours per day1 , days per 4ee(1 and +* days per year.
.ollo4ing are the current targets for response and resolution for incidents based upon priority.
Priority Target
-esponse -esol&e
' =o4 56F ' !) hours 56F ' , daysG
! ' Medium 56F ' ! hours 56F ' ) hours
1 ' Cigh 5*F ' 1* minutes 56F ' ! hours
!6,!++).doc Page 3 of 15
Incident /o&ernance Process
%hapter , Process Fo;
The follo4ing is the standard incident management process flo4 outlined in ITI= Ser&ice $peration but represented as a s4im lane chart 4ith associated roles 4ithin $S.
IS".

!6,!++).doc Page 5 of 15
Incident /o&ernance Process
,.1. Incident Management Process Fo; Steps
-oe Step $escription
-e<uesting
%ustomer
1 Incidents can be reported by the customer or technical staff through &arious
means1 i.e.1 phone1 email1 or a self ser&ice 4eb interface. Incidents may
also be reported through the use of automated tools performing 2&ent
Management.
OSF IS$ Service
$es+
Incident identification
Wor+ cannot begin on deaing ;ith an incident unti it is +no;n that an
incident has occurred. As #ar as possibe: a +e" components shoud
be monitored so that #aiures or potentia #aiures are detected ear" so
that the incident management process can be started <uic+".
Incident logging
All incidents must be fully logged and dateDtime stamped1 regardless of
4hether they are raised through a Ser&ice "es( telephone call or 4hether
automatically detected &ia an e&ent alert. All rele&ant information relating to
the nature of the incident must be logged so that a full historical record is
maintained B and so that if the incident has to be referred to other support
group8s91 they 4ill ha&e all rele&ant information at hand to assist them.
Incident categori0ation
All incidents 4ill relate to one of the published ser&ices listed in the Ser&ice
Catalog. If the customer is calling about an issue they ha&e that is not
related to one of the ser&ices in the catalog1 then it is not an incident.
Is this actually a Ser&ice -e:uest incorrectly categori0ed as an incident? If
so1 update the case to reflect that it is a Ser&ice -e:uest and follo4 the
appropriate Ser&ice -e:uest process.
Cas this issue already been reported by others?
If this is another person reporting the same issue1 relate the issue to the
cases already reported. More people reporting the same issue means the
impact of the issue is broader than 4hat might ha&e been reported at first.
The impact needs to be recorded base upon current (no4ledge of the
impact.
Incident prioriti0ation
Hefore an incident priority can be set1 the se&erity and impact need to be
assessed. See paragraph .! Incident Prioriti0ation. $nce the se&erity and
impact are set1 the priority can be deri&ed using the prescripti&e table.
Is this a priority 1 8ma%or9 incident?
If this is a priority 1 incident meaning that a ser&ice is una&ailable in part or
4hole1 all mid le&el and senior $S. D IS" management should be alerted to
ma(e certain any resources necessary to the resolution 4ill be immediately
made a&ailable.
Initial diagnosis
If the incident has been routed &ia the Ser&ice "es(1 the Ser&ice "es(
analyst must carry out initial diagnosis1 using diagnostic scripts and (no4n
error information to try to disco&er the full symptoms of the incident and to
determine e@actly 4hat has gone 4rong. The Ser&ice "es( representati&e
4ill utili0e the collected information on the symptoms and use that
information to initiate a search of the Ino4ledge Hase to find an appropriate
solution. If possible1 the Ser&ice "es( Analyst 4ill resol&e the incident and
close the incident if the resolution is successful.
Is the necessary information in the Ino4ledge Hase to resol&e the incident?
If not1 the case should then be assigned to the pro&ider group that supports
the ser&ice.
!6,!++).doc Page 16 of 15
Incident /o&ernance Process
-oe Step $escription
If the necessary information to resol&e the incident is not in the Ino4ledge
Hase1 the incident must be immediately assigned to an appropriate pro&ider
group for further support. The assignee 4ill then research the issue to
determine cause and remediation options.
After a possible resolution has been determined either from the Ino4ledge
Hase or through research1 attempt the resolution.
Jerify 4ith the customer that the resolution 4as satisfactory and the
customer is able to perform their 4or(. An incident resolution does not
re:uire that the underling cause of the incident has been corrected. The
resolution only needs to ma(e it possible for the customer to be able to
continue their 4or(.
OSF IS$ Service
$es+
If the customer is satisfied 4ith the resolution1 proceed to closure1 other4ise
continue in&estigation and diagnosis.
Incident Closure
The Ser&ice "es( should chec( that the incident is fully resol&ed and that
the users are satisfied and 4illing to agree the incident can be closed. The
Ser&ice "es( should also chec( the follo4ing#
%osure categori9ation. Chec( and confirm that the initial incident
categori0ation 4as correct or1 4here the categori0ation subse:uently turned
out to be incorrect1 update the record so that a correct closure
categori0ation is recorded for the incident B see(ing ad&ice or guidance from
the resol&ing group8s9 as necessary.
=ser satis#action surve". Carry out a user satisfaction call'bac( or e'mail
sur&ey for the agreed percentage of incidents.
Incident documentation. Chase any outstanding details and ensure that
the Incident -ecord is fully documented so that a full historic record at a
sufficient le&el of detail is complete.
Ongoing or recurring probem! "etermine 8in con%unction 4ith resol&er
groups9 4hether it is li(ely that the incident could recur and decide 4hether
any pre&enti&e action is necessary to a&oid this. In con%unction 4ith
Problem Management1 raise a Problem -ecord in all such cases so that
pre&enti&e action is initiated.
Forma cosure. .ormally close the Incident -ecord.
!6,!++).doc Page 11 of 15
Incident /o&ernance Process
%hapter .. Incident 6scaation
According to ITI= standards1 although assignment may change1 o4nership of incidents al4ays resides 4ith
the Ser&ice "es(. As a result1 the responsibility of ensuring that an incident is escalated 4hen appropriate
also resides 4ith the Ser&ice "es(.
The Ser&ice "es( 4ill monitor all incidents1 and escalate them based on the follo4ing guidelines#
Priority Time =imit before 2scalation
' =o4 business days Manager
! ' Medium ) hours Manager
If on'call contact cannot be reached during non'
business hours
Manager
If neither on'call contact or their manager cannot be
reached during non'business hours
Senior Mgt
)3 hours Senior Mgt
1 ' Cigh Immediate Manager
Immediate Senior Mgt
..1. Functiona 6scaation
$S. IS" does not employ an official tiered support system that utili0es escalation from one pro&ider group to
another. When the Ser&ice "es( recei&es notification of an incident1 they are to perform the initial
identification and diagnosis to classify the incident according to ser&ice category and prioriti0ation. If the
incident is a (no4n problem 4ith a (no4n solution1 the Ser&ice "es( 4ill attempt a resolution. If it is not a
(no4n problem or if the attempted solution fails1 they 4ill delegate responsibility for an incident to an
appropriate pro&ider group.
..&. 6scaation >oti#ications'
Any time a case is escalated1 notification 4ill occur to &arious indi&iduals or groups depending upon the
priority of the incident. .ollo4ing are basic guidelines for notifications#
The default mechanism for notification 4ill be by email unless other4ise specifically stated.
Whene&er escalation or notification by phone is indicated1 all (no4n numbers for contact should be
utili0ed1 lea&ing &oice mail on each until person is contacted. The master source for on call
information 4ill be the on'call files located in the I#K.unctionK$nCall folder.
Senior management notification 4ill include CI$1 CT$1 and all functional managers. 2scalation of a
case does not remo&e the assignment from an indi&idual. It is up to the manager of the pro&ider
group to ma(e certain the right personnel are assigned. When additional personnel need to be
in&ol&ed1 they may be added as interested parties.
Any time a case is escalated1 the case 4ill be updated to reflect the escalation and the follo4ing
notifications 4ill be performed by the Ser&ice "es(#
Customer 4ill recei&e a standard escalation email informing them of the escalation.
Person to 4hom case is currently assigned 4ill be notified.
Manager of functional group to 4hom case is currently assigned 4ill be notified
!6,!++).doc Page 1! of 15
Incident /o&ernance Process
..(. Incident 6scaation Process'
!6,!++).doc Page 1 of 15
Incident /o&ernance Process
..,. Incident 6scaation Process Steps'
All escalation process steps are performed by the Ser&ice "es(. Some of the steps may be automated.
Step $escription
2@amine all open incidents and determine actions based upon incident
priority.
Is this a priorit" 1 ?high priorit"@ incident!
If it is a high priority incident1 immediately notify $S. D IS" mid le&el and
senior management personnel. Senior management personnel should be
contacted by phone.
Monitor the status of the priority 1 incident pro&iding informational updates
to management at a minimum of e&ery ) hours.
Cas the incident been resol&ed? If not continue to monitor.
If the incident has been resol&ed1 notify $S. D IS" mid le&el and senior
management of the resolution. Senior management should be notified by
phone during business hours.
Is this a priority ! 8medium priority9 incident?
If so1 notify the manager of the pro&ider group performing the resolution.
7otification should be by email.
Cas the incident occurred during business hours or off hours? If during
business hours1 proceed to step 1).
If the incident occurred during off hours1 is the on call person a&ailable?
If the on call person is not a&ailable1 call the manager of the pro&ider group
assigned for resolution.
Is the manager of the pro&ider group a&ailable?
If neither the pro&ider group on'call person or the manager of the pro&ider
group is a&ailable1 notify senior management &ia email and phone.
Cas the time limit to resol&e the incident elapsed?
If the time limit to resol&e has elapsed1 notify the manager of the pro&ider
group &ia email.
Continue to monitor the incident
Cas the incident been resol&ed?
If the incident has been resol&ed notify the customer and all personnel
pre&iously contacted of the resolution.
!6,!++).doc Page 1) of 15
Incident /o&ernance Process
%hapter /. -A%I %hart
Obigation -oe $escription
-esponsible -esponsible to perform the assigned tas(
Accountable 8only 1 person9 Accountable to ma(e certain 4or( is assigned and performed
%onsulted Consulted about ho4 to perform the tas( appropriately
Informed Informed about (ey e&ents regarding the tas(
Activit" SP8 Mgr SP8 SM6As SP8 5eam
Service
$es+
OSF
Service
$es+ Mgr
1
-ecord Incident in C-M - A
!
Accept Information from Customer - - - - AD-

)
*
,
3
5
1
6
+
1
1

!6,!++).doc Page 1* of 15
Incident /o&ernance Process
%hapter 0. -eports and Meetings
A critical component of success in meeting ser&ice le&el targets is for $S. D IS" to hold itself
accountable for de&iations from acceptable performance. This 4ill be accomplished by producing
meaning reports that can be utili0ed to focus on areas that need impro&ement. The reports must then
be used in coordinated acti&ities aimed at impro&ing the support.
0.1. -eports
0.1.1. Service Interruptions
A report sho4ing all incidents related to ser&ice interruptions 4ill be re&ie4ed 4ee(ly during
the operational meeting. The purpose is to disco&er ho4 serious the incident 4as1 4hat steps
are being ta(en to pre&ent reoccurrence1 and if root cause needs to be pursued.
0.1.&. Metrics
Metrics reports should generally be produced monthly 4ith :uarterly summaries. Metrics to be
reported are#
Total numbers of Incidents 8as a control measure9
Hrea(do4n of incidents at each stage 8e.g. logged1 4or( in progress1 closed etc9
Si0e of current incident bac(log
7umber and percentage of ma%or incidents
Mean elapsed time to achie&e incident resolution or circum&ention1 bro(en do4n by impact
code
Percentage of incidents handled 4ithin agreed response time as defined by S=A<s or IS"
standards
7umber of incidents reopened and as a percentage of the total
7umber and percentage of incidents incorrectly assigned
7umber and percentage of incidents incorrectly categori0ed
Percentage of Incidents closed by the Ser&ice "es( 4ithout reference to other le&els of
support 8often referred to as ;first point of contact<9
7umber and percentage the of incidents processed per Ser&ice "es( agent
7umber and percentage of incidents resol&ed remotely1 4ithout the need for a &isit
Hrea(do4n of incidents by time of day1 to help pinpoint pea(s and ensure matching of
resources.
0.1.(. Meetings
The >uality Assurance Manager 4ill conduct sessions 4ith each ser&ice pro&ider group to re&ie4
performance reports. The goal of the sessions is to identify#
Processes that are 4or(ing 4ell and need to be reinforced.
Patterns related to incidents 4here support failed to meet targets
-eoccurring incidents 4here the underlying problem needs to be identified and resolution
acti&ities are pursued
Identification of 4or( around solutions that need to be de&eloped until root cause can be
corrected
!6,!++).doc Page 1+ of 15
Incident /o&ernance Process
%hapter 1. Incident Poic"
The Incident process should be follo4ed for all incidents co&ered by an e@isting ser&ice agreement1
regardless of 4hether the re:uest is e&entually managed as a pro%ect or through the Incident process.
Support for or enhancement of e@isting ser&ices identified in e@isting Ser&ice Agreements re:uires an
Incident case to be opened.
If $S. IS" already pro&ides a ser&ice to a customer1 but that customer 4ants to significantly e@pand
that ser&ice beyond the e@isting cost support model in place1 the re:uest should be treated as a
Ser&ice Catalog -e:uest and for4arded to the $S. Ser&ice "es(.
Incidents should be prioriti0ed based upon impact to the customer and the a&ailability of a 4or(around.
LIncident $4nership remains 4ith the Ser&ice "es(M -egardless of 4here an incident is referred to
during its life1 o4nership of the incident remains 4ith the Ser&ice "es( at all times. The Ser&ice "es(
remains responsible for trac(ing progress1 (eeping users informed and ultimately for Incident Closure.N
B ITIL Service Operation
-ules for re'opening incidents ' "espite all ade:uate care1 there 4ill be occasions 4hen incidents
recur e&en though they ha&e been formally closed. If the incident recurs 4ithin one 4or(ing day then it
can be re'opened B but that beyond this point a ne4 incident must be raised1 but lin(ed to the pre&ious
incident8s9.
Wor( arounds should be in conformance 4ith $S. IS" standards and policies.
!6,!++).doc Page 1, of 15