Itilso0302 incident management process

Incident Management Process

Implementation Guidance (this section must be removed from final version of the document)

Purpose of this document This document sets out the incident management process including flowchart, activities, reporting and roles and responsibilities.

Areas of the ITIL® Framework addressed The following areas of the ITIL Framework are addressed by this document: Service Operation - Incident Management

General Guidance As with the rest of ITIL, the key with incident management is to adopt and adapt so you will need to develop the incident management process in line with your particular requirements. This may include whether you accept the ITIL recommendation that all incidents should be closed by the service desk and whether you adopt the traditional first-line, second-line, third-line method of escalating incidents.

Most organizations have a primary method of contact from users to the service desk e.g. telephone, email etc. and you may need to add further detail around the specifics of how this works for you. Procedural documentation setting out how the service desk system will be used to log and manage incidents (including screenshots) and the method of production of reports will probably be useful to ensure a greater level of consistency in how this process is applied in practice.

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

Toolkit Version Number ITIL® 2011 Service Operation Process and Policy Pack Version 1 ©CertiKit 2015.

Acknowledgements ITIL is a registered trade mark of AXELOS Limited.

Version 1

Page 1 of 43

Insert date Powered by CertiKit

Incident Management Process

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 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 2 of 43

Insert date Powered by CertiKit

Incident Management Process

Incident Management Process

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

Version 1

Page 3 of 43

ITILSO0302 1 Insert date

Insert date Powered by CertiKit

Incident Management Process

Revision History Version Date

Revision Author

Summary of Changes

Distribution Name

Title

Approval Name

Version 1

Position

Signature

Page 4 of 43

Date

Insert date Powered by CertiKit

Incident Management Process

Contents LIST OF FIGURES .............................................................................................................................................. 6 LIST OF TABLES ................................................................................................................................................ 6 1

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

2

VISION STATEMENT .................................................................................................................................. 7 PURPOSE ................................................................................................................................................... 7 OBJECTIVES .............................................................................................................................................. 8 SCOPE ....................................................................................................................................................... 8

INCIDENT MANAGEMENT PROCESS ................................................................................................ 9 2.1 OVERVIEW AND PROCESS DIAGRAM ......................................................................................................... 9 2.2 PROCESS TRIGGERS ................................................................................................................................. 11 2.3 PROCESS INPUTS ..................................................................................................................................... 11 2.4 PROCESS ACTIVITIES ............................................................................................................................... 11 2.4.1 Incident Identification ................................................................................................................... 11 2.4.2 Is This Really an Incident? ........................................................................................................... 12 2.4.3 Incident Logging ........................................................................................................................... 12 2.4.4 Incident Categorisation ................................................................................................................ 13 2.4.5 Incident Prioritisation................................................................................................................... 13 2.4.6 Major Incidents ............................................................................................................................. 15 2.4.7 Initial Diagnosis ........................................................................................................................... 15 2.4.8 Escalation ..................................................................................................................................... 15 2.4.9 Investigation and Diagnosis ......................................................................................................... 16 2.4.10 Resolution Identified? .............................................................................................................. 17 2.4.11 Resolution and Recovery .......................................................................................................... 18 2.4.12 Incident Closure ....................................................................................................................... 18 2.5 PROCESS OUTPUTS .................................................................................................................................. 18 2.6 INCIDENT MANAGEMENT TOOLS ............................................................................................................ 18 2.6.1 Service desk system ....................................................................................................................... 19 2.6.2 Telephony...................................................................................................................................... 19 2.6.3 Remote control .............................................................................................................................. 20 2.6.4 Email ............................................................................................................................................. 20 2.6.5 Intranet ......................................................................................................................................... 20 2.6.6 Configuration Management System .............................................................................................. 20 2.7 COMMUNICATION AND TRAINING ........................................................................................................... 20 2.7.1 Communication with Users ........................................................................................................... 21 2.7.2 Communication between Shifts ..................................................................................................... 21 2.7.3 Process Performance .................................................................................................................... 21 2.7.4 Communication Related to Changes ............................................................................................. 22 2.7.5 Major Incident Communication .................................................................................................... 22 2.7.6 Training for Incident Management ............................................................................................... 22

3

ROLES AND RESPONSIBILITIES ....................................................................................................... 24 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

OPERATIONAL ROLES ............................................................................................................................. 24 RACI MATRIX ........................................................................................................................................ 24 INCIDENT MANAGEMENT PROCESS OWNER ............................................................................................ 25 INCIDENT MANAGEMENT PROCESS MANAGER ....................................................................................... 25 SERVICE USER......................................................................................................................................... 26 SERVICE DESK ANALYST ........................................................................................................................ 26 SECOND-LINE ANALYST ......................................................................................................................... 27 THIRD-LINE ANALYST ............................................................................................................................ 27

4

ASSOCIATED DOCUMENTATION ..................................................................................................... 29

5

INTERFACES AND DEPENDENCIES ................................................................................................. 30 5.1 5.2

