White Paper

August 2006
BMC Best Practice Process
Flows for ITIL Incident and
Problem Management
BMC Software, Inc.
www.bmc.com
Copyright 19912006 BMC Software, Inc. All rights reserved.
BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and
all other BMC Software product or service names, are registered trademarks or trademarks of BMC
Software, Inc. All other trademarks belong to their respective companies.
BMC Software, Inc., considers information included in this documentation to be proprietary and
confidential. Your use of this information is subject to the terms and conditions of the applicable end user
license agreement or nondisclosure agreement for the product and the proprietary and restricted rights
notices included in this documentation.
Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the
U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS
252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is
BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.
Contacting Us
If you need technical support for this product, contact Customer Support by email at
support@remedy.com. If you have comments or suggestions about this documentation, contact
Information Development by email at doc_feedback@bmc.com.
This edition applies to version 7.0 of the licensed program.
Contents ! 3
Contents
Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Process flow shapes and text indicators. . . . . . . . . . . . . . . . . . . 6
For more information . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2 Incident Management . . . . . . . . . . . . . . . . . . . . . . . 9
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Manually detected incidents . . . . . . . . . . . . . . . . . . . . . 13
Automatically detected incidents . . . . . . . . . . . . . . . . . . . 14
Details of the manual process . . . . . . . . . . . . . . . . . . . . . . 16
Incident detection, recording, classification and initial support. . . . . . . 16
Incident investigation and diagnosis . . . . . . . . . . . . . . . . . . 26
Incident resolution and recovery . . . . . . . . . . . . . . . . . . . 27
Incident closure . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Details of the automated process . . . . . . . . . . . . . . . . . . . . 31
Incident detection, recording, classification and initial support. . . . . . . 31
Incident closure . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 3 Problem Management . . . . . . . . . . . . . . . . . . . . . . 37
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Problem identification, recording, and classification . . . . . . . . . . . 42
Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Problem investigation and diagnosis . . . . . . . . . . . . . . . . . . 46
Problem resolution and closure . . . . . . . . . . . . . . . . . . . . 50
4 "Contents
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Known error identification and recording . . . . . . . . . . . . . . . 51
Known error classification and assessment . . . . . . . . . . . . . . . 52
Known error resolution and closure . . . . . . . . . . . . . . . . . . 54
Introduction ! 5
Chapter
1
Introduction
The BMC Best Practice Process Flows for ITIL Incident and Problem
Management White Paper describes the process flows implemented in the
BMC Remedy 7.0 Incident Management and BMC Remedy 7.0 Problem
Management applications, which are based on IT Infrastructure Library
(ITIL) best practices.
Incident management is a reactive process, typically initiated in response to
a customers call. The primary goal of the incident management process is to
restore normal service operation as quickly as possible and with minimum
disruption to the business.
Problem management is the process that identifies the cause of problems and
initiates actions that help to improve or correct the situation, preventing an
incident from recurring or from occurring in the first place.
To help you understand how the ITIL incident management and problem
management processes are supported by our applications, this white paper
includes:
! Process flow diagramsfor both the high-level overview, and the detailed
steps
! Text explaining how the process is supported by the application
! Delineation of the process into separate user roles
6 "Chapter 1Introduction
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Process flow shapes and text indicators
The process flow diagrams in this white paper use the following shapes and
text indicators:
Table 1-A: Process flow shapes and text indicators
Shape or text indicator Description
Start or end shape indicates the starting or ending
point of the process flow, for example, change
initiation.
Flow line shape indicates the sequence of steps and the
direction of the process flow.
Action or process shape indicates a single step in the
flow, for example, determine incident type.
Decision shape indicates a branching point (Yes or
No) in the process flow, for example, customer info
correct?
Off-page shape indicates that the process continues in
a different diagram; the number indicates the step.
For example, process continues in a different diagram
with step 2.1.
Chevron shape indicates that the process started from
a different diagram and continues here. For example,
process continues from step 2.11.
Change
initiation
1.8
Determine
incident
type
1.4
Customer info
correct?
2.1
2.11
For more information ! 7
White Paper
For more information
For information about additional BMC best practices, see the following
documentation:
! BMC Best Practice Process Flows for ITIL Change Management
Note: Documentation will be available at a future date to provide process
flows for the 7.0 BMC Remedy Asset Management and BMC Service Level
Management applications that are based on IT Infrastructure Library
(ITIL) best practices.
For detailed information about the ITSM 7.0 applications, see the following
documentation:
! BMC Remedy Service Desk: Incident Management 7.0 User's Guide
! BMC Remedy Service Desk: Problem Management 7.0 User's Guide
! BMC Remedy Change Management 7.0 User's Guide
Subroutine shape indicates a sequence of actions that
perform specific tasks embedded within an external
process flow, for example, Incident Management or
Change Management.
Identifies databases used in ITSM 7.0 process flows,
for example, service level management or CMDB.
Italicized blue text indicates notification, for example,
notification to assignees of related open incidents.
Table 1-A: Process flow shapes and text indicators (Continued)
Shape or text indicator Description
Incident
Management
CMDB
1RWLILFDWLRQ
WRDVVLJQHHVRI
UHODWHGRSHQLQFLGHQWV
8 "Chapter 1Introduction
BMC Best Practice Process Flows for ITIL Incident and Problem Management
For information about other BMC Remedy applications mentioned in this
white paper, see the following documentation:
! BMC Atrium CMDB 2.0 Users Guide
! BMC Remedy Knowledge Management 7.0 Users Guide Remedy Interface
! BMC Service Level Management 7.0 Users Guide
Incident Management ! 9
Chapter
2
Incident Management
BMC Remedy Incident Management is used to manage incidents. Incident
management is reactive, and is typically initiated in response to a customer
call or automated event. An example of an automated event might be an alert
from a monitoring system, such as BMC Service Impact Management
(BMC SIM). The primary goal of the incident management process,
according to ITIL standards, is to restore normal service operation as
quickly as possible with minimum disruption to the business, thus ensuring
that the best achievable levels of availability and service are maintained.
An incident is any event that is not part of the standard operation of a service
and that causes an interruption to or a reduction in the quality of that service.
Normal service operation is the operation of services within the limits
specified by Service Level Management (SLM).
The incident management process flow includes the following user roles:
Table 2-A: Incident Management user roles
Role Description
Automated tools These are tools that perform functions in
the auto-detected incident management
process. This includes monitoring
systems, such as BMC SIM.
Customer This is the person experiencing or
reporting the incident.
10 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Back office support Back office support includes the incident
assignees, incident manager, and incident
owner working to resolve the incident. In
the overview, these roles are grouped
together as back office support. In the
detailed sections, these roles are
separated.
Incident assignee (tier 1) Incident assignees are support staff
assigned to work on incidents. Tier 1
support is part of the Service Desk. They
are the primary contacts for all customers
and are responsible for coordinating their
resolution. Typically, tier 1 incident
assignees are also the incident owners.
Incident assignee (tier 2, 3, n) Tier 2 and higher support are considered
subject matter experts. Their main
responsibility is to provide an accurate
analysis and diagnosis of their assigned
incidents to restore service to the affected
customers.
Incident manager Incident managers are responsible for the
quality and integrity of the incident
management process. They are
responsible for the work of members of
their support group, and they coordinate
the assignment of incidents to support
staff.
Incident owner The incident owner is responsible for
validating incident resolutions with
customers. This is typically the person
who recorded the incident or if the
customer recorded the incident through
the Requester Consolethe initial
incident assignee.
Table 2-A: Incident Management user roles (Continued)
Role Description
! 11
White Paper
This section describes the Incident Management processes and user roles.
For information about using the application, see the BMC Service Desk:
Incident Management 7.0 User's Guide.
ITSM manual Incident Management
process
From the perspective of the auto-detected
incident management process, the
manual process is a single role.
Service support, service delivery, and
other related processes
This includes databases and other ITSM
processes that interact with the incident
management process, including:
! SLM
! Configuration Management Database
(CMDB)
! Change Management
! Problem Management
! Knowledge Management
! Capacity and availability management
! Manual investigation and diagnosis
Table 2-A: Incident Management user roles (Continued)
Role Description
12 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Overview
Incidents can be detected either manually (by a customer) or automatically.
Figure 2-A: Top-level incident management process
If the automatically detected incident is self-correcting, then the automatic
process is followed throughout the incident life cycle. Self-correcting means
that there is an automated means of correcting the incident. If it not self-
correcting, the incident flows to the manual process and the investigation
and diagnosis stage.
For overviews of the two processes, see:
! Manually detected incidents on page 13
! Automatically detected incidents on page 14
Incident auto-
detected?
Yes
No
Identification and
recording
(incIudes
cIassification)
ResoIution and
recovery
Identification and
recording
(incIudes
cIassification and
initiaI support)
Investigation and
diagnosis
SeIf-
correcting?
N o
Yes
Incident
cIosure
Incident
cIosure
Incident
detected
ITSM manuaI Incident Management process overview
ITSM auto-detect Incident Management process overview
Overview ! 13
White Paper
Manually detected incidents
The ITSM manual incident process includes four stages.
Figure 2-B: Overview of ITSM manual incident management process
Stage 1 Identification, recording, classification, and initial supportWhen an
incident is detected by a customer, either through web self-help (using the
Requester Console) or through a call to the service desk, the incident is
identified, recorded, and classified. At this stage, initial support is provided.
Stage 2 Investigation and diagnosisAfter the incident is recorded, someone in
back office support investigates and diagnoses the incident. If appropriate, a
change request is created, initiating the Change Management process.
Problem Management can be used to search for known errors and possible
solutions. If appropriate, a problem investigation can be created, initiating
the Problem Management process.
Stage 3 Resolution and recoveryDuring this stage, the resolution or workaround
is found. This might result in a change request. If appropriate, a Problem
Management process might be initiated for a problem investigation or
known error. If a resolution is found, it can be recorded in the Problem
Management solution database.
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
C
u
s
t
o
m
e
r
1
Identification,
recording,
cIassification
and initiaI
support
2
Investigation
and diagnosis
4
CIosure
3
ResoIution and
recovery
Incident
detected
Perform web
seIf-heIp
CaII the
service desk
Record
incident
Change
Management
Change
Management
ProbIem
Management
ProbIem
Management
ProbIem
Management
Find resoIution /
workaround
VaIidate and accept
resoIution /
workaround
CIosed
SoIicit
cIosure
Configuration Management
Service LeveI Management
14 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 4 ClosureDuring this stage, the customer is contacted and the resolution or
workaround validated and accepted. Problem Management processes can be
initiated at the closure stage. If closure is successful, the incident is closed.
Underlying
processes
Configuration management processes underlie the identification,
investigation, and resolution stages. This is the process of managing your
configuration items, identifying items relevant to the incident. Service Level
Management underlies all stages of incident management.
The SLM process provides Service Level Agreements (SLAs) that are targeted
to the IT user, and to response and resolution time agreements. The SLM
process also provides the Operational Level Agreements (OLAs) and
Underpinning Contracts (UCs) that are targeted to how internal IT staff
deliver fixes. These agreements and contracts consist of service targets,
milestones, and actions.
Automatically detected incidents
The availability management or capacity management process can
automatically detect an incident. For example, BMC SIM might determine
that an alert from a monitoring system is an incident. The automated process
includes two stages.
Overview ! 15
White Paper
Figure 2-C: Overview of ITSM auto-detected incident process
Stage 1 Identification, recording, classification, and initial supportThis is
provided through automated tools that record the incident. If the incident is
self-correcting, it moves to the next stage. Otherwise, it moves to the
investigation and diagnosis stage of the manual incident process.
Stage 2 ClosureBack office support is notified that an incident has been resolved.
If appropriate, back office support contacts the customer to validate that self-
correction successfully resolved the incident.
Underlying
processes
Availability management and capacity management processes can
automatically detect incidents. The configuration management processes
underlies the identification stage. By configuration management, we mean
the process of managing your configuration items, which identifies items
relevant to the incident. Service Level Management underlies all stages of
incident management.
Service Level Management measures that service targets are met.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
C
u
s
t
o
m
e
r
I
T
S
M

