Sms doc 081 2 incident management process

Incident Management Process

ISO/IEC 20000 Toolkit Version 7 ŠCertiKit

Incident Management Process

Implementation Guidance (The header page and this section must be removed from final version of the document)

Purpose of this document This document describes how the service provider will manage incidents related to the services.

Areas of the standard addressed The following areas of the ISO/IEC 20000:2011 standard are addressed by this document: 8. Resolution processes 8.1 Incident and service request management

General Guidance The standard is fairly specific about what should be covered in this procedure and so we would recommend that the headings at least be maintained in this document.

It is also a requirement to consider the impact and urgency of incidents when prioritising them.

Many organisations produce lower level procedures or work instructions that set out how to log and manage incidents in the specific service desk system in use.

Review Frequency We would recommend that this document is reviewed annually.

Toolkit Version Number ISO/IEC 20000 Toolkit Version 7 ©CertiKit.

Document Fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File

Version 1

Page 1 of 24

[Insert date]

Incident Management Process

> Info > Properties > Advanced Properties > Custom > Organization Name 2. Press Ctrl a on the keyboard to select all text in the document (or use Select, Select All on the ribbon) 3. Press F9 on the keyboard to update all fields 4. When prompted, choose the option to just update TOC page numbers If you wish to permanently convert the fields in this document to text i.e. so that they are no longer updateable, then you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible then go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check that you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions within the Project Resources folder.

Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is © copyright CertiKit except as stated below.

CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN. Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third party copyright included in this document.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use. Therefore please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional

Version 1

Page 2 of 24

[Insert date]

Incident Management Process

advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness, or adequacy of our document templates, assumes no duty of care to any person with respect its document templates or their contents, and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 3 of 24

[Insert date]

Incident Management Process

[Replace with your logo]

Incident Management Process

Document Ref. Version: Dated: Document Author: Document Owner:

Version 1

Page 4 of 24

SMS-DOC-081-1 1 [Insert date]

[Insert date]

Incident Management Process

Revision History Version Date

Revision Author

Summary of Changes

Distribution Name

Title

Approval Name

Version 1

Position

Signature

Page 5 of 24

Date

[Insert date]

Incident Management Process

Contents 1

INTRODUCTION ....................................................................................................................................... 7 1.1 1.2 1.3

2

PURPOSE ................................................................................................................................................... 7 OBJECTIVES .............................................................................................................................................. 7 SCOPE ....................................................................................................................................................... 7

INCIDENT MANAGEMENT PROCESS ................................................................................................ 9 2.1 PROCESS DIAGRAM ................................................................................................................................... 9 2.2 PROCESS TRIGGERS ................................................................................................................................. 10 2.3 PROCESS INPUTS ..................................................................................................................................... 10 2.4 PROCESS NARRATIVE .............................................................................................................................. 10 2.4.1 Log and Categorise Incident......................................................................................................... 10 2.4.2 Prioritise Incident ......................................................................................................................... 11 2.4.3 Incident Diagnosis ........................................................................................................................ 12 2.4.4 Incident Escalation ....................................................................................................................... 13 2.4.5 Resolve and Close the Incident ..................................................................................................... 13 2.5 STOPPING THE CLOCK ............................................................................................................................. 13 2.6 GOLDEN RULES ....................................................................................................................................... 14 2.7 PROCESS OUTPUTS .................................................................................................................................. 14 2.8 PROCESS ROLES AND RESPONSIBILITIES ................................................................................................. 15 2.9 RACI MATRIX ........................................................................................................................................ 15

3

INCIDENT MANAGEMENT TOOLS ................................................................................................... 16 3.1 3.2 3.3 3.4 3.5 3.6

4

SERVICE DESK SYSTEM............................................................................................................................ 16 TELEPHONY ............................................................................................................................................ 16 REMOTE CONTROL .................................................................................................................................. 17 EMAIL ..................................................................................................................................................... 17 INTRANET................................................................................................................................................ 17 CONFIGURATION MANAGEMENT SYSTEM ............................................................................................... 17

COMMUNICATION AND TRAINING ................................................................................................. 18 4.1 4.2 4.3 4.4 4.5 4.6

COMMUNICATION WITH USERS ............................................................................................................... 18 COMMUNICATION BETWEEN SHIFTS ........................................................................................................ 18 PROCESS PERFORMANCE ......................................................................................................................... 18 COMMUNICATION RELATED TO CHANGES .............................................................................................. 19 MAJOR INCIDENT COMMUNICATION ....................................................................................................... 19 TRAINING FOR INCIDENT MANAGEMENT ................................................................................................ 19