OTHER SERVICE MANAGEMENT PROCESSES ........................................................................................... 30 BUSINESS PROCESSES ............................................................................................................................. 32

Version 1

Page 5 of 43

Insert date Powered by CertiKit

Incident Management Process

6

PROCESS MEASUREMENTS AND METRICS .................................................................................. 34 6.1 6.2 6.3

7

PROCESS REPORTING ......................................................................................................................... 36 7.1 7.2 7.3

8

CRITICAL SUCCESS FACTORS .................................................................................................................. 34 KEY PERFORMANCE INDICATORS............................................................................................................ 34 PROCESS REVIEWS AND AUDITS ............................................................................................................. 35

PROCESS REPORTS .................................................................................................................................. 37 SERVICE LEVEL AND BUSINESS RELATIONSHIP REPORTS ....................................................................... 38 OPERATIONAL REPORTS .......................................................................................................................... 39

GLOSSARY, ABBREVIATIONS AND REFERENCES ...................................................................... 41 8.1 8.2 8.3

GLOSSARY .............................................................................................................................................. 41 ABBREVIATIONS...................................................................................................................................... 42 REFERENCES ........................................................................................................................................... 43

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

List of Tables TABLE 1 - DETERMINATION OF PRIORITY .............................................................................................................. 14 TABLE 2 - PRIORITY DEFINITIONS ......................................................................................................................... 14 TABLE 3 - RACI MATRIX ...................................................................................................................................... 24 TABLE 4 - ASSOCIATED DOCUMENTATION ............................................................................................................ 29 TABLE 5 - INTERFACES WITH OTHER SERVICE MANAGEMENT PROCESSES.............................................................. 32 TABLE 6 - INTERFACES WITH BUSINESS PROCESSES ............................................................................................... 33 TABLE 7 - CRITICAL SUCCESS FACTORS ................................................................................................................. 34 TABLE 8 - KEY PERFORMANCE INDICATORS .......................................................................................................... 35 TABLE 9 - PROCESS REPORTS................................................................................................................................. 38 TABLE 10 - SERVICE LEVEL AND BUSINESS RELATIONSHIP REPORTS ..................................................................... 39 TABLE 11 - OPERATIONAL REPORTS ...................................................................................................................... 40 TABLE 12 - GLOSSARY OF RELEVANT TERMS ....................................................................................................... 42

Version 1

Page 6 of 43

Insert date Powered by CertiKit

Incident Management Process

1 Introduction 1.1

Vision Statement

The vision of [Service Provider] in the area of service management is as follows: [Insert the vision statement defined as part of service strategy] This process forms a key part of the realisation of that vision.

1.2

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

The purpose of the incident management process according to ITIL®1 is:

“to restore normal service operation as quickly as possible and minimise the adverse impact on business operations, thus ensuring that agreed levels of service quality are maintained.”

(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011.

Reproduced under license from AXELOS) An incident is defined as: “an unplanned interruption to an IT service or a reduction in the quality of an IT service or failure of a CI that has not yet impacted an IT service (for example failure of one disk from a mirror set).”

(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011.

Reproduced under license from AXELOS )

1

ITIL® is a registered trade mark of AXELOS Limited.

Version 1

Page 7 of 43

Insert date Powered by CertiKit

Incident Management Process

1.3

Objectives

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

1.4

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:    

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 43

Insert date Powered by CertiKit

Incident Management Process

2 Incident Management Process 2.1

Overview and Process Diagram

The process of incident management is shown in Figure 1.

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.

Typically, incidents will be reported to the service desk by users via telephone. Once the identity of the user has been confirmed, the details of the incident will be recorded in the IT service management system by the Service Desk Analyst.

The incident will then be categorised and prioritised in conjunction with the user. An attempt will be made to resolve the incident at first point of contact, failing which it will be escalated to an appropriate support group until resolution is achieved.

The incident will be resolved by the support group that believes it has provided the fix and successful resolution will be confirmed by the service desk prior to closure.

Major incidents will be managed by a separate but related process which provides for more urgent allocation of resources and more formal communication procedures.

See the document Major Incident Management Procedure.

Version 1

Page 9 of 43

Insert date Powered by CertiKit

Incident Management Process

Event Management

Web interface

Phone call

Email

Incident identification

Is this really an incident?

N

To request fulfilment (if this is a service request) or service portfolio management (if this is a change proposal)

Y

Incident logging

Incident categorisation

Incident prioritisation

Major incident procedure

Y

Major incident?

N

Initial diagnosis

Functional escalation

Y

Functional escalation?

Escalation needed?

Y

N

Management escalation

Y

Hierarchic escalation?

N

N

Investigation and diagnosis

N

Resolution identified?

Y

Resolution and recovery

Incident closure

End

Figure 1 - Incident Management Process

(Source: “ITIL Service Operation Book 2011. Copyright Š AXELOS Limited 2011.

Reproduced under license from AXELOS )

Version 1

Page 10 of 43

Insert date Powered by CertiKit

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 Activities

The individual process activities at each step are detailed as follows.

2.4.1

Incident Identification

