OSF Service Support

magazinebindManagement

Nov 6, 2013 (3 years and 10 months ago)

73 views





OSF Service Support





Problem Management

Process




[Version 1.1]





Table of Contents

About this document

................................
................................
................................
............

1

Chapter 1. Problem Process

................................
................................
................................

2

1.1.

Primary goal

................................
................................
................................
...................

2

1.2.

Process Definition

................................
................................
................................
..........

2

1.3.

Objectives

................................
................................
................................
......................

2

1.4.

Definitions

................................
................................
................................
......................

2

1.4.1. Impact

................................
................................
................................
..................

2

1.4.2. Incident

................................
................................
................................
................

2

1.4.3. Known Error Record

................................
................................
............................

3

1.4.4. Knowledge Base

................................
................................
................................
.

3

1.4.5. Problem

................................
................................
................................
...............

3

1.4.6. Problem Repository

................................
................................
.............................

3

1.4.7. Priority

................................
................................
................................
.................

3

1.4.8. Response

................................
................................
................................
............

3

1.4.9. Resolution

................................
................................
................................
............

3

1.4.10. Service Agreement

................................
................................
............................

3

1.4.11. Service Level Agreement

................................
................................
..................

3

1.4.12. Service Level Targ
et

................................
................................
.........................

3

1.4.13. Severity

................................
................................
................................
..............

4

1.5.

Problem Scope

................................
................................
................................
..............

4

1.5.1. Exclusions

................................
................................
................................
...........

4

1.6.

Inputs and Outputs

................................
................................
................................
........

4

1.7.

Metrics

................................
................................
................................
...........................

4

Chapter 2. Roles and Responsibilities

................................
................................
...............

5

2.1.

OSF ISD Service Desk

................................
................................
................................
..

5

2.2.

Quality Assurance

................................
................................
................................
..........

5

2.3.

Service Provider Group

................................
................................
................................
.

5

2.4.

Problem Reporter

................................
................................
................................
..........

5

2.5.

Problem Management Review Team

................................
................................
............

5

Chapter

3. Problem Categorization, Target Times, Prioritization, and Escalation

........

6

3.1.

Categorization

................................
................................
................................
................

6

3.2.

Priority Determination

................................
................................
................................
....

6

3.3.

Workarounds
................................
................................
................................
..................

8

3.4.

Known Error Reord

................................
................................
................................
........

8

3.5.

Major Problem Review

................................
................................
................................
...

8

Chapter 4. Process Flow

................................
................................
................................
......

9

4.1.

Problem Management Process Flow Steps

................................
................................

10

Chapter 5. RACI Chart

................................
................................
................................
........

12

Chapter 6. Reports and Meetings

................................
................................
.....................

13

6.1.

Reports

................................
................................
................................
........................

13

6.1.1. Service Interruptions

................................
................................
.........................

13

6.1.2. Metrics

................................
................................
................................
...............

13

6.1.3. Meetings

................................
................................
................................
............

13

Chapter 7. Problem Policy

................................
................................
................................
.

14


magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
1

of 15

About this document

This document describes the

Problem

Process
.
The
P
rocess provides a
consistent method

for everyone to
follow when

working to resolve severe or recurring issues

regarding
s
ervice
s

from the
Office of State
Finance
Inf
ormation Services Division

(OSF ISD).

Who should use this document
?

This document should be used by:

OSF ISD

personnel responsible for the
restoration of

services

and analysis and remediation of root
cause of problem

OSF ISD

personnel involved in the opera
tion and management of
Problem

Process


Summary of changes

This section records the history of significant changes to this document
.
Only the most significant changes
are described here.


Version

Date

Author

Description of change

1.0

1/14/2011

OW Thomass
on

Initial version






Where significant changes are made to this document, the version number will be incremented by 1.0
.

Where changes are made for clarity and reading ease only and no change is made to the meaning or
intention of this document, the

version number will be increased by 0.1.

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
2

of 15

Chapter 1.
Problem

Process

1.1.
Primary goal