m
a
n
u
a
I

I
n
c
i
d
e
n
t

M
a
n
a
g
e
m
e
n
t

p
r
o
c
e
s
s
A
u
t
o
m
a
t
e
d

t
o
o
I
s
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
Record
incident
1
Identification,
recording,
CIassification,
and initiaI
support
Incident
detected
SeIf-
correcting?
No
Yes
2
CIosure
2.1
Configuration Management
Service LeveI Management
AvaiIabiIity /
capacity
management
Investigation
and
diagnosis
16 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Details of the manual process
This section describes the detailed steps for each stage of the manual incident
management process.
Stage 1 Incident detection, recording, classification and initial
support
In this stage, a customer detects an incident, and either performs web self-
help (using the Requester Console) or calls the service desk. The incident is
identified, recorded, and classified. Initial support is provided through
information available in ITSM.
Figure 2-D: Incident detection, recording, classification, and initial support (steps 1.1
through 1.8)
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t

a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
SLA / OLA clock based
on ncident Reported Date
Contact
Service Desk
New
Existing
Requestor ConsoIe
1.7
Update existing
incident
1.8
Record
incident
summary and
notes
Incident
detected
1.4
Identify and
vaIidate
customer
profiIe data
1.6
New or existing
incident?
1.9
Incident
Management (to
correct
customer information)
1.5
Customer info
correct?
Yes
No
1.3
Record and
cIose incident
1.2
Issue seIf-
resoIved?
Yes
No
CIosed
Service Level
Management
1.1
SeIf heIp
Incident
Management
Details of the manual process ! 17
White Paper
The process starts when the customer detects a new incident. The process
continues with the following steps:
1.1 If using the Requester Console, the customer performs self-help.
The console presents the customer with a list of possible issues to select. This
list of issues is a catalog of common requests and problems. By selecting from
the list, the customer can generate an incident or a change request.
When the customer selects the issue, if available, corresponding solutions are
displayed in the Requester Console. The BMC Remedy Problem
Management application displays solutions to prior incidents or problems.
The BMC Remedy Knowledge Management application displays knowledge
entries.
1.2 The customer determines whether any of the displayed solutions resolve the
incident.
If the customer cannot self-resolve the incident, it is recorded and assigned
to the service desk.
The process continues with step 1.8.
1.3 If the customer indicates that a solution resolves the incident, it is recorded
and closed.
1.4 If the customer contacts the service desk, the incident assignee identifies and
validates the customer profile data.
Additionally, new incidents can be created or duplicated from other
incidents. When an incident is duplicated from another incident, after the
customer information is recorded for the new duplicate incident, the process
automatically mirrors the process for the parent incident.
The initial incident assignee is typically tier 1 support. If appropriate, tier 2
or higher support can be involved from the outset.
From Service Level Management, the clock starts for relevant SLAs and
OLAs, starting from the time and date that the incident was reported.
18 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
1.5 The incident assignee checks whether the customer information in the
application is correct.
If the information is not correct, a procedure is followed to correct the
information. Depending on your processes, this could be:
! The incident assignee edits the customer information.
! The incident assignee creates another incident or a change request to
correct more significant corrections, such as information populated from
LDAP.
1.6 The incident assignee checks whether the incident is new or already exists in
the application.
1.7 If the call is about an existing incident, the incident assignee updates the
existing incident or communicates the incident status.
1.8 The incident assignee records the incident summary and notes.
Figure 2-E: Incident detection, recording, classification, and initial support (steps 1.9
through 1.13)
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t