There are two main methods by which incidents will be detected; via event monitoring and by the user. One of the goals of effective service management is to

Version 1

Page 11 of 43

Insert date Powered by CertiKit

Incident Management Process

detect and fix incidents before they impact the user but in many cases this may not be possible.

The identification of incidents as part of event management is covered in the document Event Management Process. Not all events that are generated will result in an incident being logged and the criteria used to make this decision will be finetuned over time.

For incidents reported by users over the telephone there is an opportunity for the service desk 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 self-service or by email however all the required detail may not be provided by the user. The service desk will then need to make contact and request the additional information.

2.4.2

Is This Really an Incident?

It is important that only items that meet the definition of an incident are logged and managed via the incident management process. Other types of communication from users such as service requests and change proposals will be subject to different SLA metrics and, if processed via the incident management system, will affect the validity of the reports produced. Service requests will be routed through the request fulfilment process and change proposals through the change management process.

If a service request has already been logged in the incident management system by a user (perhaps via self-service) then the incident record will be closed and a service request logged instead. The user must be informed of this action. The closure category of such incidents will indicate that it was logged in error and these incidents will be omitted from SLA performance reports. They may however be reported on separately in order to gain a clear picture of how often this is happening and as input to service improvement activities.

In the event of a change proposal being logged in error by a user, the service desk will inform the user of this fact and request that the user log the change proposal via the correct channel. This will give the user the opportunity to provide the higher level of detail that will be required of a change proposal compared to an incident. The incorrectly-logged incident will then be closed by the service desk using an appropriate closure category that puts it outside of SLA reporting. Again, such instances should still be reported on for service improvement purposes.

2.4.3

Incident Logging

It is a fundamental principle that all incidents must be logged. This will allow accurate reporting of incident volumes and performance against the SLA and provides clearer justification of the IT resources allocated to incident management. In the event that an IT analyst attends onsite to resolve one incident and is asked whilst there to resolve others, then all of the incidents reported (whether resolved at the time or not) must be individually logged.

Version 1

Page 12 of 43

Insert date Powered by CertiKit

Incident Management Process

An Incident will be recorded against the name of the user that raises it. For telephone and face-to-face interactions the contact details held within the service desk system should be confirmed with the user in order to capture changes of location, department etc. in a proactive way.

Whichever method is used to report the incident, the service desk 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.

Incident models will be used where appropriate to automate the prompting of information required and the setting of incident category and priority. Where the user is on the telephone, these details should be checked (particularly priority) to ensure that the business need is being met.

2.4.4

Incident Categorisation

Three levels of categorisation will be used for incidents. Where an incident model is used, these will be set automatically according to the specific model selected.

Category hierarchies will be available within the service desk system and will be reviewed on a regular basis as part of process improvement activities. Changes to the categories will be managed carefully so that the implications to SLA reporting and problem management are understood and catered for accordingly.

The process manager will review on a regular basis the use of categories in logging incidents to ensure that they are used consistently by all parties, particularly by firstline but also by second- and third-line teams.

The initial incident categorisation should be maintained throughout the lifecycle of the incident; in the event that it becomes clear that the incident should have been categorised differently then this will be reflected in the closure categorisation which should be a separate field on the service desk system.

2.4.5

Incident Prioritisation

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:

Version 1

Page 13 of 43

Insert date Powered by CertiKit

Incident Management Process

Impact/Urgency

High

Medium

Low

High

1

2

3

Medium

2

3

4

Low

3

4

5

Table 1 - Determination of Priority

The priority of an incident will be calculated automatically by the service desk system based on the above rules.

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

2

High

3

Medium

4

Low

5

Planning

Description Significant disruption to the business Examples: All communications links to Site A are down Transaction-processing application is unavailable to all users 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 Table 2 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.

Version 1

Page 14 of 43

Insert date Powered by CertiKit

Incident Management Process

2.4.6

Major Incidents

In the event that an incident has sufficient impact and urgency to be classified as a priority 1, the Major Incident Management Procedure will be invoked. This procedure provides for the appointment of a major incident manager who will ensure that all necessary resources are allocated to the resolution of the incident and that appropriate communication channels are opened to keep the business and IT management informed.

In the event of doubt regarding whether an incident should be a priority 1 or whether the major incident procedure should be invoked, the Service Desk Supervisor should be consulted.

In the course of a major incident the activities set out in this incident management process will still largely be followed, including the regular updating of the incident record, but additional activities (such as the consideration of invoking the service continuity plan) will be carried out in parallel.

2.4.7

Initial Diagnosis

If, after prioritisation, it is established that the incident is not major, then the service desk analyst will attempt to resolve the user’s issue immediately, if possible using remote control tools.

The service desk 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 Known Error Database (KEDB).

Once an Incident has been logged, all activities performed with respect to that incident should be recorded as actions against the incident record e.g. adding notes, referring to supplier. Where appropriate, the option to send an update email to the user should be selected in order to keep the user informed of progress at all times.

If the incident can be resolved by the service desk analyst whilst the user is still in contact e.g. on the telephone, then successful resolution should be confirmed with the user and the incident resolved and then closed.