Problem Management is the process responsible for managing the lifecycle of all problems. The primary
objectives of Problem Management are to
:



prevent problems and resu
lting incidents from happening.



eliminate recurring incidents.



minimize the impact of incidents that cannot be prevented.

1.2.
Process Definition

Problem Management includes the activities required to diagnose the root cause of incidents and to
determine t
he res
olution

to those problems. It is also responsible for ensuring that the resolution is
implemented through the appropriate control procedures.

1.3.
Objectives


Provide a
consistent process

to
track

Problem
s
that ensures
:



Problem
s are properly
logged



Problem
s are properly
routed



Problem

status is accurately reported



Queue of un
resolved

Problem
s is visible and reported



Problem
s are properly prioritized

and handled in the appropriate sequence



Resolution

provided meets the requirements
of the SLA for

th
e
customer

1.4.
De
finitions

1.4.1.
Impact

Impact is determined by how many personnel or functions are affected. There are three grades of impact:



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 se
rvice
.

Personnel from multiple agencies are affected
.
Public facing
service is unavailable

The
impact

of
the incidents associated with a

problem

will be used in determining the priority for resolution
.

1.4.2
Incident

An
incident is an
unplanned interruptio
n to an IT Service or reduction in the Quality of an IT Service.
Failure
of
any Item, software or hardware, used in the support of a system
that has not yet affected
s
ervice is also
an Incident. For example, the failure of one
component of a redundant high

availability configuration

is an
incident even though it does not interrupt service.


An incident occurs when
the operational status of a production item changes from working to failing or about
to fail, resulting in a condition in which the item is not f
unctioning as it was designed or implemented.
The
resolution for an incident involves im
plementing a repair to restore
t
he item

to its original state.

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
3

of 15

A design flaw does not create an incident. If the product is working as designed, even though the desi
gn is
not correct, the correction needs to take the form of a service request to modify the design.

The service
request may be expedited based upon the need, but it is still a modification, not a repair.

1.4.3.
Known Error Record

An entry in a table in CR
M which includes the symptoms related to open problems and the incidents the
problem is known to create. If available, the entry will also have a link to entries in the Knowledge Base
which show potential work arounds to the problem.

1.4.4.
Knowledge B
ase

A database housed within CRM that contains information on how to fulfill requests and resolve incidents
using previously proven methods / scripts.

1.4.5
Problem

A problem is the underlying cause of an incident.

1.4.6.
P
roblem

Repository

The
Probl
em

Repository is a database containing relevant information about all
problem
s

whether they
have
been
resolved

or not. General status information along with notes related to activity should also be
maintained in a format that supports standardized reporti
ng.

At OSF ISD, the
Problem

R
epository is
contained within PeopleSoft CRM.

1.4.7.
Priority

Priority is determined by utilizing a combination of the
problem
’s impact and severity.
For a full explanation
of the determination of priority refer to the paragr
aph titled Priority Determination.

1.4.8.
Response

Time elapsed between the time the
problem

is reported and the time it is assigned to an individual for
resolution.

1.4.9.
Resolution

The root cause of incidents is corrected so that the related incidents d
o not continue to occur.

1.4.10.
Service Agreement

A
Service Agreement is a
general agreement outlining services to be provided, as well as costs of services
and how they are to be billed. A service agreement may be initiated between OSF/ISD and another a
gency
or a non
-
state government entity.

A service agreement is distinguished from a Service Level Agreement in
that there are no
ongoing
s
ervice level targets identified in a Service Agreement.

1.4.11.
Service Level Agreement

Often referred to as the SLA,

the Service Level Agreement is the
agreement

between OSF

ISD

and
the
customer

outlining services to be provided, and operational support levels as well as costs of services and
how they are to be billed.

1.4.12.
Service Level Target

Service Level Target i
s a

commitment that is documented in a Service Level Agreement. Service Level
Targets are based on Service Level Requirements, and are needed to ensure that the IT Service
continues
to meet the original Service Level Requirements.