a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
No
No
1.9
CI invoIved?
Incident
Management
1.11
ReIate CI
1.10
CI found?
Yes
1.12
CI information
correct?
No
Yes
1.13
Raise incident
to correct CI
information
1.8 Yes
CMDB
1.14
Details of the manual process ! 19
White Paper
1.9 The incident assignee checks whether a configuration item (CI) is involved.
If a CI is not involved, the process continues with step 1.14.
1.10 If a CI is involved, the incident assignee checks whether the CI is found in the
BMC Atrium Configuration Management Database (BMC Atrium CMDB).
1.11 If the CI is found, the incident assignee relates the CI to the incident.
1.12 The incident assignee checks whether the CI information from the database
is correct.
1.13 If the CI information is incorrect (or if the customer is calling about a CI that
is not in the CMDBand should be), the incident assignee raises a new
incident to correct the CI information.
Figure 2-F: Incident detection, recording, classification, and initial support (steps 1.14
through 1.18)
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t

a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
1.15
Determine
type and
categorize
incident
1.17
Gather
information
Information
unknown
Information
provided
1.14
EstabIish
impact,
urgency, and
priority
SLA based on priority
and cIassification
3.1
1.9
1.13
1.19
1.16
Restoration or
information
request?
Info
request
Restoration
Service Level
Management
4.3
1.18
Information
found and
provided?
20 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
1.14 The incident assignee records the impact and urgency of the incident.
The impact and urgency of the incident determine the priority.
1.15 The incident assignee determines the incident type and categorizes the
incident.
Based on the priority and classification of the incident, the application
attaches the appropriate SLAs, OLAs, or UCs to the incident from the Service
Level Management data source.
1.16 The incident assignee determines whether the incident is a restoration or a
request for information.
To provide restoration, the incident assignee continues with step 1.19
1.17 If information is requested, the incident assignee gathers the information.
1.18 The incident assignee determines whether the information can be provided.
If the incident assignee can provide the information, the process moves to the
resolution and recovery stage with step 3.1. If the information is unknown,
the incident moves to the closure stage with step 4.3.
Details of the manual process ! 21
White Paper
Figure 2-G: Incident detection, recording, classification, and initial support (steps 1.19
through 1.23)
1.19 The incident assignee searches broadcasts.
Broadcasts are a feature of BMC Remedy ITSM that enable users to create
messages that can be viewed by the entire organization or by users in specific
groups. Records, such as incidents and problem investigations, can be
broadcast to provide broad visibility to IT staff and, possibly, to customers.
1.20 The incident assignee determines whether any of the broadcasts might assist
finding a resolution to the incident.
A broadcasted incident can be a duplicate the current incident. A broadcast
might indicate a solution or workaround. If there is no relevant broadcast,
the procedure continues with step 1.24.
1.21 The incident assignee determines whether a broadcasted incident is a
duplicate of the current incident.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t

