ITILSO0302 Incident Management Process

Incident Management Process

ITIL® 2011 Service Operation Process and Policy Pack v2 ©CertiKit ITIL is a registered trade mark of AXELOS Limited

Incident Management Process

Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions 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 firstline, 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.

Version 1

Page 2 of 44

[Insert date]

Incident Management Process

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 > 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 via the Editing header on the Home tab).

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, for instance, so that they are no longer updateable, 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, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.

Further detail on the above procedure can be found in the toolkit Completion Instructions.

This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

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.

Version 1

Page 3 of 44

[Insert date]

Incident Management Process

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 4 of 44

[Insert date]

Incident Management Process

Incident Management Process

Version 1

DOCUMENT REF

ITILSO0302

VERSION

1

DATED

[Insert date]

DOCUMENT AUTHOR

[Insert name]

DOCUMENT OWNER

[Insert name/role]

Page 5 of 44

[Insert date]

Incident Management Process

Revision history VERSION

DATE

REVISION AUTHOR

SUMMARY OF CHANGES

Distribution NAME

TITLE

Approval NAME

Version 1

POSITION

SIGNATURE

Page 6 of 44

DATE

[Insert date]

Incident Management Process

Contents 1

2

Introduction ............................................................................................................... 9 1.1

Vision statement.......................................................................................................... 9

1.2

Purpose ....................................................................................................................... 9

1.3

Objectives.................................................................................................................. 10

1.4

Scope ........................................................................................................................ 10

Incident management process .................................................................................. 11 2.1

Overview and process diagram ................................................................................... 11

2.2

Process triggers.......................................................................................................... 13

2.3

Process inputs............................................................................................................ 13

2.4

Process activities........................................................................................................ 13

2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.4.9 2.4.10 2.4.11 2.4.12

2.5

Process outputs ......................................................................................................... 20

2.6

Incident management tools ........................................................................................ 21

2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.6.6

2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6

3

Incident identification ............................................................................................................... 14 Is this really an incident? ........................................................................................................... 14 Incident logging ......................................................................................................................... 14 Incident categorisation .............................................................................................................. 15 Incident prioritisation ................................................................................................................ 15 Major incidents ......................................................................................................................... 17 Initial diagnosis.......................................................................................................................... 17 Escalation .................................................................................................................................. 18 Investigation and diagnosis ....................................................................................................... 18 Resolution identified? ........................................................................................................... 19 Resolution and recovery ....................................................................................................... 20 Incident closure .................................................................................................................... 20

Service desk system................................................................................................................... 21 Telephony ................................................................................................................................. 22 Remote control ......................................................................................................................... 22 Email ......................................................................................................................................... 22 Intranet ..................................................................................................................................... 22 Configuration management system ........................................................................................... 23

Communication and training ...................................................................................... 23 Communication with users ........................................................................................................ 23 Communication between shifts ................................................................................................. 23 Process performance ................................................................................................................. 24 Communication related to changes ........................................................................................... 24 Major incident communication.................................................................................................. 24 Training for incident management ............................................................................................ 25

Roles and responsibilities ......................................................................................... 26 3.1

Operational roles ....................................................................................................... 26

3.2

RACI matrix................................................................................................................ 26

3.3

Incident management process owner ......................................................................... 27

3.4

Incident management process manager ..................................................................... 28

Version 1

Page 7 of 44

[Insert date]

Incident Management Process

3.5

Service user ............................................................................................................... 29

3.6

Service desk analyst ................................................................................................... 29

3.7

Second-line analyst .................................................................................................... 29

3.8

Third-line analyst ....................................................................................................... 30

4

Associated documentation ....................................................................................... 31

5

Interfaces and dependencies .................................................................................... 32

6

7

8

5.1

Other service management processes ........................................................................ 32

5.2

Business processes ..................................................................................................... 34

Process measurements and metrics ......................................................................... 35 6.1

Critical success factors................................................................................................ 35

6.2