Service Level Targets a
re relevant in that they are tied to
Incidents and Assistance Service Requests. There are no targets tied to
P
roblem
Management
.

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
4

of 15

1.4.13.
Severity

Severity is determined by how much the user is restricted from performing their work. There are three
grade
s of severity:

3
-

Low

-

Issue prevents the user from performing a portion of their duties.

2
-

Medium

-

Issue prevents the user from performing critical time sensitive functions

1
-

High

-

Service or major portion of a service is unavailable

The severity

of a

problem

will be used in determining the priority

for resolution
.

1.5.
Problem

Scope

Problem Management includes the activities required to diagnose the root cause of incidents and to
determine the resolution to those problems. It is also responsible
for ensuring that the resolution is
implemented through the appropriate control procedures, especially Change Management and Release
Management.

Problem Management will also maintain information about problems and the appropriate workarounds and
resolution
s, so that the organization is able to reduce the number and impact of incidents over time. In this
respect, Problem Management has a strong interface with Knowledge Management, and tools such as the
Known Error Database will be used for both.

Although Inc
ident and Problem Management are separate processes, they are closely related and will
typically use the same tools, and use
the same

categorization, impact and priority coding systems. This will
ensure effective communication when dealing with related inc
idents and problems.

1.5.1.
Exclusions

Request
fulfillment
, i.e., Service Requests and Service Catalog Requests are

not handled by this process
.

Initial

incident
handling to restore service
is not handled by this process. Refer to
Incident

Management.

1.6.
Inputs and Outputs


Input

From

Problem

Service Desk, Problem Management Team, Service
Provider Group

Categorization Tables

Functional Groups

Assignment

Rules

Functional Groups


Output

To

Standard notification to the
problem reporter and QA

when c
ase is closed

Problem Reporter, QA Manager



1.7.
Metrics


Metric

Purpose

Process

tracking metrics

# of
Problem
s by
type,
status
,

and
customer



see
detail under
Reports and Meetings

To determine if
problem
s are being processed

in
reasonable time frame
, frequency of specific types of
problem
s,

and determine where bottlenecks exist.

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
5

of 15

Chapter 2.
Roles and Responsibilities

Responsibilities may be delegated, but
escalation

does not remove responsibility from the individual
account
able for a specific action.

2.1.
OSF ISD

Service Desk

Ensure that
all

problem
s
received by the
Service Desk

are
recorded in CRM

Delegates responsibility by a
ssign
ing

problem
s to the appropriate
provider
group for resolution based upon
the categorization ru
les

Performs post
-
resolution customer review to ensure that all work services are functioning properly

2.2.
Quality Assurance

Owns all reported
problem
s

Identify nature of
problem
s based upon reported symptoms and categorization rules supplied by provide
r
groups

Prioritize
problem
s based upon impact to the users and SLA guidelines

Responsible for
problem

closure

Prepare reports showing statistics of
problem
s resolved / unresolved

2.3.
Service Provider Group

Composed of
technical and functional staff

invol
ved in
supporting services

Perform root cause analysis of the problem and develop potential solutions

Test potential solutions and develop implementation plan

2.4.
Problem Reporter

Anyone within OSF / ISD can request a problem case to be opened.

The typica
l sources for problems are the Service Desk, Service Provider Groups, and proactive problem
management through Quality Assurance
.

2.5.
Problem Management Review Team

This may be multiple teams depending upon the service supported

Composed of technical and
functional staff involved in supporting services
, Service Desk, and Quality
Assurance

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
6

of 15

Chapter 3.
Problem

Categorization
, Target Times,
Prioritization
, and Escalation

In order to adequately determine if SLA’s are met, it will be necessary to correctly cate
gorize and prioritize
problem
s quickly
.

3.1.
Categorization

The goals of proper categorization are:



Identify Service impacted



Associate problems with related incidents



Indicate what support groups need to be involved



Provide meaningful metrics on system r
eliability

For each
problem

the specific service (as listed in the published Service Catalog) will be identified.

It is
critical to establish with the user the specific area of the service being provided.

