OSF Service Support

Problem Management Process

[Version 1.1]
Table of Contents
[VERSION 1.1].......................................................................................................................1
bout t!is "ocument..................................................................................................................................... #
Who should use this document?.................................................................................................................. 3
Summary of changes................................................................................................................................... 3
$!apter 1. Problem Process......................................................................................................................... %
1.1. Primary goal.......................................................................................................................................... 4
1.2. Process Definition................................................................................................................................. 4
1.3. b!ecti"es ........................................................................................................................................... 4
1.4. Definitions............................................................................................................................................. 4
1.4.1. #m$act......................................................................................................................................... 4
1.4.2 #ncident........................................................................................................................................ 4
1.4.3. %no&n 'rror (ecord................................................................................................................... )
1.4.4. %no&ledge *ase......................................................................................................................... )
1.4.) Problem....................................................................................................................................... )
1.4.+. Problem (e$ository.................................................................................................................... )
1.4.,. Priority......................................................................................................................................... )
1.4.-. (es$onse.................................................................................................................................... )
1.4... (esolution.......................................................................................................................................... )
1.4.1/. Ser"ice 0greement........................................................................................................................... )
1.4.11. Ser"ice 1e"el 0greement................................................................................................................. )
1.4.12. Ser"ice 1e"el Target................................................................................................................. )
1.4.13. Se"erity..................................................................................................................................... +
1.). Problem Sco$e...................................................................................................................................... +
1.).1. '2clusions................................................................................................................................... +
1.+. #n$uts and ut$uts ............................................................................................................................... +
1.,. 3etrics.................................................................................................................................................. +
$!apter &. Roles an" Responsibilities......................................................................................................... '
2.1. S4 #SD Ser"ice Des5.......................................................................................................................... ,
2.2. 6uality 0ssurance................................................................................................................................. ,
2.3. Ser"ice Pro"ider 7rou$......................................................................................................................... ,
2.4. Problem (e$orter.................................................................................................................................. ,
2.). Problem 3anagement (e"ie& Team.................................................................................................... ,
$!apter #. Problem $ategori(ation) *arget *imes) Prioriti(ation) an" Escalation...................................+
3.1. Categori8ation....................................................................................................................................... -
3.2. Priority Determination............................................................................................................................ -
3.3. Wor5arounds....................................................................................................................................... 1/
3.4. %no&n 'rror (ecord............................................................................................................................ 1/
3.). 3a!or Problem (e"ie&........................................................................................................................ 1/
$!apter %. Process Flo,............................................................................................................................. 11
4.1. Problem 3anagement Process 4lo& Ste$s........................................................................................ 12
$!apter -. R$I $!art................................................................................................................................. 1%
$!apter .. Reports an" Meetings............................................................................................................... 1-
+.1. (e$orts................................................................................................................................................ 1)
+.1.1. Ser"ice #nterru$tions................................................................................................................. 1)
+.1.2. 3etrics...................................................................................................................................... 1)
+.1.3. 3eetings................................................................................................................................... 1)
$!apter '. Problem Polic/.......................................................................................................................... 1.
bout t!is "ocument
This document describes the Problem Process. The Process $ro"ides a consistent method for e"eryone to
follo& &hen &or5ing to resol"e se"ere or recurring issues regarding ser"ices from the ffice of State
4inance #nformation Ser"ices Di"ision 9S4 #SD:.
0!o s!oul" use t!is "ocument1
This document should be used by;
S4 #SD $ersonnel res$onsible for the restoration of ser"ices and analysis and remediation of root
cause of $roblem
S4 #SD $ersonnel in"ol"ed in the o$eration and management of Problem Process
Summar/ o2 c!anges
This section records the history of significant changes to this document. nly the most significant changes
are described here.
Version 3ate ut!or 3escription o2 c!ange
1./ 1<14<2/11 W Thomasson #nitial "ersion
Where significant changes are made to this document= the "ersion number &ill be incremented by 1./.
Where changes are made for clarity and reading ease only and no change is made to the meaning or
intention of this document= the "ersion number &ill be increased by /.1.
$!apter 1. Problem Process
1.1. Primar/ goal
Problem 3anagement is the $rocess res$onsible for managing the lifecycle of all $roblems. The $rimary
ob!ecti"es of Problem 3anagement are to;
prevent problems and resulting incidents from happening.
eliminate recurring incidents.
minimize the impact of incidents that cannot be prevented.
1.&. Process 3e2inition
Problem 3anagement includes the acti"ities re>uired to diagnose the root cause of incidents and to
determine the resolution to those $roblems. #t is also res$onsible for ensuring that the resolution is
im$lemented through the a$$ro$riate control $rocedures.
1.#. Ob4ectives
Pro"ide a consistent $rocess to trac5 Problems that ensures;
Problems are properly logged
Problems are properly routed
Problem status is accurately reported
Queue of unresolved Problems is visible and reported
Problems are properly prioritized and handled in the appropriate sequence
Resolution provided meets the requirements of the SLA for the customer
1.%. 3e2initions
1.%.1. Impact
#m$act is determined by ho& many $ersonnel or functions are affected. There are three grades of im$act;
3 - Low One or two personnel. Service is degraded but still operating within SLA specifications
2 - Medium
Multiple personnel in one physical location. Service is degraded and still functional but not operating
within SLA specifications. It appears the cause of the Problem falls across multiple service provider
groups
1 - High All users of a specific service. Personnel from multiple agencies are affected. Public facing
service is unavailable
The im$act of the incidents associated &ith a $roblem &ill be used in determining the $riority for resolution.
1.%.& Inci"ent
0n incident is an un$lanned interru$tion to an #T Ser"ice or reduction in the 6uality of an #T Ser"ice. 4ailure
of any #tem= soft&are or hard&are= used in the su$$ort of a system that has not yet affected ser"ice is also
an #ncident. 4or e2am$le= the failure of one com$onent of a redundant high a"ailability configuration is an
incident e"en though it does not interru$t ser"ice.
0n incident occurs &hen the o$erational status of a $roduction item changes from &or5ing to failing or about
to fail= resulting in a condition in &hich the item is not functioning as it &as designed or im$lemented. The
resolution for an incident in"ol"es im$lementing a re$air to restore the item to its original state.
0 design fla& does not create an incident. #f the $roduct is &or5ing as designed= e"en though the design is
not correct= the correction needs to ta5e the form of a ser"ice re>uest to modify the design. The ser"ice
re>uest may be e2$edited based u$on the need= but it is still a modification= not a re$air.
1.%.#. 5no,n Error Recor"
0n entry in a table in C(3 &hich includes the sym$toms related to o$en $roblems and the incidents the
$roblem is 5no&n to create. #f a"ailable= the entry &ill also ha"e a lin5 to entries in the %no&ledge *ase
&hich sho& $otential &or5 arounds to the $roblem.
1.%.%. 5no,le"ge 6ase
0 database housed &ithin C(3 that contains information on ho& to fulfill re>uests and resol"e incidents
using $re"iously $ro"en methods < scri$ts.
1.%.- Problem
0 $roblem is the underlying cause of an incident.
1.%... Problem Repositor/
The Problem (e$ository is a database containing rele"ant information about all $roblems &hether they ha"e
been resol"ed or not. 7eneral status information along &ith notes related to acti"ity should also be
maintained in a format that su$$orts standardi8ed re$orting. 0t S4 #SD= the Problem (e$ository is
contained &ithin Peo$leSoft C(3.
1.%.'. Priorit/
Priority is determined by utili8ing a combination of the $roblem?s im$act and se"erity. 4or a full e2$lanation
of the determination of $riority refer to the $aragra$h titled Priority Determination.
1.%.+. Response
Time ela$sed bet&een the time the $roblem is re$orted and the time it is assigned to an indi"idual for
resolution.
1.%.7. Resolution
The root cause of incidents is corrected so that the related incidents do not continue to occur.
1.%.18. Service greement
0 Ser"ice 0greement is a general agreement outlining ser"ices to be $ro"ided= as &ell as costs of ser"ices
and ho& they are to be billed. 0 ser"ice agreement may be initiated bet&een S4<#SD and another agency
or a non@state go"ernment entity. 0 ser"ice agreement is distinguished from a Ser"ice 1e"el 0greement in
that there are no ongoing ser"ice le"el targets identified in a Ser"ice 0greement.
1.%.11. Service 9evel greement
ften referred to as the S10= the Ser"ice 1e"el 0greement is the agreement bet&een S4 #SD and the
customer outlining ser"ices to be $ro"ided= and o$erational su$$ort le"els as &ell as costs of ser"ices and
ho& they are to be billed.
1.%.1&. Service 9evel *arget
Ser"ice 1e"el Target is a commitment that is documented in a Ser"ice 1e"el 0greement. Ser"ice 1e"el
Targets are based on Ser"ice 1e"el (e>uirements= and are needed to ensure that the #T Ser"ice continues
to meet the original Ser"ice 1e"el (e>uirements. Ser"ice 1e"el Targets are rele"ant in that they are tied to
#ncidents and 0ssistance Ser"ice (e>uests. There are no targets tied to Problem 3anagement.
1.%.1#. Severit/
Se"erity is determined by ho& much the user is restricted from $erforming their &or5. There are three
grades of se"erity;
3 @ 1o& @ #ssue $re"ents the user from $erforming a $ortion of their duties.
2 @ 3edium @ #ssue $re"ents the user from $erforming critical time sensiti"e functions
1 @ Aigh @ Ser"ice or ma!or $ortion of a ser"ice is una"ailable
The se"erity of a $roblem &ill be used in determining the $riority for resolution.
1.-. Problem Scope
Problem 3anagement includes the acti"ities re>uired to diagnose the root cause of incidents and to
determine the resolution to those $roblems. #t is also res$onsible for ensuring that the resolution is
im$lemented through the a$$ro$riate control $rocedures= es$ecially Change 3anagement and (elease
3anagement.
Problem 3anagement &ill also maintain information about $roblems and the a$$ro$riate &or5arounds and
resolutions= so that the organi8ation is able to reduce the number and im$act of incidents o"er time. #n this
res$ect= Problem 3anagement has a strong interface &ith %no&ledge 3anagement= and tools such as the
%no&n 'rror Database &ill be used for both.
0lthough #ncident and Problem 3anagement are se$arate $rocesses= they are closely related and &ill
ty$ically use the same tools= and use the same categori8ation= im$act and $riority coding systems. This &ill
ensure effecti"e communication &hen dealing &ith related incidents and $roblems.
1.-.1. E:clusions
(e>uest fulfillment= i.e.= Ser"ice (e>uests and Ser"ice Catalog (e>uests are not handled by this $rocess.
#nitial incident handling to restore ser"ice is not handled by this $rocess. (efer to #ncident 3anagement.
1... Inputs an" Outputs
Input From
Problem Ser"ice Des5= Problem 3anagement Team= Ser"ice
Pro"ider 7rou$
Categori8ation Tables 4unctional 7rou$s
0ssignment (ules 4unctional 7rou$s
Output *o
Standard notification to the $roblem re$orter and 60
&hen case is closed
Problem (e$orter= 60 3anager
1.'. Metrics
3etric
Purpose
Process trac5ing metrics
B of Problems by ty$e= status= and customer C see
detail under Reports an" Meetings
To determine if $roblems are being $rocessed in
reasonable time frame= fre>uency of s$ecific ty$es of
$roblems= and determine &here bottlenec5s e2ist.
$!apter &. Roles an" Responsibilities
(es$onsibilities may be delegated= but escalation does not remo"e res$onsibility from the indi"idual
accountable for a s$ecific action.
&.1. OSF IS3 Service 3es;
'nsure that all $roblems recei"ed by the Ser"ice Des5 are recorded in C(3
Delegates res$onsibility by assigning $roblems to the a$$ro$riate $ro"ider grou$ for resolution based u$on
the categori8ation rules
Performs $ost@resolution customer re"ie& to ensure that all &or5 ser"ices are functioning $ro$erly
&.&. <ualit/ ssurance
&ns all re$orted $roblems
#dentify nature of $roblems based u$on re$orted sym$toms and categori8ation rules su$$lied by $ro"ider
grou$s
Prioriti8e $roblems based u$on im$act to the users and S10 guidelines
(es$onsible for $roblem closure
Pre$are re$orts sho&ing statistics of $roblems resol"ed < unresol"ed
&.#. Service Provi"er =roup
Com$osed of technical and functional staff in"ol"ed in su$$orting ser"ices
Perform root cause analysis of the $roblem and de"elo$ $otential solutions
Test $otential solutions and de"elo$ im$lementation $lan
&.%. Problem Reporter
0nyone &ithin S4 < #SD can re>uest a $roblem case to be o$ened.
The ty$ical sources for $roblems are the Ser"ice Des5= Ser"ice Pro"ider 7rou$s= and $roacti"e $roblem
management through 6uality 0ssurance.
&.-. Problem Management Revie, *eam
This may be multi$le teams de$ending u$on the ser"ice su$$orted
Com$osed of technical and functional staff in"ol"ed in su$$orting ser"ices= Ser"ice Des5= and 6uality
0ssurance
$!apter #. Problem $ategori(ation) *arget *imes)
Prioriti(ation) an" Escalation
#n order to ade>uately determine if S10?s are met= it &ill be necessary to correctly categori8e and $rioriti8e
$roblems >uic5ly.
#.1. $ategori(ation
The goals of $ro$er categori8ation are;
Identify Service impacted
Associate problems with related incidents
Indicate what support groups need to be involved
Provide meaningful metrics on system reliability
4or each $roblem the s$ecific ser"ice 9as listed in the $ublished Ser"ice Catalog: &ill be identified. #t is
critical to establish &ith the user the s$ecific area of the ser"ice being $ro"ided. 4or e2am$le= if it?s
Peo$leSoft= is it 4inancial= Auman (esources= or another area? #f it?s Peo$leSoft 4inancials= is it for
7eneral 1edger= 0ccounts Payable= etc.? #dentifying the ser"ice $ro$erly establishes the a$$ro$riate
Ser"ice 1e"el 0greement and rele"ant Ser"ice 1e"el Targets.
#n addition= the se"erity and im$act of the $roblem need to also be established. 0ll $roblems are im$ortant
to the user= but $roblems that affect large grou$s of $ersonnel or mission critical functions need to be
addressed before those affecting 1 or 2 $eo$le.
Does the $roblem cause a &or5 sto$$age for the user or do they ha"e other means of $erforming their !ob?
0n e2am$le &ould be a bro5en lin5 on a &eb $age is an incident but if there is another na"igation $ath to the
desired $age= the incident?s se"erity &ould be lo& because the user can still $erform the needed function.
The $roblem may create a &or5 sto$$age for only one $erson but the im$act is far greater because it is a
critical function. 0n e2am$le of this scenario &ould be the $erson $rocessing $ayroll ha"ing an issue &hich
$re"ents the $ayroll from $rocessing. The im$act affects many more $ersonnel than !ust the user.
#.&. Priorit/ 3etermination
The $riority gi"en to a $roblem that &ill determine ho& >uic5ly it is scheduled for resolution &ill be set
de$ending u$on a combination of the related incidents? se"erity and im$act.
Problem Priorit/ Severit/
3 @ 1o&
#ssue $re"ents
the user from
$erforming a
$ortion of their
duties.
2 @ 3edium
#ssue $re"ents the
user from
$erforming critical
time sensiti"e
functions
1 @ Aigh
Ser"ice or ma!or
$ortion of a
ser"ice is
una"ailable
I
m
p
a
c
t
#

>

9
o
,
ne or t&o
$ersonnel
Degraded
Ser"ice
1e"els but
still
$rocessing
&ithin S10
constraints
# > 9o, # > 9o, & > Me"ium
&

>

M
e
"
i
u
m
3ulti$le
$ersonnel
in one
$hysical
location
Degraded
Ser"ice
1e"els but
not
$rocessing
&ithin S10
constraints
or able to
$erform
only
minimum
le"el of
ser"ice
#t a$$ears
cause of
incident
falls across
multi$le
functional
areas
& > Me"ium & > Me"ium 1 > ?ig!
1

>

?
i
g
!0ll users of
a s$ecific
ser"ice
Personnel
from
multi$le
agencies
are affected
Public
facing
ser"ice is
una"ailable
0ny item
listed in the
Crisis
(es$onse
tables
1 > ?ig! 1 > ?ig! 1 > ?ig!
#.#. 0or;aroun"s
#n some cases it may be $ossible to find a &or5around to the incidents caused by the $roblem C a tem$orary
&ay of o"ercoming the difficulties. 4or e2am$le= an S61 may be may be run against a file to allo& a $rogram
to com$lete its run successfully and allo& a billing $rocess to com$lete satisfactorily.
#n some cases= the &or5around may be instructions $ro"ided to the customer on ho& to com$lete their &or5
using an alternate method. These &or5arounds need to be communicated to the Ser"ice Des5 so they can
be added to the %no&ledge *ase and therefore be accessible by the Ser"ice Des5 to facilitate resolution
during future recurrences of the incident.
#n cases &here a &or5around is found= it is im$ortant that the $roblem record remains o$en and details of
the &or5around are al&ays documented &ithin the Problem (ecord.
#.%. 5no,n Error Recor"
0s soon as the diagnosis is far enough along to clearly identify the $roblem and its sym$toms= and
$articularly &here a &or5around has been found 9e"en though it may not yet be a $ermanent resolution:= a
%no&n 'rror (ecord must be raised and $laced in the %no&n 'rror tables &ithin C(3 C so that if further
incidents or $roblems arise= they can be identified and the ser"ice restored more >uic5ly.
Ao&e"er= in some cases it may be ad"antageous to raise a %no&n 'rror (ecord e"en earlier in the o"erall
$rocess C !ust for information $ur$oses= for e2am$le C e"en though the diagnosis may not be com$lete or a
&or5around found.
The 5no&n error record must contain all 5no&n sym$toms so that &hen a ne& incident occurs= a search of
5no&n errors can be $erformed and find the a$$ro$riate match.
#.-. Ma4or Problem Revie,
'ach ma!or 9$riority 1: $roblem &ill be re"ie&ed on a &ee5ly basis to determine $rogress made and &hat
assistance may be needed. The re"ie& &ill include;
Which configuration items failed
S$ecifics about the failure
'fforts to&ard root cause analysis are being ta5en
Solutions are being considered
Time frame to im$lement solution
What could be done better in the future to identify the issue for earlier correction
Ao& to $re"ent recurrence
Whether there has been any third@$arty res$onsibility and &hether follo&@u$ actions are needed.
0ny lessons learned &ill be documented in a$$ro$riate $rocedures= &or5 instructions= diagnostic scri$ts or
%no&n 'rror (ecords. The Problem 3anager 96uality 0ssurance 3anager: facilitates the session and
documents any agreed actions.
$!apter %. Process Flo,
The follo&ing is the standard $roblem management $rocess flo& outlined in #T#1 Ser"ice $eration but re$resented as a s&im lane chart &ith associated roles &ithin S4
#SD.

Problem 3anagement Process
%.1. Problem Management Process Flo, Steps
Role Step 3escription
Problem
Reporter
Problems can be re$orted by any grou$ &ithin S4<#SD that has the
o$$ortunity to recogni8e a situation that is li5ely to create incidents. The
Ser"ice Des5 or the Ser"ice Pro"ider 7rou$ may recogni8e there is a
$roblem because of multi$le related incidents. 6uality 0ssurance or other
grou$s may do trend analysis to identify $otential recurring issues.
Problem
Management
Revie, *eam
Problem detection
#t is li5ely that multi$le &ays of detecting $roblems &ill e2ist in all
organi8ations. These &ill include;
D Sus$icion or detection of an un5no&n cause of one or more incidents by
the Ser"ice Des5= resulting in a Problem (ecord being raised C the des5
may ha"e resol"ed the incident but has not determined a definiti"e cause
and sus$ects that it is li5ely to recur= so &ill raise a Problem (ecord to
allo& the underlying cause to be resol"ed. 0lternati"ely= it may be
immediately ob"ious from the outset that an incident= or incidents= has
been caused by a ma!or $roblem= so a Problem (ecord &ill be raised
&ithout delay.
D 0nalysis of an incident by a technical su$$ort grou$ &hich re"eals that
an underlying $roblem e2ists= or is li5ely to e2ist.
D 0utomated detection of an infrastructure or a$$lication fault= using
e"ent<alert tools automatically to raise an incident &hich may re"eal the
need for a Problem (ecord.
D 0nalysis of incidents as $art of $roacti"e Problem 3anagement C
resulting in the need to raise a Problem (ecord so that the underlying fault
can be in"estigated further.
Problem
Management
Revie, *eam
Problem 1ogging
(egardless of the detection method= all the rele"ant details of the $roblem
must be recorded so that a full historic record e2ists. This must be date
and time stam$ed to allo& suitable control and escalation.
0 cross@reference must be made to the incident9s: &hich initiated the
Problem (ecord C and all rele"ant details must be co$ied from the
#ncident (ecord9s: to the Problem (ecord. #t is difficult to be e2act= as
cases may "ary= but ty$ically this &ill include details such as;
D Eser details
D Ser"ice details
D '>ui$ment details
D Date<time initially logged
D Priority and categori8ation details
D #ncident descri$tion
D Details of all diagnostic or attem$ted reco"ery actions ta5en.
Problem Categori8ation
Problems must be categori8ed in the same &ay as incidents using the
same codes so that the true nature of the $roblem can be easily tied to the
su$$orted ser"ice and related incidents.
23),+).//.doc Page 12 of 1)
Problem 3anagement Process
Role Step 3escription
Problem Prioriti8ation
Problems must be $rioriti8ed in the same &ay and for the same reasons
as incidents C but the fre>uency and im$act of related incidents must also
be ta5en into account. *efore a $roblem $riority can be set= the se"erity
and im$act need to be assessed. See $aragra$h 3.2 #ncident
Prioriti8ation. nce the se"erity and im$act are set= the $riority can be
deri"ed using the $rescri$ti"e table.
Solution
Provi"er =roup
Problem #n"estigation and Diagnosis
0n in"estigation should be conducted to try to diagnose the root cause of
the $roblem C the s$eed and nature of this in"estigation &ill "ary
de$ending u$on the $riority.
Wor5arounds
#n some cases it may be $ossible to find a &or5around to the incidents
caused by the $roblem C a tem$orary &ay of o"ercoming the difficulties. #n
cases &here a &or5around is found= it is im$ortant that the $roblem record
remains o$en= and details of the &or5around are al&ays documented
&ithin the Problem (ecord.
(aising a %no&n 'rror (ecord
0s soon as the diagnosis has $rogressed enough to 5no& &hat the
$roblem is e"en though the cause may not yet be identified= a %no&n
'rror (ecord must be raised and $laced in the %no&n 'rror Database C so
that if further incidents arise= they can be identified and related to the
$roblem record.
Aas the root cause been determined and a solution identified?
Problem resolution
0s soon as a solution has been found and sufficiently tested= it should be
fully documented and $re$ared for im$lementation.
Problem
Management
Revie, *eam @
$!ange
Management @
Solution
Provi"er =roup
Changes to $roduction to im$lement the solution need to be scheduled
and a$$ro"ed through the Change 3anagement $rocess.
Problem
Management
Revie, *eam
Problem Closure
When any change has been com$leted 9and successfully re"ie&ed:= and
the resolution has been a$$lied= the Problem (ecord should be formally
closed C as should any related #ncident (ecords that are still o$en. 0
chec5 should be $erformed at this time to ensure that the record contains
a full historical descri$tion of all e"ents C and if not= the record should be
u$dated.
The status of any related %no&n 'rror (ecord should be u$dated to
sho&n that the resolution has been a$$lied.
Service Provi"er
=roup Managers
A $*O
Wee5ly re"ie& of the status of o$en ma!or 9$riority 1: $roblems 9See
Paragra$h 3.) 3a!or Problem (e"ie&:
23),+).//.doc Page 13 of 1)
Problem 3anagement Process
$!apter -. R$I $!art
Obligation Role 3escription
Res$onsible (es$onsible to $erform the assigned tas5
ccountable 9only 1 $erson: 0ccountable to ma5e certain &or5 is assigned and $erformed
$onsulted Consulted about ho& to $erform the tas5 a$$ro$riately
Informed #nformed about 5ey e"ents regarding the tas5
ctivit/ Service 3es;
Service
3es; Mgr
Service
Provi"er
=roup
Service
Provi"er
=roup Mgr
<
Manager
(ecord Problem in C(3 ( 0 # # C
Categori8e $roblem according to ser"ice and $riority C # ( 0 #
Perform (oot Cause 0nalysis # ( 0 #
De"elo$ Solution # # ( 0 #
Document conditions for 5no&n $roblem record # # ( 0 #
Create 5no&n $roblem record ( 0 C # #
Document &or5around solution # # ( 0 #
'nter &or5around solutions into 5no&ledge base ( 0 C # #
E$date C(3 &ith current status on $roblem
analysis F resolution # # ( 0 #
Gerify solution &ith customer ( 0 C C #

23),+).//.doc Page 14 of 1)
Problem 3anagement Process
$!apter .. Reports an" Meetings
0 critical com$onent of success in meeting ser"ice le"el targets is for S4 < #SD to hold itself
accountable for de"iations from acce$table $erformance. This &ill be accom$lished by $roducing
meaning re$orts that can be utili8ed to focus on areas that need im$ro"ement. The re$orts must then
be used in coordinated acti"ities aimed at im$ro"ing the su$$ort.
..1. Reports
..1.1. Service Interruptions
0 re$ort sho&ing all $roblems related to ser"ice interru$tions &ill be re"ie&ed &ee5ly during the
o$erational meeting. The $ur$ose is to disco"er ho& serious the $roblem &as= &hat ste$s are being
ta5en to $re"ent reoccurrence= and if root cause needs to be $ursued.
..1.&. Metrics
3etrics re$orts should generally be $roduced monthly &ith >uarterly summaries. 3etrics to be
re$orted are;
Total numbers of problems (as a control measure)
Breakdown of problems at each stage (e.g. logged, work in progress, closed etc)
Size of current problem backlog
Number and percentage of major problems
..1.#. Meetings
The 6uality 0ssurance 3anager &ill conduct sessions &ith each ser"ice $ro"ider grou$ to re"ie&
$erformance re$orts. The goal of the sessions is to identify;
Status of $re"iously identified $roblems
#dentification of &or5 around solutions that need to be de"elo$ed until root cause can be corrected
Discussion of ne&ly identified $roblems
23),+).//.doc Page 1) of 1)
Problem 3anagement Process
$!apter '. Problem Polic/
The Problem $rocess should be follo&ed to find and correct the root cause of significant or recurring
incidents.
Problems should be $rioriti8ed based u$on im$act to the customer and the a"ailability of a
&or5around.
Problem &nershi$ remains &ith 6uality 0ssuranceH (egardless of &here a $roblem is referred to
during its life= o&nershi$ of the $roblem remains &ith the 6uality 0ssurance at all times. 6uality
0ssurance remains res$onsible for trac5ing $rogress= 5ee$ing users informed and ultimately for
Problem Closure.
(ules for re@o$ening $roblems @ Des$ite all ade>uate care= there &ill be occasions &hen $roblems
recur e"en though they ha"e been formally closed. #f the related incidents continue to occur under the
same conditions= the $roblem case should be re@o$ened. #f similar incidents occur but the conditions
are not the same= a ne& $roblem should be o$ened.
Wor5 arounds should be in conformance &ith S4 #SD standards and $olicies.
23),+).//.doc Page 1+ of 1)