Đang tải... (xem toàn văn)
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).
Incident Management Procedure PREPARED BY: APPROVED BY: IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 REVISION HISTORY Rev No Description of Change Author Date Change Ref No - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 TABLE OF CONTENTS INTRODUCTION 1.1 Purpose 1.2 Scope 1.3 Process Overview 1.4 Definition of Terms PROCESS FLOW 1.5 Process Flow PROCESS DESCRIPTION ROLES & RESPONSIBILITIES and RACI Table 1.6 Roles and Responsibilities 1.7 RACI Table METRIC AND MEASUREMENT REFERENCES 1.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 - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 INTRODUCTION 1.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 ’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: Incident classification based on Priority, Severity and Category Configuration details from the Configuration Management Database (CMDB) Any defined work-around The major activities of Incident Management are: Incident Logging and Categorization - - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 Immediate Incident Resolution by 1st Level Support Incident Resolution by 2nd Level Support Handling of Major Incidents Incident Closure and Evaluation Incident Monitoring and Escalation Pro-Active User Information Incident Management Reporting Outputs of the process are: A Request for Change (RFC) An updated Incident record (including a solution and/or any available workaround) Resolved Incident, a closed Incident record Response from Incident matching to Problems and Known Errors Management information 1.4 Definition of Terms Terms Definition PMS Problem Management System RCA Root Cause Analysis KEDB Known Error Data Base CMDB Configuration Management Data Base Work Around Method of avoiding an Incident or Problem, either from a temporary fix 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 Resolution Action that will resolve an Incident SLA Service Level Agreement SLM Service Level Management Known Error An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified - - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: SD Engineer Service Desk Engineer CTI Computer Telephony Integration PABX Private Automatic Branch Exchange CI Configuration Item Version: Page of 19 End of Section - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 PROCESS FLOW 1.5 Process Flow - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Effective Date: Version: Page of 19 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 • Incident Report ( SLA) • Updated ticket with Resolution • Possible Problem Case • Possible CMDB Control Form • Possible RFC Case Step Task Description 1.0 Log into PMS SD Engineer receives Incident from customer through call, fax and email 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 2.0 Incident Classification (Category, Severity) and Prioritization Doer SD Engineer SLA / Service Catalog are used as SD Engineer reference in determining the severity of an Incident Incidents are diagnosed and classified based on Category and Impact and Priority must be determined Template / Tool • • • • • • • • PMS CTI PABX System Lotus Notes Service Desk Procedure CMDB PMS SLM Procedure (Service Catalogue) 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 - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Step Task Effective Date: Version: Description Doer Page of 19 Template / Tool 3.0 Is incident a Sey 1? If the Incident received is a Severity SD Engineer / then go to step 11.0, else go to step Coordinator 4.0 • • • • PMS SMS Email CTI 4.0 Resolution/ 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 SD Engineer • • KEDB Problem Management Procedure 5.0 Perform Trouble shooting at 1st Level First level troubleshooting is performed in order to resolve the Incident SD Engineer • Troubleshooti ng Guideline Known Error Database 6.0 Is Incident 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 SD Engineer • PMS 7.0 Solved with 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 SD Engineer • • CTI PMS 8.0 User Received Notification User will be informed that the Incident will now be closed SD Engineer • • CTI PMS 9.0 Incident Closure SD representative will update log SD Engineer 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 10.0 Update KEDB SD representative will update KEDB for any changes / new workaround available • KEDB • SD Engineer - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Effective Date: Version: Doer Page of 19 Step Task Description Template / Tool 11.0 2nd level Support Work on the Incident Second Level Support will troubleshoot and provide Incident resolution to be updated in the PMS 2nd level support • • PMS CTI 12.0 Resolved at 2nd level? Has the Incident been solved at second level? If Yes, go to step 13.0 If No, go to step 14.0 2nd level support • • PMS Problem Management Procedure Change Management Procedure • 13.0 Update SD Engineer, PMS and KEDB Second level will update the resolution taken to SD representative, to be updated to the PMS and KEDB Second level • • PMS CTI 14.0 Change 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 2nd level support • RFC 15.0 Change Management Procedure If a change is required, the 2nd Level Support will refer to Predefined Change Management Procedure 2nd level support • Change Management Procedure 16.0 Problem Management procedure If the incident is considered as a problem, then the 2nd Level Support will refer to the Predefined Problem Management Procedure 2nd level support • Problem Management Procedure - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Effective Date: Version: Page of 19 ROLES & RESPONSIBILITIES AND RACI TABLE 1.6 Roles and Responsibilities Role Service Desk Engineer Responsibility • • • • • Incident Manager • • • Second Level Support • • • • • Receives, logs, reports, dispatch and escalates the Incident Provide Incident updates to the customer upon the customer’s request Updates Incident records per advice of Service Support Engineers Provides the necessary support skill in responding to Incidents or technical issues and problems from the time of endorsement until resolution Meet Service Level Agreement Accountable for the implementation and management of the Incident Management Process Delegate responsibility for execution of activities Ensure that Service Level is met Receives and verifies the Incident ticket Provides second level support Updates Incident Reports Meet Service Level Agreement Review / verify workaround / Permanent solution that will be updated in KEDB - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Effective Date: Version: Page of 19 A=ACCOUNTABLE C=CONSULTED I=KEEP INFORMED 1.0 Log into PMS 2.0 Incident Classification (Category, Severity) and Prioritization 3.0 Is incident a Sev 1? 4.0 Perform trouble shooting at 1st level 5.0 Resolution/Workaround match found in KEDB? 6.0 Is Incident Resolved at 1st level? 7.0 Solved with User Concurrence? 8.0 User Received Notification 9.0 Incident Closure 10.0 Update KEDB 11.0 2nd Level Support Work on the Incident 12.0 Resolved at 2nd level? 13.0 Update SD Engineer, PMS and KEDB 14.0 Change Request Required? Process Owner Customer R= RESPONSIBLE Service Desk Manager RACI Table Service Desk Engineer 1.7 Incident Management Procedure - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Effective Date: Version: Page of 19 METRIC AND MEASUREMENT Key Performance Indicator Total No of Incidents Description Number of Incidents captured per month Responsible Template/Tool Incident Manager PMS, CCC Performance Report Incident Manager PMS, SLA monthly report Incident Manager PMS, CCC Performance Report Incident Manager PMS, CCC Performance Report 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 Average Percentage of SLA Compliance Average percentage of SLA compliance for all Incidents recorded by service type Source of Data: PMS data, Service Contract Frequency: Monthly Target/Objective: 97% SLA Compliance 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 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 - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Incident Management Procedure Document No.: Key Performance Indicator Percentage of Idle Incidents Effective Date: Description Percentage of Incidents that have no update within business days (16 hours) Version: Responsible Page of 19 Template/Tool Incident Manager PMS, CCC Performance Report Incident Manager PMS, NMS, CCC Performance Report Source of Data: PMS data Frequency: Quarterly Target/Objective: 95% of updated log within business days (16 hours) Percentage of WAN Proactive Monitoring Percentage of WAN Incidents detected proactively through Network Monitoring System (NMS) Source of Data: PMS data, NMS Frequency: Quarterly Target/Objective: 60% proactive monitoring for WAN Incidents - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 REFERENCES 1.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 - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy IT Service Management Document No.: Incident Management Procedure Effective Date: Version: Page of 19 - This material is intended for use only It must not be reproduced in whole or in part, in any form, or by any means without a formal agreement or the written consent of the or Any hard copy or unprotected soft copy of this document shall be regarded as uncontrolled copy ... Change Management Procedure If a change is required, the 2nd Level Support will refer to Predefined Change Management Procedure 2nd level support • Change Management Procedure 16.0 Problem Management. .. 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 • Incident. .. Support Incident Resolution by 2nd Level Support Handling of Major Incidents Incident Closure and Evaluation Incident Monitoring and Escalation Pro-Active User Information Incident Management