For example, if it’s
PeopleSoft, is it Financial
, Human Resources, or another area? If it’s PeopleSoft Financials, is it for
General Ledger, Accounts Payable, etc.? Identifying the service properly establishes the appropriate
Service Level Agreement and relevant Service Level Targets.

In addition, th
e severity and impact of the
problem

need to also be established.

All
problem
s are important
to the user, but
problem
s that affect large groups of personnel or mission critical functions need to be
addressed before those affecting 1 or 2 people.

Does th
e
problem

cause a work stoppage for the user or do they have other means of performing their job?
An example would be a broken link on a web page is an incident but if there is another navigation path to the
desired page, the incident’s severity would be
low because the user can still perform the needed function.

The
problem

may create a work stoppage for only one person but the impact is far greater because it is a
critical function. An example of this scenario would be the person processing payroll havi
ng an issue which
prevents the payroll from processing. The impact affects many more personnel than just the user.

3.2.
Priorit
y Determin
ation

The priority given to a
problem

that will determine how quickly it is scheduled for resolution will be set
depen
ding upon a combination of the
related
incident
s’

severity and impact.

Problem

Priority

Severity

3
-

Low

Issue prevents
the user from
performing a
portion of their
duties.

2
-

Medium

Issue prevents the
user from
performing critical
time sensitive
funct
ions

1
-

High

Service or major
portion of a
service is
unavailable

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
7

of 15

Impact

3
-

Low

One or two
personnel

Degraded
Service
Levels but
still
processing
within SLA
constraints

3
-

Low

3
-

Low

2
-

Medium

2
-

Medium

Multiple
personnel
in one
physical
location

Degraded
Service
Levels but
not
processing
within SLA
constraints
or able to
perform
only
minimum
level of
service

It appears
cause of
incident
falls across
multiple
functional
areas

2
-

Medium

2
-

Medium

1
-

High

1
-

High

All users of
a specific
service

Personnel
from
multiple
agencies
are affected

Public
facing
service is
unavailable

Any item
listed in the
Crisis
Response
tables

1
-

High

1
-

High

1
-

High

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
8

of 15

3.3.
Workarounds

In some cases it may be possible to find a workaround to the incidents caused by

the problem


a temporary
way of overcoming t
he difficulties. For example, an SQL
may be ma
y be run against a

file to allow a program
to complete its run successfully and allow a billing process to complete satisfactorily
.


In some cases, the workaround

may be instructions provided to the customer on how to complete their work
using an alternate method. These workarounds need to be communicated to the Service Desk so they can
be added to the Knowledge Base and therefore be accessible by the Service Desk

to facilitate resolution
during future recurrences of the incident.

In cases where a workaround is found, it is important that the problem record remains
open

and details of
the workaround are always documented within the Problem Record.

3.4.
Known Error
Record

As soon as the diagnosis is
far enough along to clearly identify the problem and its symptoms
, and
particularly where a workaround has been found (even though it may not yet be a permanent resolution), a
Known Error Record must be raised and placed
in the Known Error
tables within CRM



so that if further
incidents or problems arise, they can be identified and the service restored more quickly.

However, in some cases it may be advantageous to raise a Known Error Record even earlier in the overall
pro
cess


just for information purposes, for example


even though the diagnosis may not be complete or a
workaround found.

The known error record must contain all known symptoms so that when a new incident occurs, a search of
known errors can be performed a
nd find the appropriate match.

3.5.
Major Problem Review

Each
major
(
priority 1
)

problem

will be reviewed on a weekly basis to determine progress made and what
assistance may be needed. The review will include
:

Which configuration items failed

Specifics a
bout the failure


Efforts toward root cause analysis are being taken

Solutions are being considered


Time frame to implement solution

What could be done better in the future
to identify the issue for earlier correction

How to prevent recurrence

Whether th
ere has been any third
-
party responsibility and whether follow
-
up actions are needed.

A
ny lessons learned
will

be documented in appropriate procedures, work instructions, diagnostic scripts or
Known Error Records. The Problem Manager
(Quality Assurance Man
ager)
facilitates the session and
documents any agreed actions.

Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
9