a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
Yes
No
Yes
No
3.1
1.22
ReIate to
dupIicate
(Process now
mirrors the
parent incident)
1.16
1.24
Change
Management
ncident Management
1.20
DupIicate incident,
soIution /
workaround
avaiIabIe?
1.21
DupIicate
exists?
1.23
ReIate simiIar
incident or
impacting
change
1.19
Search
broadcasts
22 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
1.22 If there is a duplicate, the incident assignee relates the current incident as a
duplicate.
For the current incident, the process now automatically mirrors the parent
incident (the broadcasted incident). When the parent incident is resolved, all
duplicates are also resolved.
1.23 If a broadcast provides a solution or workaround, the incident assignee
relates the incident to a similar incident or impending change, which comes
from the Incident Management or Change Management data source.
The process moves to the resolution and recovery stage with step 3.1.
Figure 2-H: Incident detection, recording, classification, and initial support (steps 1.24
through 1.28)
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
1.28
ReIate to
incident,
probIem,
known error, or
knowIedge
1.24
Perform
incident
matching
No
1.29
ProbIem
Management
3.1
1.20
1.27
SoIution /
workaround
avaiIabIe?
Yes
1.25
DupIicate
exists?
1.26
ReIate to dupIicate
(Process now
mirrors the parent
incident)
Yes
No
Incident
Management
Details of the manual process ! 23
White Paper
1.24 The incident assignee performs incident matching to search for a solution or
workaround.
The incident matching function is used primarily to search for known errors
and solution entries that were recorded in the Problem Management
application. If you have BMC Remedy Knowledge Management, you can
search for knowledge entries. It can also be used to search for problem
investigations and even other incidents that match criteria from the current
incident.
Searching for other incidents can be used both to help find a solution and to
help determine if the current incident is a duplicate of an existing incident.
1.25 The incident assignee determines whether a matching incident is a duplicate
of the current incident.
1.26 If there is a duplicate, the incident assignee relates the current incident as a
duplicate.
For the current incident, the process now automatically mirrors the parent
incident.
1.27 The incident assignee evaluates whether the results of the incident matching
search include a solution or workaround to the incident.
1.28 If a solution or workaround is available, the incident assignee relates the
source of the solution or workaround to the incident.
The process moves to the resolution and recovery stage with step 3.1.
24 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Figure 2-I: Incident detection, recording, classification, and initial support (steps 1.29
through 1.34)
1.29 If tier 1 support cannot resolve the incident, the incident assignee determines
whether a broadcast is required.
Broadcasts can be used to inform others in IT support, and even customers,
about an incident with widespread impact, such as an email outage.
1.30 If appropriate, the incident assignee broadcasts the incident.
1.31 The incident assignee assigns the incident for resolution by tier 2 or higher
support.
When an incident is assigned, notification is sent to the assignee.
Note: At later stages of the process, the incident might return to this step, if
the current assignee cannot resolve the incident.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
No Yes
No
No Yes
1RWLILFDWLRQ
WRDVVLJQHH
1RWLILFDWLRQ
WRDVVLJQHH
1.32
Accept incident
assignment?
2.1
1.31
Assign incident
for resoIution
1.27
1.30
Broadcast
Incident
1.34
Reassign
incident for
resoIution
1.29
Broadcast
required?
1.33
RecIassify, if
required, and assign
to incident owner
SLA / OLA might change
based on reclassification
and assignment
Service LeveI
Management
2.8
3.6
4.5
Details of the manual process ! 25
White Paper
1.32 The tier 2 or higher incident assignee determines whether to accept the
assignment.
If the assignee accepts the assignment the process moves to the investigation
and diagnosis stage with step 2.1.
1.33 Otherwise, the assignee reclassifies the incident, if required, and assigns the
incident back to the incident owner.
Reclassifying the incident might change the SLAs, OLAs, or UCs attached to
the incident.
The application notifies the incident owner that the incident has been
assigned.
1.34 The incident owner reassigns the incident for resolution by tier 2 or higher
support.
The application notifies the assignee that the incident has been assigned.
26 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 2 Incident investigation and diagnosis
In this stage, tier 2 and higher support investigates the incident. The process
starts after the incident assignee accepts the assigned incident.
Figure 2-J: Incident investigation and diagnosis
2.1 The assignee diagnoses the incident.
2.2 The assignee evaluates whether a solution or workaround is available.
If a solution or workaround is available, the process moves to the resolution
and recovery stage with step 3.1.
2.3 If there is no solution or workaround, the assignee performs a fact-gathering
investigation, checking incident management records, problem
management records, and the CMDB. The assignee also checks with other
sources, such as other IT staff and the web.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
2.1
Diagnose
incident
Yes
3.1
2.3
Gather facts,
investigate
No
Yes
3.1
No
2.2
SoIution /
workaround
avaiIabIe?
2.7
SoIution /
workaround
avaiIabIe?
ProbIem
Management
2.8
Reassignment
possibIe?
1.31
Yes
2.9
Request
probIem
investigation
No 1.32
Problem
Management
Configuration
Managment
ncident
Management
2.4
Assistance
needed?
2.5
Generate
tasks
Yes
No
2.6
CIose task
activities
Details of the manual process ! 27
White Paper
2.4 The assignee determines whether he or she needs assistance.
If the assignee does not need assistance, the process continues with step 2.7.
2.5 The assignee generates tasks.
BMC Remedy Incident Management supports ad hoc tasks. The incident
assignee creates the tasks with a description of what needs to be
accomplished, and assigns them as appropriate.
2.6 The task assignees complete their tasks.
2.7 The assignee evaluates whether a solution or workaround is available.
If a solution or workaround is available, the process moves to the resolution
and recovery stage with step 3.1.
2.8 If the assignee cannot find a solution or workaround, the assignee determines
whether the incident can be reassigned.
If reassignment is appropriate, the process returns to step 1.31.
2.9 If the assignee cannot for a solution or workaround and also cannot reassign
the incident, the assignee requests a problem investigation.
Problem management communicates suggestions and status to incident
management.
The problem investigation proceeds in the Problem Management process.
The incident assignee monitors the progress of the problem management
process, continues to gather facts, and works with the problem management
team to determine a solution or workaround.
Stage 3 Incident resolution and recovery
In this stage the assignee performs the steps necessary to apply the resolution
and recover from the incident. If tier 1 support found a solution or
workaround to the incident, the tier 1 incident assignee continues this
process. If the incident was assigned to someone in tier 2 or higher support,
that person continues the process.
28 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Figure 2-K: Incident resolution and recovery
3.1 The incident assignee records the incident resolution.
The incident resolution should be categorized.
If the solution or workaround was found from a completed problem
investigation in the Problem Management records, that information is
copied into the incident. If a relevant completed infrastructure change was
found in the Change Management records, that information is copied into
the incident.
3.2 The incident assignee determines whether infrastructure change is required
to find a more permanent solution.
3.3 If change is required, the incident assignee creates an infrastructure change
request.
The Change Management process completes the infrastructure change
request.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
Yes
3.5
Communicate
and execute
soIution /
workaround
3.4
Notify owner
(if appIicabIe)
3.3
Create
infrastructure
change
No
3.1
Record
incident
resoIution
3.2
Change
required?
Change
Management
Yes
3.6
SoIution/
workaround
confirmed?
No
1.31
3.7
Root
cause anaIysis
required?
Yes
ProbIem
Management
3.8
Create
probIem
investigation
4.1
No
2.2
2.7
1.18
1.23
1.28
Completed
infrastructure change
Completed
problem investigation
with solution/workaround
Problem
Management
Change
Management
Details of the manual process ! 29
White Paper
3.4 If the current incident assignee is not the incident owner, the incident owner
is notified that the incident is resolved.
3.5 The incident assignee communicates with the customer and executes the
solution or workaround.
3.6 The customer is asked to confirm whether the solution or workaround
resolves the incident.
If the incident is not resolved, the process returns to step 1.31 to reassign the
incident. Otherwise, the incident is resolved.
3.7 If the incident is resolved, the assignee determines whether a root cause
analysis is required.
The purpose of incident management is to get the customer working as
quickly as possible. If the customer is provided with a temporary
workaround, root cause analysis might be required to fix the underlying
problem. There might be other reasons to perform a root cause analysis, for
example, to determine whether the incident is a symptom of an underlying
problem that has not been resolved.
3.8 If root cause analysis is required, the incident assignee creates a problem
investigation.
The Problem Management process completes the problem investigation.
Whether or not root cause analysis is completed, the incident moves to the
incident closure stage with step 4.1.
30 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 4 Incident closure
In this stage, the incident owner performs the steps necessary to close the
incident.
Figure 2-L: ITSM incident closure
4.1 If the incident was broadcast, the incident owner removes the broadcast.
4.2 The incident owner validates that the incident is properly categorized.
If the incident is related to a problem investigation that is complete (with a
solution or workaround determined), the incident owner can check the
categorization recorded for the Problem Management record.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
I
n
c
i
d
e
n
t
o
w
n
e
r
I
n
c
i
d
e
n
t
m
a
n
a
g
e
r
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

