Problem Management HS2016

Problem Management
Problem Management
Contents
1. PURPOSE ......................................................................................................................................................... 4
2. STRUCTURE OF THE DOCUMENT .................................................................................................................... 5
3. SCOPE ............................................................................................................................................................. 6
4. GENERAL ASSUMPTIONS ................................................................................................................................ 7
5. PROBLEM MANAGEMENT FRAMEWORK ....................................................................................................... 8
5.1 Problem Management Interactions ...................................................................................................... 8
5.2 Problem Identification .......................................................................................................................... 9
5.3 Open Problem Ticket ............................................................................................................................. 9
5.4 Problem Categorization ...................................................................................................................... 10
5.5 Problem Prioritization ......................................................................................................................... 10
5.6 Problem Diagnosis ............................................................................................................................... 10
5.7 Define a Work Around ........................................................................................................................ 12
5.8 Raise a Known Error Record ................................................................................................................ 12
5.9 Change Required ................................................................................................................................. 12
5.10 Update Ticket ...................................................................................................................................... 12
5.11 Notify the Originator ........................................................................................................................... 12
5.12 Close Ticket ......................................................................................................................................... 12
6. PROBLEM MANAGEMENT PROCESS ............................................................................................................. 13
6.1 Process Model ..................................................................................................................................... 13
6.2 Process Specification ........................................................................................................................... 13
6.3 Roles and Responsibilities ................................................................................................................... 16
6.4 Sub Process–Generate Problem Ticket ............................................................................................... 18
6.5 Sub Process–Generate Problem Ticket Specification .......................................................................... 19
6.6 Sub Process–Generate Problem Ticket Roles and Responsibilities ..................................................... 21
6.7 Sub Process–Problem Categorization ................................................................................................. 22
6.8 Sub Process–Problem Categorization Specification ............................................................................ 23
6.9 Sub Process–Problem Categorization Roles and Responsibilities ....................................................... 24
6.10 Sub Process–Problem Prioritization .................................................................................................... 25

2
Hartono Subirto 2016
Problem Management
6.11 Sub Process–Problem Prioritization Specification .............................................................................. 26
6.12 Sub Process–Problem Prioritization Roles and Responsibilities ......................................................... 27
6.13 Sub Process–Perform Problem Diagnosis ........................................................................................... 28
6.14 Sub Process–Perform Problem Diagnosis Specification ...................................................................... 29
6.15 Sub Process–Perform Problem Diagnosis Roles and Responsibilities ................................................. 30
6.16 Sub Process–Notify Originator ............................................................................................................ 31
6.17 Sub Process–Notify Originator Specification ....................................................................................... 32
6.18 Sub Process–Notify Originator Roles and Responsibilities .................................................................. 34
6.19 Sub Process–Close Ticket .................................................................................................................... 35
6.20 Sub Process–Close Ticket Specification ............................................................................................... 36
6.21 Sub Process- Close Ticket Roles and Responsibilities .......................................................................... 38
7. REFERENCE ................................................................................................................................................... 39
7.1 Business Rules ..................................................................................................................................... 39
7.2 Risk ...................................................................................................................................................... 39
7.3 Quality Attribute ................................................................................................................................. 40
7.4 Data Quality Dimension ...................................................................................................................... 41
7.5 Operation Policy .................................................................................................................................. 41
7.6 KPI ....................................................................................................................................................... 41
7.7 CTQ ...................................................................................................................................................... 42
7.8 Abstract Time-Scale............................................................................................................................. 42
7.9 SLA Terms ............................................................................................................................................ 42
GLOSSARY/ ACRONYMS ........................................................................................................................................ 43
APPENDIX A: BUSINESS PROCESS MODELING NOTATION REFERENCE ................................................................ 45
3
Problem Management
1. PURPOSE
The purpose of this document is to establish Problem Management process to manage the
lifecycle of all the problems pertaining to NOC operations in an effective way. The prime
objective of Problem Management is to assist resolution of incidents by identifying the root
cause of the incident, and thus to eliminate recurring incidents.
TR
4
Problem Management
2. STRUCTURE OF THE DOCUMENT
The Problem Management process document comprises the following chapters:
Chapter–3: Scope: This chapter describes the scope of the document and the Problem
Management process.
Chapter–4: General Assumptions: This chapter describes the underlined assumptions made
for both the document and Problem Management process.
Chapter–5: Problem Management Framework: This chapter exhibits the interaction of

Problem Management process with other related ITIL processes and also describes the high
level process sequence for Problem Management based on ITIL framework.
Chapter–6: Problem Management Process: In this chapter Problem Management process

and sub processes (if any) will be depicted and specified using rigorous BPMN and process
specification templates.
Chapter–7: References: This chapter serves as a prime reference to Problem Management

process and presents the details supporting it in tabular formats. The chapter describes
relevant Business Rules, Risks, Quality Attributes, Data Quality Dimensions, Operation
Policies, KPIs, CTQs, Abstract Time-scales and SLAs terms specific to Problem Management
process.
The Problem Management process is supposed to be a living document and consists of

various variable values which would frequently evolve or change as NOC’s Problem
Management process matures or changes
5
Problem Management
3. SCOPE
Following comprises the scope of Problem Management process.
 All the incidents which cannot be resolved by the Incident Management process and
