Incident Management

Transport Network
Business Process

PT. Telekomunikasi Selular

2014

Version
1.1

Incident Management
Business Process

Page
2/21

Transport Network

Document Approval
Prepared By
No

Name

Title

Thomas Heriyanto

Manager Resource Operation Center

Mohamad Ichsan

Manager Change and Release

Management

Suseno Ari Wibowo

Agus Wijaya

Pj Supervisor Resource Incident

Ronald Renaldi

Staff Resource Event

Hendri M. Tarigan

Manager Transport Support and

Readiness

Bany Nugroho

Senior Engineer Transmission

Operation Expert Job Coordinator

Adhe Pahlevi

Andon B. Bandono

Signature

Pj Manager Service Operation Center

Senior Engineer Data

Communication Core Operation
Expert Job Coordinator
Senior Engineer Data
Communication Service Operation
Expert Job Coordinator

Reviewed by
No

Name

Charles Mankin

Moelky Furqan

Title
General Manager NOC
Management and
Service Helpdesk

Remarks

Signature

Remarks

Signature

General Manager
Transport Network
Operation

Approved by
No
1

Name
Juanita Erawati

Title
Vice President Network
Operation Management

Approved by
No

Name

Title

Abdus Somad Arief

Director of Network

Remarks

Date
23/04/14

Signature

Version
1.1

Incident Management
Business Process

Page
3/21

Transport Network

Version History
No
1
2
3

Date
July, 24 2012
August 6,2012
February 14,2014

Version
0.1
1.0
1.1

Description
First Draft
Initial Release
Update Release

Date
23/04/14

Author
Suseno AW
Suseno AW
Ronald Renaldi

Incident Management
Business Process

Version
1.1

Date
23/04/14

Transport Network

Table Of Contents

Document Approval ....................................................................................................................2

Version History ............................................................................................................................3
Table Of Contents .......................................................................................................................4
1.

Executive Summary..............................................................................................................5

2.

Purpose ................................................................................................................................6

3.

Scope ....................................................................................................................................6

4.

Incident Management Process ............................................................................................6

4.1.

High Level Process ........................................................................................................6

4.2.

Sub Process Incident Management for Transmission Non Leased Line .......................8

4.3.

Sub Process Incident Management for Data Communication .....................................9

4.4.

Sub Process Incident Management for Transmission Leased Line ............................10

4.5.

Sub Process Problem Management Transport Domain .............................................11

5.

Roles & Responsibility........................................................................................................12

6.

Incident Ticket Process ......................................................................................................13

7.

Service Level Management ................................................................................................15

Appendix 1- Glossary of Terms .................................................................................................16

Appendix 2 Service Level Management .................................................................................20
Appendix 3 Emergency Escalation Process ............................................................................21

Page
4/21

Incident Management
Business Process
Transport Network

Version
1.1

Date
23/04/14
Page
5/21

1. Executive Summary
Telkomsel as one of the biggest Telco operator in the world, have the vision of Best, Leading and
Trusted Mobile Lifestyle and Solutions Provider in the Region and mission of Deliver mobile
lifestyle-services & solution in excellent way that exceed customer expectation, create value for
all stakeholders, and the economic development of the nation.
In an effort to realize the Telkomsel Vision and Mission as well as in order to face the second
curve of the Telkomsel business dynamics, comprehensive transformation program implemented
in all function unit in Telkomsel, Not least in the Network Operation.
Network operation transformations including People & Organization, Process & Procedures,
Tools Application & Infrastructure domain, while the main objective is to realize Operational
Excellence.

Figure 1 Transformation Domain

People & Organization

New Network organization structure has implemented in early 2012, as one of the main key of
transformation.
System Transformation
System transformation including Next Generation OSS Fault Management, Configuration
Management, Performance Management & Service Quality Management implementation,
Application for Business Support deployment, also consolidation of existing tools & application is
conducted to create an Network unified & automation system.
Process Transformation
Along with People & System transformation, Process transformation also required to align
between Organization & System that deployed.
One of Network Operation Key Process is Incident Management.
Incident Management
Incident Management is set of process to manage lifecycle of incident, while the main objective is
to restore a 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
On this document, Incident Management Process for Transport Network Domain is described and
documented.

Version
1.1

Incident Management
Business Process

Date
23/04/14
Page
6/21

Transport Network

2. Purpose
The purpose of Incident Management business process is to be an operational guidance of
incident handling in network operation that can be conduct more effectively, and follow
administrative procedures and documented.