2
/
3
/
n
)
I
n
c
i
d
e
n
t
a
s
s
i
g
n
e
e
(
t
i
e
r

1
)
C
u
s
t
o
m
e
r
4.2
VaIidate proper
categorization
4.7
CIose
incident
4.3
SoIicit cIosure
No
Yes
1.31
KnowIedge
Management
4.1
Remove
broadcast if
appIicabIe.
4.4
Accept
cIosure?
Yes
No
4.5
AdditionaI issue
reported?
No
Yes
Related problem solution/
workaround determined
4.6
Update
knowIedge
database?
3.7
3.8
Yes
Problem
Management
Incident
Management
1.18
Details of the automated process ! 31
White Paper
4.3 The incident owner solicits closure from the customer.
The incident owner performs this step after the fix has been running in the
customer environment over a period of time; this helps determine whether
the fix fully resolved the incident, or whether more work is required. For
example, the fix might have worked for a short period of time, and then
failed.
4.4 The customer indicates whether the incident can be closed.
4.5 If the customer indicates that the incident is not closed, the customer is asked
whether he or she has an additional issue to report.
If there is an additional issue, a new incident is created; this new incident
follows the incident management process.
If there is no additional issue, the incident returns to step 1.31 for
reassignment.
4.6 The incident owner determines whether to update the knowledge database
with the solution.
Details of the solution can be copied directly from the Incident Management
application to the Problem Management application, for storage in the
solution database. If you have BMC Remedy Knowledge Management, you
can copy the solution directly into a knowledge entry.
4.7 The incident owner closes the incident.
Details of the automated process
This section describes the detailed steps for each stage of the auto-detected
incident management process.
Stage 1 Incident detection, recording, classification and initial
support
In this stage, automated tools detect an incident before a customer reports it.
These tools identify, record, and classify the incident. In addition, they
provide initial support, which might be able to correct the incident.
32 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Figure 2-M: Automated incident detection, recording, and classification (steps 1.1
through 1.5)
The process starts when an automated tool, such as BMC SIM, detects a new
incident. The capacity and availability management processes provide
information to the automated tool. For example, BMC SIM can receive logs
from an event monitor. The tool evaluates the information and determines
whether an incident has been detected.
The process continues with the following steps:
1.1 Automated tools identify the customer.
Although the customer did not report the incident, the customer must be
identified. The customer is contacted during the closure stage.
From Service Level Management, the clock starts for relevant SLAs and
OLAs, starting from the time and date that the incident was reported.
1.2 Automated tools determine whether the customer exists.
If the customer does not exist, an error code is returned to the calling system,
and the incident is not recorded.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
A
u
t
o
m
a
t
e
d

t
o
o
I
s
C
u
s
t
o
m
e
r
SLA / OLA clock based on
ncident Reported Date
Reported
New
Existing Yes
1.6
1.3
New or existing
incident?
1.1
Identify
customer
Incident
detected
1.2
Customer
exists?
1.4
Update existing
incident if
required
1.5
Record
incident
summary and
notes
Capacity/
avaiIabiIity
management
No
Return error code
Service Level
Management
Details of the automated process ! 33
White Paper
1.3 Automated tools determine whether the incident is new or an existing
incident.
1.4 If it is an existing incident, the tools update the existing incident, if required.
1.5 Automated tools record the incident summary and notes.
Figure 2-N: Automated incident detection, recording, and classification (steps 1.6
through 1.9)
1.6 Automated tools identify the incident type.
1.7 Automated tools check whether a CI is involved.
If a CI is not involved, the process moves to the incident closure stage with
step 1.10.
1.8 If a CI is involved, the automated tool checks whether the CI is found in the
CMDB.
1.9 If the CI is found, the tool relates the CI to the incident.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
A
u
t
o
m
a
t
e
d

t
o
o
I
s
C
u
s
t
o
m
e
r
1.9
ReIate CI
1.7
CI invoIved?
1.8
CI found?
1.10
1.6
Identify
incident
Type
Yes
No
Yes
No
1.5
Configuration
Management
34 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
The process moves to the ITSM incident closure stage with step 1.10.
Figure 2-O: Automated incident detection, recording, and classification (steps 1.10
through 1.14)
1.10 Automated tools establish the impact and urgency of the incident.
The impact and urgency of the incident determine the priority.
Based on the priority and classification of the incident, the application
attaches the appropriate SLAs to the incident from the Service Level
Management data source.
1.11 Automated tools categorize the incident.
1.12 Automated tools determine whether there is a related incident.
For example, if an email server goes down, BMC SIM creates an incident for
the mail server and an incident for the mail service unavailability, and relates
the two incidents.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
A
u
t
o
m
a
t
e
d

t
o
o
I
s
C
u
s
t
o
m
e
r
1.13
ReIate other
incidents
1.11
Categorize
incident
1.10
EstabIish
impact,
urgency, and
priority
1.12
Incidents to reIate?
Yes
No
1.14
SeIf-correcting
incident?
No
2.1
Yes
1.7
1.8
1.9
SLA based on priority
and classification
Service Level
Management
1.31 in manuaI
process
Details of the automated process ! 35
White Paper
1.13 If applicable, automated tools relate the current incident to the related
incident.
1.14 Automated tools determine whether the incident is self-correcting.
If the incident can be corrected without manual intervention, the process
moves to the incident closure stage with step 2.1.
Otherwise, the incident moves to the investigation and diagnosis stage of the
manual process with step 1.31 on page 24.
Stage 2 Incident closure
In this stage, back office support staff complete the incident process,
performing the steps necessary to close the incident.
Figure 2-P: Incident closure
2.1 If the tool is trusted to automatically close the incident, the process moves to
step 2.8.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
A
u
t
o
m
a
t
e
d

t
o
o
I
s
C
u
s
t
o
m
e
r
B
a
c
k

o
f
f
i
c
e