If the incident can’t be resolved while the user is on the phone, the service desk analyst will inform the user of the reference number of the incident and the target resolution time and end the call. It may be that First-Line is able to resolve the incident without escalation to additional support teams in which case it will be processed, resolved and closed in the normal way.

2.4.8

Escalation

For those incidents which cannot be resolved by the service desk, possibly through lack of knowledge or access, they should be escalated to the most appropriate

Version 1

Page 15 of 43

Insert date Powered by CertiKit

Incident Management Process

second-line team. This is functional escalation. The starting point for the decision regarding which team to escalate to will be the categorisation of the incident. A list of categories and the teams to escalate to will be held and maintained by the service desk with regular input and review from other teams.

Details of the methods and timescales for escalation will be documented in operational level agreements (OLAs) with each separate group. Where a second-line support group is external to the organization this information will be agreed in an under-pinning contract (UC). Copies of all relevant OLAs and UCs will be held within the service desk knowledgebase and where possible incorporated into the configuration of the service desk system.

In line with ITIL best practice, the ownership of an escalated incident will remain with the service desk as the primary interface with the user.

In addition to the hierarchic escalation involved in a major incident, there may be occasions when an incident of lower priority than 1 needs to be escalated to management. This may, for example, be when a priority 2 incident has exceeded its SLA timescale. Hierarchic escalation allows for communication to management of a potential issue and for the allocation of additional resources if they are felt to be warranted. Escalation via email will be achieved automatically via the service desk system.

2.4.9

Investigation and Diagnosis

Beyond initial diagnosis, further investigation and diagnosis may be carried out either by the service desk or by a second- or third-line team. When working on an incident, analysts will temporarily assign it to themselves so that other analysts are aware that they are working on it and there is no duplication of effort.

If the current support team cannot resolve the incident the analyst may opt to escalate it further to an external supplier. If the external supplier has no access to the service desk system and no electronic interface is in place between [Service Provider] system and that of the supplier the incident remains assigned to the internal team that escalated it. In this case it is the analyst’s responsibility to ensure that the incident is updated on a regular basis based on feedback from the external supplier.

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 the service desk 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

Version 1

Page 16 of 43

Insert date Powered by CertiKit

Incident Management Process



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.

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: 

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 will be aligned with the SLA so that they provide support within the SLA timeframe agreed with the users

2.4.10 Resolution Identified?

Based on the investigation and diagnosis carried out, a potential resolution to the incident may be identified and this may need to be tested and confirmed in the next step of the process.

However, if no potential resolution has been found a further step of functional escalation may be required. This could be to the next level in the hierarchy of technical teams or could be to another team at the same level e.g. if the server team has ruled out a server issue and passes the incident to the networking team so that possible network causes may be investigated.

In addition, hierarchical management escalation may be required if the incident is proving difficult to resolve and all existing avenues of support have been explored. It may be necessary to involve a specialist external organization which is not part of the normal escalation process.

Version 1

Page 17 of 43

Insert date Powered by CertiKit

Incident Management Process

2.4.11 Resolution and Recovery

Once a potential resolution has been identified, this must be tested and implemented. If the required resolution action comes under the scope of the change management process then a change request must be raised and assessed in the normal way before implementation. If the priority of the incident justifies it then an emergency change may be raised so that the corrective action can be applied as soon as possible.

Sufficient testing must be carried out post-resolution to confirm that the action has had the desired effect. Once satisfactorily resolved, the incident record must be updated with the details of the resolution (including the correct closure category) and passed back to the service desk for closure.

2.4.12 Incident Closure

The user should be contacted by the service desk before setting the incident to the closed status to confirm that this is the user’s understanding also. If the user cannot be contacted after reasonable efforts (which should be recorded on the incident record), the incident may be set to closed without user confirmation.

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

If the incident was resolved without the root cause having been identified (e.g. the server was rebooted and it seemed to work afterwards) then it may be appropriate for a problem record to be raised so that the underlying root cause can be investigated. In this case the new problem record should be linked to the relevant incident record(s) so that a history is available to problem management.

2.5

Process Outputs

The outputs of the incident management process will be the following:       2.6

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 Incident Management Tools

Version 1

Page 18 of 43

Insert date Powered by CertiKit

Incident Management Process

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.

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

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

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

Version 1

Page 19 of 43

Insert date Powered by CertiKit

Incident Management Process

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

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

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

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

2.7

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.

Version 1

Page 20 of 43

Insert date Powered by CertiKit

Incident Management Process

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

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

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

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.

Version 1

Page 21 of 43

Insert date Powered by CertiKit

Incident Management Process

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

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

2.7.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 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:

Version 1

Page 22 of 43

Insert date Powered by CertiKit

Incident Management Process

   

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 23 of 43

Insert date Powered by CertiKit

Incident Management Process

3 Roles and Responsibilities This section describes the main operational roles involved in the incident management process, their interaction with the process and their detailed responsibilities.

3.1

Operational Roles

The following main roles participate in the incident management process:      