Key performance indicators........................................................................................ 36

6.3

Process reviews and audits......................................................................................... 36

Process reporting ..................................................................................................... 38 7.1

Process reports .......................................................................................................... 38

7.2

Service level and business relationship reports ........................................................... 40

7.3

Operational reports ................................................................................................... 41

Glossary, abbreviations and references .................................................................... 42 8.1

Glossary..................................................................................................................... 42

8.2

Abbreviations ............................................................................................................ 43

8.3

References................................................................................................................. 44

Figures Figure 1: Incident management process ...................................................................................... 12

Tables Table 1: Determination of priority .............................................................................................. 16 Table 2: Priority definitions ........................................................................................................ 16 Table 3: RACI matrix ................................................................................................................... 27 Table 4: Associated documentation ............................................................................................ 31 Table 5: Interfaces with other service management processes .................................................... 33 Table 6: Interfaces with business processes ................................................................................ 34 Table 7: Critical success factors ................................................................................................... 35 Table 8: Key performance indicators ........................................................................................... 36 Table 9: Process reports ............................................................................................................. 39 Table 10: Service level and business relationship reports ............................................................ 40 Table 11: Operational reports..................................................................................................... 41 Table 12: Glossary of relevant terms ........................................................................................... 43

Version 1

Page 8 of 44

[Insert date]

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® 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. Version 1

Page 9 of 44

[Insert date]

Incident Management Process

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

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

1.4 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 10 of 44

[Insert date]

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 11 of 44

[Insert date]

Incident Management Process

Figure 1: Incident management process

Source: ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS Version 1

Page 12 of 44