s
u
p
p
o
r
t
No
Yes
KnowIedge
Management
2.8
CIose
incident
2.2
VaIidate proper
categorization
2.3
VaIidate
fix
2.4
Fix sucessfuI
Yes
No
2.6
Create
incident
Incident
Management
No
2.5
ManuaI
assignment
CIosed
1.14
2.7
Update
knowIedge
database?
Related problem solution /
workaround
To rectify deficiency within
self-corrected process
Problem
Management
1.31 in manuaI
process
2.1
Trusted tooI?
Yes
No
36 "Chapter 2Incident Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
2.2 Back office support validates that the incident has been properly categorized.
If there is a related problem investigation with a solution or workaround in
the Problem Management records, they can check the categorization of the
investigation.
2.3 Back office support validates the fix.
2.4 Back office support determines whether the fix was successful.
2.5 If the fix was not successful, back office support assigns the incident, and the
incident moves to the investigation and diagnosis stage of the manual process
with step 1.31 on page 24.
2.6 If the fix was not successful, back office support also creates a new incident
to determine why the automated system not fix the problem.
2.7 Back office support determines whether to update the knowledge database.
The knowledge database is updated using the Knowledge Management
process. This could involve copying the solution from the Incident
Management application to the solution database in the Problem
Management application. It could also involve creating a knowledge
management entry in the Knowledge Management application.
2.8 Back office support closes the incident.
Problem Management ! 37
Chapter
3
Problem Management
BMC Remedy Problem Management is used to manage problem
investigations, known errors, and solution database entries. Problem
management can proactively prevent the occurrence of incidents, errors, and
additional problems. A problem investigation helps an IT organization get to
the root cause of incidents. It initiates actions that help to improve or correct
the situation, preventing the incident from recurring.
After a problem investigation identifies the cause, this information can result
in either a known error or a solution database entry. A known error is a
problem that has been successfully diagnosed and for which a temporary
workaround or permanent solution has been identified. A solution database
entry contains information that might be required to provide or restore a
service.
38 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
The problem management process flow includes the following user roles:
Table 3-A: Problem Management user roles
Role Description
Support technician The support technician is someone who
initiates a problem investigation or a
known error. This might be a problem
assignee, or it might be an incident
assignee with access to submit problem
tickets.
Problem assignee Problem assignees are support staff who
work on problem investigations, known
errors, and solution entries as assigned.
They investigate and validate tickets,
relate tickets to other records,
recommend action to be taken with
problem investigation results or known
errors, and create and activate solution
database entries.
Problem manager Problem managers are responsible for the
quality and integrity of the problem
management process. They monitor
problem investigations and known errors,
review problem investigations and
perform business impact analysis,
coordinate the assignment of problem
investigations and known errors to
problem assignees, and review completed
problem investigations and known errors.
! 39
White Paper
This section describes the Problem Management processes and user roles.
For information about using the application, see the BMC Service Desk:
Problem Management 7.0 User's Guide.
Problem queue manager The queue manager is responsible for
coordinating the assignment of problems
(and possibly incidents) to support staff.
There is no swim lane for this role in the
flows, because this role is typically
combined with another, such as the
problem manager. In BMC Remedy ITSM
this role can be automated through the
assignment processes.
Service support, service delivery, and
other related processes
This includes databases and other ITSM
processes that interact with the incident
management process, including:
! SLM
! CMDB
! Change Management
! Problem Management
! Knowledge Management
! Capacity and availability management
! Manual investigation and diagnosis
Table 3-A: Problem Management user roles (Continued)
Role Description
40 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Overview
The problem management process includes nine stages.
Figure 3-A: Overview of problem management process
The problem management process begins when a support technician
initiates a problem investigation.
Stage 1 Problem identification, recording, and classificationEither the problem
manager or problem assignee identify, record, and classify the problem.
Incident Management and reports from BMC Atrium CMDB can be used to
initiate problem investigations or to facilitate proactive problem
management.
Stage 2 ReviewIf the problem investigation is recorded by the problem assignee, it
is reviewed by a problem manager. The problem manager evaluates whether
to proceed with the problem investigation.
Stage 3 Problem investigation and diagnosisThe problem assignee investigates
the problem and determines the diagnosis.
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
1
ProbIem
identification,
recording, and
cIassification
2
Review
3
ProbIem
investigation
and diagnosis
4
ProbIem
resoIution and
cIosure
Investigation
initiated
Change
Management
5
Known error
identification
and recording
6
Known error
cIassification
and
assessment
7
Known error
resoIution and
cIosure
Incident
Management
Change
impIemented
8
KnowIedge
identification
and recording
9
KnowIedge
vaIidation and
pubIication
Incident
Management
Incident
Management
Configuration
Management
(management reports)
Overview ! 41
White Paper
Stage 4 Problem resolution and closureThe problem assignee or the problem
manager resolves and closes the problem investigation. The problem is
complete with the identification of a known error, or if a solution is
determined, which can be recorded as knowledge. When the problem is
complete, notification is sent to Incident Management, so that related open
incidents might be resolved.
Stage 5 Known error identification and recordingIf the problem investigation
resulted in a known error, the problem assignee identifies and records the
known error.
Stage 6 Known error classification and assessmentEither the problem assignee or
problem manager classifies and assesses the known error.
Stage 7 Known error resolution and closureEither the problem assignee or
problem manager resolves and closes the known error. Resolving the known
error involves the Change Management process. After the change is
implemented, the known error can be closed. When the known error is
closed, notification is sent to Incident Management, so that related open
incidents might be resolved.
Stage 8 Knowledge identification and recordingThe problem assignee identifies
and records knowledge generated from the process.
Stage 9 Knowledge validation and publicationThe problem assignee or problem
manager validates and publishes the recorded knowledge.
42 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Details
This section describes the detailed steps for each stage of the problem
management process.
Stage 1 Problem identification, recording, and classification
In this stage, the support technician initiates a problem investigation. The
support technician identifies the problem, records details, classifies it, and
assigns it to the problem manager for review.
Figure 3-B: Problem identification, recording, and classification
The process starts when the support technician initiates a problem
investigation. A problem investigation is typically initiated based on
information from Incident Management. A support technician working on
an incident can create a problem investigation from the incident to
determine the root cause.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
1.3
ReIate reIevant
CIs
1.2
ReIate reIevant
incidents
Investigation
initiated
Configuration
Management
Incident
Management
Incident
Management
1.1
Record
probIem detaiIs
1.4
CIassify
probIem
1.6
Assign
probIem to
probIem
manager
1.5
EstabIish
impact,
urgency, and
priority
2.1
1RWLILFDWLRQWR
DVVLJQHG
SUREOHPPDQDJHU
Details ! 43
White Paper
In the case of proactive problem management, a problem manager might
initiate a problem investigation if there is a pattern of incidents that indicate
a potential problem.
Figure 3-C: Proactive problem management
The process continues with the following steps:
1.1 The support technician or problem manager records the details of the
problem.
1.2 The support technician or problem manager relates relevant incidents to the
problem investigation.
If the problem manager initiated the investigation, it might be assigned to a
problem assignee to continue the work for this stage.
If the support technician created the investigation from an incident, the
application automatically relates the investigation to the incident. If
appropriate, the he or she can relate the investigation to multiple incidents.
If acting proactively, the problem manager could create the problem
investigation before any incidents are reported.
1.3 The support technician or problem manager relates relevant CIs to the
problem investigation.
For example, if there is a problem with email, the support technician might
relate the problem investigation to an email service CI, and possibly to the
email server CI.
The Configuration Management process manages and populates the CIs in
the CMDB.
1.4 The support technician or problem manager classifies the problem
investigation.
He or she specifies the appropriate product and operational categories for the
problem investigation.
Review health
Review incidents
for trouble areas
Generate RFC, as
appropriate, to
correct issues
44 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
1.5 The support technician or problem manager records the impact and urgency
of the investigation.
The impact and urgency of the investigation determine the priority.
1.6 The support technician assigns the investigation to a problem manager for
review.
The application notifies the assigned problem manager that a problem
investigation has been assigned. If the problem manager initiated the
investigation, it might not be reassigned.
Stage 2 Review
In this stage, the problem manager reviews and assigns the investigation.
Figure 3-D: Problem review
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
No
Yes
1RWLILFDWLRQ
WRSUREOHPDVVLJQHH
No
1RWLILFDWLRQ
WRSUREOHPPDQDJHU
Yes
3.1
2.1
Perform
business
impact anaIysis
2.2
Proceed with
investigation?
CanceI probIem
investigation
2.3
Assign
probIem for
root cause
determination
2.5
RecIassify, if
required, and
reassign
2.4
Accept
assignment?
1.6
3.12
Details ! 45
White Paper
2.1 The problem manager analyzes the impact of the problem on the business.
This analysis includes the cost of allowing the problem to continue, and also
the cost of investigating the problem.
2.2 The problem manager decides whether to proceed with the investigation.
If not proceeding with the investigation, the problem manager cancels the
investigation.
2.3 The problem manager assigns the problem investigation to a problem
assignee.
The problem assignee is responsible for determining the root cause of the
problem. The application notifies the problem assignee of the assigned
problem investigation.
2.4 The problem assignee determines whether to accept the assignment.
If the assignee accepts the assignment, the investigation moves to the
problem investigation and diagnosis stage with step 3.1.
2.5 If the assignee does not accept the assignment, the assignee performs the
following steps:
a If required, the assignee reclassifies the problem investigation.
b The assignee reassigns the investigation back to the problem manager.
The application notifies the problem manager that the assignment has
been reassigned. The process returns to step 2.3.
46 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 3 Problem investigation and diagnosis
In this stage, the problem assignee investigates the problem, and diagnoses
the root cause.
Figure 3-E: Problem investigation and diagnosis (steps 3.1 through 3.12)
3.1 The problem assignee starts to investigate the problem.
The assignee looks at both internal and external sources of data, such as the
Web. The assignee also looks at CIs in the CMDB.
3.2 The assignee determines whether he or she needs assistance.
If the assignee does not need assistance, the process continues with step 3.5.
3.3 The problem assignee generates tasks.
BMC Remedy Problem Management supports ad hoc tasks. The problem
assignee creates the tasks with a description of what needs to be
accomplished, and assigns them as appropriate.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
3.1
InitiaI
investigation
No
Configuration
Management
Change
Management
3.7
ReIate change
to probIem
Yes
No
Yes
No
3.6
Change
cause of
probIem?
3.8 Match to
existing
known errors?
3.9
ReIate
known error
to probIem
No
No
3.13
3.12 Continue
investigation?
3.10 Root
cause
Identified?
CompIete probIem
investigation
Yes
InternaI and
externaI data
sources,
incIuding the
Web
3.11
EscaIate to
probIem
manager
Yes
3.5
RFE?
Yes
2.4
2.3
3.2
Assistance
needed?
No
3.4
CIose task
activities
3.3
Generate
appropriate
tasks
Yes
3.14
Details ! 47
White Paper
3.4 The task assignees complete their tasks.
3.5 The problem assignee determines whether the problem is a request for
enhancement.
The end goal of the problem management process is to return normal to
operations or to prevent the loss or degradation of normal operations.
If the reported problem is a request to enhance services, this would be
performed by another process, such as change management. The problem
manager completes the investigation.
3.6 If there are recent changes, the problem assignee determines whether a
change caused the problem.
The Change Management process manages changes to CIs, and records the
history and rationale of the change process.
3.7 If a change caused the problem, the problem assignee relates the change to
the problem.
The problem assignee has found the root cause. The process continues with
step 3.13.
3.8 The problem assignee checks whether the problem matches any existing
known errors.
3.9 If it matches a known error, the problem assignee relates the known error to
the problem investigation.
The known error indicates the root cause. The process continues with
step 3.13.
3.10 The problem assignee determines whether the root cause has been identified.
If the root cause has been identified, the process continues with step 3.13.
3.11 If the root cause has not been identified, the problem assignee escalates the
investigation to a problem manager.
3.12 The problem manager determines whether to continue the investigation.
If the investigation is not being continued, the problem manager completes
the investigation.
If the investigation continues, the process returns to step 2.3, assigning the
problem investigation.
48 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Figure 3-F: Problem investigation and diagnosis (steps 3.13 through 3.19)
3.13 The problem assignee documents the root cause of the problem.
3.14 The problem assignee determines whether a workaround has been identified.
If a workaround has not been identified, the process returns tostep 3.11 for
the problem manager to evaluate.
3.15 The problem assignee documents the workaround.
3.16 The problem assignee completes the problem investigation.
The application notifies assignees of related open incidents that the problem
investigation is complete. This might allow the incident assignees to resolve
the incidents.
3.17 The problem assignee determines whether the problem creates a known
error.
When a problem is completed, it typically creates either a known error or a
knowledge entry. If it creates a known error, the process moves to the known
error identification and recording stage with step 5.1 on page 51.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
3.15
Document
workaround
3.13
Document
root cause
Yes
Yes
1RWLILFDWLRQ
WRDVVLJQHHVRI
UHODWHGRSHQLQFLGHQWV
5.1
Incident
Management
3.16
CompIete
probIem
investigation
3.14
Workaround
identified?
Yes
No
3.17
Known error?
3.18
KnowIedge
entry
required?
No
No
KnowIedge
Management
3.19
Create
knowIedge
entry
3.11
3.7 3.9 3.10
4.1
Details ! 49
White Paper
3.18 The problem assignee determines whether a knowledge entry is required.
If neither a known error nor a knowledge entry is created, the process moves
to the problem resolution and closure stage with step 4.1.
3.19 If a knowledge entry is required, the problem assignee creates it.
The problem investigation continues with step 4.1. The knowledge entry
follows the knowledge management process. A solution entry can be created
in the Problem Management application and validated prior to publication.
A more complete knowledge management process can be followed when
using BMC Remedy Knowledge Management.
50 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 4 Problem resolution and closure
In the problem resolution and closure stage, the problem manager reviews
the problem investigation and closes it. This stage occurs if a knowledge entry
is created from a completed problem investigation. If a known error is
created from the problem investigation, this stage occurs when the known
error is closed.
Figure 3-G: Problem resolution and closure
4.1 The problem manager reviews and validates the details of the problem
investigation.
The problem manager then closes the problem investigation. The application
notifies assignees of related incidents. The assignees might be able to resolve
the incidents.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
CIose probIem
investigation
4.1
Review and
vaIidate detaiIs
1RWLILFDWLRQWRDVVLJQHHV
RIUHODWHGLQFLGHQWV
Incident
Management
3.18
7.9
Details ! 51
White Paper
Stage 5 Known error identification and recording
This is the first stage of the known error process. In this stage, the problem
assignee records the details about the known error.
Figure 3-H: Known error identification and recording
A known error can be initiated from a problem investigation. In addition, a
support technician can create a known error without a problem investigation
when the root cause has already been determined.
5.1 The problem assignee records the known error details.
5.2 If the known error was initiated from a problem investigation, the problem
assignee relates the investigation to the known error.
5.3 If there are relevant incidents, the problem assignee relates them to the
known error.
5.4 The problem assignee relates the relevant CIs to the known error.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
Known error
initiated
6.1
A known error can be created without a
problem investigation when the root cause
has already been determined (for example,
errors discovered in development)
5.4
ReIate reIevant
CIs to known
error
5.1
Record known
error detaiIs
5.3
ReIate reIevant
incidents to
known error
5.2
ReIate probIem
investigation to
known error
3.17
Incident
Management
Configuration
Management
52 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
The process moves to the known error classification and assessment stage
with step 6.1.
Stage 6 Known error classification and assessment
In this stage, the problem assignee classifies the known error, the problem
manager reviews and assigns the known error, and the problem assignee
assesses how to correct the error.
Figure 3-I: Known error classification and assessment
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
6.4
Review known
error detaiIs
6.1
CIassify
known error
6.3
Assign known
error to
probIem
manager
6.2
EstabIish
impact,
urgency, and
priority
No
6.5
Assign known
error for
determination
of corrective
action
6.7
RecIassify, if
required, and
assign back
7.1
Yes
6.8
Assess means
of correcting
known error
6.6 Accept
assignment?
5.4
Details ! 53
White Paper
6.1 The problem assignee classifies the known error.
The problem assignee selects the appropriate product and operational
categorization.
6.2 The problem assignee establishes the impact and urgency of the known error.
The impact and urgency of the error determine the priority.
6.3 The problem assignee assigns the known error to a problem manager.
6.4 The problem manager reviews the details of the known error.
6.5 The problem manager assigns the known error to a problem assignee to
determine the appropriate corrective action.
This problem assignee might not be the same problem assignee who recorded
the details about the known errors.
6.6 The problem assignee determines whether to accept the assignee.
6.7 If not accepting the assignment, the assignee performs the following steps:
a If required, reclassify the known error.
b Assign the known error back to the problem manager.
The process returns to step 6.5.
6.8 The problem assignee assesses how to correct the known error.
The process moves to the known error resolution and closure stage with
step 7.1.
54 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Stage 7 Known error resolution and closure
In this stage, the problem assignee resolves the known error, and the problem
manager closes the known error.
Figure 3-J: Known error resolution and closure
7.1 The problem assignee determines whether third-party action is required, for
example if a vendor must repair equipment.
7.2 If third-party action is required, the problem assignee assigns the known
error to the vendor and monitors the known error.
Within ITSM, assigning a known error to a vendor is for informational
purposes. The problem assignee must communicate with the vendor about
the known error.
S
e
r
v
i
c
e

