itqms incident management process v1.0.doc

7/21/2019 ITQMS Incident Management Process V1.0.doc

http://slidepdf.com/reader/full/itqms-incident-management-process-v10doc 1/5

LOGOINCIDENT MANAGEMENT

PROCEDURE

CODE: ICM_P1

Page: 1 / 5

MODIFICATION HISTORY

DATE VER DESCRIPTION OF

CHANGES

MM/DD/YY 1.0 Baseline

EDITED BY APPROVED BY

Name

Title

Date

Name

Title

Date

PURPOSE & SCOPE

The purpose of incident management is to restore

normal serice operations as soon as possi!le

and to minimi"e aderse impact on !usiness

operations.

The scope of incident management coers allincidents related to #T serices and assets $see

incident definition%.

VALUE TO BUSINESS

#ncreased aaila!ilit& of !usiness serices

'educed impact on the !usiness operations

Timel& resolution of incidents

(ser/!usiness satisfaction

R EFERENCE DOCUMENTS

#T#)* + ,erice -perations uidance $#T#)*is a registered trade mar of the -ffice of

oernment ommerce in the (nited ingdom%

DEFINITIONS & ABBREVIATIONS

ITEM DESCRIPTION

M,onfiguration Management

,&stem

# onfiguration #tem

2irst )eel

,upport

3andles less complicated

technical incidents $e.g.

!usiness support teamspeciali"ing in specific lines of

!usiness%#ncident 4n unplanned interruption or a

reduction in the ualit& to the

normal operation of an #T

serice.

-)4 -perational )eel 4greement

'2 'euest for hange

,econd )eel

,upport

3andles deep rooted technical

pro!lems $e.g. net6or

specialists7 application

specialists7 and data!ase

specialists%.,erice Des ,ingle point of contact to report

incidents and trac incidents

,)4 ,erice )eel 4greement

( (nderpinning ontract

8oraround Temporar& solution to oercome

a serice interruption

PROCESS INPUTS & OUTPUTS

PROCESS INPUTS PROCESS OUTPUTS

#ncident $occurrence% #ncident )og/Data!ase

,)4Temporar& ,olution/

8oraround

M, 'euest for change

no6n 9rror Data!ase Pro!lem 'eport

Defects Data!ase Performance 'eports

R OLES & R ESPONSIBILITIES

'-)9 '9,P-N,#B#)#T9,

#ncident

Manager

- Define and maintain

incident management

procedure.

- oordinate and manage

incident throughout the

incident lifec&cle.

- Proide training to the

serice des agents.

- oordinate 6ith support

personnel $at arious

leels% to find a6oraround or temporar&

Confideni!"

op&right ;010 !& #T <ualit& Management ,olutions $P=T% )TD. 4ll rights resered. No part of this pu!lication ma& !e reproduced7 stored in an& retrieals&stem7 or transmitted in an& form or !& an& means7 electronic or other6ise7 6ithout 6ritten permission.




PROCEDURE

CODE: ICM_P1

Page: ; / 5

fi>.- Monitor the effectieness

of the incident

management process.

- Manage ma?or incidents.

- -pen pro!lem ticets

$6hen reuired%.

- -pen 'euests for hange

$'2%.

- Proide periodic

management reports.

# EY PERFORMANCE INDICATORS $#PI%

-B@9T#=9 P#

9fficienc&Mean time to resole

incidents

9ffectienessPercent of incidents

resoled !& serice des


incorrectl& assigned


reopened

CRITICAL SUCCESS FACTORS

#ncident Manager/Process -6ner

,ingle point of contact for recording incidents

Management commitment

R IS#S

#ncidents recorded in multiple locations/logs

)ac of trained serice des agents

#nsufficient resources and funds allocated to the

incident management process

Confideni!"





PROCEDURE

CODE: ICM_P1

Page: + / 5

PROCEDURE FLOCHART

PROCEDURE DESCRIPTION

Re'o(d !nd C"!))if*

1. #ncident Manager is responsi!le for recording7

filtering7 monitoring7 and resoling incidents.;. #ncidents can !e detected and reported in one of

the follo6ing 6a&s:

a.% (ser contacts the serice des !& phone7fa>7 email7 or intranet $directl& logs an

incident in the incident log/data!ase%.

!.% ,upplier initiates an incident.

c.% ustomer contacts the call center.

d.% 9ent management identifies an incident

or potential incident and reports to the

serice des.

e.% Technical staff identifies and reports an

incident.

+. 9ent management should monitor and report

failures or potential failures to the serice des.

A. #ncident Manager should reie6 and filterincidents !efore recording.

N-T9: Predefined procedures should !e used to

handle specific t&pes of incidents critical to !usiness

operations.

5. #ncidents should !e recorded in a single central

data!ase.

N-T9: #ncident management tools can range from a

comple> s&stem to a simple e>cel sheet.

. #ncident Manager should consider the follo6ing

6hile recording incidents:

• #f there is no incident histor&7 start 6ith the

ne6 incidents.

• 'ecoding the same incident t6ice must !e

aoided.

• #ncidents should !e handled according to a

defined ,)4.

• #ncident status should !e maintained

throughout the incident lifec&cle.

C. #ncidents ma& !e recorded !& an assigned team

in the serice des or !& the user him/herself.

. ,erice des agents and users must !e trained to

record and classif& incidents.

E. #ncident classification guidelines should !eclearl& defined and communicated to the releant

teams.

10. 4ll incidents should !e gien a uniue reference

num!er and the follo6ing details should !e

recorded against each incident:.

a.% Date and time

!.% Description of s&mptom

c.% ategor&