5

INTERFACES AND DEPENDENCIES ................................................................................................. 21

6

REPORTING ............................................................................................................................................ 23

7

CONCLUSION.......................................................................................................................................... 24

List of Figures FIGURE 1 - INCIDENT MANAGEMENT PROCESS ........................................................................................................... 9

List of Tables TABLE 1 - PRIORITY ASSESSMENT TABLE................................................................................................................... 11 TABLE 2 - PRIORITY DEFINITIONS ............................................................................................................................ 12 TABLE 3 - RACI MATRIX.......................................................................................................................................... 15 TABLE 4 - PROCESS INTERFACES AND DEPENDENCIES .............................................................................................. 22 TABLE 5 - PROCESS KPIS ........................................................................................................................................ 23

Version 1

Page 6 of 24

[Insert date]

Incident Management Process

1 Introduction 1.1

Purpose

The effective management of incidents affecting IT services is absolutely critical to the provision of adequate service availability. Incident management is very much a “front-line” activity and is often the only view a user will have of [Service Provider]. It is important therefore that it is carried out according to a clear, well designed process.

This document defines how the process of Incident Management is implemented within [Organization Name]. It should be read in conjunction with the following related documents: • • •

Problem Management Process Major Incident Management Process Change Management Process

The ITIL definition of an Incident is: “an unplanned interruption to an IT service or reduction in the quality of an IT service” Incident management is obviously one of the most visible processes to the user and as such represents an excellent opportunity to promote a positive view of the [Service Provider] amongst the user population.

The process of incident management is delivered via the Service Desk function.

1.2

Objectives

The objectives of the incident management process are to: • • • •

1.3

Define the way in which incidents will be managed and reported on so that consistency is achieved within the IT organization Ensure that the management of incidents takes due account of business priorities and helps to maximise business productivity Foster an effective and efficient approach to the handling of incidents that presents a positive image to the business and maintains user satisfaction Ensure that information about incidents and their impact is communicated to the relevant parties in a timely and accurate manner at all times Scope

The scope of this process is defined according to the following parameters:

Version 1

Page 7 of 24

[Insert date]

Incident Management Process

• • • •

Organizational o [List organizations and parts of those organizations covered] Geographical o [List locations from which incidents will be reported and managed] Services o [Define the services covered by the process] Technical o [If necessary, cover the technology that may give rise to incidents managed via this process]

This process covers all incidents recorded by [Service Provider] in support of the customers and users of services defined in the service catalogue.

The following areas are specifically excluded from this process: [Describe any areas that need to be clearly stated as outside the scope]

Version 1

Page 8 of 24

[Insert date]

Incident Management Process

2 Incident Management Process 2.1

Process Diagram

The process of incident management within [Service Provider] is shown below.

Event Management

Telephone

Self-Service

Email

Other

Log and categorise incident

Prioritise incident

Major incident process

Major incident?

Diagnosis

Resolved?

Yes

Set incident status to Resolved

Closed after threshold number of days

No

Assign to resolver group

Escalate

Incident diagnosis Yes

No

Resolved?

Figure 1 - Incident management process

Version 1

Page 9 of 24

[Insert date]

Incident Management Process

2.2

Process Triggers

The incident management process is initiated as a result of one or more of the following triggers: • •

•

2.3

An event occurs which is recognised by the event management process as an incident requiring investigation An interaction from a user of a service within scope via one of the following methods: o Telephone o Email o Web portal o In person visit o Note: additional methods may be introduced as technology evolves Notification from another part of the support organization including secondand third-line and suppliers Process Inputs

The process of incident management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be: • • • • • • • • • •

2.4

Information about planned service outages Details of the scope and timing of changes being implemented under change management (including those for which an outage is not expected) Access to the problem management and known error databases, including workarounds Access to the Configuration Management System (CMS) Key business operation cycles e.g. peak times at which incidents may become more urgent Organizational and contact information Availability of key support resources Service Level and Operational Level Agreements Filtered event information from monitored Configuration Items (CIs) User and customer communication about incident symptoms, priority and satisfaction levels Process Narrative

2.4.1

Log and Categorise Incident

An Incident will be recorded against the user that raises it. Three levels of classification will be used for most incidents. Where possible standard incident descriptions are defined which pre-set the description, priority and classification of the incident. This will reduce variation in the logging of incidents and ensure more accurate reporting.

