Incident Management

Procedure Manual

TeliaSonera
The purpose of this document is to lay down the procedure for Incident
Management.

Document Control
0.1 Change History
Published
/ Version No.
Revised Date

Author

Section / Nature
of Change

18th December
2012

0.1

Santosh
Chaudhari

Initial Draft

21st December
2012

0.2

Santosh
Chaudhari

Output of first
workshop

0.2 Distribution List

Name

Role

Representing

Kerstin Wennberg

Business Solution
Manager

Telia Sonera

Annelie Hasselblad

Business Solution
Specialist

Telia Sonera

Hakan Pohjanen

Business Solution
Specialist

Telia Sonera

Amit Pai

Service Manager

Capgemini India

Bertil Vilhelmsson

Functional & Technical

( Herkulas)

Capgemini Sweden

Niklas Drewitz

Incident Manager

Capgemini Sweden

Anders Linden

Production Planner

Capgemini Sweden

Boris Ristov

Functional & Technical

(Argus)

Capgemini Sweden

Hiten Vira

Functional & Technical

(HAR)

Capgemini India

Role

Representing

Kerstin Wennberg

Business Solution
Manager

Telia Sonera

Annelie Hasselblad

Business Solution
Specialist

Telia Sonera

Hakan Pohjanen

Business Solution
Specialist

Telia Sonera

Amit Pai

Service Manager

Capgemini India

0.3 Approval List

Name

Table of contents
1

Scope and Objective.......................................................................................................................... 1

References / Definitions..................................................................................................................... 1

Policies................................................................................................................................................ 2

Process Workflow.............................................................................................................................. 3

Roles and Responsibilities................................................................................................................ 5

Procedure............................................................................................................................................ 6

RACI Matrix for the Incident Management......................................................................................11

Measurements, Verifications & References...................................................................................12

8.1 SLA Measurements.................................................................................................................... 12
8.2 Verification.................................................................................................................................. 13
8.3 Templates:.................................................................................................................................. 13

Interfaces/References to Other Processes.....................................................................................13

10

Guidelines......................................................................................................................................... 14

1 Scope and Objective

The primary objective of the Incident Management process is to restore normal services as soon as
possible, and minimize the adverse impact on business operations, thus ensuring that the best Current
levels of service quality and availability are maintained.
The Incident management process focuses on rapid service restoration. It does not include a detailed root
cause analysis of the incident.
This document defines the procedural activities on Incident Management to be operated at locations
TeliaSonera (Sweden) and Capgemini India.
The scope of Incident Management covers sub-processes and related activities for
Incident Detection & Recording wherein a Customer Operation/Telia Users identifies an issue and
reports it in the Remedy ticketing tool. In case the Originator is not able to log an incident they will
call/email to Telia System Support for logging of the Incident Record.
Incident Classification & Support wherein the Incident is analyzed regarding its priority, urgency,
impact and risk. Based on the classification the incident gets assigned to an appropriate Resolver Group.
Incident Investigation & Diagnosis wherein the HAR AM team (Level2 and Level3 support) collect all
needed information and, as preparation for the resolution, analyzes the Incident in detail.
Incident Resolution & Recovery wherein the resolution is precipitated by resolution team and handed
over to the Originator.
Incident Closure wherein the Telia System Support (L1 support) close the incident record in the remedy
system on accepted solution.

Proposal Title |

2 References / Definitions
The references and definitions used in this process manual are listed as below

Herkulas Contract Synopsis

ITIL V3: Service Lifecycle Service Operations covering Incident Management
AS-IS Processes of Incident Management

Abbreviation

Description

AM

Application Management

CI

Configuration Item

IM

Incident Management

ITIL

Information Technology Infrastructure Library

KEDB

Known Error Database

KPI

Key Performance Indicator

KDB

Knowledge Database

OLA

Operational Level Agreement

A,B,C,D

Priority of the Incidents

SLA

Service Level Agreement

Terms

Definitions

Incident

