Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 1 of 12
Project No: [Click here]
Contents
1.
2.
3.
4.
5.
6.
7.
8.
9.
8.
Purpose ............................................................................................................... 2
Scope .................................................................................................................. 2
Objective .............................................................................................................. 2
Structure .............................................................................................................. 2
Problem Management Responsibilities ............................................................... 3
Problem Management Workflow ......................................................................... 4
Problem Management Process ........................................................................... 5
Major Incident Workflow ...................................................................................... 8
Major Incident Process ........................................................................................ 9
Related Documents ........................................................................................... 12
INFORMATION ONLY - Refer to the online system for the current approved document
Quality
Page 2 of 12
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Project No: [Click here]
1. Purpose
The Purpose of this document is to describe the Problem Management Process in
operation within Company UK MIS department (MIS).
It is a reference document for all MIS staff, other IT support staff and management.
It documents the agreed procedure for the management and resolution of MIS
Problems logged via the Service Desk and internally within MIS.
N.B. A 'Problem' is the underlying cause of one or more Incidents.
2. Scope
The scope of Problem Management within IT support includes the logging,
management and resolution of IT Problems across all Company locations, including
the Service Desk, all 2nd and 3rd level Groups and other Abbott staff involved.
3. Objective
Problem Management is a wide ranging function covering a variety of diverse
activities, which have both short and long term aims. Problem Management’s
overall objective is getting to the root cause of Incidents, and then instigating actions
to improve or correct the situation. The System X Problem Management system will
be configured to easily distinguish between Incidents and Problems.
4. Structure
In the event of a Major Incident and the subsequent Post Mortem review, the role of
Problem Manager will be undertaken by a senior member of MIS, not required to be
directly involved in the technical resolution of the Major Incident. The most senior
member of MIS present will nominate this individual.
All other aspects of Problem Management will be shared amongst all IT Support
Groups, supported by the Service Desk team for day to day Problem tracking.
106732603
Edition No.1
Quality
Page 3 of 12
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Project No: [Click here]
5. Problem Management Responsibilities
MIS is a small department without a dedicated Problem Management team.
Therefore, Problem Management responsibilities will be shared between the
nominated Problem Managers, the Service Desk and 2 nd & 3rd level groups.
a. Reactive Responsibilities






Intervention when escalation times are exceeded - The Service Desk will be
automatically informed via System X, when escalation times are likely to be
exceeded so the appropriate action can be taken.
Arbitration where ownership of an Incident or Problem is in dispute – The
Service Desk will monitor for Incidents that may be ‘bounced’ between technical
domains with no team taking responsibility for investigation, diagnosis or
resolution.
Liaison with suppliers and vendor staff – Analysts assigned Problems will
liaise directly with suppliers and vendors. The Service Desk will oversee liaison
to ensure that Incidents and Problems are satisfactorily resolved within SLA
targets.
Management of Problem lifecycle – The Service Desk Manager(s) will monitor
the Problem database and compile a list of current outstanding Problems for
discussion & review at the weekly CAB meetings.
Control of Major Incidents – The nominated Problem Manager will take control
of Major Incidents, relieving the Service Desk of what may be a time consuming
and long running activity.
Post mortem reviews - As soon as possible after the resolution of a Major
Incident, a post mortem will be held to identify what lessons can be learned. The
nominated Problem Manager will own this process and chair all meetings.
b. Proactive Responsibilities



Feedback – The Service Desk will feed back information from the investigation
and diagnosis of Incidents and Problems, and the analysis of related information
into development and procurement functions, training requirements and the
production of manuals and documentation.
Trend analysis – The Service Desk will analyse the volume and nature of
Incidents so that, over time, trends can be identified. Separate resolution
categories will be utilised to aid this analysis.
Targeting actions to reduce worst peaks – The Service Desk will use the
Incident analysis and trend information to identify the aspects of service support
that cause the most ‘pain’ so that problem areas can be targeted.
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 4 of 12
Project No: [Click here]
6. Problem Management Workflow
Incident Management
Problem Alert
NEW Problem
Major Incident
Problem Alert
Problem LOGGED
Assign Business
/CategoryImpact/Categor
Impact/Category
y
Assign to Group
or 3rd party
Create Known Error
record
Incident Management
Raise RFC
Update Problem record
with RFC ID
Change Management
RESOLVED
Auto-assign to
Service Desk
Incident Management
Close related Incidents
Customer Agreement?
(Req’d for all Problems)
CLOSED
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 5 of 12
Project No: [Click here]
7. Problem Management Process
a. Receiving New Problems