Version 1

Page 10 of 24

[Insert date]

Incident Management Process

For incidents reported over the telephone there is an opportunity for First-Line to ensure that sufficient detail is obtained so that a good explanation of the incident can be recorded within the Service Desk system. If the incident is reported via selfservice however all the required detail may not be provided by the user. First-Line will then need to contact the user and request the additional information.

Whichever method is used to report the incident, First-Line will have available a set of scripts which set out the information required according to the subject of the incident. For example for a situation where the user can’t print the name of the printer will be required.

2.4.2

Prioritise Incident

The priority of an incident will determine the order in which it is addressed by the service desk and subsequent teams involved in its resolution. This will be based on a combination of two factors: Impact -

A measure of the effect of an incident on business processes

Urgency -

A measure of how long it will be until an incident has a significant impact on the business

Both impact and urgency will be assessed on a scale of high, medium and low. The priority of an incident will then be calculated based on the rating of its urgency and impact as follows: Impact/Urgency

High

Medium

Low

High

1

2

3

Medium

2

3

4

Low

3

4

5

Table 1 - Priority assessment table

The Analyst must initially assess the impact and urgency (and therefore resulting priority) of the call to determine whether it represents a major incident. If it does, the Major Incident Management process is invoked (see document ITSM081002).

The definitions of each priority level are as follows: Priority Title 1 Major incident

Version 1

Description Significant disruption to the business Examples: All communications links to Site A are down Transaction-processing application is unavailable to all users

Page 11 of 24

[Insert date]

Incident Management Process

Priority Title 2

High

3

Medium

4

Low

5

Planning

Description E-Commerce website is unavailable to customers Significant disruption to parts of the business Examples: Warehouse running at reduced capacity One floor of office building without IT access Non real-time system unavailable Localised disruption affecting one or more users Examples: Single user unable to work System running slowly for a few users Intermittent network problems Localised inconvenience affecting single user Examples: User unable to print to specific printer Power supply failed on PC Desktop software corruption issue Very minor inconvenience or non-urgent query Examples: Bug in infrequently-used software PC runs slowly on occasion Personal printer has intermittent fault

Table 2 - Priority definitions

The examples given in the table above are for guidance only; there may be circumstances where an incident affecting a single user has a significant business impact. The priority should therefore be set in consultation with the user.

Incidents logged with one of the above priorities will be addressed within the timescale targets for response and resolution set out in the relevant SLA. Success against these targets will be monitored as part of regular service reports.

2.4.3

Incident Diagnosis

If it is established that the call is a new incident that is not major, then the Service Desk Analyst will attempt to resolve the user’s issue immediately, often using remote control tools.

The Knowledgebase may be referenced for articles that detail resolutions for incidents with similar symptoms. Known Errors and Workarounds that relate to problems that have been diagnosed but not yet fixed may also be found in the Knowledgebase.

Once an Incident has been logged, all activities performed with respect to that incident should be recorded as Actions e.g. adding notes, referring to supplier.

Where appropriate, the option to send an email to the user should be selected in order to keep the user informed of progress at all times.

Version 1

Page 12 of 24

[Insert date]

Incident Management Process

2.4.4

Incident Escalation

Where the incident cannot be resolved at first line, it is assigned to an appropriate second line resolver group. This may be internal or external to [Organization Name].

The incident database should be searched to see if any similar incidents have been successfully resolved previously.

When working on an incident, technicians should temporarily assign it to themselves so that other technicians are aware that they are working on it.

If the current resolver group cannot resolve the incident the technician may opt to escalate it further e.g. to an external supplier. In this case the incident remains with the internal resolver group and it is the technician’s responsibility to ensure that the incident is updated on a regular basis based on feedback from the external supplier.

2.4.5

Resolve and Close the Incident

Upon resolving an incident clear details of the resolution must be entered and the category under which it was logged checked to ensure it is still correct.

The user will be automatically emailed to inform them of resolution and a link to a satisfaction survey will be included in x% of cases.

The user should be contacted before setting the incident to the resolved status to confirm that this is their understanding also. If the user cannot be contacted after reasonable efforts (which should be recorded on the incident record), the incident should be set to resolved.

[OR] There is no explicit requirement to contact the user before resolving the incident. It is expected that the user will contact the Service Desk if the incident has not been resolved to their satisfaction. Resolved incidents will be automatically closed after 5 days.