Incident means
(a) any event that is not part of the standard operation
of a service and that causes, or may cause, an
interruption to or a reduction in the quality of that
service.

Major Incident

Is an Incident classified according to its high impact

and urgency as priority A Incident.

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.

Incident Record

Incident record means information captured by Telia

Telia System Support personnel about an Incident.

Incident Management System

Is an automated system used to track the status of

Incident Records defined and maintained by Telia Telia
System Support personnel.

Impact

Represents the level to which an issue has the

potential of affecting the Business.

Proposal Title |

Terms
Priority

Definitions
A calculated value based upon Impact and Urgency.
This value can be used by the HAR AM team, to
establish the order in which incident tickets should be
considered and to resolve scheduling conflicts, as well
as to manage workload.

Known Error

Known underlying cause. Successful diagnosis of the

root cause of a Problem, and workaround or permanent
solution has been identified

Work Around

The pre-defined and documented technique in which to

restore functionality to the Originator with the required
functionality. A workaround is NOT a permanent
(structural) solution and only addresses the symptoms
of errors. These workarounds are stored in the KEDB.

Proposal Title |

3 Policies
Policy #

Policy Statement

3.1

Altering the priority policy

To alter the Priority of an Incident the impact and urgency must be reassessed. Any
reassessment must occur prior to the resolution of an Incident.
Approval must be obtained from the Originator prior to upgrading or downgrading the
Priority of an Incident. Where the incident Priority has been altered, the reason and
any obtained approvals must be entered in the remedy tool by the resolving group.

3.1

Incident Life Cycle Policy

An incident goes through different phases through its life cycle, the uses of the
stages needs to be chosen only based on scenarios mentioned under :

New: The initial state of an incident in which the concerned person records
the incidents, feeds in the information and generates a unique incident
number. The stage is automated and no manual intervention is required.

Assigned: Post logging the Incident, the incident originator/Telia System

Support assigns the incident to the appropriate resolver group. The status
change is automated and does not require manual intervention.

Work In Progress: Once the incident is assigned to a specific queue, a

member of the specific support group has to acknowledge the Incident. The
status must only be used by the specific resolver group and no one else.
Work in progress is a status in which the SLA counter calculates the effort
involved in actual resolution, the time spend on waiting for information,
coordinating with a third party etc will not be a part of this status.

Dormant: The status stops the SLA clock from ticking, for the following
reasons 1) Used prior to assigning an incident back to the Telia System
Support, in case more information is required from the user to
resolve the incident.
2) In case HAR AM team would like a third party or an internal
support group within Telia to extend support during the
resolution process. HAR AM team dials the Telia System
Support, provides the Incident/ Request number, and asks for
support in transferring the record to the appropriate resolver
group. The status of the ticket is changed from work in
progress to Dormant.
3) In case a change is required for an Incident to be resolved,
the status of the Incident will reflect as Dormant, from the
time the change is logged - till the time taken for the Change
approvals, to the next available deployment window.

Resolved: The status must be only used by a resolver group post validation
of resolution, after applying the fix. Resolved status does not mean the
closure of the Incident; the Originator receives a communication when the
status is modified to Resolved and is further contacted by the Telia System
Support team for confirmation. In case the Originator denies resolution, the
Incident is assigned back to the HAR AM team.

Closed: Incident is termed as closed once the originator is satisfied with the
resolution and provides a formal communication to Telia System Support
team for closure of the incident.

Proposal Title |

4 Process Workflow
Process Workflow Description

Proposal Title |

Proposal Title |

Proposal Title |

5 Roles and Responsibilities

Role

Organization

Incident
Initiator

Telia
Users/Customer
Operation
team/Capgemini/
3rd Party

Responsibility
Incident Management process gets initiated by the Incident
Initiator or through Event Management

Logging an Incident in the Remedy tool or by

calling Telia System Support team (+46) 020-909095)
to log an Incident in the Remedy tool.

Initiator can also email the issue to the Telia