3. Scope
Incident Management focus on managing the lifecycle of incident that arise within Transport
Network NE, comprise but not limited to :
- Transmission Non Leased Line
SDH & DWDM FO, Microwave
- Data Communication
IPBB Router,CS Router, PS Router, OCS Router,IN Router,VAS Router, CLNS Router (OAM BSC),
MSC Router(OAM MSC), XOT Router(OAM BSC X25), CE Router(consentrator BSC router), BSC
Router(OAM BSC IP),Hi-Cap Router
- Transmission Leased Line
Terrestrial, Satellite

4. Incident Management Process

4.1. High Level Process

Event Arise

Incident
Detection &
Preliminary
Impact
Analisys

Incident
Assignment &
Notification
Broadcast

Investigation,
Resolution &
Recovery

Closure

Figure 2 High Level Processes

Event Arise
Event arriving as the input of Incident Management Process. It can be NE Alarm, performance
degradation alert.
Incident Detection & Preliminary Impact Analysis
This step is related to incident detection, including NE Alarm detection from system & Alarm
Management on how to manage alarm arriving from NE including, filtering/suppress,
normalization and correlation to have preliminary root cause analysis.
Preliminary impact analysis also conduct in this step in order to classify the priority of
Event/Alarm to be handled by assigned workgroup.
Incident Assignment & Notification Broadcast
In this activity, Incident is assigned to specific workgroup by Ticketing System. For many specific
Event/Alarm, according to user agreement, Incident assignment can be done either by Manually
or Automatic in the ticketing system.
Fault / Incident notification also broadcasted via defined media (SMS & Email) followed by phone
call to Network Operation and Business User.

Incident Management
Business Process
Transport Network

Version
1.1

Date
23/04/14
Page
7/21

Investigation, Resolution & Recovery

This activity is the troubleshooting process in order to network service restoration/recovery.
In relation to that, Change Management process might be arise and/or workaround solution is
conducted.
Closure
In this phase consist of Incident ticketing closing & Report , notification broadcast closing activity.
Incident evaluation is conducted to check whether there are new Problems, Workarounds or
Known Errors that must be submitted to Problem Management process

Version
1.0

Incident Management
Business Process

Date
23/04/14
Page
8/21

Transport Network

4.2. Sub Process Incident Management for Transmission Non Leased Line
Business Process

: Incident Management Transmission Non Leased Line Domain

Network Element

NOC Management &

Service Helpdesk
Event Arise

SDH DWDM FO, Microwave

ICT Region
NS (1st Layer)

NOM-TNO
(3rd Layer)

RPA/TPA (2nd Layer)

Remarks

Incident Detection &

Preliminary Impact
Analysis

Investigation &
Diagnose

4
8
5

Resolution (Workaround
or permanent)

12

Investigation &
Diagnose

Investigation &
Diagnose
9

Incident Escalation &

Notification Broadcast

Change Management
Network (If Needed)
7

No
Incident Update

Service
Recovered?

Yes
Monitoring
Stability

Resolution (Workaround
or permanent)

Resolution, (Workaround
or permanent)

Change Management
Network (if needed)

Change Management
Network (if needed)

Escalate
11

Service
Recovered?

rd

No

party TSA
covered?

No

Service
Recovered ?

3rd party TSA

covered?

No
Yes

Yes

3rd Party Vendor

Resolution

Yes

10

Monitoring
Stability
14

Incident Closing &

Closed Notification
Broadcast

Closed

15

Monitoring
Stability

Yes

1.Event arriving as the input of Incident Management