Service User Service Desk Analyst Second-Line Analyst Third-Line Analyst Process Owner (Service Desk Supervisor) Process Manager (Service Desk Supervisor)

There will also be interaction with IT and business management at various points in the process, particularly in the event of escalation to a major incident.

3.2

RACI Matrix

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

A= Accountable Role:

Step Incident identification Incident logging Incident categorisation Incident prioritisation Major incident notification Incident diagnosis Functional escalation Hierarchic escalation Investigation and diagnosis Resolution and recovery Incident closure

Service User

C= Consulted

I= Informed

R C C C C

Service Desk Analyst R R R R R

SecondLine Analyst R

ThirdLine Analyst R

Service Desk Supervisor

C I I I

R R R I/C

I

I

R

R

A/I A A/R A

I

R

R

R

A

C

R

A/R A A A A

A

Table 3 - RACI Matrix

Version 1

Page 24 of 43

Insert date Powered by CertiKit

Incident Management Process

3.3

Incident Management Process Owner

The role of the Incident Management Process Owner will be carried out by the Service Desk Supervisor.

The responsibilities of the incident management process owner are:                

Sponsoring, designing and change managing the process and its metrics Defining the process strategy Assisting with process design Ensuring that appropriate process documentation is available and current Defining appropriate policies and standards to be employed throughout the process Periodically auditing the process to ensure compliance to policy and standards Periodically reviewing the process strategy to ensure that it is still appropriate and change as required Communicating process information or changes as appropriate to ensure awareness Providing process resources to support activities required throughout the service lifecycle Ensuring process technicians have the required knowledge and the required technical and business understanding to deliver the process and understand their role in the process Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process Addressing issues with the running of the process Identifying improvement opportunities for inclusion in the CSI register Making improvements to the process Designing incident models and workflows Working with other process owners to ensure there is an integrated approach to the design and implementation of incident management, problem management, event management, access management and request fulfilment

(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011.

Reproduced under license from AXELOS ) 3.4

Incident Management Process Manager

The role of the Incident Management Process Manager will be performed by the Service Desk Supervisor.

The responsibilities of the incident management process manager are:  

Working with the process owner to plan and co-ordinate all process activities Ensuring all activities are carried out as required throughout the service lifecycle

Version 1

Page 25 of 43

Insert date Powered by CertiKit

Incident Management Process

               

Appointing people to the required roles Managing resources assigned to the process Working with service owners and other process managers to ensure the smooth running of services Monitoring and reporting on process performance Identifying improvement opportunities for inclusion in the CSI register Working with the CSI manager and process owner to review and prioritise improvements in the CSI register Making improvements to the process implementation Planning and managing support for incident management tools and processes Coordinating interfaces between incident management and other service management processes Driving the efficiency and effectiveness of the incident management process Producing management information Managing the work of incident support staff (first- and second-line) Monitoring the effectiveness of incident management and making recommendations for improvement Developing and maintaining the incident management systems Managing major incidents Developing and maintaining the incident management process and procedures

(Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011.

Reproduced under license from AXELOS) 3.5

Service User

The responsibilities of the user of a service in the incident management process are to:        3.6

identify that an incident affecting them has occurred, or is likely to occur report the incident to the service desk via one of the approved communication methods provide all available information regarding the incident to assist in incident investigation and resolution ensure that the service desk has a clear understanding of the impact and urgency of the incident from a user viewpoint provide feedback to the service desk about whether resolution actions have been successful follow any directions given to implement workarounds allow remote access to the affected computer(s) when requested Service Desk Analyst

The responsibilities of the Service Desk Analyst with respect to the incident management process are to:

Version 1

Page 26 of 43

Insert date Powered by CertiKit

Incident Management Process

         

3.7

interact with users and other parties in a professional manner at all times log incidents in a timely manner according to the organization’s established procedures ensure that all appropriate questions are asked to establish the impact, urgency and circumstances of the incident collect all relevant information regarding the incident for use in diagnosis and investigation record all relevant information accurately and promptly within the incident management system follow procedures to ensure that major incidents are recognised and escalated promptly follow procedures to recognise when a problem record should be created use appropriate tools and training to resolve the incident at first point of contact where possible escalate incidents to second-line support where a first-line resolution is not possible confirm with the user that an incident has been successfully resolved prior to closure Second-Line Analyst

The responsibilities of the Second-Line Analyst with respect to the incident management process are to:      

3.8

interact with users, first-line and other parties in a professional manner at all times record all relevant information accurately and promptly within the incident management system follow procedures to ensure that major incidents are recognised and escalated promptly follow procedures to recognise when a problem record should be created use appropriate tools and training to resolve the incident as soon as possible escalate incidents to third-line support where a second-line resolution is not possible Third-Line Analyst

The responsibilities of the Third-Line Analyst with respect to the incident management process are to:    

interact with users, first-line, second-line and other parties in a professional manner at all times record all relevant information accurately and promptly within the incident management system follow procedures to ensure that major incidents are recognised and escalated promptly follow procedures to recognise when a problem record should be created