[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: • •

•

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 second- and third line and suppliers

2.3 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: • • • • • • • • • •

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

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

Version 1

Page 13 of 44

[Insert date]

Incident Management Process

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 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 fine-tuned 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

Version 1

Page 14 of 44

[Insert date]

Incident Management Process

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.

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 cannot 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 first line, 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:

Version 1

Page 15 of 44

[Insert date]

Incident Management Process • •

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

DESCRIPTION

1

Critical

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

2

High

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

3

Medium

Localised disruption affecting one or more users Examples: Single user unable to work System running slowly for a few users Intermittent network problems

4

Low

Localised inconvenience affecting single user Examples: User unable to print to specific printer Power supply failed on PC Desktop software corruption issue

5

Planning

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

Version 1

Page 16 of 44

[Insert date]

Incident Management Process

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.

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 cannot 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

Version 1

Page 17 of 44

[Insert date]

Incident Management Process

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

Version 1

Page 18 of 44

[Insert date]

Incident Management Process

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

Version 1

Page 19 of 44

[Insert date]

Incident Management Process

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.

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

Resolved incidents

Version 1

Page 20 of 44

[Insert date]

Incident Management Process • • • • •

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

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

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.

Version 1

Page 21 of 44

[Insert date]

Incident Management Process

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

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 easily automated 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.

Version 1

Page 22 of 44

[Insert date]

Incident Management Process

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.

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

Version 1

Page 23 of 44

[Insert date]

Incident Management Process

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.

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.

Version 1

Page 24 of 44

[Insert date]

Incident Management Process

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

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 25 of 44

[Insert date]

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 C: Consulted I: Informed

Version 1

Page 26 of 44

[Insert date]

Incident Management Process

STEP

SERVICE USER

SERVICE DESK ANALYST

SECOND-LINE ANALYST

THIRD-LINE ANALYST

R

R

SERVICE DESK SUPERVISOR

Incident identification

R

R

Incident logging

C

R

A

Incident categorisation

C

R

A

Incident prioritisation

C

R

A

Major incident notification

C

R

A

Incident diagnosis

C

R

A/I

Functional escalation

I

R

Hierarchic escalation

I

R

Investigation and diagnosis

I

I/C

R

R

A

Resolution and recovery

I

R

R

R

A

Incident closure

C

R

I

I

A/R

A A/R

A

Table 3: RACI matrix

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

Version 1

Page 27 of 44

[Insert date]

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

Version 1

Page 28 of 44

[Insert date]

Incident Management Process

3.5 Service user The responsibilities of the user of a service in the incident management process are to: • • • • • • •

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

3.6 Service desk analyst The responsibilities of the Service Desk Analyst with respect to the incident management process are to: • • • • • • • • • •

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

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

Version 1

Page 29 of 44

[Insert date]

Incident Management Process

• • • • • •

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

3.8 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 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 30 of 44

[Insert date]

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

REFERENCE

VERSION

LOCATION

ITIL Service Operation Book

ISBN number 9780113313075

2011

[Network drive location]

Incident logging and management procedure

[Network drive location]

Service management system user guide

[Network drive location]

Service management system administration guide

[Network drive location]

Major Incident Management Process

ITILSO0302

V1.0 Final

[Network drive location]

Event Management Process

V1.0 Final

[Network drive location]

Request Fulfilment Process

V1.0 Final

[Network drive location]

Problem Management Process

V1.0 Final

[Network drive location]

Change Management Process

V1.0 Final

[Network drive location]

Configuration Management Process

V1.0 Final

[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 31 of 44

[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 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

PROCESS

INPUTS TO INCIDENT MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM INCIDENT MANAGEMENT TO THE NAMED PROCESS

Service Strategy

Business Relationship Management

Updates regarding business changes e.g. staff movers and leavers Business awareness and knowledge Feedback regarding user and customer satisfaction levels

Communication regarding major incidents Reports concerning incident trends by business area Potential training requirements

Service Design

Service Level Management

SLA targets for incident response and resolution Understanding of contents of SLAs

Reports on achievement against SLA targets for incident management

Information Security Management

Alerts regarding current threats e.g. phishing emails Guidance on the handling of security-related incidents, including preservation of evidence Information security policy

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

Capacity Management

Advance warning of possible capacity constraints affecting service

Notice of incidents caused by capacity issues

Availability Management

Understanding of availability measures in place

Reports on incidents affecting availability, including lengths of outages

Supplier Management

Information regarding changes within suppliers e.g. contact details and support structure

Reports on performance of suppliers in incident management (e.g. third line)

Service Asset and Configuration Management

Configuration Management System (CMS) records

Updates to configuration items (CIs) discovered as part of incident management Incidents linked to CIs

Change Management

Notice of upcoming changes that may give rise to incidents

Information about incidents occurring as a result of changes Changes raised as a result of incidents

Service Transition

Version 1

Page 32 of 44

[Insert date]

Incident Management Process

ITIL LIFECYCLE STAGE

Service Operation

Continual Service Improvement

PROCESS

INPUTS TO INCIDENT MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM INCIDENT MANAGEMENT TO THE NAMED PROCESS

Release and Deployment Management

Consultation regarding timing of deployment of releases Deployment schedules Information regarding contents of future releases that may address common incidents

Feedback about numbers of incidents resulting from deployments Incidents that may require changes to be raised and included in future releases, including priority

Transition Planning and Support

Advance notice of transition plans and timing

Feedback on success of transitions

Knowledge Management

Knowledge about existing and planned services in the Service Knowledge Management System (SKMS)

Information regarding knowledge required and success of current provision

Problem Management

Status of current problems Known Error Database (KEDB) Workarounds

New problems raised Updates to existing problems based on information from new incidents

Access Management

Updates regarding new users, leavers and movers

Notification of incidents related to access control e.g. account sharing violations

Event Management

Events that meet the criteria for incidents

Feedback regarding the accuracy and quality of incidents raised from events Reports on trends for eventgenerated incidents

Request Fulfilment

Updates and trends concerning service requests carried out

Service request that were initially logged as incidents

7-Step Improvement Process

Incident management process improvements

Potential service improvements identified from incidents Reports on incident trends related to service improvements

Table 5: Interfaces with other service management processes

Version 1

Page 33 of 44

[Insert date]

Incident Management Process

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

BUSINESS AREA

BUSINESS PROCESS

INPUTS TO INCIDENT MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM INCIDENT MANAGEMENT TO THE NAMED PROCESS

Distribution and Logistics

All

IT-related incidents

Resolved incidents

Customer Services

All

IT-related incidents

Resolved incidents

Purchasing

All

IT-related incidents

Resolved incidents

Public Relations

All

IT-related incidents

Resolved incidents

Administration

All

IT-related incidents

Resolved incidents

[Insert further business processes here] Table 6: Interfaces with business processes

Version 1

Page 34 of 44

[Insert date]

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

CRITICAL SUCCESS FACTOR

CSF1

Business disruption is minimised

CSF2

Service levels are being maintained

CSF3

User satisfaction and confidence in IT services is maintained

CSF4

The process is being followed by all staff in a consistent manner

CSF5

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

Version 1

Page 35 of 44

[Insert date]

Incident Management Process

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:

CSF REF

KPI REF

KEY PERFORMANCE INDICATOR

CSF1

KPI1.1

Number of incidents raised per week

KPI1.2

Number of incidents resolved per week

KPI1.3

Number of incidents still open at the end of each week

KPI1.4

Number of major incidents raised per week

KPI1.5

Percentage of incidents resolved at the service desk (first-line fix rate)

KPI1.6

Percentage of incidents resolved on first contact with the user (first-time fix rate)

CSF2

KPI2.1

Percentage of incidents resolved within SLA target

CSF3

KPI3.1

User satisfaction scores from user surveys

KPI3.2

Customer satisfaction scores from customer surveys

KPI3.3

Number of complaints about the incident management service

KPI4.1

Number and percentage of incidents re-opened

KPI4.2

Number and percentage of incidents incorrectly categorised

KPI4.3

Number and percentage of incidents incorrectly prioritised

KPI5.1

Staff to resolved incident ratio

KPI5.2

Average cost per incident

CSF4

CSF5

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

Version 1

Page 36 of 44

[Insert date]

Incident Management Process

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 37 of 44

[Insert date]

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.

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

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

CSFR1

New incident

Number of incidents raised per week

Service desk system reporting tool

Service desk database

Weekly

Process owner

CSFR2

Resolved incident

Number of incidents resolved per week

Service desk system reporting tool

Service desk database

Weekly

Process owner

CSFR3

Incident backlog

Number of incidents still open at the end of each week

Service desk system reporting tool

Service desk database

Weekly

Process owner

CSFR4

Major incident

Number of major incidents raised per week

Service desk system reporting tool

Service desk database

Weekly

Process owner

Version 1

Page 38 of 44

[Insert date]

Incident Management Process

REF

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

CSFR5

First-Line Fix

Percentage of incidents resolved at the service desk (first-line fix rate)

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR6

First-time Fix

Percentage of incidents resolved on first contact with the user (first-time fix rate)

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR7

Incident SLA

Percentage of incidents resolved within SLA target

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR8

User satisfaction

User satisfaction scores from user surveys

Survey tool report

Survey tool database

Quarterly

Process owner

CSFR9

Customer satisfaction

Customer satisfaction scores from customer surveys

Survey tool report

Survey tool database

Sixmonthly

Process owner

CSFR10

Incident complaints

Number of complaints about the incident management service

Complaints system reports

Complaints database

Monthly

Process owner

CSFR11

Incident re-open

Number and percentage of incidents re-opened

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR12

Incident category error

Number and percentage of incidents incorrectly categorised

Sample from service desk system

Service desk database

Quarterly

Process owner

CSFR13

Incident priority error

Number and percentage of incidents incorrectly prioritised

Sample from service desk system

Service desk database

Quarterly

Process owner

CSFR14

Resolution ratio

Staff to resolved incident ratio

Spreadsheet chart

Service desk database and staff attendance records

Monthly

Process owner

CSFR15

Incident cost

Average cost per incident

Spreadsheet costing model

Service desk system and costings from Finance

Quarterly

Process owner

[Insert further reports] Table 9: Process reports

Version 1

Page 39 of 44

[Insert date]

Incident Management Process

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

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

SLAR1

Incident SLA by customer

Percentage of incidents resolved within SLA target, broken down by customer, rolling 12 months

Service desk system reporting tool

Service desk database

Quarterly

Customers Service managers

SLAR2

Incidents by customer

Number of incidents logged and resolved by customer, rolling 12 months

Service desk system reporting tool

Service desk database

Quarterly

Customers Service managers

SLAR3

Major incidents by customer

Listing of major incidents affecting each customer with dates/times, impact, resolution times, root cause and preventative action report

Service desk system reporting tool Manual review of major incidents

Service desk database Major incident review records

Quarterly

Customers Service managers

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

Version 1

Page 40 of 44

[Insert date]

Incident Management Process

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

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQ

AUDIENCE

OPR1

Analyst productivity

Incidents opened and closed by service desk analyst

Service desk system reporting tool

Service desk database

Weekly

Process manager

OPR2

SLA breach

Incidents that have breached SLA or are close to breaching SLA

Service desk system filter view

Service desk database

Daily

Process manager

OPR3

High priority

Incidents of priority 1 and 2 that are currently open

Service desk system filter view

Service desk database

Daily

Process manager

OPR4

Call waiting time

Average waiting time for incidents reported by phone

Telephony system reporting tool

Telephony database

Daily

Process manager

[Insert further reports] Table 11: Operational reports

Version 1

Page 41 of 44

[Insert date]

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

MEANING

Call

A telephone call to the service desk from the user. A call could result in an incident or a service request being logged

Change

The addition, modification or removal of anything that could have an effect on IT services

Closed

The final status in the lifecycle of an incident, problem, change etc. When the status is closed, no further action is taken

Configuration item

Any component or other service asset that needs to be managed in order to deliver an IT service

Configuration management system

A set of tools, data and information that is used to support service asset and configuration management

Continual service improvement

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

Customer

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

Diagnosis

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

Diagnostic script

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

Escalation

An activity that obtains additional resources when these are needed to meet service level targets or customer expectations.

First-line support

The first level in a hierarchy of support groups involved in the resolution of incidents

Impact

A measure of the effect of an incident, problem or change on business processes

Incident

An unplanned interruption to an IT service or reduction in the quality of an IT service

Incident management

The process responsible for managing the lifecycle of all incidents

Incident model

A repeatable way of dealing with a particular category of incident

IT service

A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes

Key performance indicator

A metric that is used to help manage an IT service, process, plan, project or other activity

Known error database

A database containing all known error records

Version 1

Page 42 of 44

[Insert date]

Incident Management Process

TERM

MEANING

Major incident

The highest category of impact for an incident. A major incident results in significant disruption to the business

Operational level agreement

An agreement between an IT service provider and another part of the same organization

Priority

A category used to identify the relative importance of an incident, problem or change

Problem

A cause of one or more incidents

Resolution

Action taken to repair the root cause of an incident or problem, or to implement a workaround

Root cause

The underlying or original cause of an incident or problem

Second-line support

The second level in a hierarchy of support groups involved in the resolution of incidents and the investigation of problems

Service desk

The single point of contact between the service provider and the users

Service level agreement

An agreement between an IT service provider and a customer

Super user

A user who helps other users, and assists in communication with the service desk or other parts of the IT service provider

Third-line support

The third level in a hierarchy of support groups involved in the resolution of incidents and investigation of problems

Urgency

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

User

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

Vision

A description of what the organization intends to become in the future

Workaround

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: Configuration Item CMS: Configuration Management System CSI: Continual Service Improvement IT: Information Technology ITIL: Information Technology Infrastructure Library

Version 1

Page 43 of 44

[Insert date]

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 44 of 44

[Insert date]