Process
2. This step is related to incident detection, including NE
Alarm detection from system & Alarm Management on how to
manage alarm arriving from NE including, filtering/suppress,
normalization and correlation to have preliminary root cause
analysis.
Preliminary impact analysis also conduct in this step in order
to classify the priority of Event/Alarm to be handled by
assigned workgroup.
3. In this activity, Incident is assigned to specific workgroup
by Ticketing System. For many specific Event/Alarm,
according to user agreement, Autofault rules is defined and
running to have an automatic ticket assignment to specific
workgroup.
Incident notification also broadcasted via defined media
(SMS & Email) to Network Operation and Business User.
Incident Mgt Perform tracking and update the info to the
Incident are being handled, to the service back to normal
(until the ticket closed), as well as collecting evidence from
the incident happened
4. NS Conduct investigations and diagnosis of the root
Caused Incident happened
5. NS Incident Resolution either by workaround or
permanent solution. In this step, change mgt process might
be involved.
6. If Service recovered, Monitoring stability is performed &
NS will do change ticket status into Resolved. .
7. If Service not recovered, and need 2nd level support
escalation, NS will Reassign ticket to RPA/TPA
8. RPA/TPA parallel with TNO will do root caused
Investigation & diagnosis.
9. RPA/TPA parallel with TOS conduct Incident Resolution
either by workaround or permanent solution. In this step,
change mgt process might be involved.
10. If Service recovered, monitoring stability is performed &
RPA/TPA will do change ticket status into Resolved
11. If Service not recovered, and include for 3rd party TSA.
RPA/TPA will escalate to 3rd party vendor. 3rd Party Vendor
will do incident resolution.
Otherwise need for HQ 3rd level support escalation, RPA/TPA
will Reassign ticket to TNO HQ.
12. TNO will do Investigation, Diagnose, Resolution &
Recovery
13. Incident Mgt will do ticket closing & Closed Notification
Broadcast. Incident Inventarization & Documentation
performed. Problem Management Process Is Performed if
necessary
Document Information
Version
Date
Author
Page

:
:
:
:

1.0
06 August 2012
Suseno Ari Wibowo, Liberty S
1 of 4

Version
1.0

Incident Management
Business Process

Date
23/04/14
Page
9/21

Transport Network

4.3. Sub Process Incident Management for Data Communication

NOC Management &

Service Helpdesk
Event Arise

Business Process

: Incident Management Data Communication Domain

Network Element

: IPBB Router,CS Router, PS Router, OCS Router,IN Router,VAS Router, CLNS Router (OAM BSC), MSC Router(OAM MSC),
XOT Router(OAM BSC X25), CE Router(consentrator BSC router), BSC Router(OAM BSC IP),Hi-Cap Router

ICT Region
NS (1st Layer)

RPA/TPA (2nd Layer)

NOM-TNO
DCCO & DCSO (3rd Layer)

Incident Detection &

Preliminary Impact
Analysis

Investigation &
Diagnose

4
8
5

Resolution (Workaround
or permanent)

12

Investigation &
Diagnose

Investigation &
Diagnose
9

Incident Escalation &

Notification Broadcast

Change Management
Network (If Needed)
7

No
Incident Update

Service
Recovered?

Yes
Monitoring
Stability

Resolution (Workaround
or permanent)

Resolution, (Workaround
or permanent)

Change Management
Network (if needed)

Change Management
Network (if needed)

Escalate
11

Service
Recovered?

rd

No

party TSA
covered?

No

Service
Recovered ?

3rd party TSA

covered?

No
Yes

Yes

3rd Party Vendor

Resolution

Yes

10

Monitoring
Stability
14

Incident Closing &

Closed Notification
Broadcast

Closed

15

Monitoring
Stability

Yes

Remarks
1.Event arriving as the input of Incident Management
Process
2. This step is related to incident detection, including NE
Alarm detection from system & Alarm Management on how to
manage alarm arriving from NE including, filtering/suppress,
normalization and correlation to have preliminary root cause
analysis.
Preliminary impact analysis also conduct in this step in order
to classify the priority of Event/Alarm to be handled by
assigned workgroup.
3. In this activity, Incident is assigned to specific workgroup
by Ticketing System. For many specific Event/Alarm,
according to user agreement, Auto fault rules is defined and
running to have an automatic ticket assignment to specific
workgroup.
Incident notification also broadcasted via defined media
(SMS & Email) to Network Operation and Business User.
Incident Mgt Perform tracking and update the info to the
Incident are being handled, to the service back to normal
(until the ticket closed), as well as collecting evidence from
the incident happened
4. NS Conduct investigations and diagnosis of the root
Caused Incident happened
5. NS Conduct Incident Resolution either by workaround or
permanent solution. In this step, change mgt process might
be involved.
6. If Service recovered, monitoring stability is performed &
NS will do change ticket status into Resolved. .
7. If Service not recovered, and need 2nd level support
escalation, NS will Reassign ticket to RPA/TPA
8. RPA/TPA parallel with DCCO/DCSO will do root caused
Investigation & diagnosis.
9. RPA/TPA parallel with DCCO/DCSO Conduct Incident
Resolution either by workaround or permanent solution. In
this step, change mgt process might be involved.
10. If Service recovered, monitoring stability is performed &
RPA/TPA will change ticket status into Resolved
11. If Service not recovered, and include for 3rd party TSA.
RPA/TPA will escalate to 3rd party vendor. 3rd Party Vendor
will do incident resolution.
Otherwise need for HQ 3rd level support escalation, RPA/TPA
will Reassign ticket to DCCO/DCSO.
12. DCCO/DCSO will do Investigation, Diagnose, Resolution
& Recovery
13. Incident Mgt will do ticket closing & Closed Notification
Broadcast. Incident Inventarization & Documentation
performed. Problem Management Process Is Performed if
necessary
Document Information
Version
Date
Author
Page