Version 1

Page 27 of 43

Insert date Powered by CertiKit

Incident Management Process

 

use appropriate tools and training to resolve the incident as soon as possible escalate incidents to external support (i.e. suppliers) where a third-line resolution is not possible

Version 1

Page 28 of 43

Insert date Powered by CertiKit

Incident Management Process

4 Associated Documentation The following documentation is relevant to the incident management process and should be read in conjunction with it: Document ITIL Service Operation Book Incident logging and management procedure Service management system user guide Service management system administration guide Major Incident Management Process Event Management Process Request Fulfilment Process

Reference ISBN number

Version 2011

9780113313075

ITILSO0302

V1.0 Final V1.0 Final V1.0 Final

Problem Management Process Change Management Process Configuration Management Process

V1.0 Final V1.0 Final V1.0 Final

Location [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location] [Network drive location]

Table 4 - Associated Documentation

In the event that any of these items is not available please contact the Service Desk Supervisor.

Version 1

Page 29 of 43

Insert date Powered by CertiKit

Incident Management Process

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

5.1

Other Service Management Processes

ITIL Lifecycle Stage Service Strategy

Process

Service Design

Service Level Management

Business Relationship Management

Information Security Management

Capacity Management Availability Management Supplier Management

Version 1

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 securityrelated incidents, including preservation of evidence Information security policy Advance warning of possible capacity constraints affecting service Understanding of availability measures in place Information regarding changes within suppliers e.g. contact details and Page 30 of 43

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) Insert date Powered by CertiKit

Incident Management Process

ITIL Lifecycle Stage Service Transition

Process

Inputs to Incident Management from the named process support structure Service Asset and Configuration Management System Configuration Management (CMS) records

Change Management

Release and Deployment Management

Transition Planning and Support Knowledge Management

Service Operation

Problem Management

Access Management

Event Management

Version 1

Outputs from Incident Management to the named process

Updates to configuration items (CIs) discovered as part of incident management Incidents linked to CIs Notice of upcoming changes that may Information about incidents occurring as give rise to incidents a result of changes Changes raised as a result of incidents Consultation regarding timing of Feedback about numbers of incidents deployment of releases resulting from deployments Deployment schedules Incidents that may require changes to Information regarding contents of be raised and included in future future releases that may address releases, including priority common incidents Advance notice of transition plans Feedback on success of transitions and timing Knowledge about existing and Information regarding knowledge planned services in the Service required and success of current Knowledge Management System provision (SKMS) Status of current problems New problems raised Known Error Database (KEDB) Updates to existing problems based on Workarounds information from new incidents Updates regarding new users Notification of incidents related to created, leavers and movers access control e.g. account sharing violations Events that meet the criteria for Feedback regarding the accuracy and incidents quality of incidents raised from events Reports on trends for event-generated incidents Page 31 of 43

Insert date Powered by CertiKit

Incident Management Process

ITIL Lifecycle Stage

Process Request Fulfilment

Continual Service Improvement

7-Step Improvement Process

Inputs to Incident Management from the named process Updates and trends concerning service requests carried out Incident management process improvements

Outputs from Incident Management to the named process Service request that were initially logged as incidents Potential service improvements identified from incidents Reports on incident trends related to service improvements

Table 5 - Interfaces with other service management processes

5.2

Business Processes

[Business processes will obviously be numerous and highly industry- and organization-specific. We therefore recommend that you only address those that are closely linked to the process in question here.]

Business Area

Business Process

Human Resources

All Recruitment

Termination Finance Sales and Marketing Production/Operations Legal and Compliance Research and Development

Version 1

All All All All All

Inputs to Incident Management from the named process IT-related incidents List of starters within the business for inclusion in the service desk system List of leavers to disable within the service desk system IT-related incidents IT-related incidents IT-related incidents IT-related incidents IT-related incidents

Page 32 of 43

Outputs from Incident Management to the named process Resolved incidents

Resolved incidents Resolved incidents Resolved incidents Resolved incidents Resolved incidents

Insert date Powered by CertiKit

Incident Management Process

Business Area

Business Process

Distribution and Logistics Customer Services Purchasing Public Relations Administration [Insert further business processes here]

All All All All All

Inputs to Incident Management from the named process IT-related incidents IT-related incidents IT-related incidents IT-related incidents IT-related incidents

Outputs from Incident Management to the named process Resolved incidents Resolved incidents Resolved incidents Resolved incidents Resolved incidents

Table 6 - Interfaces with business processes

Version 1

Page 33 of 43

Insert date Powered by CertiKit

Incident Management Process

6 Process Measurements and Metrics In order to determine whether the incident management process is working effectively and achieving what we want it to achieve, we must first define our critical success factors and identify how we will determine if they are being fulfilled.

6.1

Critical Success Factors

The following factors are defined as critical to the success of the incident management process: Ref. CSF1 CSF2 CSF3 CSF4 CSF5

Critical Success Factor Business disruption is minimised Service levels are being maintained User satisfaction and confidence in IT services is maintained The process is being followed by all staff in a consistent manner The process provides value for money