of
15

Chapter 4.
Process Flow

The following is the standard
problem

management

process flow outlined in ITIL Service Operation but represented as a swim lane chart with associated roles within OSF

ISD.


Problem Management Process Flow
Solution Provider Group
Problem Management
Review Team
Problem
Reporter
Yes
7
Work
Around
?
4
Categorization
1
c
Proactive Problem
Management
1
a
Service Desk
1
b
Service Provider
Group
2
Problem Detection
3
Problem Logging
5
Prioritization
6
Investigation
&
Diagnosis
8
Create Known
Error Record
Known Error
Database
9
Solution
?
10
Resolution
12
Closure
End
11
Change
Management
No
13
Major
Problem
Review
Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc

Page
10

of
15





4.1.
Problem

Management Process Flow Steps

Role

Step

Description

Problem
Reporter





Problem
s can be reported by
any group within OSF/ISD that has the
opportunity to recognize a situation that is likely to create inciden
ts. The
Service Desk or the Service Provider Group may recognize there is a
problem because of multiple related incidents. Quality Assurance or other
groups may do trend analysis to identify potential recurring issues.

Problem
Management
Review Team




Pr
oblem detection

It is likely that multiple ways of detecting problems will exist in all
organizations. These will include:



Suspicion or detection of an unknown cause of one or more incidents by
the Service Desk, resulting in a Problem Record being raised


the desk
may have resolved the incident but has not determined a definitive cause
and suspects that it is likely to recu
r, so will raise a Problem Record to
allow the underlying cause to be resolved. Alternatively, it may be
immediately obvious from the outset that an incident, or incidents, has
been caused by a major problem, so a Problem Record will be raised
without dela
y.



Analysis of an incident by a technical support group which reveals that
an underlying problem exists, or is likely to exist.



Automated detection of an infrastructure or application fault, using
event/alert tools automatically to raise an incident which

may reveal the
need for a Problem Record.



Analysis of incidents as part of proactive Problem Management


resulting in the need to raise a Problem Record so that the underlying fault
can be investigated further.

Problem
Management
Review Team




Problem
Logging

Regardless of the detection method, all the relevant details of the problem
must be recorded so that a full historic record exists. This must be date
and time stamped to allow suitable control and escalation.

A cross
-
reference must be made to the i
ncident(s) which initiated the
Problem Record


and all relevant details must be copied from the
Incident Record(s) to the Problem Record. It is difficult to be exact, as
cases may vary, but typically this will include details such as:



User details



Service details



Equipment details



Date/time initially logged



Priority and categorization details



Incident description



Details of all diagnostic or attempted recovery actions taken.




Problem Categorization

Problems must b
e categorized in the same way as incidents us
ing the
same codes
so that the true nature of the problem can be easily
tied to the
supported service and related incidents.

Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc

Page
11

of
15





Role

Step

Description




Pr潢l敭⁐ri潲楴iz慴a潮

Pr潢l敭s m畳琠t攠eri潲楴ize搠dn⁴ e⁳慭攠eay⁡湤⁦潲⁴桥⁳a
m攠牥慳潮s
慳⁩湣i摥湴n


扵琠瑨攠er敱u敮cy 慮搠im灡c琠tf⁲敬慴ad⁩湣i摥湴n畳琠tls漠
扥⁴ k敮⁩湴n 慣c潵湴n
B敦潲攠愠oro扬敭⁰物潲楴y⁣a渠ne⁳整e⁴ e⁳敶敲楴y
慮搠im灡c琠t敥搠瑯tb攠ess敳s敤⸠⁓敥 灡r慧r慰栠㌮P 䥮fi摥湴n
mri潲o瑩z慴io渮n⁏湣攠e桥⁳ev敲楴y a
n搠dm灡c琠tr攠e整e⁴ 攠eri潲ity⁣慮 扥
摥riv敤 畳in朠gh攠er敳cri灴iv攠e慢l攮

Solution
Provider Group




