The purpose of the Incident Management Procedure is to restore a Normal Service Operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. Normal Service Operation is defined here as Service Operation within Service Level Agreement (SLA).
Trang 1Incident Management
Procedure
< Enter Version No >
< Enter Effective Date >
PREPARED BY:
< Enter Name >
APPROVED BY:
< Enter Name >
< Enter Name >
Trang 2REVISION HISTORY Rev.
<MM-DD-YY>
<MM-DD-YY>
<MM-DD-YY>
<Enter Document Classification>
Trang 3-TABLE OF CONTENTS
INTRODUCTION 4
1.1 Purpose 4
1.2 Scope 4
1.3 Process Overview 4
1.4 Definition of Terms 5
PROCESS FLOW 1
1.5 Process Flow 1
PROCESS DESCRIPTION 1
ROLES & RESPONSIBILITIES and RACI Table 1
1.6 Roles and Responsibilities 1
1.7 RACI Table 2
METRIC AND MEASUREMENT 1
REFERENCES 1
1.8 Severity Levels 1
1.9 KEDB and Troubleshooting guidelines 1
1.10 Problem Management Procedure 1
1.11 Change Management Procedure 1
1.12 Request for Change Template (RFC) 1
1.13 Project Handover Document 1
<Enter Document Classification>
Trang 41.1 Purpose
The purpose of the Incident Management Procedure is to restore a Normal Service
Operation as quickly as possible and to minimize the impact on business operations,
thus ensuring that the best possible levels of service quality and availability are
maintained 'Normal Service Operation' is defined here as Service Operation within
Service Level Agreement (SLA)
1.2 Scope
The Incident Management Process covers all operations environment of the computer
systems and networking for all <company>’s Customers from Vertical & Horizontal
1.3 Process Overview
Incident management is a defined process for logging, recording and resolving
incidents
The aim of Incident Management is to restore the service to the customer as quickly
as possible, often through a workaround or temporary fixes, rather than through trying
to find a permanent solution
Inputs to the Incident Management process are:
The major activities of Incident Management are:
<Enter Document Classification>
Trang 5- Immediate Incident Resolution by 1st Level Support
Outputs of the process are:
work-around)
information
1.4 Definition of Terms
or from a technique that means the Customer is not reliant on a particular aspect of a service that is known to have a problem
a temporary Work-around or a permanent alternative has been identified
<Enter Document Classification>
Trang 6-SD Engineer Service Desk Engineer
End of Section
<Enter Document Classification>
Trang 7-PROCESS FLOW
1.5 Process Flow
<Enter Document Classification>
Trang 8-PROCESS DESCRIPTION
Entry Criteria Received any call from Customer / Internal Team / Vendor / Network
Monitoring System generated alert which identifies an Incident
Exit Criteria All Incidents are resolved with user acknowledgement
Inputs Updated Incident Ticket with Description and Contact details
Outputs • Incident Ticket Number
customer through call, fax and e-mail or detect thru NMS The Incidents can be received from Service Desk team
All Incidents received are logged into PMS And Crosscheck with CMDB for affected CI
• CTI
Procedure
• CMDB
Classification
(Category,
Severity) and
Prioritization
SLA / Service Catalog are used as reference in determining the severity
of an Incident
Incidents are diagnosed and classified based on Category and Impact and Priority must be determined
Category is based on affected services e.g WAN/LAN/DMS and will be break down by affected components e.g as router for WAN, printer for DMS For Severity, please refer to attachment
• SLM Procedure (Service Catalogue)
<Enter Document Classification>
Trang 9-Step Task Description Doer Template / Tool
Sey 1?
If the Incident received is a Severity
1 then go to step 11.0, else go to step 4.0
SD Engineer /
• SMS
• CTI
Workaround
Match Found
in KEDB?
Is there any workaround or resolution found in the KEDB?
Check for Workaround in the KEDB
If Yes, go to step 5.0
If No, go to Problem Management Procedure
Management Procedure
Trouble
Level
First level troubleshooting is performed in order to resolve the Incident
ng Guideline
Database
Resolved at
1st Level?
Has the Incident been solved at 1st Level?
If Yes, go to step 11.0
If No, go to step 7.0
User
Concurrence?
SD representative has to confirm with customer before closing the Incident whether the Incident is resolve to their satisfaction
If Yes, go to 8.0
If No, go back to step 11.0
• PMS
Received
Notification
User will be informed that the
• PMS
Closure
SD representative will update log and check the validity of the Incident Log such as verifying the Incident Description, Resolution, Incident Category, Severity, Language, and Spelling, include disclaimer and Bypass Temporary Solutions, and make necessary correction before closing the Incident Log
SD Engineer
KEDB
SD representative will update KEDB for any changes / new workaround available
<Enter Document Classification>
Trang 10-Step Task Description Doer Template / Tool
Support Work
on the
Incident
Second Level Support will troubleshoot and provide Incident resolution to be updated in the PMS
• CTI
2nd level?
Has the Incident been solved at second level?
If Yes, go to step 13.0
If No, go to step 14.0
Management Procedure
Management Procedure
Engineer,
PMS and
KEDB
Second level will update the resolution taken to SD representative, to be updated to the PMS and KEDB
• CTI
Request
Required?
Does the Incident need to raise a change in order to resolve?
If Yes, go to predefined Change Management Procedure
If No, go to Predefined Problem Management Procedure
Management
Procedure
Support will refer to Predefined Change Management Procedure
Management Procedure
Management
procedure
If the incident is considered as a
will refer to the Predefined Problem Management Procedure
Management Procedure
<Enter Document Classification>
Trang 11-ROLES & RESPONSIBILITIES AND RACI TABLE
1.6 Roles and Responsibilities
request
technical issues and problems from the time of endorsement until resolution
Management Process
updated in KEDB
<Enter Document Classification>
Trang 12-1.7 RACI Table
R= RESPONSIBLE
A=ACCOUNTABLE
C=CONSULTED
Severity) and Prioritization
KEDB?
<Enter Document Classification>
Trang 13-METRIC AND MEASUREMENT
Key Performance
month Source of Data: PMS data with all status (open, closed, cancel, duplicate, reopen)
Frequency: Quarterly Target/Objective: To monitor trend
of incoming Incidents by Incident Classification
Incident
Report
Average Percentage of
recorded by service type Source of Data: PMS data, Service Contract
Frequency: Monthly Target/Objective: 97% SLA Compliance
Incident Manager
PMS, SLA monthly report
Percentage of First
Level Incident
Resolution
Percentage of Incidents resolved by
SD Engineer without routing to second level
Source of Data: PMS data Frequency: Quarterly Target/Objective: 60% of Overall Incidents resolved at first level
Incident Manager
PMS, CCC Performance Report
Percentage of
Incidents with
Accurate
Classification
Percentage of Incidents that has accurate classification (severity and category) over total log created
Source of Data: PMS data Frequency: Quarterly Target/Objective: 97% accurate classification
Incident Manager
PMS, CCC Performance Report
<Enter Document Classification>
Trang 14-Key Performance
Percentage of Idle
hours) Source of Data: PMS data Frequency: Quarterly Target/Objective: 95% of updated log within 2 business days (16 hours)
Incident Manager
PMS, CCC Performance Report
Percentage of WAN
Network Monitoring System (NMS) Source of Data: PMS data, NMS Frequency: Quarterly
Target/Objective: 60% proactive monitoring for WAN Incidents
Incident Manager
PMS, NMS, CCC Performance Report
<Enter Document Classification>
Trang 151.8 Severity Levels
1.9 KEDB and Troubleshooting guidelines
1.10 Problem Management Procedure
1.11 Change Management Procedure
1.12 Request for Change Template (RFC)
1.13 Project Handover Document
End of Section
<Enter Document Classification>
Trang 16<Enter Document Classification>