:
:
:
:

1.0
06 August 2012
Suseno Ari Wibowo, Liberty S
2 of 4

Version
1.0

Incident Management
Business Process

Date
23/04/14
Page
10/21

Transport Network

4.4. Sub Process Incident Management for Transmission Leased Line

NOC Management &

Service Helpdesk

Business Process

: Incident Management Transmission Leased Line

Network Element

: Transmission Terrestrial & Satellite

ICT Network Mgt Region

NS/RPA (1st & 2nd Layer)

External Network
Provider

NOM-TNO
(3rd Layer)

Start
Receive
Notification
Incident
Transmission
Leased Line

Acknowledge
Event
Transmission
Leased Line From
NMS

Escalate Incident
to Helpdesk
Network Provider

Broadcast
Notification
Incident Leased
Line

Receive Notification
Incident Transmission
.Leased Line

Helpdesk Provider
Create Ticket
Incident

Investigate &
Diagnose

Escalate Incident
to Network
Provider

5
Escalate Incident to
Network Provider

Resolution &
Recovery

Remarks

1. Incident Mgt will do acknowlegdgement of Event

Transmisi leased line from alarm NMS.
2. Incident Mgt escalate the incident to Network provider
Helpdesk .
3. Incident Mgt will do Incident Notification Broadcast to
ICT Regional & TOS, with informasi of Incident Ticket
Number that has been submited.
4. ICT Regional conduct investigation of Incident, whether
incident cause came from Tsel NE or Provider NE and
update incident information to TNO and/or escalate to
provider.
5.TNO will escalate to Network provider if Incident cause
is in provider NE also coordinate for Resolution &
Recovery .
Resolution time according to SLA of provider
6. Provider will do incident resolution & recovery incident
& provide incident report to Telkomsel (TNO, ICT Region)
also inform if incident has been resolved (Closed)
Incident that has service impact, incident update will be
updated every hour.
7. After receive incident report that has been resolved, ICT
region will update incident info to Incident Mgt.
8. Incident Mgt will collect & give recapitulation of Incident
info to TNO as a reference of recommendation creation
restitusion of leased line payment.

Incident Update
6

Broadcast
Notification
Incident Closed

Recapitulation
Data of Incident
Leased Line

Report Incident
(Closed)

7
Progress Update
Incident Closed

Recapitulation Data of
Incident Leased Line

Document Information

End

Version
Date
Author
Page

:
:
:
:

1.0
06 August 2012
Suseno Ari Wibowo, Hirwandi, Liberty S
3 of 4

Version
1.0

Incident Management
Business Process

Date
23/04/14
Page
11/21

Transport Network

4.5. Sub Process Problem Management Transport Domain

Business Process

: Problem Management

NOC Management & Service Helpdesk

Customer Complain
Management Process

ICT Region

ROC

SOC
Incident
Management
Process

Remarks

NOM-TNO

1. Problem Identification
Identification Problem to that came from
Incident, Customer Complain.

Problem
Identification
Categorization &
Prioritization

2.Categorization & Prioritization

To Record & Prioritize the problem with
appropriate diligence, in order to facilitate a
swift and effective resolution.
If the problem is caused by infrastructure
reason, then diagnosis will be conducted by
TNO.
As for other reason, diagnosis will be
conducted by NOC with related parties.

Problem
Type?
Infrastructure
Reason

Others
(Process, etc)
Problem Mgt
Meeting

Diagnosis (Root
Cause Analysis)

3
Problem Mgt
Meeting

Diagnosis (Root
Cause Analysis)

Recommendation of
Permanent Solutions

4
Recommendation of
Permanent Solutions

Apply Fix?
Problem
Tracking &
Monitor

YES
Change & Release
Management
Process

Record Know
Error Database

6
Implementation
Fix

Problem Closing
Review

NO

Effective?

Implementation
Fix

5
NO