System Support common mail ID (DL-SystemsupportAlla@tms.telia.se) to log an Incident.

Providing any required information to the

resolver group

Telia System
Support team

Telia

Confirming of the resolution as required

The Telia System Support team is responsible for the following:

tool

Opening an Incident Record in the Remedy

Gathering any required information for the

Incident

Reviewing and modifying initial Incident

priority

Interacting with Incident Initiator for any

additional information

Actively liaison with HAR AM team during the

resolution process

Incident
Manager

Capgemini

Closing the Incident

The Incident Manager is responsible for the following:

The Incident Manager is the owner of the
incoming incidents and has the overall end-to-end
responsibility for those incidents.

Confirming that each Incident is responded to

within the appropriate time frame

Check on Incident are resolved within the

stipulated time based on SLAs

Conducting Incident Review Meetings

Monitoring regular Incident measurements

Analyzing incidents to identify and act on

trends

Managing day-to-day Incident management

issues

Registering & assessing various situations

that may require critical situation handling

Preparing and submitting monthly MIS report

on Incident Management process

Proposal Title |

Role

Organization

Responsibility

Providing feedback to the appropriate parties

regarding Incident routing errors.

HAR AM
team

Capgemini

The HAR AM team is responsible for the following:

The HAR AM team has overall responsibility
for analyzing and resolving Incidents.

Ensure all the details for Incident resolution

are entered into the incident record.

Reviewing the Incident Record for

completeness

Contacting the Telia System Support team for

additional information as required.

Updating the Incident Record with any

additional information

Developing Permanent Resolution Plans for

Incidents

Contacting other support groups to arrange for

and schedule resources from other operational
Processes to execute solution plan tasks

Communicating with 3rd Party

Resolving the Incident

Confirming that the solution resolves the

Incident

Communicating the status of resolution

activities, as required

Notifying appropriate parties of the success or

failure of the resolution plan, as required

Recording all actions and status updates in

the Incident Record

3rd Party

Internal to
Telia/Support
Vendors/Contrac
tor

Providing status as requested

The 3rd Party is responsible for the following:

External activities needed for restoration of
services and functions.

frame

Resolution of Incident within the SLA time

Communicate with HAR AM team for

additional information

Providing status as requested

Proposal Title |

6 Procedure
Standard Incident Management Lifecycle is basically broken into five stages:

Incident Detection and Recording

Incident Classification and Initial Support

Investigation and Diagnosis

Resolution and Recovery

Incident Closure

Each stage is denoted as an activity and comprises of detailed tasks. These activities and associated
tasks are outlined below.

Activity IM 1: Incident Detection & Recording

Input

Tasks

Description of
Incident

Step 1.1 Experience Issue/Request

The general process is initiated by a Telia
User/Customer Operation facing an issue
and reporting it in the Remedy tool/or
raising it via Telia System Support
(L1Support).

Responsible

Output

Customer
Operation
team/ Telia
Users

An Issue has been

identified and
reported through
email / telephone /
Online Portal.

Customer
Operation
team/ Telia
Users

New Incident Record

Status of Incident= New

Description of
incident like
type of
service that
got impacted

Step 1.2 Log new Incident/Update

existing Incident Record
a) Incidents are logged by Customer
Operation team/ Telia Users in the
Remedy tool.
b) Incidents are logged by support
team
performing
proactive
monitoring.

Updated incident
record in case the
originator is not
satisfied with earlier
resolution
Update in case the
Telia System Support,
Application
Maintenance team
provides inputs on an
existing incident.

c) Incident can be logged by

Customer Operation team/Telia
Users by emailing to Telia System
Support
email
ID
DLSystemsupport-Alla@tms.telia.se
Status of Incident= New
Description of
Incident

Step 1.3 Call Telia System Support

Customer Operation team/Telia Users can
log Incident by calling to (+46) 020-909095)

Customer
Operation
team/ Telia
Users

Log an Incident ticket

by calling Telia
System Support
team.

Telia System
Support