d.% (rgenc&

e.% #mpact

f.% Priorit&

g.% Name or the person recording theincident

Confideni!"





PROCEDURE

CODE: ICM_P1

Page: A / 5

h.% Name of the person affected !& theincident

i.% Preferred call !ac channel

?.% #s affected $from the M,%

.% 'elated no6n error $if an&%

l.% 3istor& of the incident $6here7 6hat7

6ho%

m.% 9>pected resolution date and time $!ased

on the ,)4%

N-T9: 4ccurate and complete details should !e

recorded for each incident. This 6ill assist arious

specialist groups and suppliers to resole incidents in

a timel& manner.11. #ncidents should !e classified according to:

• #ncident t&pe $standard incident7 ma?or

incident7 '27 standard change%

• ategor& $hard6are7 soft6are%

• ,u!Fcategor& $email7 M, office%

• ,erice $email7 office automation%

• Priorit& $high7 medium7 lo6/1F5%

P(io(ii+e

1;. #ncident Manager should prioriti"e incidents

!ased on urgenc& and impact. N-T9: The leel of urgenc& depends on ho6 fast the

incident needs to !e resoled7 and the impact

depends on !usiness criticalit& and ris.

1+. #ncident Manager should proide the incident

classification guidelines to all serice des

agents to ena!le them to determine the correct

urgenc& and impact.

N-T9: #ncident classification criteria should !e

printed on a card and made aaila!le to all serice

des agents.

1A. ,erice des agents should also use common

sense 6hen assigning a priorit& to an incident.15. #ncident priorit& should !e d&namic. #f

conditions change7 the priorit& should !e

updated.

Inii!" in,e)i-!ion !nd Di!-no)i)

1. ,erice des agents should carr& out the initial

diagnosis and tr& to resole the incident.

1C. 9ach incident should !e matched 6ith other

no6n errors and defects discoered during

testing.

1. #f a 6oraround or temporar& fi> is aaila!le7 it

should !e proided so that users can continue

6ith normal !usiness operations.

In,e)i-!e !nd Di!-no)e

1E. #f the serice des agent is una!le to resole the

incident it should !e escalated $transferred% to the

first line support.

N-T9: #f it is o!ious that the first line support

6ould !e una!le to resole the incident7 the incident

should !e transferred directl& to the second line

$technical or application support%.

;0. #f the first line support is una!le to resole the

incident7 the incident should !e transferred to the

second leel support for inestigation and

diagnosis. N-T9: 4n incident ma& !e escalated to different

leels of technical support groups until the solution is

found. The different leels ma& !e 6ithin the

organi"ation or outsourced to suppliers. The

escalation and handling of each incident must !e

defined in an -)4 and ( 6ith internal and e>ternal

groups.

;1. ,upport groups should inestigate and diagnose

each incident and identif& a solution/6oraround

as soon as possi!le.

N-T9: #nestigation ma& inole identif&ing the

triggers7 interfaces7 impact7 people inoled7 and process issues.

;;. ,erice des agents should ensure that users are

ept informed of the incident status until the

incident is resoled and closed.

;+. #f the incidents are high priorit& and impact

!usiness7 the appropriate #T managers and

!usiness o6ners must !e notified immediatel&.

Re)o",e !nd Re'o,e(

;A. Technical/specialist groups should proide more

than one solutions to resole or recoer the

incident 6ithin the ,)4.

;5. ,olutions should !e erified and alidated !efore

the& are deplo&ed into the lie enironment.

;. #ncident records and the no6n error data!ase

must !e updated 6ith all releant details in order

to speed up the resolution process the ne>t time a

similar incident occurs.

N-T9: #f there is a change to a #7 an '2 should !e

raised !efore resoling the incident.

C"o)e

;C. -nce the solution has !een deplo&ed7 thetechnical group should transfer the incident !ac

to the serice des.Confideni!"





PROCEDURE

CODE: ICM_P1

Page: 5 / 5

;. The serice des agent should contact the userand agree on the solution and close the incident.

N-T9: ,ome organi"ations proide an automated

user satisfaction sure& !efore closing an incident.

;E. The serice des should erif& and modif& the

initial incident classification and details $if

reuired%.

+0. The complete details of the incident life c&cle

should !e documented and maintained.

N-T9: 4lthough users are ased 6hether an incident

can !e closed7 an auto closing process should also !e

in place $for e>ample7 to close the incident after E0

da&s%.+1. #f the incident reFoccurs 6ithin a specified short

period7 the incident should !e reopened and its

status updated.

N-T9: #f the incident does not reFoccur 6ithin the

specified period a ne6 incident should !e raised.

Monio(. Me!)/(e. !nd Re0o(

+;. #ncident Manager should monitor7 measure7 and

improe the incident lifec&cle.

++. The incident resolution rate should !e compared

6ith the defined ,)4 target.

+A. #ncidents not resoled 6ithin the specified ,)4target should !e anal&"ed and reported to the

senior management.

M!o( In'iden G/ide"ine)

+5. Ma?or incident process $recording7 classification7

escalation7 resolution7 and closure% should !e

defined and communicated to all staeholders.

+. Ma?or incidents should !e clearl& defined and

documented to aoid an& confusion.

N-T9: Definition can !e !ased on financial impact7

reputational impact7 num!er of users/customer

affected7 or/and disruption to critical !usiness processes/serices.

+C. Ma?or incidents should tae priorit& oer all

other incidents.

+. ,erice des agents should follo6 up the ma?or

incident status and eep the users7 !usiness7

senior #T management7 and regulator&

organi"ations informed.

+E. ,erice des agents should raise an '2 if

changes are needed to resole the incident.

N-T9: ,ome organi"ations ma& esta!lish a ma?or

incident team to follo6 up the ma?or incident

resolution process and maintain detailed records ofthe incident.

Confideni!"


itqms incident management process v1.0.doc

Documents