2.5

Stopping the Clock

The length of time it takes to resolve an incident is of course a key metric when determining the level of service being delivered. There are times however when the duration of the incident is affected by circumstances outside the control of [Service Provider] and therefore the elapsed time does not represent a true picture of service provided. In this situation it is acceptable to stop the clock and restart it again when control is once again within [Service Provider].

These circumstances are:

Version 1

Page 13 of 24

[Insert date]

Incident Management Process

• •

Waiting for further information from the user without which diagnosis and resolution of the incident cannot progress e.g. which printer is not working, what do they mean by “broken” Waiting for the user to test whether the incident is resolved

Where the incident is waiting for information or assistance from a third party supplier this will not stop the clock as it is a part of the service provided by [Service Provider].

Contracts with suppliers should be aligned with the SLA so that they provide support within the SLA timeframe agreed with the users.

2.6

Golden Rules

During the diagnosis and resolution of an incident there are a number of actions that should always be carried out as a matter of course by each member of [Service Provider]. These are: • • • •

Always update the incident record with actions carried out, even if it is only the fact that the user was telephoned without success. This shows activity on the incident which is useful to First Line if the user calls for an update Always set the incident to the Resolved status as soon as this is thought to be the case so that a fair picture is obtained from later service level reporting Be descriptive when entering the resolution text so that the incident record may be useful in future as part of the knowledge base. “Fixed” or “Resolved” is not acceptable Make sure the incident is set to the correct status at all times, including when waiting for feedback from the user as the clock will be stopped at this point

Following these rules will mean that a clear, concise picture of the status of every incident is available at all times.

2.7

Process Outputs

The outputs of the incident management process will be the following: • • • • • •

Resolved incidents Complete and accurate incident records Feedback from customers and users regarding levels of satisfaction Communication and feedback to other service management processes such as business relationship management, service level management and problem management Reports to management regarding incident volumes and process effectiveness Problem records for incidents where no root cause was identified

Version 1

Page 14 of 24

[Insert date]

Incident Management Process

2.8

Process Roles and Responsibilities •

Service Analyst o o o o

•

Receives communications from users regarding incidents Logs incidents in the incident management system Attempts to resolve the incident Escalates incident where necessary

User o Provides information regarding the incident o Keeps the IT Service Desk informed of any changes with regard to the incident (e.g. it starts working) o Carries out any re-testing requested by the IT Service Desk

•

Service Desk Manager o Controls allocation of resources within the Service Desk o Acts as management escalation point for Service Analysts and users when required

•

Resolver group o Diagnoses and resolves escalated incidents o Liaises with third parties where required

2.9

RACI Matrix

The table below clarifies the responsibilities at each step using the RACI system, i.e.: R= Responsible

Step

A= Accountable

C= Consulted

Role: Service Analyst

Log and categorise incident Prioritise incident Incident diagnosis Incident escalation Resolve and close incident Reporting

User

R R R R R C

C C C I I I

I= Informed Service Desk Manager A A A I A A/R

Resolver Group

C R I

Table 3 - RACI matrix

Version 1

Page 15 of 24

[Insert date]

Incident Management Process

3 Incident Management Tools There are a number of key software tools that underpin an effective incident management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However the main types of tools that play a significant part in the process within [Organization Name] are as follows.

3.1

Service desk system

The service desk system provides the workflow engine and database to implement the core activities within incident management. These include: • • • • • • • • • • • • • • •

Incident logging Routing and assignment of incidents to teams and individuals Recording of actions against incidents Updating of incident status from open through to closed Definition and selection of incident models Assessment of impact and urgency and auto-calculation of priority Email communication with users from within incident records Incident categorisation to multiple levels Reporting Definition of SLA targets for incidents Automated incident escalation according to SLA Provision of self-service interface for users to log incidents and view status of open incidents Search capabilities for previously encountered incidents Known Error Database (KEDB) accessible from within an incident Facility to create incident records from an email mailbox

The service desk system is integrated with the systems that support various other processes, including problem, change and configuration management.

3.2

Telephony

As well as providing the basic functionality to make and receive telephone calls, the telephony system allows for the following additional features: • • • • • • •

Recording of front-end messages for users Call queuing Allocation of calls to service desk analysts according to predetermined rules Ability to log in and out of the system to signify availability Allowance for call wrap-up time Real-time monitoring of call volumes and waiting times Reporting on call volumes, length, sources and other parameters