Pr潢l敭⁉ v敳瑩条ti潮⁡ 搠䑩慧湯sis

A渠inv敳瑩条ti潮⁳桯ul搠扥 c潮摵c瑥搠d漠瑲y⁴漠oi慧湯s攠e桥⁲潯琠ta畳攠ef
瑨t⁰牯扬敭


瑨t⁳灥e搠dn搠d慴畲攠潦⁴ is

inv敳ti条瑩o渠will v慲y
摥灥湤i湧 異潮⁴桥
灲i潲楴y
.





Work慲潵湤s

䥮Is潭攠e慳敳⁩琠tay⁢攠eossi扬攠e漠oi湤 愠w潲o慲潵湤 瑯t瑨攠e湣i摥湴n
c慵s敤⁢y⁴桥⁰ 潢l敭


愠a敭灯r慲y 睡y  敲e潭i湧⁴ 攠eiffic畬瑩敳⸠.渠
c慳敳⁷h敲攠e w潲o慲潵湤 is⁦潵湤Ⱐi琠is

im灯r瑡t琠瑨慴a瑨t⁰牯扬敭⁲散潲搠
r敭慩湳 敮Ⱐ慮搠摥t慩ls 潦⁴ 攠w潲o慲潵湤 慲攠always 摯c畭敮瑥t
睩瑨i渠n桥 mr潢l敭⁒散潲搮




剡Rsi湧⁡⁋湯wn⁅rr潲⁒散潲搠

As⁳潯渠慳⁴ 攠摩慧n潳is
h慳⁰牯杲敳s敤 敮o畧h⁴ 湯w 睨慴⁴桥
灲潢p敭⁩s⁥ 敮 瑨t畧h⁴ e⁣慵s
攠eay 湯琠y整⁢ id敮tifi敤
Ⱐ愠a湯睮w
Err潲⁒散潲搠o畳琠t攠牡ese搠dn搠dl慣敤 i渠瑨t Know渠Err潲⁄慴o扡s攠


s漠o桡琠if⁦畲瑨敲⁩湣i摥湴n aris攬e瑨ty⁣a渠ne⁩摥湴ifi敤 慮搠
rel慴敤⁴漠oh攠
灲潢p敭⁲散潲搮




䡡H⁴ 攠牯潴oc慵s攠ee敮 d整ermi湥搠dn搠d⁳ol畴io渠nde
湴nfie搿




Pr潢l敭⁲敳潬畴uon

As
s潯渠慳⁡ s潬畴i潮 桡s⁢敥渠n潵nd

a湤⁳畦fici敮tly⁴敳瑥t
Ⱐi琠t桯畬搠de

f畬ly 摯c畭敮瑥t 慮搠灲数慲敤⁦潲⁩m灬敭敮瑡tio渮n

Problem
Management
Review Team /
Change
Management /
Solution
Provider Group




䍨慮来s⁴ 灲潤畣瑩
o渠n漠im灬em敮琠瑨攠eol畴i潮 湥e搠d漠扥⁳c桥d畬敤
慮搠慰灲pve搠d桲h畧栠hh攠䍨慮来 䵡n慧敭敮琠tr潣敳s.

Problem
Management
Review Team




Pr潢l敭⁃ 潳畲u

Wh敮⁡ y⁣h慮g攠e慳⁢ e渠n潭灬整e搠⡡湤⁳畣c敳s晵fly⁲eviewe搩Ⱐ慮搠
瑨t⁲敳ol畴i潮⁨ s⁢敥n⁡ 灬i敤Ⱐ瑨t
Pr潢l敭⁒散潲搠s桯畬搠de⁦潲m慬ly
cl潳敤


慳⁳桯ul搠慮y⁲ela瑥t⁉湣i摥湴no散潲摳⁴ a琠tr攠e瑩ll 敮⸠A
c桥ck⁳桯畬搠d攠灥rf潲o敤⁡ ⁴ is⁴ m攠e漠o湳畲攠瑨慴at桥⁲散潲搠oo湴ni湳
愠a畬l 桩s瑯tic慬 摥scri灴i潮 潦⁡ l 敶敮瑳