require detailed problem analysis.
 All the incidents which occur frequently or periodically
 All the events which occur periodically and are repetitive
 Issues discover via Access Management process which signify a potential problem.
6
Problem Management
4. GENERAL ASSUMPTIONS
The following are the assumptions made for Problem Management process:
 Full coordination is provided to Problem Management team by Incident Management

team, and by the suppliers.
 KEDB already exists and the information provided via it, is accurate.
 The roles defined in all processes within this document can be attached to the existing
position e.g. Problem Manager role, can be played by a NOC Manager. Also the
distribution of roles to positions is dynamically handled based on the dynamics of shifts,
availability of resources, knowledge, load, soft threshold breaches etc. For instance,
Availability Manager role can be assigned in 1st shift to Problem Manager, and in the
2nd Shift this might be assigned to the Shift Leader.
 Any activity related assumptions are explicitly identified in related Process Specification
table in Chapter 6
7
Problem Management
5. PROBLEM MANAGEMENT FRAMEWORK
5.1 Problem Management Interactions
The following depiction shows the points of interaction of NOC’s Problem Management
process with other related ITIL processes. The arrows moving into Problem Management
process signify the inputs from the other processes to Problem Management process, and
the arrows moving out of the Problem Management process signify the inputs from Problem
Management process to other related ITIL processes. All these processes depicted below are
defined in their own respective dedicated documents.
IT Service Capacity Availability

Continuity Management Management
Release &
Deployment
Management
information
Performance
Problems that can Issues
Lead to business disruption
knowledge
Knowledge
Management
Fixed Problems
Problem
Event Periodic recurring
Management
Management events
Change to be done to resolve
Information to
improve Change
Management
CI information
Financial costs
Management
Access related problems
Incident
Data
Access
Management Incident Configuration Service Level
Management Management Management
The Problem Management process comprises of following sequence of activities:
 Problem Identification
 Open Problem Ticket
 Problem Categorization
 Problem Prioritization
 Problem Diagnosis
8
Problem Management
 Define a Work Around
 Raise a Known Error Record
 Change Required
 Update Ticket
 Notify the Originator
 Close Ticket
Section 5.2 -5.12 below describes the process sequence for NOC's Problem Management
based on ITIL framework. Section 6.1 Process Model sheds more light on the flow of
Problem Management process.
5.2 Problem Identification
Problem is identified via following sources:
 Event Management Process. When the actual root cause for the event is not known
or when the events are repetitive.
 Incident Management Process. All the incidents which cannot be resolved by the
Incident Management Process and require detailed problem analysis
 Access Management Process. Issues discovered via Access Management process

which signify a potential problem
5.3 Open Problem Ticket
Once the problem is identified, information in the Incident or event ticket are replicated into
the problem ticket. All the relevant details of the problem are recorded so that a full historic
record exists.
A cross-reference is made to the incident(s) which initiated the problem record and all
relevant details are copied from the Incident Record(s) to the Problem Record.
The following data is entered during the creation of a Problem Record:
 Unique Problem ID (assigned automatically by the system)

 Creation date and time (allocated automatically by the system)
 Person in charge for the creation
 Problem Details / Description
 Affected Service(s)
 Relevant SLA information
9
Problem Management
 Relationship to Configuration Item (CI)

 Problem Priority and Category
 Links to
o Incidents associated with this problem
o Other Problems, whose resolution is associated with this Problem
 Workaround for the circumvention of the Problem, if known
 Status
5.4 Problem Categorization
Problems follow the same classification as defined in the incident/event tickets.

Categorization is done on the below mentioned basis:
 Customer Segmentation
1) Region or Sector wise
 Type of services Provided
2) IP-VPN
3) DIA
 Category of Failure
4) Hardware
5) Software
6) Operating System
7) Application
8) Transmission
9) Data
10) Site Infrastructure
5.5 Problem Prioritization
Problems are prioritized in the way as incidents are:
 Severity /Urgency of the incident (how quickly the business needs a resolution) and
 The level of impact it is causing.
5.6 Problem Diagnosis
This investigation involves using various problem solving techniques to identify the root
cause of the problem. The symptoms of the problem are identified from incident records.
Various problem solving techniques can be applied. Few are mentioned below
 Pain Value Analysis. This is where a broader view is taken of the impact of an incident or
problem. Instead of just analyzing the number of incidents/problems of a particular type
in a particular period, a more in-depth analysis is done to determine exactly what level
10
Problem Management
of pain has been caused to the organization/business by these incidents/problems.

Following is taken into account:
o the number of people affected
o the duration of the downtime caused
o the cost to the business (if this can be readily calculated or estimated).
By taking all of these factors into account, a much more detailed picture of those
incidents/problems or incident/problem types that are causing most pain can be
determined – to allow a better focus on those things that really matter and deserve
highest priority in resolving.
 Kepner and Tregoe. Charles Kepner and Benjamin Tregoe developed a useful way of
problem analysis which can be used formally to investigate deeper rooted problems.
They defined the following stages:
o defining the problem

o describing the problem in terms of identity, location, time and size
o establishing possible causes
o testing the most probable cause
o verifying the true cause.
The above mentioned problem analysis can result into deeper insight into the problem
and hence the result.
 Ishikawa Diagrams: Kaoru Ishikawa (1915–89), developed a method of documenting