3, Diagnosis
Conduct Diagnosis to Identify the underlying
root cause of a problem.
Problem Management Meeting with related
party including 3rd party vendor will be
conducted if necessary.
4. Recommendation of permanent solution
Document Deliver to TNO
5. Problem Resolution, initiate the most
appropriate & economical problem
resolution. Change Management Process
will be conducted if necessary.
6. Implementation & Evaluation Resolution
To ensure that after a successful problem
solution, the problem record contains a full
historical description and that related Known
Error Record are updated.
7. Problem Closing Review
To Review the resolution of a problem in
order to prevent recurrence and learn any
lesson for the future.
If the resolution is not effective to solve
problem, then have to initiate a further
diagnosis.
Document Information

YES
Closed

Version
Date
Author
Page

:
:
:
:

1.0
20 Juli 2012
Suseno Ari Wibowo, Liberty S
4 of 4

Incident Management
Business Process

Version
1.1

Page
12/21

Transport Network

5. Roles & Responsibility

No
1

Role
Event Management

Incident Management

First Layer Incident Resolution

Second Layer Incident

Resolution

Third Layer Incident

Resolution

Problem Management

Description
Event Management including
- Alarm Monitoring & Detection
Manage lifecycle of incident
- Incident Escalation/assignment
- Incident Tracking
- Incident Notification Broadcast
- Incident closing
First Layer Incident Resolution
- Investigation
- Resolution
- Recovery
Second Layer Incident Resolution
- Investigation
- Resolution
- Recovery
Third Layer Incident Resolution
- Investigation
- Resolution
- Recovery
Problem Identification,
Administration & Inventory
Problem Diagnose (root cause
analysis),
Resolution/Implementation Fix

Date
23/04/14

Role Mapping
Resource Operation
Center Department
Resource Operation
Center Department

ICT Region- Network

Service Department

ICT Region- Resource

Performance
Assurance Department
Transport Network
Operation Division

Resource Operation
Center Department
Transport Network
Operation Division

Version
1.1

Incident Management
Business Process

Page
13/21

Transport Network

6. Incident Ticket Process

Incident Management Ticket Process Flow
Incident Management Ticketing Process
New

NOC

Ticket Started

Assigned

InProgress

Assign to Prev
Assignee

Resolved

Yes

Re Open ?

Canceled

No

Perform 1st Level

Troubleshooting

Yes

Solved?
No

ICT Region - NS

Received
Assignment

Working On
Ticket

Yes

Canceled ?

Ticket
Cancelled

No
Yes
Solved ?
No

Ticket
Resolved

No
Escalate ?
Yes

ICT Region - RPA

Received
Assignment

Working On
Ticket

Ticket
Cancelled

Canceled ?
No
Yes
Solved ?

No

Ticket
Resolved

No
Escalate ?
Yes

NOM - TNO

Received
Assignment

Working On
Ticket

No

Canceled ?

Yes

No
Yes
Solved ?

Ticket
Resolved

Date
23/04/14

Ticket
Cancelled

Closed

Ticket Closed

Version
1.1

Incident Management
Business Process

Date
23/04/14
Page
14/21

Transport Network

Detail :
1. Ticket creation (Status = New).
2. Incident ticket will be assigned to her/himself in order to perform 1st level troubleshooting. If
the incident still remains, the ticket will be assigned to 1st level support , ICT Region Network
Service (NS) workgroup (Status = Assigned).
3. A member of assigned group will take the assignment to her/himself (Status = Assigned).
4. Assignee will work on ticket (Status = In Progress).
5. Assignee can update ticket to pending (Status = Pending) and then resumes it again after
some time (Status = In Progress).
6. If NS cannot solve ticket, it can be escalated to 2nd support, ICT Region Resource Performance
Assurance (RPA) workgroup. (Status = Assigned).
7. If 2nd Support RPA cannot solve ticket, it can be escalated to 3rd support NOM HQ group, TNO
(Status = Assigned).
8. Once incident ticket is solved (Status = Resolved), it will need validation conducted by NOCROC Department
9. ROC-Incident Management can close CC ticket (Status = Closed), or reopen it if the solution is
not solving incident ticket (Status = Assigned).
10. If there is no validation until 3 days after ticket resolved, then it will be closed automatically
by system (Status = Closed).
Incident Management Status & Lifecycle
The status represents the state of the incident ticket handling. The following is the table of status
Status
New
Assigned
In Progress
Pending
Resolved
Closed

Description
The Incident Ticket is unassigned.
The Incident ticket has been assigned to workgroup
but has not acknowledge
The assignment has been accepted and the assignee
is working toward resolution
Work on the incident ticket has been temporary
suspended
A resolution or work around to restore the service
has been determine, need further validation
Restoration of the service has been validated and no
longer required.