s
u
p
p
o
r
t
,
s
e
r
v
i
c
e

d
e
I
i
v
e
r
y
,
a
n
d

o
t
h
e
r

r
e
I
a
t
e
d

p
r
o
c
e
s
s
e
s
P
r
o
b
I
e
m

m
a
n
a
g
e
r
P
r
o
b
I
e
m

a
s
s
i
g
n
e
e
S
u
p
p
o
r
t

t
e
c
h
n
i
c
i
a
n
7.8
Change
required?
7.1
Third-party
action
required?
No
7.2
Assign to
vendor and
monitor known
error
Yes
7.7
Document
permanent
corrective
action
No
Yes
Change
Management
7.6
Permanent
correction
avaiIabIe?
Yes
No
No
7.9
CompIete error
controI
After PIR approvaI
ProbIem
Management
1RWLI\DVVLJQHHV
RIUHODWHG SUREOHPV
CIose known
error
6.8
7.3
InternaI
assistance
required?
7.4
Generate
appropriate
tasks
7.5
CIose task
activities
Yes
4.1
Details ! 55
White Paper
7.3 The problem assignee determines whether he or she needs assistance from
someone within the organization.
If the assignee does not need assistance, the process continues with step 7.6.
7.4 The problem assignee generates tasks.
BMC Remedy Problem Management supports ad hoc tasks. The problem
assignee creates the tasks with a description of what needs to be
accomplished, and assigns them as appropriate.
7.5 The task assignees complete their tasks.
7.6 The problem assignee determines whether a permanent correction is
available.
7.7 If the known error can be corrected, the problem assignee documents the
permanent corrective action.
7.8 The problem assignee determines whether a change is required to correct the
known error.
If required, the change request goes through the Change Management
process. After the change is complete and the post implementation review
(PIR) approves the successful implementation, the known error process
continues.
7.9 The problem manager completes error control.
The problem manager closes the known error. The application notifies
problem assignees of related problems, and it might be possible to close these
problems. A problem remains complete, but not closed, until the known
error is closed.
For the related problems, the process continues with the resolution and
closure stage at step 4.1 on page 50
56 "Chapter 3Problem Management
BMC Best Practice Process Flows for ITIL Incident and Problem Management
Backmatter.fm Page 17 Monday, October 16, 2006 10:28 AM
* 6 5 6 7 8 *
* 6 5 6 7 8 *
* 6 5 6 7 8 *
* 6 5 6 7 8 *
*65678*
Backmatter.fm Page 18 Monday, October 16, 2006 10:28 AM