Version 1

Page 16 of 24

[Insert date]

Incident Management Process

The telephony system is also integrated with the service desk system to provide automation capabilities based on the calling number (CTI).

3.3

Remote control

The remote control tool provides a method for the service desk analyst to take control of the keyboard and mouse of the user’s computer and see what the user sees. This is extremely useful in shortening the time taken to resolve incidents as it removes the need for the user to describe what she is seeing and gives the service desk analyst more certainty about what actions have been taken to resolve the incident.

3.4

Email

The email system is key to communication between the user and the service desk. In addition to allowing users to email in their incidents, it also provides an easilyautomated method of keeping users informed of the progress on the incidents they have logged.

3.5

Intranet

The intranet provides a window for the user into the IT organization in general and the service desk in particular. The self-service portal is accessible from the intranet and can be supported by helpful articles on how to resolve common incidents without contacting the service desk at all, thus speeding up resolution time for the user.

Reports on incident management performance against the SLA can also be made available via the intranet.

3.6

Configuration Management System

The CMS provides real-time information about the hardware and software within the IT environment and allows the service desk and other teams to view any changes that have been implemented on key components that are under consideration with regard to an incident. It allows the installed software and its versions to be viewed without the need to access the user’s computer remotely as well as helping the service desk analyst understand the relationships between service components.

Version 1

Page 17 of 24

[Insert date]

Incident Management Process

4 Communication and Training The incident management process is all about communication and there are various forms of this that must take place for the process to be effective.

These are described below.

4.1

Communication with Users

In addition to the initial communication that will take place when an incident is reported by a user, it is vital that a two-way dialogue with the user is maintained regarding the progress of an incident, in particular: • • • •

Whether the user needs to do anything to assist e.g. test a resolution or provide further information Whether the target timescale for the resolution of the incident is likely to be met – if not, the user may need to make alternative arrangements and as much notice of this as possible is likely to be appreciated If the user finds that the incident has resolved itself and no longer needs to be investigated (although a problem record may need to be raised) If the user will be unavailable for a significant period of time perhaps due to holiday or assignment

Emails that are exchanged with the user should be incorporated into the incident record so that a full audit trail of all communication is kept and is available to whoever is working on the incident.

4.2

Communication between Shifts

Although accurate and complete status information should be available as part of each incident record, it is also important that any key items of information should be passed on when service desk (and other support team) shifts change. This should include notification of ongoing major incidents, their status and next actions and a general summary of the position of incident management at the end of the shift e.g. unusual call volumes, specific types of incident being logged more frequently than usual, or priority activities that were not able to be completed by the previous shift.

4.3

Process Performance

It is important that the performance of the incident management process is monitored and reported upon on a regular basis in order to assess whether SLAs are being met and whether the process is operating as expected. The content of performance reports is set out in section 6 of this document but it is vital that the reports are not only produced but are also communicated to the appropriate audience.

Version 1

Page 18 of 24

[Insert date]

Incident Management Process

This will include the customers of the IT service with regard to SLAs and the management of IT concerning resource utilisation and allocation. Depending on the health of the process it may be appropriate to hold regular meetings with customers and IT management to discuss the performance and agree any actions to improve it.

4.4

Communication Related to Changes

Changes to the IT environment can have a significant impact on the delivery of an effective IT service and the service desk must be aware of any changes that are due to take place prior to them happening. This will allow the incident management process to diagnose related incidents more quickly and so potentially minimise disruption to users.

The incident management process manager must have visibility of the change management schedule as a minimum and ideally will be briefed on any changes with the potential to give rise to incidents. This may be a regular meeting or carried out on an ad-hoc basis according to the frequency of occurrence of such changes.

4.5

Major Incident Communication

The incident management process includes the opportunity to recognise that a major incident has occurred or is likely to occur and will communicate with the designated major incident manager from the initiation of the major incident management procedure through to its conclusion and beyond.

This communication will largely be under the control of the major incident manager but updates should be given by the service desk to the individual in that role if things change e.g. if similar incidents begin to be reported from new areas of the business.

4.6

Training for Incident Management

In addition to a well-defined process and appropriate software tools it is essential that the people aspects of incident management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible.

The main areas in which training will be required for service desk and other IT support staff are as follows. • • •

The incident management process itself, including the activities, roles and responsibilities involved Incident management tools such as the service desk system, remote control and telephony Soft skills such as customer service, dealing with difficult conversations and avoiding technical jargon