The following is the flow diagram of status changes during the life cycle of incident ticket.
Cancelled

New

Assigned

In Progress

Pending

Resolved

Closed

Version
1.1

Incident Management
Business Process

Date
23/04/14
Page
15/21

Transport Network

7. Service Level Management

Incident Severity Baseline:
Severity
Critical

Description
Incident that has criteria of :
- NE Down
- No Service Available/Totally
Outage
- Totally signaling down
- CDR Billing Interruption

Major

Incident that has criteria of :

- Partially Service
Available/Partially Outage
- Partially Performance
Degradation

Minor

Network System or Service is UP,

and usable with minor problem
or warning condition.

Sample of Case
- NE Down due to power module problem
- Router Core Down.
- FO Cut for main & protection route for
backbone link
- Cross connect Main Module fail and cant
switch to protection for main ring of
backbone link
- Optical Transceiver main module problem
fail and cant switch to protection for
backbone link.
- Aggregate module problem for STM-16
above.
- Etc
Note : Correlate with critical severity at Core &
RAN
- Cross connect Main Module fail and cant
switch to protection for satellite ring.
- Microwave link stm1 propagation problem.
- Etc.
Note : Correlate with major severity at Core &
RAN
- Crossconnect Main Module fail and able to
switch to protection
- Optical Transceiver main module problem
fail and can switch to protection
- NE Module problem, but Service still UP.
- Etc
Note : Correlate with minor severity at Core &
RAN

Service Level Commitment:

Incident Assignment
Incident Resolution

Critical
10 Minutes
4 Hours

Please see appendix 2 for more detail.

Major
30 Minutes
8 Hours

Minor
30 Minutes
24 Hours

Incident Management
Business Process

Version
1.1

Date
23/04/14

Transport Network

Page
16/21

Appendix 1- Glossary of Terms

Term
Agreement

Term Definition
In ITSM (IT Service Management) terms, the use of the word 'agreement' rather
than contract signifies less the legal differences between the two and more a
difference in approach and style.
'Agreement' is used exclusively for an understanding, normally written, between
internal parties (though it may be
appended to and therefore form part of an external contract). An agreement is
likely to register an aspiration for a particular service level whereas a contract will
usually record the minimum service level permissible. The wording in a contract
must represent its legally binding nature but the wording of an ITSM agreement
reflects much more the nature of the (aimed for) relationship between the parties
involved.

Closure

When a Customer or User is satisfied that an Incident or Problem has been

resolved.

Customer
Diagnose

The people who use the service on a day-to-day basis

The third stage, after Detection & Investigation, in an Incident life-cycle during which
the service provider seeks to understand the root cause of the failure
Passing information and/or requesting action on an Incident, Problem or Change
to more senior staff (hierarchical escalation) or other specialists (functional
escalation). The circumstances in which either vertical escalation for
information/authority to apply further resources or horizontal escalation for greater
functional involvement need to be precisely described, so that the purpose of the
escalation and the nature of the required response is absolutely clear to all parties
as the escalation occurs. Escalation rules will be geared to priority targets.
Functional Escalation is sometimes called Referral.
a change of state that has significance for the management of a Network Service or
Configuration Item . NE will send a notification when there was a Event. Notification
is often known as Alarm

Escalation

Event

Function Unit

The actions or intended purpose of a person, team or thing in a specific role.

Service Management functions may be considered as high-level business
activities, often with a broad scope and associated with a particular job, consisting
of a collection of lower level activities. The characteristics of a function are that it
is continuous and represents a defining aspect of the business enterprise. It is
usually associated with more than one process and contributes to the execution of
those processes. Rarely do (or should) functions mirror the organizational
structure.

Help Center

An interface often referred to as a 'SPOC' (Single Point of Contact), between IT

and its Users. Its core processes are Incident Management and the management
of User requests, ensuring that no call or Incident is lost, forgotten or ignored and
that service is returned as quickly as possible.

Impact

A measure of the effect that an Incident, Problem or Change is having or might

have on the business being provided with IT services. Often equal to the extent to
which agreed or expected levels of service may be distorted. Together with
urgency, and perhaps technical security, it is the major means of assigning priority
for dealing with Incidents, Problems or Changes.

Impact Analysis

The identification of critical business processes and the potential damage or loss

Incident Management
Business Process

Version
1.1

Date
23/04/14

Transport Network

Page
17/21

that may be caused to the organization resulting from a disruption to those