New Incident Record

Status of Incident=New
Description of
Incident

Step 1.4 Log a new Incident/Update

by L1 team
a) Incidents are logged by Telia

Update an Incident
record

Proposal Title | 10

System Support team on Originator

behalf.
b) Incidents are logged by support
team
performing
proactive
monitoring.
c) Incidents are updated by Telia
System Support team for an
existing incident
Status of Incident=New Assigned

Activity IM 2: Incident Classification & Support 1 st Level

Issue
reported to
Telia System
Support by
Customer
Operation
team/ Telia
Users

Step 2.1 Incident Categorization and

Prioritization
Based on the Issue being reported to the
Telia System Support via Phone, Email, or
Online Portal, Telia System Support
classifies the Incident based on the impact
and urgency and accordingly set the
priority of the incident.

Telia System
Support (L1
Support)

Prioritized and
categorized incident
in the Remedy tool.

Telia System
Support (L1
Support)

Resolution of the
incident by Telia
System Support
based on selfanalysis.

Status of Incident=WIP
Prioritized
and
categorized
incident in the
Remedy Tool
Reference of
incident
resolution in
Knowledge
Database

Step 2.2 Incident Diagnosis and Update

Incident Details
Based on an initial diagnosis and reference
to the Knowledge Database, the Telia
System Support checks whether resolution
of the incident is possible by them.

Status Update of
Incident in Remedy
tool.

a) Service Request process is

invoked by Telia System Support
team if the ticket is related to
service request.
b) However, If the Telia System
Support identifies the Ticket as
priority A Incident then Major
Incidents process is triggered
c) If a known solution exists, please
refer to Activity 4: Resolution and
Recovery (Apply Fix)

Invoked Service
Request process
Invoked Major
Incident Process

Status of Incident=WIP
Updated
Incident
Record

Step 2.3 Determine Appropriate

Resolver group
In the case, Telia System Support cannot
resolve the incident on its own; they pass
the ticket to the appropriate resolver group.

Telia System
Support (L1
Support)

Status update of
incident in the
Remedy tool.
Assign the Incident
ticket to the resolver
group

HAR AM team
(L2 and L3
Support)

Incident
acknowledgement in
the Remedy system
for response SLAs in
accordance with

Status of Incident= Assigned

Updated
Incident
Record

Step 2.4 Accept the ticket and

Investigate
Upon receipt of incident, the HAR AM team
acknowledges its receipt to Telia System
Support for adherence to Response SLAs

Proposal Title | 11

guidelines

in accordance with the agreed guidelines.

a) However if the HAR AM team
identifies the ticket as Service
Request then, Service request
process will be invoked.
Status of Incident=WIP
Ticket
assigned to
HAR AM
team

Step 2.5 Communicate to Telia System

Support
HAR AM team member checks if the
priority, category of the incident is correct
and the incident is not out of scope for the
HAR AM team.

HAR AM team
(L2 and L3
Support)

Validation for out of

scope incident and
thereby routing to
Telia System Support.

If its out of scope, HAR AM team

communicates the same to Telia System
Support team. Afterwards it is for the Telia
System Support team to re-investigate the
assignment of the ticket. The ticket status
is set to Assigned in order to calculate
the SLA properly.

Activity IM 3: Investigation & Diagnosis

Incident
acknowledge
d in the
Remedy tool.

Step IM 3.1, IM3.2 and IM3.3 Provide

Requested Information
Based on response from Telia System
Support, for correct assignment of the
incident, it will be handled by HAR AM
team, anyway.

HAR AM team
(L2 and L3
Support), Telia
System
Support team
and Originator

Additional information
is gathered as
necessary

After the ticket is acknowledged by HAR

AM team, they validate the results of the
initial classification by the Telia System
Support.
To ensure adequacy in resolution of
incident, the HAR AM team ensures that
the required information is available, if its
in scope.
If this is not the case, then the information
is requested from Telia System Support
which serves as an interface to the
Originator and gathers the needed details.
The ticket status is set to Dormant in
order to calculate the SLA properly.
This information gathering loop is
conducted until all necessary information is
present with the HAR AM Team properly.
Status of Incident=WIP/Dormant
The ticket is
allocated and
all necessary
information is