causes and effects which can be useful in helping identify where something may be
going wrong, or be improved. Such a diagram is typically the outcome of a brainstorming
session where problem solvers can offer suggestions. The main goal is represented by
the trunk of the diagram, and primary factors are represented as branches. Secondary
factors are then added as stems, and so on. Creating the diagram stimulates discussion
and often leads to increased understanding of a complex problem.
 Pareto Analysis. This is a technique for separating important potential causes from more
trivial issues. The following steps should be taken:
o Form a table listing the causes and their frequency as a percentage.

o Arrange the rows in the decreasing order of importance of the causes, i.e. the
most important cause first.
o Add a cumulative percentage column to the table
11
Problem Management
5.7 Define a Work Around
If the resolution of the problem would take longer or does not solve the problem, the next
step is to create a work around the problem. KEDB can be checked for work around, and in
case it does not exist a new work around should be created which can solve the problem
temporarily.
5.8 Raise a Known Error Record
As soon as the diagnosis is completed or a work around is identified for the problem a know
error record is raised.
5.9 Change Required
If the solution requires any change in the functionality it should be passed to the Change
Management Process, and resolution should be applied only when the change is approved
and schedule for release via release management process.
5.10Update Ticket
The Problem ticket should be updated upon completion.
5.11Notify the Originator
Once the problem is resolved, Service Desk informs the customer via email and telephonic
call, and upon confirmation closes the ticket.
5.12Close Ticket
When problem is resolved, the Problem Record is formally closed. A check shall be
performed at this stage to ensure that the record contains a full historical description of all
events and if record is not updated, the record shall be updated. The status of any related
Known Error Record is updated to show that the resolution is applied. Final closure of the
ticket is done by the Service Desk after approval from the NOC Operations Manager.
12
Problem Management
6. PROBLEM MANAGEMENT PROCESS
6.1 Process Model

Request Problem Manager Change Manager Service Desk
Event Incident
management management
Generate Problem
Ticket
+
Periodic events
Unsolved Incident/
Recurring incidents Problem
Categorization
+
Problem Detection
Problem
Prioritization
+
delegation
Perform Problem
Diagnosis
+
Access Create Known Error

Management Record
Yes
Success
no
Changed
Check for needed
work around available
yes
Not available
Change
Management
Define a work +
Around
Update ticket update
Notify the orginator
Close Ticket
6.2 Process Specification
Specification Description
13
Problem Management
Summary/Purpose The purpose is to prevent problems and resulting incidents from happening,
to eliminate recurring incidents and to minimize the impact of incidents that
cannot be prevented.
Scope This is a Level 2 Process Specification.
Primary ITIL Reference Problem Management-Service Operation Processes
Related ITIL Practices Release and Deployment Management, IT Service Continuity. Capacity
Management, Availability Management, Knowledge Management, Change
Management, Service Level Management, Configuration Management,
Incident Management, Event Management.
 Maintain high availability of services

Related Business Driver
 Provide quality service
Related Operational (Ref. 7.5)

Policies
Assumptions  Full coordination is provided to Problem Management process by

Incident Management team, Event Management team and by the
suppliers.
 KEDB already exists and the information provided via it is accurate.
Problem assigned from:

Trigger  Incident Management
 Access Management
 Supplier or Contractor
 Event Management
Problem Management
Basic Course of Event 1. Problem Detection (by requester Incident Management, Access
Management, Supplier or Contractor, Event Management)
2. Problem Manager generates problem Ticket
3. Problem Manager categorizes problem
4. Problem Manager prioritizes problem
5. Problem Manager performs problem diagnosis
6. Problem Manager creates Known Error Record
7. Problem Manager updates Ticket
8. Service Desk notifies the originator
9. Service Desk closes the ticket
10. End
Alternative Path Diagnosis Not successful Workaround is available
1. Problem Manager checks for work around in KEDB

2. Problem Manager applies work around
3. Problem Manager updates ticket
14
Problem Management
5. Service Desk closes the Ticket

6. End
Diagnosis Not successful Workaround not available
1. Problem Manager defines workaround

2. Problem Manager updates KEDB
3. Problem Manager updates ticket
6. End
Change Required
1. Problem escalates to Change Management process

2. Problem Manager Updates ticket
5. End
Change request not Approved

3. End
Exception Path Problem tickets are duplicate and are not Genuine
1. Problem Manager updates the information in the ticket

2. Problem Manager rectifies the problem
3. End
Extension points  Change Management
 Configuration & Release Management
Preconditions  A genuine problem as defined in the scope
 Availability of necessary information
Post -conditions  Root cause Identified
 Problem resolved
 Ticket closed
 KEDB updated
Related Business Rules (Ref.7.1)
Related Risks RR-001, RR-002, RR-008 (Ref.7.2)
15
Problem Management
Related Quality Attributes (Ref.7.3)
Related Data Quality (Ref.7.4)

Dimensions
Related Primary SLA Terms NA
Related KPIs (Ref.7.6)
Related CTQs (Ref.7.7)
Actors/Agents Problem Manager , Change Manager, Configuration Manager, Supplier