processes, or perhaps from a proposed change. Business impact analysis
identifies the form the loss or damage will take; how that degree of damage or
loss is likely to escalate with time following an Incident; the minimum staffing,
facilities and services needed to enable business processes to continue to
operate at a minimum acceptable level; and the time within which they should be
recovered. The time within which full recovery of the business processes is to be
achieved is also identified.
Incident

An event which is not part of the standard operation of a service and which
causes or may cause disruption to, or a reduction in, the quality of services and
Customer productivity. An Incident might give rise to the identification and
investigation of a Problem. In the Remedy Help Center application a incident can
be promoted to a problem and have additional cases tied to it. Problem
Management might, however, manage the resolution of the Incident and Problem
in tandem, for instance if the Incident can only be closed by resolution of the
Problem.

Job Description

Agreed written statement of tasks to be undertaken for a given post, often

including responsibilities, knowledge/skill requirements and measures of success
A measure (quantitative or qualitative) that enables the overall delivery of a
service to be assessed by both business and IT representatives. KPIs should be
few in number and focus on the service's potential contribution to business
success. To be effective in improving business performance, they must be linked
to a strategic plan which details how the business intends to accomplish its vision
and mission. The metrics selected must address all aspects of performance
results, describe the targeted performance in measurable terms and be deployed
to the organizational level that has the authority, resources and knowledge to take
the necessary action.

Key Performance
Indicator (KPI)

Knowledge

Knowledge is part of the hierarchy made up of data, information and knowledge.

Data are raw facts. Information is data with context and perspective. Knowledge
is information with guidance for action based upon insight and experience.

Knowledge
Base

Data repository holding information on Incidents, Problems and Known Errors,

enabling an organization to match new Incidents against previous ones and thus
to reuse established solutions and approaches.

Objective

A future measurable achievement; usually in support of a more general aim or

goal.

Occurrence

The first stage in an Incident life-cycle when the loss of service quality occurs.
Occurrence precedes Detection
(OLA) An internal document, owned by both parties, that defines the working
relationship between different functional areas within IS&T. The OLA sets out the
responsibilities for the support and delivery of IT services to Customers. Between
the Help Center and other support/software maintenance/network management it
may be mainly concerned with the activities that must take place should a service
fail. In other circumstances, for example in support of Change Management, it is
likely to describe various executive responsibilities and activities of the parties
involved. The terms of any OLA must support the qualitative and quantitative
statements contained in the SLAs. There is a strong relationship between OLAs
and procedures.
All of the individuals employed by the organization including full time, part time,
temporary and contract employees. The term may also include Customers, Users

Operating Level
Agreement

People

Incident Management
Business Process

Version
1.1

Date
23/04/14

Transport Network

Page
18/21

and contractors.
Problem

The root cause of one or more existing or potential Incidents. Problems may
sometimes be identified because of multiple incidents that exhibit common
symptoms. Problems can also be identified from a single significant Incident,
indicative of a single error, for which the cause is unknown and all standard
troubleshooting and diagnostics have failed to produce a verifiable solution or the
case is unable to define a bounded time for a solution. A problem may also have a
known solution, but implementing the solution is not possible due to resource
limitations or application version. Occasionally Problems will be identified well
before any related Incidents occur.

Priority

The value given to an Incident, Problem or Change to indicate its relative

importance in order to ensure the appropriate allocation of resources and to
determine the timeframe within which the action is required. Priority is based
upon a coherent and up-to-date understanding of business impact and urgency
and, sometimes, technical severity. It is set by Level 1 support and can be
updated by technicians working on the case.

Procedure

A set of specific steps that describe how an activity should be carried out, and by
whom. For example, the procedure dealing with carrying out a postimplementation
review of a Change would be likely to describe the scope of the
procedure (to what Changes does this procedure apply), its purpose and how the
success of the Change will be measured, the individual procedural steps and the
responsibilities for carrying out or being involved in each of those steps.
Procedures may be supported by more detailed Work Instructions.

Process Owner

A Process Owner is a senior manager with overall responsibility for ensuring the
sustainability of a process. The Process Owner's responsibilities include those of
sponsorship, design (including relevant metrics for process) and operation, mainly
quality assurance of continuing process suitability
A party who provides a service. May be an internal service department (e.g.
engineering, computer department, building services), or an external outsourcing
company or third party supplier
The totality of features and characteristics of a product or service which bear on
its ability to satisfy stated and implied needs
A request for a change, usually both common and straightforward, to be made to
a service. A Service Request is characterized by the fact that the Change can be
made under strict, well-defined procedural control and is therefore (virtually) risk
free. Providing access to services for a new member of staff and relocating PCs
are two typical examples.
Finding the real cause of the problem and dealing with it rather than simply
continuing to deal with the symptoms.