Step IM 3.4 Perform Diagnosis (Detailed

Impact Analysis)
Based on the provided information, HAR
AM team checks the Solution Database of

HAR AM team
(L2 and L3
Support)

Impact analysis of the

incident and its
corresponding update
in the system.

Proposal Title | 12

gathered.

similar incidents and their solutions.

Ticket Status
= In
Progress

In the case, a suitable solution is present,

the HAR AM team can immediately
proceed applying the solution in the
Resolution & Recovery phase.

Trigger for Problem

Management /
Change
Management
process for resolution
of the issue.

However, if no satisfactory solution is

recorded, then the HAR AM team performs
a detailed diagnosis of the Incident,
including a detailed impact analysis, in
order to fully examine the issue and
prepare the resolution.
If this diagnosis reveals, that resolution is
not possible though workaround, then the
Problem Management process gets
triggered for permanent resolution of the
incident
Also, if a Change is needed, then the
Change Management gets initiated.
However, if the solution can be provided via
the Incident Management process itself,
then the activities progress further with the
next phase i.e. Resolution & Recovery.
Due to the activities of the Investigation &
Diagnosis phase continues, the HAR AM
team tracks all actions and outcomes in the
Incident Record. Thus, a complete history
of the event is provided, which is useful in
resolution and in similar cases.
Status of Incident=WIP

Activity IM 4: Resolution & Recovery

Updated
incident
status in the
Remedy tool
based on
completion of
impact
analysis

Step IM 4.1 and IM4.2 Incident ticket

assigned to 3rd Party
The HAR AM team identifies the
corresponding workaround / solution for
fixing the incident. Within this step, HAR
AM team identifies triggers for 3rd party
support, as needed, for resolution of the
incident. In this case, the HAR AM team
hands over the ticket to 3rd party for
providing the resolution.

HAR AM team
(L2 and L3
Support)
3rd Party

Workaround/Solution
identified.
Trigger for 3rd party
support for resolution
of incident, as
needed.

The status of the incident in the system at

Capgemini is changed to Assigned.
The 3rd party thereafter works towards
Incident as described above. Upon
completion of the resolution, the solution is
communicated by the 3rd party to HAR AM
team.
The status of the incident in the system is
now changed to In Progress.

Proposal Title | 13

Workaround /
solution of the
incident
identified and
updated in
system

Step IM 4.3 Apply Solution / Perform

Testing
The Telia System Support (from step
IM2.3), HAR AM team continues further
with providing the solution for fix of the
Incident.

HAR AM team
(L2 and L3
Support), Telia
System
Support

Workaround / solution
are applied properly.

HAR AM team
(L2 and L3
Support), Telia
System
Support team,
Originator

Resolution of the
incident
communicated to
Originator for
acceptance.

Status of Incident=Resolved

Activity IM 5: Closure
Resolution of
the incident
provided to
Telia System
Support for
communicatio
n to
Originator

Step IM 5.1 and IM 5.2 Incident Closure

The HAR AM team communicates the
resolution of the incident in accordance
with the SLA to Telia System Support team,
which further communicates the resolution
to the Originator.
In the case the user accepts the solution,
the Telia System Support team receives
this feedback and communicates the
acceptance to HAR AM team. Based on the
feedback received from the originator, Telia
System Support team updates the incident
record and closes the ticket by updating the
ticket status to Closed.

Acceptance of ticket
solution
communicated to
Telia System Support
team and HAR AM
team
Incident update in the
system as Closed
based on acceptance.

However, if the Originator is not satisfied

with the solution the ticket is reassigned to
HAR AM team with the updates.

Ticket is reassigned
to HAR AM team if
the Originator is not
satisfied with the
solution provided.

After providing resolution to incidents, if