Table 7 - Critical success factors

Achievement of these critical success factors will be measured via the use of relevant Key Performance Indicators (KPIs).

6.2

Key Performance Indicators

The following KPIs will be used on a regular basis to evidence the successful operation of the incident management process: CSI Ref. CSF1

KPI Ref. KPI1.1 KPI1.2 KPI1.3 KPI1.4 KPI1.5 KPI1.6

CSF2 CSF3

CSF4

CSF5

Version 1

KPI2.1 KPI3.1 KPI3.2 KPI3.3 KPI4.1 KPI4.2 KPI4.3 KPI5.1 KPI5.2

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 Page 34 of 43

Insert date Powered by CertiKit

Incident Management Process

Table 8 - Key performance indicators

6.3

Process Reviews and Audits

Reviews will be carried out by the process owner in conjunction with the process manager on a three monthly basis to assess whether the incident management process is operating effectively and delivering the desired results. These reviews will have the following as input:        

Follow-up action list from previous reviews Relevant changes and developments within the business and IT KPI reports from the previous period Details of all complaints logged during the period Internal and external audit reports Major incident reports from the period Feedback from users and customers Identified opportunities for improvement

Each review will be documented by the process owner and actions arising agreed and published.

Audits will be carried out on an annual basis by the internal auditing department. The scope and timing of the audit will be agreed in advance. Recommendations from the audit will be published and actions discussed and agreed with the process owner.

All actions will be followed up by the internal auditor within the agreed timescales for each action.

Version 1

Page 35 of 43

Insert date Powered by CertiKit

Incident Management Process

7 Process Reporting It is important that regular reports are produced for three main reasons: 1. to help to assess whether the incident management process is meeting its critical success factors (see section 6.1 above) 2. To inform the business and IT management about whether SLA targets are being met 3. to assist operational supervisors in the day-to-day management of the incident management process and its resourcing These three purposes may require different views of the information available and will need to be produced at varying frequencies for differing audiences.

The format of the reports produced will also be subject to regular review and amendment as requirements become clearer and the available reporting technology within the business matures. What must be avoided is the continued production of reports that are not read and serve no purpose. It is up to the process owner, in consultation with the process manager, to ensure that all reporting remains focussed and relevant.

The following tables show the reports that will be produced together with their purpose, method of production, data source, audience and frequency. Some of the reports listed will be used for multiple purposes.

Version 1

Page 36 of 43

Insert date Powered by CertiKit

Incident Management Process

7.1

Process Reports

The following reports are produced by the process manager and are intended to help the process owner assess whether the CSFs for incident management are being met.

Ref. CSFR1

Report Title New incident

CSFR2 CSFR3

Resolved incident Incident backlog

CSFR4

Major incident

CSFR5

First-Line Fix

CSFR6

First-time Fix

CSFR7

Incident SLA

CSFR8

User satisfaction

CSFR9

Customer satisfaction

CSFR10 Incident complaints Version 1

Description 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

Method of Production Service desk system reporting tool Service desk system reporting tool Service desk system reporting tool

Data Source Service desk database Service desk database Service desk database

Frequency Audience Weekly Process owner Weekly Process owner Weekly Process owner

Service desk system reporting tool Service desk system reporting tool

Service desk database Service desk database

Weekly

Service desk system reporting tool

Service desk database

Monthly

Process owner

Service desk system reporting tool Survey tool report

Service desk database Survey tool database Survey tool database

Monthly

Process owner Process owner Process owner

Complaints database

Monthly

Survey tool report

Complaints system reports Page 37 of 43

Process owner Process owner

Monthly

Quarterly Sixmonthly

Process owner

Insert date Powered by CertiKit

Incident Management Process

Ref.

Report Title

Description service CSFR11 Incident re-open Number and percentage of incidents re-opened CSFR12 Incident category Number and percentage of error incidents incorrectly categorised CSFR13 Incident priority Number and percentage of error incidents incorrectly prioritised CSFR14 Resolution ratio Staff to resolved incident ratio

Method of Production

Data Source

Frequency Audience

Service desk system reporting tool Sample from service desk system

Service desk database Service desk database

Monthly

Sample from service desk system

Service desk database

Quarterly

Process owner

Spreadsheet chart

Monthly

Process owner

CSFR15 Incident cost

Spreadsheet costing model

Service desk database and staff attendance records Service desk system and costings from Finance

Quarterly

Process owner

Average cost per incident

Process owner Process owner

Quarterly

[Insert further reports] Table 9 - Process reports

7.2

Service Level and Business Relationship Reports

The following reports are intended to gauge whether SLAs are being met and provide feedback to customers.

Ref. SLAR1

Version 1

Report Title Incident SLA by customer

Description Percentage of incidents resolved within SLA target, broken down by customer,

Method of Production Service desk system reporting tool

Page 38 of 43

Data Source Service desk database

Frequency Audience Quarterly Customers Service managers

Insert date Powered by CertiKit

Incident Management Process

Ref.

Report Title