慮d⁩f 琬⁴ 攠牥e潲搠o桯畬d⁢

異摡瑥t.

q桥⁳瑡t畳 ⁡ y⁲敬a瑥t h湯w渠brr潲⁒散潲o⁳桯ul搠扥⁵灤慴敤⁴漠
s桯w渠n桡琠t桥⁲敳ol畴io渠n慳⁢ e渠np灬ie搮

Service Provider
Group Managers
& CTO




Weekly⁲eview

瑨t⁳瑡t畳

潰敮

m慪潲
灲楯rity‱⤠ r潢l敭s†⡓ 攠
P慲慧aa灨 ㌮3 䵡j潲⁐o潢l
敭⁒敶iew)


Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
12

of
15

Chapter 5.
RACI Chart

Obligation

Role Description

R
esponsible

Responsible to perform the assigned task

A
ccountable (only 1 person)

Accountable to make certain work is assigned and performed

C
onsulted

Consulted about how to perform the task

appropriately

I
nformed

Informed about key events regarding the task



Activity

Service Desk

Service
Desk Mgr

Service
Provider
Group

Service
Provider
Group Mgr

QA
Manager


Record Problem in CRM

R

A

I

I

C


Categorize problem according to service and pri
ority

C

I

R

A

I


Perform Root Cause Analysis


I

R

A

I


Develop Solution

I

I

R

A

I


Document conditions for known problem record

I

I

R

A

I


Create known problem record

R

A

C

I

I


Document workaround solution

I

I

R

A

I


Enter workaround solutions into
knowledge base

R

A

C

I

I


Update CRM with current status on problem
analysis & resolution

I

I

R

A

I


Verify solution with customer

R

A

C

C

I


Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc
Page
13

of
15

Chapter 6.
Reports

and Meetings

A critical component of
success in meeting service level targets is for OSF /
ISD to hold itself
accountable for deviations from acceptable performance. This will be accomplished by producing
meaning reports that can be utilized to focus on areas that need improvement. The reports must then
be used in coordinated activities aimed
at improving the support.

6.1.
Reports

6.1.1.
Service Interruptions

A report showing all
problem
s related to service interruptions will be reviewed weekly during the
operational meeting.

The purpose is to discover how serious the
problem

was, what steps
are being
taken to prevent reoccurrence, and if root cause needs to be pursued.

6.1.2.
Metrics

Metrics reports should generally be produced monthly with quarterly summaries. Metrics to be
reported are:



Total numbers of
problem
s (as a control measure)



Brea
kdown of
problem
s at each stage (e.g. logged, work in progress, closed etc)



Size of current
problem

backlog



Number and percentage of major
problem
s

6.1.3.
Meetings

The Quality Assurance Manager will conduct sessions with each service provider group to revi
ew
performance reports. The goal of the sessions is to identify
:


Status of previously identified problems

Identification of work around solutions that need to be developed until root cause can be corrected

Discussion of newly identified problems

Problem Management

Process

magazinebind_4a36004b
-
f7fb
-
4298
-
9564
-
81a426f68bf9.doc

Page
14

of
15





Chapter

7.
Problem

Policy

The
Problem

process should be followed to find and correct the root cause of significant or recurring
incidents.

Problem
s should be prioritized based upon impact to the customer and the availability of a
workaround.

Problem

Ownership remains with

Quality Assurance
!

Regardless of where a
problem

is referred to
during its life, ownership of the
problem

remains with the
Quality Assurance

at all times.
Quality
Assurance

remains responsible for tracking progress, keeping users i
nformed and ultimately for
Problem

Closure
.

Rules for re
-
opening
problem
s
-

Despite all adequate care, there will be occasions when
problem
s
recur even though they have been formally closed. If the
related incidents continue to occur under the
same condit
ions, the problem case should be re
-
opened.


If similar incidents occur but the conditions
are not the same, a new problem should be opened.

Work arounds should be in conformance with OSF ISD standards and policies.