Download Incident Management Procedure-V0.2.docx PDF

TitleIncident Management Procedure-V0.2.docx
File Size869.6 KB
Total Pages27
Table of Contents
                            1 Scope and Objective
2 References / Definitions
3 Policies
4 Process Workflow
5 Roles and Responsibilities
6 Procedure
7 RACI Matrix for the Incident Management
8 Measurements, Verifications & References
	8.1 SLA Measurements
	8.2 Verification
	8.3 Templates:
9 Interfaces/References to Other Processes
10 Guidelines
                        
Document Text Contents
Page 13

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

 Providing status as requested

3rd Party Internal to
Telia/Support

Vendors/Contrac
tor

The 3rd Party is responsible for the following:-

 External activities needed for restoration of
services and functions.

 Resolution of Incident within the SLA time
frame

 Communicate with HAR AM team for
additional information

 Providing status as requested

Proposal Title | 9

Page 14

mailto:[email protected]
mailto:[email protected]

Page 26

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) 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.

(ii) The effect of the Incident is such that it does not require an immediate response
(iii) 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) 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.

(ii) The effect of the Incident is such that it does not require immediate resolution.
(iii) The Incident is one that does not require immediate attention and no business critical

Services are degraded or failed.
(iv) 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 ManagerService 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

Similer Documents