confirmation is not received from Originator
to close the tickets, Telia System Support
team will send three emails to the users
and then close the ticket. The rule is also
applicable for incidents where further
information has been requested from the
user and the user has failed to provide the
details despite sending 3 intimations.
Status of Incident= Closed Assigned
Incident
Update in the
system as
Closed

Step IM 5.3 Update KEDB at L1 Support

The Telia System Support team (L1
Support) updates the Knowledge database
with resolution of the incident.

Telia System
Support team

Updates in
Knowledge Database
with resolution of
incidents

HAR AM team
(L2 and L3
Support)

Updates in
Knowledge Database
with resolution of
incidents

Status of Incident= Closed

Incident
update in the
system as
Closed

Step IM 5.3 Update KEDB at HAR AM

team (L2 and L3 Support)
The HAR AM team updates the Knowledge
Database with resolution of the incident.
This update of solution serves as future
reference for incidents and also triggers for
Continual Service Improvement in the
engagement. Progress and status reporting
is done for incidents to Capgemini Senior
Management and Telia.

Weekly & Monthly

Status Reports for
incidents

Proposal Title | 14

Status of Incident= Closed

Proposal Title | 15

7 RACI Matrix for the Incident Management

R Responsible
A Accountable
C Consulted
I Informed

Box
Ref
No

Description

Customer
Operation
s
team/Telia
Users

IM 1.4

Log New Incident

R/A

IM 2.1

Incident Categorization and

Prioritization

R/A

IM 2.2

Incident Diagnosis

C/I

R/A

C/I

IM 2.3

Determine Appropriate resolver

group

R/A

IM 2.4

Accept ticket and Investigate

A/C

IM 3.1

Communicate to Telia System

Support

C/I

R/A

IM 3.2

Need more information

C/I

IM 3.3

Request for Information

IM 3.4

Provide requested information

C/I

IM 3.5

Perform Diagnosis (Detailed

Impact Analysis)

R/A

IM 4.1

Identify Workaround / Solution

C/I

R/A

IM 4.2

Apply Solution / workaround

C/I

R/A

Telia System
Support (L1
Support)

HAR AM team
(L2 and L3
support)

3rd Party

Proposal Title | 16

Box
Ref
No

Description

Customer
Operation
s
team/Telia
Users

IM 4.3

Incident ticket assigned to 3rd

party

C/I

R/A

IM 5.1

Communicate to the Originator

R/A

IM 5.2

Incident Closure

C/I

R/A

IM 5.3

Update KEDB at L1 Support

only

IM 5.4

Update KEDB at HAR AM

team only

Telia System
Support (L1
Support)

HAR AM team
(L2 and L3
support)

3rd Party

R/A

R/A

Proposal Title | 17

8 Measurements, Verifications & References

8.1 SLA Measurements
KPI

Priority
Level A

Priority
Level B

Priority
Level C

Priority
Level D

Response time

Immediate

4 hours

2 working
days

Analyzed for
possible
further
development

Resolution time

2 hours

8 hours

5 working
days

Status every

60 minutes

2 hours

The monthly IM statistics have to include:

The number of Incidents

Sources of the Incidents (including reference to the impacted Services)
Frequency regarding the types or categories of Incidents
The duration of open Incidents (average and quantities by age)
Number of Incidents resolved
Other pertinent information regarding Incident resolution, including Service Level measurement
reporting

8.2 Verification

Monthly Incident manager review

Service review meeting
Senior Management reviews (Internally at Capgemini India)
Process Reviews and Internal Audits (Internally at Capgemini India)

8.3 Templates:

Monthly Status Report

Weekly Status Report
Metrics Sheet (Internal at Capgemini India)
Senior Management Review Report (Internal at Capgemini India)
Peer Review Log (Internal at Capgemini)

Proposal Title | 18

9 Interfaces/References to Other Processes

Capacity Management
Incident Management provides a trigger for performance monitoring where there appears to be a
performance problem. Capacity Management may develop workarounds for Incidents.