Provider

Quality
Request

Root Cause
Analysis
Service

Service Hours
Severity Code

Single Point of
Contact

An integrated composite that consists of a number of components, such as

management process, hardware, software, facilities and people, that provides a
capability to satisfy a stated management need or objective
The agreed hours when the service is to be available
A simple code assigned to Problems and Known Errors, indicating the
seriousness of their effect on the quality of IT service. It is a common name given
to the means of recording priority for resolution.
Where all day-to-day communications are channeled through one place. Typically
for IT Services this will be the Service Desk. This ensures that Users are able to
contact trained staff, all contacts can be recorded consistently, specialist staffs are

Incident Management
Business Process

Version
1.1

Date
23/04/14

Transport Network

Page
19/21

able to concentrate on their work without interruption and work can be coordinated
and matters dealt with once.
Service Level
Agreement (SLA)

A formal negotiated document that defines (or attempts to define) in

quantitative (and perhaps qualitative) terms the service being offered to a
Customer. Confusion must be avoided over whether the quantitative definitions
constitute thresholds for an acceptable service, targets to which the supplier
should aspire or expectations that the supplier would strive to exceed. Any
metrics included in a SLA should be capable of being measured on a regular
basis and the SLA should record by whom. Typically it will cover: service hours,
service availability, Customer support levels, throughputs and responsiveness,
restrictions, functionality and the service levels to be provided in a contingency. It
may also include information on security, charges and terminology.
Apart from regular periodic reviews, SLAs should be renegotiated whenever a
business service is subject to a change of requirement, or there is an inability to
deliver to requirement.

System

An integrated composite that consists of one or more of the processes, hardware,

software, facilities and people, that provides a capability to satisfy a stated need
or objective.

Trouble Ticket

A term used in a number of Service Support tools, analogous but not normally
directly equivalent to the more precise ITIL terms Incident and Problem
A measure of business criticality of an Incident, Problem or Change where there is
an effect upon business deadlines. The urgency reflects the time available for
repair or avoidance before the impact is felt by the business. Together with
impact, and perhaps technical severity, it is the major means of assigning priority
for dealing with Incidents, Problems or Changes. It is set by the customer based
on the assessment of the business impact.

Urgency

Work in
Progress

Tasks formally identified but not yet completed. WIP reports will normally
comment on the extent to which the WIP is complete and on any aspect of the
WIP that changes previous assumptions about time, cost or quality.

Version
1.1

Incident Management
Business Process

Date
23/04/14
Page
20/21

Transport Network

Appendix 2 Service Level Management

Operational Level Agreement
Severity

Core NE Domain

CRITICAL Transport -Transmission Non Leased Line

(SDH DWDMFO, Microwave)
Data Communication (IPBB Router,CS Router,
PS Router, OCS Router,IN Router,VAS Router,
CLNS Router (OAM BSC), MSC Router(OAM
MSC), XOT
Router(OAM BSC X25), CE
Router(consentrator BSC router), BSC
Router(OAM BSC IP),Hi-Cap Router)
MAJOR Transport -Transmission Non Leased Line
(SDH DWDM FO, Microwave)
Data Communication (IPBB Router,CS Router,
PS Router, OCS Router,IN Router,VAS Router,
CLNS Router (OAM BSC), MSC Router(OAM
MSC), XOT
Router(OAM BSC X25), CE
Router(consentrator BSC router), BSC
Router(OAM BSC IP),Hi-Cap Router)
MINOR

Transport -Transmission Non Leased Line

(SDH DWDM FO, Microwave)
Data Communication (IPBB Router,CS Router,
PS Router, OCS Router,IN Router,VAS Router,
CLNS Router (OAM BSC), MSC Router(OAM
MSC), XOT
Router(OAM BSC X25), CE
Router(consentrator BSC router), BSC
Router(OAM BSC IP),Hi-Cap Router)

OLA SAM Incident

Mgt -Incident
Assigment
(Minutes)

OLA NSA
(Hours)

OLA
RPA/NRA
(Hours)

10 Minutes

10 Minutes

OLA NIM
TOTAL
(Hours) RESOLUTION TIME
(Hours)

30 Minutes

30 Minutes

30 Minutes

12

12

24

30 Minutes

12

12

24

Incident Management
Business Process
Transport Network

Appendix 3 Emergency Escalation Process

Version
1.1

Date
23/04/14
Page
21/21