New Problems will be raised from the Incident Management process by the
Service Desk and 2nd & 3rd level groups. Workarounds from the Problem
Management system Knowledgebase should be implemented where possible to
minimise the impact on the Customer.
In other cases a Problem might affect multiple users and an Incident record may
have been opened for each case that the Problem was reported. A Problem
record must be opened for the overall issue and Incident records must be linked
to it via System X.
The Service Desk will identify new Problems from the analysis of Incident
statistics. 2nd & 3rd level teams will also report Problems.
b. Problem Logging



All Problems must be logged in System X. Logging enables the management of
the lifecycle of the Problem by technical staff and the feedback of up to date
information to the Customer, via the Service Desk. The use of key fields for
classification also enables reporting to be carried out on trends.
As with Incidents, a Business Impact and categorisation will be assigned to the
Problem. Business Impact codes are defined as follows:
Business
Impact Level
Description
A
An Incident causing an extremely serious impact to the business as a result of the
system(s) / service(s) affected and/or the number of people affected by the Incident
e.g. A complete loss of the customers’ service or the impacted business function
is halted completely and interim restoration is either not possible or not acceptable.
B
An Incident causing significant impact to the business as a result of the system(s) /
service(s) affected and/or the number of people affected by the Incident e.g.
significant loss of customer’s service but the impacted business function is not
halted although interim restoration is not possible or not acceptable.
C
An Incident which affects the customer’s service but has a small impact to the
business e.g. single user or component affected but the trouble can be
circumvented.
D
Incidents that have a negligible impact to the business, requests or enquiries for
information purposes only.
N.B. Although Business Impact codes will be allocated and used for assigning
resources, no Priority code is assigned, and therefore there are no Customer
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project


Page 6 of 12
Project No: [Click here]
SLA targets associated with the resolution of Problems due to their long-term
nature.
However, if workarounds are not available, an Incident or Major Incident record
will remain open until the Problem is resolved and performance will be tracked
against the related Incident Priority target.
Incidents relating to a Problem will be linked to the Problem record within System
X.
c. Assigning Problems



By definition a Problem requires the technical expertise or access levels of a 2 nd
or 3rd level team or 3rd Party supplier. Problems are therefore normally assigned
outside the Service Desk immediately.
3rd party suppliers do not have access to System X, hence the Problem Manager
or an appropriate 2nd or 3rd level resource will own Problems assigned to them.
Where a Problem spans more than one technical team, or where the root cause
is unclear, the Problem will be owned by a nominated appropriate Problem
Owner who will co-ordinate the efforts of all groups and facilitate a resolution.
d. Knowledgebase Records


Once the root cause has been established a Knowledgebase record will be
created. The Service Desk is responsible for the maintenance & housekeeping
of the Knowledgebase. Workaround information to be implemented whilst a
long-term Problem resolution is sought should be forwarded to the Service Desk
via the Knowledgebase facility in System X or E-Mail.
Knowledgebase records will be stored centrally in System X and will be
accessible by all Service Desk and 2nd & 3rd level staff.
e. Resolving the Problem


All details of the Problem resolution must be recorded concisely on the Problem
record within System X. Any related RFC numbers should be referenced in the
Problem record.
Once the Problem is ‘Resolved’, the Problem record should be reassigned to the
Service Desk to feed back into the Incident Management process.
f. Closing the Problem


It is the Service Desk’s responsibility to Close Problems.
The Service Desk Call Co-ordinator role will be responsible for final closure of
‘Resolved‘ Problems following Customer agreement and a check of the accuracy
and completeness of the System X Problem data.
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project

Page 7 of 12
Project No: [Click here]
All linked Incidents must be revisited before the Problem can be Closed.
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 8 of 12
Project No: [Click here]
8. Major Incident Workflow
NEW Incident
Incident LOGGED
Assign Priority/Category
SLA Targets Set
Major
Incident?
no
Use normal Incident
Management process
yes
Create associated
Problem record
(Problem Manager Nominated)
nd
rd
Assign to 2 /3 level
or 3rd party
of Problem ID to
link related Incidents
Problem
Management
Notify Service Desk
RESOLVED
Auto-assign to
Service Desk
Customer Agreement?
Incident Management
Close related Incidents
Close Problem record
Post Mortem Review
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 9 of 12
Project No: [Click here]
9. Major Incident Process
a. Identification