Availability Management
Availability Management will use Incident Management data to determine the availability of IT
services and look at where the incident lifecycle can be improved.

Service Level Management

The ability to resolve Incidents in a specified time is a key part of delivering an agreed level of
service. Incident Management enables Service Level Management (SLM) to define measurable
responses to service disruptions. It also provides reports that enable SLM to review Service Level
Agreements objectively and regularly. In particular, Incident Management is able to assist in defining
where services are at their weakest, so that SLM can define actions as part of the Service
Improvement Program (SIP). SLM defines the acceptable levels of service within which Incident
Management works, including:

Incident response times

Impact definitions

Target fix times

Service definitions, which are mapped to Telia

Expectations for providing feedback to Telia

Change Management
Where a change is required to implement a workaround or resolution, this will need to be logged as
an RFC and progressed through Change Management. In turn, Incident Management is able to
detect and Resolve Incidents that arise from failed changes.

Configuration Management
Configuration Management provides the data used to identify and progress Incidents. One of the
uses of the Configuration Management System (CMS) is to identify faulty equipment and to assess
the impact of an incident. It is also used to identify the Customers affected by potential problems. The
CMS also contains information about which categories of incident should be assigned to which
support group. In turn, Incident Management can maintain the status of faulty CIs. It can also assist
Configuration Management to audit the infrastructure when working to resolve an incident.

Knowledge Management
Data held in Knowledge Management repository should be accessed when analyzing and diagnosing
Incidents. Details of known errors and their workarounds should be documented in here to enable
quicker resolution of Incidents either by Telia System Support or HAR AM team.

Problem Management
For recurring incidents and major incidents Problem management is necessary to be carried out.
Incidents are often caused by underlying problems, which must be solved to prevent the incident from
recurring.

Event Management

Proposal Title | 19

Event Management is the process that (automatically) monitors all events that occur through the IT
infrastructure. Some events will raise an Incident; Incident Management will concentrate on restoring
the service as quickly as Current.

Proposal Title | 20

10 Guidelines
Appendix A Incident Classification
Tickets are analyzed by the Telia System Support (L1 Support team) and by HAR AM team (L2 and L3
support). The classification of an incident depends on impact and urgency. The priority levels contain the
Levels A (Critical Incident), B (high), C (medium) and D (low). Incidents identified as Major or highly
impacting are classified as A Incident and thus get handled by the Major Incident Management processes.
The incident gets analyzed regarding Impact and urgency.
Impact is defined under ITIL as a measure of the business criticality of an Incident, often equal to the
extent of a distortion of agreed or expected service levels. As such, it can be assessed based on the
effect of an Incident on the Clients business operations. An Impact may be assessed by taking into
account the number and business roles of the people affected or the business functions supported by the
systems affected.
Urgency is defined under ITIL as a measure of the business criticality of an Incident based on the
impact and on the business needs of the customer. As such, it can be assessed based on how quickly the
business of the Client will be affected by the loss of Service resulting from the Incident. A high-impact
Incident does not necessarily have an immediate Impact. For example, a Telia System Supporting end-ofmonth processing (impact high) can be assessed as urgency low if it occurs early in the monthly
processing cycle, but may be assessed as high if it nears the end of the cycle. A system that supports
the staffs dealing directly with the Clients customers or that supports online, real-time transactions may
always be assessed as a high urgency, even if it is only of moderate impact.

Priority A: An Incident will be assigned as Priority Level A, if the Incident is characterized by at least
one of the following:
(i)
(ii)
(iii)
(iv)
(v)

The Incident is one that has critical or significant impact through single or multiple or part IT
system failures.
The problems cause a complete loss of service or constitute a serious obstacle to essential
parts of the Telia business and the Telia customers that are affected by the Object.
The Incident is one that has a high impact on the operation of the affected Application or
other Service and that cannot be circumvented
The Incident, because of the immediacy of its effect on critical business functions, requires a
Change be made on an immediate-response basis.
Class A incidents include e.g. corrupt data, a critical function not being accessible, the system
hanging in an unidentifiable way, causing unacceptable or impossible delays for internal
resources in the Object or delays to internal answers, system crashes or repeated system
crashes during restart attempts.