SLAR2

Incidents by customer

SLAR3

Major incidents by customer

Description rolling 12 months Number of incidents logged and resolved by customer, rolling 12 months Listing of major incidents affecting each customer with dates/times, impact, resolution times, root cause and preventative action report

Method of Production

Data Source

Frequency Audience

Service desk system reporting tool

Service desk database

Quarterly

Service desk system reporting tool Manual review of major incidents

Service desk database Major incident review records

Quarterly

Customers Service managers Customers Service managers

[Insert further reports] Table 10 - Service level and business relationship reports

7.3

Operational Reports

The following reports are to provide further ongoing operational information to the process manager. They are in addition to the relevant process and service level reports described above.

Ref. OPR1 OPR2

Report Title Analyst productivity SLA breach

OPR3

High priority

OPR4

Call waiting time

Version 1

Description Incidents opened and closed by service desk analyst Incidents that have breached SLA or are close to breaching SLA Incidents of priority 1 and 2 that are currently open Average waiting time for incidents reported by phone

Method of Production Service desk system reporting tool Service desk system filter view

Data Source Service desk database Service desk database

Frequency Audience Weekly Process manager Daily Process manager

Service desk system filter view Telephony system reporting tool

Service desk database Telephony database

Daily

Page 39 of 43

Process manager Process manager

Daily

Insert date Powered by CertiKit

Incident Management Process

Ref.

Report Title [Insert further reports]

Description

Method of Production

Data Source

Frequency Audience

Table 11 - Operational reports

Version 1

Page 40 of 43

Insert date Powered by CertiKit

Incident Management Process

8 Glossary, Abbreviations and References 8.1

Glossary

For a full list of terms used and their definitions within ITIL, please refer to the back of any of the books in the ITIL Lifecycle Suite 2011.

The following subset of terms is specifically relevant to this document: Term call change closed configuration item configuration management system continual service improvement

customer

diagnosis

diagnostic script

escalation first-line support impact incident incident management incident model IT service

Version 1

Meaning A telephone call to the service desk from the user. A call could result in an incident or a service request being logged The addition, modification or removal of anything that could have an effect on IT services The final status in the lifecycle of an incident, problem, change etc. When the status is closed, no further action is taken Any component or other service asset that needs to be managed in order to deliver an IT service A set of tools, data and information that is used to support service asset and configuration management A stage in the lifecycle of a service. Continual service improvement ensures that services are aligned with changing business needs by identifying and implementing improvements to IT services that support business processes Someone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees the service level targets A stage in the incident and problem lifecycles. The purpose of diagnosis is to identify a workaround for an incident or the root cause of a problem A structured set of questions used by service desk staff to ensure they ask the correct questions, and to help them classify, resolve and assign incidents An activity that obtains additional resources when these are needed to meet service level targets or customer expectations.

The first level in a hierarchy of support groups involved in the resolution of incidents A measure of the effect of an incident, problem or change on business processes An unplanned interruption to an IT service or reduction in the quality of an IT service The process responsible for managing the lifecycle of all incidents A repeatable way of dealing with a particular category of incident A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and

Page 41 of 43

Insert date Powered by CertiKit

Incident Management Process

Term key performance indicator known error database major incident operational level agreement priority problem resolution root cause second-line support service desk service level agreement super user third-line support urgency user

vision workaround

Meaning processes A metric that is used to help manage an IT service, process, plan, project or other activity A database containing all known error records The highest category of impact for an incident. A major incident results in significant disruption to the business An agreement between an IT service provider and another part of the same organization A category used to identify the relative importance of an incident, problem or change A cause of one or more incidents Action taken to repair the root cause of an incident or problem, or to implement a workaround The underlying or original cause of an incident or problem The second level in a hierarchy of support groups involved in the resolution of incidents and the investigation of problems The single point of contact between the service provider and the users An agreement between an IT service provider and a customer A user who helps other users, and assists in communication with the service desk or other parts of the IT service provider The third level in a hierarchy of support groups involved in the resolution of incidents and investigation of problems A measure of how long it will be until an incident, problem or change has a significant impact on the business A person who uses the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly A description of what the organization intends to become in the future Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available

Table 12 - Glossary of Relevant Terms

(Based on “ITIL Service Operation Book 2011�. Copyright Š AXELOS Limited 2011.

Reproduced under license from AXELOS) 8.2

Abbreviations

The following abbreviations are used in this document: CI CMS CSI IT ITIL Version 1

Configuration Item Configuration Management System Continual Service Improvement Information Technology Information Technology Infrastructure Library Page 42 of 43

Insert date Powered by CertiKit

Incident Management Process

8.3

References

The following sources have been used in the creation of this process document and should be consulted for more information on particular aspects of it:     

ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011 [Organization Name] IT organization structure, published dd/mm/yy [Organization Name] Business Strategy yyyy-yyyy [Organization Name] IT Strategy yyyy-yyyy [Organization Name] IT Service Management Strategy yyyy-yyyy

Version 1

Page 43 of 43

Insert date Powered by CertiKit