A Major Incident is defined as a serious outage or problem affecting all or large
business areas, for example, server or network outages, or a virus outbreak.
Therefore, Business Impact A & B Incidents will always be logged as, or
escalated to, a Major Incident.
A Major Incident will generally be detected by the logging of one or more
Incidents, but may also be detected by 2nd or 3rd level staff.
A Major Incident may also be logged as a response to a significant number of
recurring ‘lower’ Business Impact Incidents, e.g. as the result of a significant
failure of a Change or as a result of a serious Complaint about service.
At the point at which a Major Incident is identified the Major Incident process is
invoked and a Problem Manager is nominated and becomes the central point of
contact for all communication and updates relating to the Major Incident.
b. Problem Manager Responsibilities
The nominated Problem Manager will:







Keep the Service Desk informed of the status of the Major Incident at all times
Keep the System X Problem record updated at all times
Issue updates to MIS management at agreed ‘appropriate’ intervals
Issue updates to key business representatives at agreed ‘appropriate’ intervals
Co-ordinate and/or assign the roles and responsibilities of multiple Support
Groups as necessary
Call and Chair a Post Mortem Review meeting
Issue a written Post Mortem report to MIS management.
c. Post-Mortem Review



At the earliest opportunity following the resolution of a Major Incident, the
nominated Problem Manager will organise and chair a Post Mortem Review
meeting and produce a Major Incident Report.
The meeting will be attended by the following as a minimum:
Problem Manager
Head of MIS
nd
rd
2 /3 Level Representative(s)
Business Representative(s)
3rd Party Representative(s), if appropriate
If the Major Incident is straightforward, e.g. standard hardware fault, the Problem
Manager may decide that a formal meeting is not required, and gather any
further information informally via e-mail, telephone or one to one conversations.
106732603
Edition No.1
Quality
Problem Management
Process
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project


Page 10 of 12
Project No: [Click here]
It is important to note that the purpose of a Post Mortem is not to assign blame
but to identify the root cause(s) of the Major Incident and implement any actions
identified to minimise the chances of any recurrence.
A draft Major Incident Report will be issued at least one working day prior to the
meeting. Information within this report will be taken from the Problem Record on
System X, along with details that may be available from e-mails.
d. The Major Incident Report
 The Major Incident Report (MIR) template is shown at the end of this section.
 As stated above the details within the MIR are taken from a variety of sources, but
chiefly from the System X Problem Record and the Post-Mortem Review
meeting. The draft MIR acts as the basis for the full report, and is the catalyst for
discussion at the meeting.
 The Report is a factual account of what occurred, why it occurred (if known), and
what was done to resolve the Incident. Having completed this account the
nominated Problem Manager will also make recommendations on:
 How to resolve any outstanding Incidents/Problems linked to the Major
Incident
 Improvements to processes that may have delayed the resolution of the
Major Incident
 Any other matters that are raised
 Some recommendations may be deemed impractical through cost or time
reasons, and rejected. However, they will remain within the Report and
alternative suggestions implemented and recorded with the reasons.
 The primary audience for the report is the management of MIS and those support
analysts involved in resolving the Incident. The CAB process will identify when it
is appropriate to forward this information to senior management within the
business areas affected by the Major Incident.
e. Major Incident Report
106732603
Edition No.1
Page 11 of 12
Problem Management
Process
Quality
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Project No: [Click here]
MIR Ref:
Date Occurred:
User Name:
Priority
Recurring
Failed Change
Solution in place
Interim Fix
Long-term
solution
Incident Type:
System X MI
No(s):
Complaint
Customer / Site(s):
Service(s) affected:
Problem Status:
Business Impact:
Root Cause(s):
Support Groups:
Description:
Corrective actions:
By when:
Date Customer
Advised
Outcome of Corrective Actions:
Date
Customer
advised:
By who:
Report Closed:
By:
106732603
By who:
Edition No.1
Problem Management
Process
Quality
See Document:
Company Ltd. - UK
Project: MIS Service Improvement Project
Page 12 of 12
Project No: [Click here]
8. Related Documents
Incident Management Process
Major Incident Process
Operational Change Management Process
UK Service Level Agreement
Operational Level Agreements for MIS UK
AUTHOR & APPROVAL
Written by:
Date
[Click here and type Job Title]
Approved by:
Date
[Click here and type name]
Development Manager & Ops
Manager
Approved by:
Date
[Click here and type name]
MIS Manager
REVISION HISTORY
Ed. No.
1
2
Reason for Change
New document written
=== end of document ===
106732603
Edition No.1