Response time: Once a Priority Level A is acknowledged, it is required that the Support group starts work
immediately on fixing it and that normal Service is restored as soon as possible and within the shortest
Service Level of the affected Services.

Priority B: An Incident will be assigned as Priority Level B, if the Incident does not qualify for Priority
Level A but is characterized by at least one of the following:
(i)
(ii)
(iii)

The Incident can materially affect the Client, causing a substantial impact.
No acceptable Work Around is available, but operation can take place to a limited extent in
the Object.
The Incident is one that has an impact where Services are highly degraded to Telia Users at
one or more primary Client locations.

Proposal Title | 21

Response time: Once a Priority Level B is acknowledged, it is required that the Support group starts work
as soon as possible on fixing it (without adversely affecting the resolution of any Priority Level A Incidents)
and that normal service is restored as soon as possible and within the shortest Service Level of the
affected Services.

Priority C: An Incident will be assigned as Priority Level C, if the Incident does not qualify for priority
Level A or B but is characterized by the following:
(i)
(ii)
(iii)

The Incident does not materially affect the Client or does not cause a substantial impact,
but has the potential to do so if not resolved expeditiously.
The effect of the Incident is such that it does not require an immediate response
The Incident is one that has an impact where services are degraded to Telia Users at a
single non-primary Client location.

Response time: Once a Priority Level C is acknowledged, it is required that the Support group starts work
as soon as possible on fixing it (without adversely affecting the resolution of any Priority Level A or Priority
Level B Incidents) and that normal Service is restored as soon as possible and within the shortest Service
Level of the affected Services.

Priority D: An Incident will be assigned as Priority Level D, if the Incident does not qualify for Priority
Level A, B or C but is characterized by any of the following:
(i)

(ii)
(iii)
(iv)

The Incident does not have an adverse impact on the business operations of Telia
because of either the nature of the fault or the small extent of the fault and an acceptable
work around is in place.
The effect of the Incident is such that it does not require immediate resolution.
The Incident is one that does not require immediate attention and no business critical
Services are degraded or failed.
The problems cause no loss in the operation of the Object and comprise minor incidents,
incorrect behaviour or are not included in the documentation/operations manual for the
Object.

Response time: Once a Priority Level D is acknowledged, it is required that the Support group schedules
the remediation work (without adversely affecting the resolution of any Priority Level A, Priority Level B or
Priority Level C Incidents) such that normal Service is restored within the shortest Service Level of the
affected Services.

Appendix B Knowledge Database

The central knowledge database is used to capture, store and retrieve information and solutions for reuse
by Support group. This Knowledge Database will enable the sharing of policies, procedures, best
practices, and methods to resolve Incidents.

Appendix C Escalation
Escalation is the mechanism that assists timely resolution of an Incident. It can take place during every
activity in the resolution process. Escalation leads to the necessary management attention. The
management will decide about additional measures, which will assist the resolution process or start
interim solutions. The Incident Manager (IM) is the central point of escalation, wherein the escalation path
is local Incident ManagerService Manager Telia SPOC.
To be escalated are incidents which were not resolved in the time frames appropriate to the priority Level
of the Incident and the priority of the Telia User. The escalation procedures reflect and describe the
Incident, including:

Proposal Title | 22

Priority of the Incident

Location of the Incident and the name and/or number of affected Users
Elapsed time before an Incident is escalated to the next higher Priority Level

Appendix E Reporting

Key issues related to Incident Management

Number of Incidents during the month, grouped by priority
List of Incidents, short description, reference number
Links to Problems and Known Errors
Trend analysis of the Incidents reported during the 3 most recent months
Risks related to the recurrence of Incidents or emerging trends

Proposal Title | 23