Incident Manager, Access Manager, Event Manager.
Delegation Delegation Rule -1: Problem Manager Not Available
1. Delegate the task to the shift leader

2. Update the task
3. Log the delegation
Delegation Rule -2: Problem Manager Overloaded
1. Delegate the task to the shift leader

2. Update the task
3. Log the delegation
Escalation NA
Process Map Section 5.1
Process Model Section 6.1
Other References Appendix A: Business Process Notation Reference
6.3 Roles and Responsibilities

Roles Responsibilities
Requester  Provides all relevant information.

 Acknowledges the resolution.
Problem Manager  Defines workarounds for problems not in KEDB

 Investigates the underlying causes of any real or potential anomalies in the
network
 Performs trend analysis using the necessary tools to identify the root cause
 Defines possible solutions to anomalies
16
Problem Management
 Puts forward requests for changes (RFC) needed to re-establish quality of

service
 Carries out post-implementation reviews to ensure that the changes have
brought about the desired results without causing side effects
 Periodically updates KEDB and initiate awareness to the NOC personnel to
improve the efficiency
Change Manager  Approves the RFCs

 Facilitates the Problem Manager for implementing the change
Service Desk  Notifies the originator

 Closes the ticket
17
Problem Management
6.4 Sub Process–Generate Problem Ticket
Incident Manager Access Manager Event Manager Problem Manager
Auto generate
Problem Ticket ID
detected
Probelm
Category
Ticket ID
Identify Priority
Problem Date
and Time
Owner
Problem Owner
details
Effected
Service
Event record
Symptoms
Problem details
Symptoms
Access
record
Symptoms
CI details
Notify the owner
Incident
record
Resolution or
work around
CMS
Current Status
Related
Problem KEDB
Closure Time
and date
18
Problem Management
6.5 Sub Process–Generate Problem Ticket Specification
Summary/Purpose Open Problem Ticket
Scope This is a level 2 Process Specification.
Primary ITIL Reference Problem Management- Service Operation Processes
Related ITIL Practices NA
Related Business Driver Accuracy of record
Related Operational NA
Policies
Assumptions  Problem has been correctly identified
 Problem information provided by customer is correct and accurate.
 Problem information emerging from Event Management, Access

Management, and Request Management are accurate.
Trigger Identified Problem
Open Ticket
Basic Course of Event 1. Problem Manager auto generates Ticket ID
2. Problem Manager enters Problem Category
3. Problem Manager identifies Priority
4. Problem Manager enters Problem Date and Time
5. Problem Manager enters Problem Owner
6. Problem Manager checks Effect Service
7. Problem Manager enters Problem Details
8. Problem Manager enters Configuration Item (CI) Details
9. Problem Manager identifies the category (resolution or work around)
10. Problem Manager enters current problem status
11. Problem Manager assigns other related Problem
12. Problem Manager enters closure Time and date
13. End
Notify Owner
1. Problem Manager identifies the auto generates Ticket ID, Identifies
problem Owner and current status
2. Problem Manager notifies Problem Owner
19
Problem Management
3. End
Alternative Path NA
Exception Path NA
Extension points  Problem Categorization
 Problem Prioritization
Preconditions Problem is genuine.
Post -conditions  Problem record gets established.
 Problem owner gets notified.
Related Business Rules NA
Related Risks RR-003(Ref 7.2)
NA
Related Quality Attributes
NA
Related Data Quality
Dimensions
NA
Related Primary SLA Terms
NA
Related KPIs
NA
Related CTQs
Actors/Agents Problem Manager, Event Manager, Access Manager, Problem Manager .
1. Delegate the Issue to additional agent with same Role

2. Update the Issue
3. Log the Delegation

2. Update the Issue
20
Problem Management
Escalation NA
Process Map 5.1
Process Model 6.4
Other References NA
6.6 Sub Process–Generate Problem Ticket Roles and Responsibilities

Problem Manager Provides details on Problem description
Event Manager Provides details on Problem description
Access Manager Provides details on Problem description
Problem Manager  Collects Problem information from Problem, Event and Access Manager.
 Open a problem ticket and fills in applicable details
21
Problem Management
6.7 Sub Process–Problem Categorization
Service Desk
Categorization rules
Open
Ticket
Customer
Segmentation
Sector Wise Region
Types of Service
IP-VPN DIA
Failure Category
Operating Transmission Data