Version 1

Page 19 of 24

[Insert date]

Incident Management Process

• •

The basics of the technology and how it is implemented within [Organization Name] The business, its structure, locations, priorities and people

In addition, training should be provided to the user population regarding how to access the IT support function, including: • • • •

The difference between an incident, a service request and a change proposal and how they are handled How to log an incident via the various means available Use of the self-service portal, including logging, updating and tracking an incident Use of the self-help service available via the intranet

This training may be provided via short workshops and supplemented by on demand resources such as videos and user guides.

Version 1

Page 20 of 24

[Insert date]

Incident Management Process

5 Interfaces and Dependencies The incident management process has a number of interfaces and dependencies with other processes within service management. These are outlined here and are described in further detail in the relevant procedural documentation.

Process Business Relationship Management

Service Level Management Information Security Management

Capacity Management Availability Management

Inputs to Incident Management from the named process Updates regarding business changes e.g. staff movers and leavers Business awareness and knowledge Feedback regarding user and customer satisfaction levels SLA targets for incident response and resolution Understanding of contents of SLAs Alerts regarding current threats e.g. phishing emails Guidance on the handling of security-related incidents, including preservation of evidence Information security policy Advance warning of possible capacity constraints affecting service Understanding of availability measures in place

Supplier Management

Information regarding changes within suppliers e.g. contact details and support structure Service Asset and Configuration Management System (CMS) Configuration Management records Change Management

Version 1

Notice of upcoming changes that may give rise to incidents

Page 21 of 24

Outputs from Incident Management to the named process Communication regarding major incidents Reports concerning incident trends by business area Potential training requirements Reports on achievement against SLA targets for incident management Notification of security-related incidents (particularly major incidents e.g. significant data loss) Reports on volume of security-related incidents e.g. account sharing violations Notice of incidents caused by capacity issues Reports on incidents affecting availability, including lengths of outages Reports on performance of suppliers in incident management (e.g. third-line) Updates to configuration items (CIs) discovered as part of incident management Incidents linked to CIs Information about incidents occurring as a result of changes Changes raised as a result of incidents

[Insert date]

Incident Management Process

Process Release and Deployment Management

Problem Management

Service Request Management

Inputs to Incident Management from the named process Consultation regarding timing of deployment of releases Deployment schedules Information regarding contents of future releases that may address common incidents Status of current problems Known Error Database (KEDB) Workarounds Updates and trends concerning service requests carried out

Outputs from Incident Management to the named process Feedback about numbers of incidents resulting from deployments Incidents that may require changes to be raised and included in future releases, including priority New problems raised Updates to existing problems based on information from new incidents Service request that were initially logged as incidents

Table 4 - Process interfaces and dependencies

Version 1

Page 22 of 24

[Insert date]

Incident Management Process

6 Reporting Reports on Incidents will be produced on a monthly basis and consolidated into the IT Service Report every quarter.

Many of the reports are produced as part of the Problem Management process to try to identify particular areas that need to be investigated further.

The following KPIs will be used on a regular basis to evidence the successful operation of the incident management process: KPI Ref. KPI1 KPI2 KPI3 KPI4 KPI5 KPI6 KPI7 KPI8 KPI9 KPI10 KPI11 KPI12 KPI13 KPI14 KPI15

Key Performance Indicator Number of incidents raised per week Number of incidents resolved per week Number of incidents still open at the end of each week Number of major incidents raised per week Percentage of incidents resolved at the service desk (first-line fix rate) Percentage of incidents resolved on first contact with the user (first-time fix rate) Percentage of incidents resolved within SLA target User satisfaction scores from user surveys Customer satisfaction scores from customer surveys Number of complaints about the incident management service Number and percentage of incidents re-opened Number and percentage of incidents incorrectly categorised Number and percentage of incidents incorrectly prioritised Staff to resolved incident ratio Average cost per incident

Table 5 - Process KPIs

Version 1

Page 23 of 24

[Insert date]

Incident Management Process

7 Conclusion The successful transition of the existing Helpdesk to a more proactive and centralised Service Desk will return major business benefits to both [Service Provider] and its customer base. By clearly understanding our customers and their business needs, we can tailor our services to meet the demand more fully. This enhanced service provision is heavily reliant upon a solid foundation, namely the Service Desk.

The acid test of this transformation must be the customer perception of the service delivered and its contribution to the overall performance of the organisation.

Version 1

Page 24 of 24

[Insert date]