Hardware Software Application Infrastructure
System
22
Problem Management
6.8 Sub Process–Problem Categorization Specification
Summary/Purpose Problem Categorization
Related Business Driver Accuracy of records
Policies
Assumptions Problem categorization rules have been established
Trigger Open Ticket
Problem Categorization
Basic Course of Event 1. Problem Manager identifies the Customer Segmentation (Sector Wise/
Region)
2. Problem Manager identifies type of Service (IP-VPN, DIA)
3. Problem Manager categories Failure (hardware/ Software/ Operating
System/ Application/ Transmission/ data/ Infrastructure
4. End
Alternative Path NA
Exception Path NA
Extension points Problem Prioritization.
Preconditions Ticket should be opened.
Post -conditions Problem category gets identified.
23
Problem Management
Related Risks RR-004 (Ref 7.2)
NA
Related Quality Attributes
NA
Related Data Quality
Dimensions
NA
Related Primary SLA Terms
NA
Related KPIs
NA
Related CTQs
Actors/Agents Problem Manager
Delegation Delegation Rule -1: Problem Not Available

2. Update the Issue

2. Update the Issue
NA
Escalation
Process Map 5.1
Process Model 6.7
6.9 Sub Process–Problem Categorization Roles and Responsibilities

 Identifies customer segmentation
Problem Manager
 Identifies type of service
 Identifies failure category
24
Problem Management
6.10Sub Process–Problem Prioritization
Problem Manager
Categorized
Problem
Business
Severity Level
Impact
Prioritization rules
Establish
Prioritization
25
Problem Management
6.11Sub Process–Problem Prioritization Specification
Summary/Purpose To prioritization problem
Related Business Driver Accuracy of records
Policies
Assumptions Problem categorization rules have been established
Trigger Categorized Problem
Problem Prioritization
Basic Course of Event 1. Problem Manager identifies severity Level and business Impact
2. Problem Manager establishes priority
3. End
Alternative Path NA
Exception Path VIP tickets are treated on high priority
Extension points Perform Diagnosis
Preconditions NA
Post -conditions Problem category gets identified.
Related Risks RR-005 (Ref 7.2)
26
Problem Management
Related Quality Attributes NA
Related Data Quality NA

Dimensions
Related KPIs NA
Related CTQs NA

2. Update the Issue

2. Update the Issue
Escalation NA
Process Map 5.1
Process Model 6.10
6.12Sub Process–Problem Prioritization Roles and Responsibilities

 Identifies severity level and business Impact
Problem Manager
 Establishes prioritization.
27
Problem Management
6.13Sub Process–Perform Problem Diagnosis
Problem Manager
Prioritized problem
Incident
database
Pain Value
Analysis
Problem Analysis Specialist groups

Problem trends
Techniques (supplier vendors)
+
Kepner and
Tregoe
ok
Problem Identified
Ishikawa Diagrams
Identify Solution
Pareto Analysis
Test
28
Problem Management
6.14Sub Process–Perform Problem Diagnosis Specification
Summary/Purpose This process describes problem diagnosis
Related Business Driver NA
Policies
Assumptions Problem database already exists and is accurate.
Trigger Prioritized Problem
Problem Diagnosis
Basic Course of Event 1. Problem Manager identifies problem trends. uses vendor/ supplier
support, applies problem analysis techniques
2. Problem Manager Identifies the problem
3. Problem Manager Identifies the solution
4. Problem Manager tests the solution
5. End
Alternative Path NA
Exception Path NA
Extension points Work Around, Create Knowledge Error Record
Preconditions NA
Post -conditions Problem gets resolved
29
Problem Management
Related Risks RR-006, RR-007 (Ref 7.2)

Dimensions
Related KPIs NA
Related CTQs NA

2. Update the Issue

2. Update the Issue
Escalation NA
Process Map 5.1
Process Model 6.13
6.15Sub Process–Perform Problem Diagnosis Roles and Responsibilities

Tries to resolve the incident using vendor support and various problem
Problem Manager solving techniques.
30
Problem Management
6.16Sub Process–Notify Originator
Service Desk Incident Manager Event Manager Access Manager
Problem Update Problem Solved
Problem Record
Requestor contact
details
Obtain contact
details
Email
Call the requester
NO
Confirm Confirm Confirm

Acceptance Acceptance Acceptance
Receive
Confirmation
Confirmation
Yes
31
Problem Management
6.17Sub Process–Notify Originator Specification
Summary/Purpose Notify Customer
Related Business Driver Validation
Policies
Assumptions Protected means of communication exist between Service Desk and customer
Trigger Resolved Problem, Problem update
Notify Customer
Basic Course of Event 1. Service Desk obtains contact details from problem record
2. Service Desk calls and /or emails customer
3. Requester confirms acceptance (email)
4. Service Desk receives confirmation
5. End
Alternative Path NA
Confirmation Not received

Exception Path 1. Service Desk obtains contact details from problem record again (new)
2. Service Desk calls and /or emails customer
3. Requester confirms acceptance (email)
4. Service Desk receives confirmation
5. End
Extension points Close Ticket
Preconditions Valid Incident request has been identified
Post -conditions Customer confirms the receipt of notification.
32
Problem Management
Related Risks NA

Dimensions
Related KPIs NA
Related CTQs NA
Actors/Agents Service Desk, Incident Manager, Event Manager, Access Manager
Delegation Delegation Rule -1: Service Desk Not Available

2. Update the Issue
Delegation Rule -2: Service Desk Overloaded

2. Update the Issue
Delegation Rule -3: Customer Not Available

1. Identify alternate contact
2. Update the Issue
Escalation NA
Process Map 5.1
Process Model 6.16
33
Problem Management
6.18Sub Process–Notify Originator Roles and Responsibilities

Receives the notification and confirms the acceptance
Customer

Event Manager

Incident Manager

Access Manager
 Obtains contact details from problem record.

Service Desk
 Calls and /or emails requester to update on the problem status , if the
receipt is not confirmed, rechecks the contact details and resends the
notification
 Receives confirmation
34
Problem Management
6.19Sub Process–Close Ticket

Service Desk Incident Manager Event Manager Access Manager
KEDB
Requester Notified
KEDB Update
KEDB updated?
Update
YES
Access record
Check
Documentation
Documentation Update
updated?
YES
Conduct Send Feedback Send Feedback

Send Feedback
Satisfaction
Survey
Update Problem
Survey record
Information
Formal closure Update Ticket status
Problem record
35
Problem Management
6.20Sub Process–Close Ticket Specification
Summary/Purpose Close Problem ticket
Related Business Driver Integrity and Accuracy of records
Policies
Assumptions Secure communication exists between Service Desk and Customer
Trigger Customer acknowledges the Problem decision /resolution
Close Ticket
Basic Course of Event 1. Service Desk checks whether KEDB is updated
2. Service Desk checks whether the documentation is complete
3. Service Desk conducts satisfaction survey (email)
4. Requester sends feedback ( email)
5. Service desk updates problem information
6. Formal Closure
7. End
Alternative Path NA
Exception Path NA
Extension points NA
Preconditions Problem request has been entertained.
Post -conditions Formal Closure of the problem request.
36
Problem Management
Related Risks NA

Dimensions
Related KPIs NA
Related CTQs NA
Actors/Agents Service Desk, Incident Manager, Event Manager, Access Manager
Delegation Delegation Rule -1: Service Desk Not Available

2. Update the Issue
Delegation Rule -2: Service Desk Overloaded

2. Update the Issue
Delegation Rule -3: Customer Not Available

1. Identify alternate contact
2. Update the Issue
Escalation NA
Process Map 5.1
Process Model 6.19
37
Problem Management
6.21Sub Process- Close Ticket Roles and Responsibilities

Receives customer satisfaction survey and after evaluation of the service sends
Event Manager it to Service Desk.
Incident Manager it to Service Desk.
Access Manager it to Service Desk.
 Checks whether the KEDB has been correctly updated.

Service Desk
 Verifies the documentation, if the documentation is not updated updates
it.
 Conducts satisfaction survey (email) and updates the survey record
 Formally closes the ticket and problem.
38
Problem Management
7. REFERENCE
This chapter serves as a prime reference to Chapter 6 and presents the details supporting
Chapter 6 in tabular formats. This chapter consists of various variable values which would
frequently evolve or change as NOC’s Problem Management process matures or changes.
At minimal this document would be updated by NOC’s operation team biannually.

However, if need arises this document may be updated earlier than its prescribed revision
period.
7.1 Business Rules
BR ID Description Context Rule Source
BR-001 Problem Manager will not work on Operations Problem Management NA

ongoing incidents for resolution
BR-002 It is not mandatory to know the root Operations There may be some NA
cause of all problems. problems with root
causes not known
7.2 Risk
Risk ID Description Source Severity Level Status Resolution
RR-001 Only one Problem Manager Medium NA To train other

resource on
problem
management
RR-002 Resources not provided to High NA To establish

Problem Manager to identify better
root cause communication
means, and
involve NOC top
management
when required.
RR-003 Integration between problem Generate High NA To maintain a

record and other records Problem single central
(event, access, incident) Ticket information
should be compatible Specification repository
39
Problem Management
RR-004 Problem categorization is not low NA Streamline the

in line with the incident categorization categorization
categorization process so to
have similar data
values such that
incident record
can be easily
transferred to
the problem
record.
RR-005 The priority of problem prioritization Medium NA Frequently

changes in course of time Monitor the
priority of the
problem and
update when
required.
RR-006 To facilitate the investigations Problem High NA To establish a

time stamping should refer to Diagnosis single time
a common time server. Specification server in .
RR-007 In order to facilitate the Problem High NA Detailed testing

investigation and diagnosis Diagnosis of the problem
there does not exist any test Specification should be
environment. conducted
before its release
in the live
environment.
RR-008 KEDB information is not Process High NA The KEDB should

accurate be Problem
Manager s
responsibility
and all records
added or deleted
should be vetted
by Problem
Manager.
7.3 Quality Attribute
QA ID Description Threshold
40
Problem Management
QA-001 Authenticity TBD
QA-002 Non-Repudiation TBD
7.4 Data Quality Dimension
DQ ID Description Threshold
DQ-001 Timeliness TBD
7.5 Operation Policy
Policy ID Description Context Importance (1-5)
OP-001 Problem Manager is available only in General Shift Operations TBD
7.6 KPI
Name Acronym Description Context Importance Soft Hard

Threshold Threshold
Time to TTRP Defines the cycle Operations 3 TBD TBD

resolve time to complete
problem the problem
resolution
process
Note: the above section refers to internal KPIs, which would be managed and monitored by
Problem Manager as per the timescale mentioned in the respective KPI
41
Problem Management
7.7 CTQ
Name Acronym Description Context Importance Soft Hard

Threshold Threshold
Time to TTRPV Deviations in Operations 3 TBD TBD

resolve TTRP
problem
Variation
7.8 Abstract Time-Scale
Name Acronym Description Quantification
NA NA NA NA
7.9 SLA Terms
SLA ID Description Context KPI CTQ
SLA-001 TDB Operations TBD TBD
42
Problem Management
GLOSSARY/ ACRONYMS
Terminology Description
Abstract Time Scale Time Scale that will be quantified both during operations and continuous
process improvement. These time identifiers are correlated with the soft
thresholds that are dynamically specified during life span of the process.
BPMN Business Process Modelling Notation
Business Process Modelling Notation is the practice of documenting an

organisation’s key business processes in a graphical format
Business Rules Business Rules are intended to assert business structure or to control or
influence the behaviour of the Business. Business rules describe the operations,
definitions and constraints that apply to an organization
CMDB Configuration Management Database
A set of tools and databases that are used to manage an IT Service Provider's
Configuration data. The CMS also includes information about Incidents,
Problems, Known Errors, Changes and Releases; and may contain data about
employees, Suppliers, locations, Business Units, Customers and Users
CTQ Critical to Quality
Critical To Quality (CTQ) is continuous measuring and monitoring tool agreed

between the internal processes to achieve greater customer satisfaction
Data Quality The totality of features and characteristics of data that bears on their ability to
Dimensions satisfy a given purpose
DIA Dedicated Internet Access
ITIL Information Technology Infrastructure Library
The Information Technology Infrastructure Library (ITIL) is a set of concepts and

practices for Information Technology Services Management (ITSM), Information
Technology (IT) development and IT operations.
KEDB Known error Database
This is a database provided for storing essential data on trouble shooting

information and retrieving them as when require. Inputs will be from Incident
43
Problem Management
management or from problem management
KPI Key Performance Indicator
A metric that is used to help manage a process, IT service or activity. Many

metrics may be measured, but only the most important of these are defined as
KPIs and used to actively manage and report on the process, IT service or
activity. KPIs should be selected to ensure that efficiency, effectiveness, and cost
effectiveness are all managed
MC Maintenance Centre
NOC Network Operation Centre
Operational Policy Rules defined to operate the process.
Problem A cause of one or more Incidents. The cause is not usually known at the time a
Problem Record is created, and the Problem Management Process is responsible
for further investigation.
Quality Attributes Quality attributes are non-functional requirements used to evaluate the
performance of a process.
RCA Root Cause Analysis
Risk A metric that is used to help manage a process, IT service or activity. Many
metrics may be measured, but only the most important of these are defined as
KPIs and used to actively manage and report on the process, IT service or
activity. KPIs should be selected to ensure that efficiency, effectiveness, and cost
effectiveness are all managed.
Root Cause The underlying or original cause of an Incident or Problem.
SLA Service level Agreement
An Agreement between an IT Service Provider and a Customer. The SLA

describes the IT Service, documents Service Level Targets, and specifies the
responsibilities of the IT Service Provider and the Customer
TTRP Time to resolve problem
TTRPV Time to resolve problem variation.
44
Problem Management
APPENDIX A: BUSINESS PROCESS MODELING NOTATION REFERENCE
INTRODUCTION
Business Process Modelling (“BPM”) is the practice of documenting an organisation’s key

business processes in a manner which:
 is highly graphical
 focuses on business terminology rather than technical
 allows all business steps/tasks to be included, not just those which involve a computer
system.
Below is a mention of various concepts of BPMN with the relevant definition and graphic
notation.
PROCESS START
All processes have to start somehow, general notation for a process models
commence with the START event, is a circle.
One can use simply the basic unmarked start event as above, or one of the different types of start
event, to provide more detail as described below.
If a process starts when some sort of message arrives, mail, email, text. Following Message start
notation can be used
If a process starts by virtue of the passage of time – e.g. TIMER Start

1st Jan review or 4 days after the purchase order is sent, following notation can be
used
If the process starts when a rule/condition is met – e.g. RULE Start

when Incident Impact is more than 100,000.
If a process starts when another process finishes. Following notation can be used LINK Start
If there is more than one ‘trigger’ for a process to start. Following notation can be MULTIPLE Start
used
TASK AND SUB PROCESS

Task Task is a lowest level activity in a process map. A
task is used when the work is not broken down to a
45
Problem Management
finer level of detail

Sub A Sub-process is a compound activity which can be
Process broken down into finer details.
Loops Loops task or sub process continues to iterate until

the loop condition is true. Review
INTERMEDIATE EVENTS
Following
notation can be
used to display
BASIC MESSAGE TIMER RULE LINK MULTIPLE
the intermediate
event, similar to
start and end
events.
PROCESS END
All processes have to end somehow, general notation for a process models end will be
a circle with a solid line.
One can use simply use the basic end event as above, or you can use one of the different types of end
event, to provide more detail, as described below:
If a process ends by something being sent via a message of some sort e.g., mail, email, MESSAGE End
document, following notation can be used.
If the end of this process causes the start of another, following notation can be used. LINK End
If more than one consequence of the process ending, following notation can be used. MULTIPLE End
46
Problem Management
SWIMLANES
A Pool represents a participant in a

Process. It is also acts as a
Pool “swimlane” and a graphical
Name
container for partitioning a set of
activities from other Pools
A Lane is a sub-partition within a
Pool and will extend the entire
Lane length of the Pool, either vertically
Name
or horizontally. Lanes are used to
organize and categorize activities.
CONNECTORS
A Sequence Flow is represented by a solid line with a solid

arrowhead (see the figure to the right) and is used to show
Sequence Flow the order (the sequence) that activities will be performed
in a Process.
A Message Flow is represented by a dashed line with an
open arrowhead (see the figure to the right) and is used to
Message Flow show the flow of messages between two separate Process
Participants. In BPMN, two separate Pools in the Diagram
will represent the two Participants.
ARTIFACTS
The ANNOTATION shape is used to add comments to a This is some text which
Annotation helps explain something
process model. It consists of text in a square left bracket about the model
A data object represents a piece of data which is required or

Data Object
produced by the process eg. Customer details, output.
A grouping is purely for documentation or explanatory

purposes. It has no impact on the model. It consists of a
Group
rectangle with dashed lines and rounded corners, usually
enclosing other objects.
47
Problem Management
GATEWAYS
The values of the process are examined to determine

Exclusive which path to take
Each branch will be evaluated and will not stop when

Inclusive one branch condition becomes true.
Provides a mechanism to synchronise parallel flow and

Parallel to create parallel flow.
48

Problem Management HS2016

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Problem Management HS2016

Uploaded by

Copyright:

Available Formats

Problem Management

2. STRUCTURE OF THE DOCUMENT .................................................................................................................... 5

4. GENERAL ASSUMPTIONS ................................................................................................................................ 7

5. PROBLEM MANAGEMENT FRAMEWORK ....................................................................................................... 8

5.1 Problem Management Interactions ...................................................................................................... 8

5.2 Problem Identification .......................................................................................................................... 9

5.3 Open Problem Ticket ............................................................................................................................. 9

5.4 Problem Categorization ...................................................................................................................... 10

5.5 Problem Prioritization ......................................................................................................................... 10

5.6 Problem Diagnosis ............................................................................................................................... 10

5.7 Define a Work Around ........................................................................................................................ 12

5.8 Raise a Known Error Record ................................................................................................................ 12

5.9 Change Required ................................................................................................................................. 12

5.10 Update Ticket ...................................................................................................................................... 12

5.11 Notify the Originator ........................................................................................................................... 12

5.12 Close Ticket ......................................................................................................................................... 12

6. PROBLEM MANAGEMENT PROCESS ............................................................................................................. 13

6.1 Process Model ..................................................................................................................................... 13

6.2 Process Specification ........................................................................................................................... 13

6.3 Roles and Responsibilities ................................................................................................................... 16

6.4 Sub Process–Generate Problem Ticket ............................................................................................... 18

6.5 Sub Process–Generate Problem Ticket Specification .......................................................................... 19

6.6 Sub Process–Generate Problem Ticket Roles and Responsibilities ..................................................... 21

6.7 Sub Process–Problem Categorization ................................................................................................. 22

6.8 Sub Process–Problem Categorization Specification ............................................................................ 23

6.9 Sub Process–Problem Categorization Roles and Responsibilities ....................................................... 24

6.10 Sub Process–Problem Prioritization .................................................................................................... 25

6.11 Sub Process–Problem Prioritization Specification .............................................................................. 26

6.12 Sub Process–Problem Prioritization Roles and Responsibilities ......................................................... 27

6.13 Sub Process–Perform Problem Diagnosis ........................................................................................... 28

6.14 Sub Process–Perform Problem Diagnosis Specification ...................................................................... 29

6.15 Sub Process–Perform Problem Diagnosis Roles and Responsibilities ................................................. 30

6.16 Sub Process–Notify Originator ............................................................................................................ 31

6.17 Sub Process–Notify Originator Specification ....................................................................................... 32

6.18 Sub Process–Notify Originator Roles and Responsibilities .................................................................. 34

6.19 Sub Process–Close Ticket .................................................................................................................... 35

6.20 Sub Process–Close Ticket Specification ............................................................................................... 36

6.21 Sub Process- Close Ticket Roles and Responsibilities .......................................................................... 38

7.1 Business Rules ..................................................................................................................................... 39

7.2 Risk ...................................................................................................................................................... 39

7.3 Quality Attribute ................................................................................................................................. 40

7.4 Data Quality Dimension ...................................................................................................................... 41

7.5 Operation Policy .................................................................................................................................. 41

7.6 KPI ....................................................................................................................................................... 41

7.7 CTQ ...................................................................................................................................................... 42

7.8 Abstract Time-Scale............................................................................................................................. 42

7.9 SLA Terms ............................................................................................................................................ 42

GLOSSARY/ ACRONYMS ........................................................................................................................................ 43

APPENDIX A: BUSINESS PROCESS MODELING NOTATION REFERENCE ................................................................ 45

2. STRUCTURE OF THE DOCUMENT

The Problem Management process document comprises the following chapters:

Chapter–5: Problem Management Framework: This chapter exhibits the interaction of

Chapter–6: Problem Management Process: In this chapter Problem Management process

Chapter–7: References: This chapter serves as a prime reference to Problem Management

The Problem Management process is supposed to be a living document and consists of

Following comprises the scope of Problem Management process.

 All the incidents which occur frequently or periodically

 All the events which occur periodically and are repetitive

 Full coordination is provided to Problem Management team by Incident Management

5. PROBLEM MANAGEMENT FRAMEWORK

5.1 Problem Management Interactions

IT Service Capacity Availability

The Problem Management process comprises of following sequence of activities:

 Open Problem Ticket