Incident Management: Difference between revisions

From IT Process Wiki
No edit summary
Line 1: Line 1:
<seo metakeywords="itil incident management, incident management itil" metadescription="Incident Management: ITIL process definition - Sub-processes - Terms - Additional information on Incident Management." />
<seo metakeywords="itil incident management, incident management itil, incident itil" metadescription="Incident Management: ITIL process definition - Sub-processes - Terms - Additional information on Incident Management." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-de-es.jpg|DE - ES - Incident Management|100px
Image:ITIL-Wiki-de-es.jpg|DE - ES - Incident Management|100px
Line 8: Line 8:
<br style="clear:both;"/>
<br style="clear:both;"/>


<html><div itemscope="itemscope" itemtype="https://schema.org/WebPage"><!-- define schema.org/WebPage --><p></html>
<p>&nbsp;</p>
<p>&nbsp;</p>


==<span id="ITIL Incident Management">Overview</span>==
'''<span id="Overview">Objective:</span>''' <html><span itemprop="description"><i><span itemprop="alternativeHeadline">ITIL <span itemprop="name Headline">Incident Management</span></span></i> aims to manage the lifecycle of all Incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible.</span></p>
<p><b>Part of</b>: <a itemprop="isPartOf" href="https://wiki.en.it-processmaps.com/index.php/ITIL_Service_Operation" title="ITIL Service Operation">Service Operation</a></html>


'''Objective''': ''ITIL Incident Management'' aims to manage the lifecycle of all Incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible.
'''Process Owner''': [[Incident Management#Incident-Manager|Incident Manager]]
 
'''Part of''': [[ITIL V3 Service Operation|Service Operation]]
 
'''Process Owner''': [[Incident Management#Incident Manager|Incident Manager]]


<p>&nbsp;</p>
<p>&nbsp;</p>


== Process Description ==
==Process Description==


Incident Management according to ITIL V3 distinguishes between [[Incident Management#Incident|Incidents]] (Service Interruptions) and [[Request Fulfilment#Service Request|Service Requests]] (standard requests from users, e.g. password resets). Service Requests are no longer fulfilled by Incident Management; instead there is a new process called Request Fulfilment.  
Incident Management according to ITIL V3 distinguishes between [[Incident Management#Incident|Incidents]] (Service Interruptions) and [[Request Fulfilment#Service Request|Service Requests]] (standard requests from users, e.g. password resets). Service Requests are no longer fulfilled by Incident Management; instead there is a new process called Request Fulfilment.  


There is a dedicated process in ITIL V3 for dealing with emergencies ("[[Incident Management#Handling of Major Incidents|Major Incidents]]"). Furthermore a process interface was added between Event Management and Incident Management. Significant [[Event Management#Event|Events]] are triggering the creation of an [[Incident Management#Incident|Incident]].
There is a dedicated process in ITIL V3 for dealing with emergencies ("[[Incident Management#Handling-of-Major-Incidents|Handling of Major Incidents]]"). Furthermore a process interface was added between Event Management and Incident Management. Significant [[Event Management#Event|Events]] are triggering the creation of an [[Incident Management#Incident|Incident]].


<p>&nbsp;</p>
<p>&nbsp;</p>
Line 30: Line 28:
[[Image:Incident-management-itil.jpg|right|thumb|375px|alt=Incident Management ITIL|[https://wiki.en.it-processmaps.com/images/pdf/process_overview_incident_management_itilv3.pdf ITIL Incident Management]]]
[[Image:Incident-management-itil.jpg|right|thumb|375px|alt=Incident Management ITIL|[https://wiki.en.it-processmaps.com/images/pdf/process_overview_incident_management_itilv3.pdf ITIL Incident Management]]]
<span id="Incident Management ITIL 2011">'''''ITIL 2011''''' describes [[Incident Management]] in greater detail:</span>
<span id="Incident Management ITIL 2011">'''''ITIL 2011''''' describes [[Incident Management]] in greater detail:</span>
<p>&nbsp;</p>


Guidance has been improved in Incident Management on how to prioritize an Incident (see [[Checklist Incident Priority|Checklist Incident Prioritization Guideline]]).  
Guidance has been improved in Incident Management on how to prioritize an Incident (see [[Checklist Incident Priority|Checklist Incident Prioritization Guideline]]).  


Additional steps have been added to [[Incident Management#ITIL Incident Management 1st Level|Incident Resolution by 1st Level Support]] to explain that Incidents should be matched (if possible) to existing Problems and Known Errors.  
Additional steps have been added to [[Incident Management#ITIL-Incident-Management-1st-Level|Incident Resolution by 1st Level Support]] to explain that Incidents should be matched (if possible) to existing Problems and Known Errors.  


Incident Resolution by 1st Level Support and [[Incident Management#ITIL Incident Management 2nd Level|Incident Resolution by 2nd Level Support]] have been considerably expanded to provide clearer guidance on when to invoke Problem Management from Incident Management. The emphasis is now on restoring services as quickly as possible, and to seek the help of Problem Management if the underlying cause of an Incident cannot be resolved with a minor Change and/or within the committed resolution time.  
Incident Resolution by 1st Level Support and [[Incident Management#ITIL-Incident-Management-2nd-Level|Incident Resolution by 2nd Level Support]] have been considerably expanded to provide clearer guidance on when to invoke Problem Management from Incident Management. The emphasis is now on restoring services as quickly as possible, and to seek the help of Problem Management if the underlying cause of an Incident cannot be resolved with a minor Change and/or within the committed resolution time.  


The Incident Management sub-process [[Incident Management#ITIL Incident Management Closure|Incident Closure and Evaluation]] now states more clearly that it is important to check whether there are new Problems, Workarounds or Known Errors that must be submitted to Problem Management.
The Incident Management sub-process [[Incident Management#Incident-Closure|Incident Closure and Evaluation]] now states more clearly that it is important to check whether there are new Problems, Workarounds or Known Errors that must be submitted to Problem Management.


The process overview of [[Media:Incident-management-itil.jpg|ITIL Incident Management]]
The process overview of [[Media:Incident-management-itil.jpg|ITIL Incident Management]]
Line 44: Line 44:
<p>&nbsp;</p>
<p>&nbsp;</p>


== Sub-Processes ==
==Sub-Processes==
 
These are the [[Incident Management|ITIL Incident Management]] sub-processes and their process objectives:
 
<p>&nbsp;</p>
 
;<span id="ITIL Incident Management Support">Incident Management Support</span>
:Process Objective: ITIL Incident Management Support aims to provide and maintain the tools, processes, skills and rules for an effective and efficient handling of [[Incident Management#Incident|Incidents]].
 
;<span id="Incident Management Categorization">Incident Logging and Categorization</span>
:Process Objective: To [[Incident Management#Incident Record|record]] and [[Incident Management#Incident Prioritization Guideline|prioritize]] the Incident with appropriate diligence, in order to facilitate a swift and effective resolution.
 
;<span id="ITIL Incident Management 1st Level">Immediate Incident Resolution by 1st Level Support</span>
:Process Objective: To solve an [[Incident Management#Incident|Incident]] (service interruption) within the agreed time schedule. The aim is the fast recovery of the IT service, where necessary with the aid of a [[Problem Management#Workaround|Workaround]]. As soon as it becomes clear that [[Incident Management#1st Level Support|1st Level Support]] is not able to resolve the Incident itself or when target times for 1st level resolution are exceeded, the Incident is transferred to a suitable group within [[Incident Management#2nd Level Support|2nd Level Support]].
 
;<span id="ITIL Incident Management 2nd Level">Incident Resolution by 2nd Level Support</span>
:Process Objective: To solve an [[Incident Management#Incident|Incident]] (service interruption) within the agreed time schedule. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers ([[Incident Management#3rd Level Support|3rd Level Support]]) are involved. If the correction of the root cause is not possible, a [[Problem Management#Problem Record|Problem Record]] is created and the  error-correction transferred to [[Problem Management]].
 
;<span id="Handling of Major Incidents">Handling of Major Incidents</span>
:Process Objective: To resolve a [[Incident Management#Major Incident|Major Incident]]. Major Incidents cause serious interruptions of business activities and must be resolved with greater urgency. The aim is the fast recovery of the service, where necessary by  means of a Workaround. If required, [[Incident Management#Support Request|specialist support groups]] or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to [[Problem Management]].
 
;<span id="Incident Escalation">Incident Monitoring and Escalation</span>
:Process Objective: To continuously monitor the processing status of outstanding Incidents, so that counter-measures may be introduced as soon as possible if service levels are likely to be breached.
 
;<span id="ITIL Incident Management Closure">Incident Closure and Evaluation</span>
:Process Objective: To submit the [[Incident Management#Incident Record|Incident Record]] to a final quality control before it is closed. The aim is to make sure that the Incident is actually resolved and that all information required to describe the Incident's life-cycle is supplied in sufficient detail. In addition to this, findings from the resolution of the Incident are to be recorded for future use.
 
;<span id="Incident User Information">Pro-Active User Information</span>
:Process Objective: To inform users of service failures as soon as these are known to the Service Desk, so that users are in a position to adjust themselves to interruptions. [[Incident Management#Pro-Active User Information|Proactive user information]] also aims to reduce the number of inquiries by users. This process is also responsible for distributing other information to users, e.g. [[IT Security Management#Security Alert|security alerts]].
 
;<span id="ITIL Incident Management Reporting">Incident Management Reporting</span>
:Process Objective: ITIL Incident Management Reporting aims to supply [[Incident Management#Incident Management Report|Incident-related information]] to the other Service Management processes, and to ensure that that improvement potentials are derived from past [[Incident Management#Incident|Incidents]].
 
<p>&nbsp;</p>
 
== Definitions ==
 
The following ITIL terms and acronyms (''information objects'') are used in the ITIL Incident Management process to represent process outputs and inputs:


<html><div itemscope="itemscope" itemtype="https://schema.org/ItemList"><!-- define schema.org/ItemList -->
<meta itemprop="itemListOrder" content="Ascending" />
<p><span itemprop="name" content="Incident Management sub-processes:">These are the <strong class="selflink">ITIL Incident Management</strong> sub-processes and their process objectives:</span>
</p>
<p>&#160;</p>
<p><b><span id="ITIL_Incident_Management_Support" itemprop="itemListElement">Incident Management Support</span></b>
</p>
<ul><li itemprop="description">Process Objective: ITIL Incident Management Support aims to provide and maintain the tools, processes, skills and rules for an effective and efficient handling of <a href="/index.php/Incident_Management#Incident" title="Incident Management">Incidents</a>.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Categorization" itemprop="itemListElement">Incident Logging and Categorization</span></b>
</p>
<ul><li itemprop="description">Process Objective: To <a href="/index.php/Incident_Management#Incident-Record" title="Incident Management">record</a> and <a href="/index.php/Incident_Management#Incident-Prioritization-Guideline" title="Incident Management">prioritize</a> the Incident with appropriate diligence, in order to facilitate a swift and effective resolution.
</li></ul>
<p><br />
</p><p><b><span id="ITIL-Incident-Management-1st-Level" itemprop="itemListElement">Immediate Incident Resolution by 1st Level Support</span></b>
</p>
<ul><li itemprop="description">Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the IT service, where necessary with the aid of a <a href="/index.php/Problem_Management#Workaround" title="Problem Management">Workaround</a>. As soon as it becomes clear that <a href="/index.php/Incident_Management#1st-Level" title="Incident Management">1st Level Support</a> is not able to resolve the Incident itself or when target times for 1st level resolution are exceeded, the Incident is transferred to a suitable group within <a href="/index.php/Incident_Management#2nd-Level" title="Incident Management">2nd Level Support</a>.
</li></ul>
<p><br />
</p><p><b><span id="ITIL-Incident-Management-2nd-Level" itemprop="itemListElement">Incident Resolution by 2nd Level Support</span></b>
</p>
<ul><li itemprop="description">Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers (<a href="/index.php/Incident_Management#3rd-Level" title="Incident Management">3rd Level Support</a>) are involved. If the correction of the root cause is not possible, a <a href="/index.php/Problem_Management#Problem_Record" title="Problem Management">Problem Record</a> is created and the  error-correction transferred to <a href="/index.php/Problem_Management" title="Problem Management">Problem Management</a>.
</li></ul>
<p><br />
</p><p><b><span id="Handling-of-Major-Incidents" itemprop="itemListElement">Handling of Major Incidents</span></b>
</p>
<ul><li itemprop="description">Process Objective: To resolve a <a href="/index.php/Incident_Management#Major-Incident" title="Incident Management">Major Incident</a>. Major Incidents cause serious interruptions of business activities and must be resolved with greater urgency. The aim is the fast recovery of the service, where necessary by  means of a Workaround. If required, specialist support groups or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to <a href="/index.php/Problem_Management" title="Problem Management">Problem Management</a>.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Monitoring" itemprop="itemListElement">Incident Monitoring and Escalation</span></b>
</p>
<ul><li itemprop="description">Process Objective: To continuously monitor the processing status of outstanding Incidents, so that counter-measures may be introduced as soon as possible if service levels are likely to be breached.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Closure" itemprop="itemListElement">Incident Closure and Evaluation</span></b>
</p>
<ul><li itemprop="description">Process Objective: To submit the <a href="/index.php/Incident_Management#Incident-Record" title="Incident Management">Incident Record</a> to a final quality control before it is closed. The aim is to make sure that the Incident is actually resolved and that all information required to describe the Incident's life-cycle is supplied in sufficient detail. In addition to this, findings from the resolution of the Incident are to be recorded for future use.
</li></ul>
<p><br />
</p><p><b><span id="Pro-Active-User-Information" itemprop="itemListElement">Pro-Active User Information</span></b>
</p>
<ul><li itemprop="description">Process Objective: To inform users of service failures as soon as these are known to the Service Desk, so that users are in a position to adjust themselves to interruptions. Proactive user information also aims to reduce the number of inquiries by users. This process is also responsible for distributing other information to users, e.g. <a href="/index.php/IT_Security_Management#Security_Alert" title="IT Security Management">security alerts</a>.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Mgmt-Reporting" itemprop="itemListElement">Incident Management Reporting</span></b>
</p>
<ul><li itemprop="description">Process Objective: ITIL Incident Management Reporting aims to supply <a href="/index.php/Incident_Management#Incident-Management-Report" title="Incident Management">Incident-related information</a> to the other Service Management processes, and to ensure that that improvement potentials are derived from past Incidents.
</li></ul>
</div><!-- end of schema.org/ItemList --><p></html>
<p>&nbsp;</p>
<p>&nbsp;</p>


;<span id="Incident">Incident</span>
==Definitions==
:An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).
 
;<span id="Incident Escalation Rules">Incident Escalation Rules</span>
:A set of rules defining a hierarchy for [[Incident Management#Incident Escalation|escalating Incidents]], and triggers which lead to escalations. Triggers are usually based on Incident severity and resolution times. See also: [[Checklist Incident Priority]]
 
;<span id="Incident Management Report">Incident Management Report</span>
:A report supplying Incident-related information to the other Service Management processes.
 
;<span id="Incident Model">Incident Model</span>
:An Incident Model contains the pre-defined steps that should be taken for dealing with a particular type of Incident. This is a way to ensure that routinely occurring Incidents are handled efficiently and effectively.
 
;<span id="Incident Prioritization Guideline">Incident Prioritization Guideline</span>
:The Incident Prioritization Guideline describes the rules for assigning priorities to Incidents, including the definition of what constitutes a [[Incident Management#Major Incident|Major Incident]]. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering [[Incident Management#Incident Escalation Rules|appropriate escalations]]. See also: [[Checklist Incident Priority|Checklist Incident Prioritization Guideline]]
 
;<span id="Incident Record">Incident Record</span>
:A set of data with all details of an [[Incident Management#Incident|Incident]], documenting the history of the Incident from registration to closure. An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives). See also: [[Checklist Incident Record|ITIL Checklist Incident Record]]
 
;<span id="Incident Status Information">Incident Status Information</span>
:A message containing the present status of an Incident sent to a user who earlier reported a service interruption. Status information is typically provided to users at various points during an Incident's lifecycle.
 
;<span id="Major Incident">Major Incident</span>
:Major Incidents cause serious interruptions of business activities and must be solved with greater urgency.  See also: [[Checklist Incident Priority#Circumstances that warrant the Incident to be treated as a Major Incident|Checklist Incident Priority: Major Incidents]]
 
;<span id="Major Incident Review">Major Incident Review</span>
:A Major Incident Review takes place after a [[Incident Management#Major Incident|Major Incident]] has occurred. The review documents the Incident's underlying causes (if known) and the complete resolution history, and identifies opportunities for improving the handling of future Major Incidents.
 
;<span id="Notification of Service Failure">Notification of Service Failure</span>
:The reporting of a service failure to the [[Incident Management#1st Level Support|Service Desk]], for example by a user via telephone or e-mail, or by a system monitoring tool.
 
;<span id="Pro-Active User Information">Pro-Active User Information</span>
:A [[Incident Management#Incident User Information|notification to users]] of existing or imminent service failures even if the users are not yet aware of the interruptions, so that users are in a position to prepare themselves for a period of service unavailability.
 
;<span id="Incident Status Inquiry">Status Inquiry</span>
:An inquiry regarding the present status of an Incident or Service Request, usually from a user who earlier reported an Incident or submitted a request.
 
;<span id="Support Request">Support Request</span>
:A request to support the resolution of an [[Incident Management#Incident|Incident]] or [[Problem Management#Problem|Problem]], usually issued from the Incident or Problem Management processes when further assistance is needed from technical experts.
 
;<span id="User Escalation">User Escalation</span>
:[[Incident Management#Incident Escalation|Escalation]] regarding the processing of an Incident or Service Request, initiated by a user experiencing delays or a failure to restore their services.
 
;<span id="User-FAQs">User FAQs</span>
:Self-help information for users supplied by the [[Incident Management#1st Level Support|Service Desk]], usually as part of the Support Pages on the intranet.


<html><div itemscope="itemscope" itemtype="https://schema.org/ItemList"><!-- define schema.org/ItemList -->
<meta itemprop="itemListOrder" content="Ascending" />
<p><span itemprop="name">The following <a href="/index.php/ITIL%20Glossary#ITIL%20Glossary%20A-Z" title="ITIL Glossary">ITIL terms and acronyms</a> (<i>information objects</i>) are used in the ITIL Incident Management process to represent process outputs and inputs:</span>
</p>
<p>&#160;</p>
<p><b><span id="Incident" itemprop="itemListElement">Incident</span></b>
</p>
<ul><li itemprop="description">An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).
</li></ul>
<p><br />
</p><p><b><span id="Incident-Escalation-Rules" itemprop="itemListElement">Incident Escalation Rules</span></b>
</p>
<ul><li itemprop="description">A set of rules defining a hierarchy for escalating Incidents, and triggers which lead to escalations. Triggers are usually based on Incident severity and resolution times. See also: <a href="/index.php/Checklist_Incident_Priority" title="Checklist Incident Priority">Checklist Incident Priority</a>
</li></ul>
<p><br />
</p><p><b><span id="Incident-Management-Report" itemprop="itemListElement">Incident Management Report</span></b>
</p>
<ul><li itemprop="description">A report supplying Incident-related information to the other Service Management processes.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Model" itemprop="itemListElement">Incident Model</span></b>
</p>
<ul><li itemprop="description">An Incident Model contains the pre-defined steps that should be taken for dealing with a particular type of Incident. This is a way to ensure that routinely occurring Incidents are handled efficiently and effectively.
</li></ul>
<p><br />
</p><p><b><span id="Incident-Prioritization-Guideline" itemprop="itemListElement">Incident Prioritization Guideline</span></b>
</p>
<ul><li itemprop="description">The Incident Prioritization Guideline describes the rules for assigning priorities to Incidents, including the definition of what constitutes a <a href="/index.php/Incident_Management#Major-Incident" title="Incident Management">Major Incident</a>. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering <a href="/index.php/Incident_Management#Incident-Escalation-Rules" title="Incident Management">appropriate escalations</a>. See also: <a href="/index.php/Checklist_Incident_Priority" title="Checklist Incident Priority">Checklist Incident Prioritization Guideline</a>
</li></ul>
<p><br />
</p><p><b><span id="Incident-Record" itemprop="itemListElement">Incident Record</span></b>
</p>
<ul><li itemprop="description">A set of data with all details of an <a href="/index.php/Incident_Management#Incident" title="Incident Management">Incident</a>, documenting the history of the Incident from registration to closure. An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives). See also: <a href="/index.php/Checklist_Incident_Record" title="Checklist Incident Record">ITIL Checklist Incident Record</a>
</li></ul>
<p><br />
</p><p><b><span id="Incident-Status-Info" itemprop="itemListElement">Incident Status Information</span></b>
</p>
<ul><li itemprop="description">A message containing the present status of an Incident sent to a user who earlier reported a service interruption. Status information is typically provided to users at various points during an Incident's lifecycle.
</li></ul>
<p><br />
</p><p><b><span id="Major-Incident" itemprop="itemListElement">Major Incident</span></b>
</p>
<ul><li itemprop="description">Major Incidents cause serious interruptions of business activities and must be solved with greater urgency.  See also: <a href="/index.php/Checklist_Incident_Priority#Circumstances_that_warrant_the_Incident_to_be_treated_as_a_Major_Incident" title="Checklist Incident Priority">Checklist Incident Priority: Major Incidents</a>.
</li></ul>
<p><br />
</p><p><b><span id="Major-Incident-Review" itemprop="itemListElement">Major Incident Review</span></b>
</p>
<ul><li itemprop="description">A Major Incident Review takes place after a <a href="/index.php/Incident_Management#Major-Incident" title="Incident Management">Major Incident</a> has occurred. The review documents the Incident's underlying causes (if known) and the complete resolution history, and identifies opportunities for improving the handling of future Major Incidents.
</li></ul>
<p><br />
</p><p><b><span id="Service-Failure" itemprop="itemListElement">Notification of Service Failure</span></b>
</p>
<ul><li itemprop="description">The reporting of a service failure to the <a href="/index.php/Incident_Management#1st-Level" title="Incident Management">Service Desk</a>, for example by a user via telephone or e-mail, or by a system monitoring tool.
</li></ul>
<p><br />
</p><p><b><span id="Pro-active-User-Info" itemprop="itemListElement">Pro-Active User Information</span></b>
</p>
<ul><li itemprop="description">A notification to users of existing or imminent service failures even if the users are not yet aware of the interruptions, so that users are in a position to prepare themselves for a period of service unavailability.
</li></ul>
<p><br />
</p><p><b><span id="Status-Inquiry" itemprop="itemListElement">Status Inquiry</span></b>
</p>
<ul><li itemprop="description">An inquiry regarding the present status of an Incident or Service Request, usually from a user who earlier reported an Incident or submitted a request.
</li></ul>
<p><br />
</p><p><b><span id="Support-Request" itemprop="itemListElement">Support Request</span></b>
</p>
<ul><li itemprop="description">A request to support the resolution of an Incident or Problem, usually issued from the Incident or Problem Management processes when further assistance is needed from technical experts.
</li></ul>
<p><br />
</p><p><b><span id="User-Escalation" itemprop="itemListElement">User Escalation</span></b>
</p>
<ul><li itemprop="description">Escalation regarding the processing of an Incident or Service Request, initiated by a user experiencing delays or a failure to restore their services.
</li></ul>
<p><br />
</p><p><b><span id="User-FAQ" itemprop="itemListElement">User FAQs</span></b>
</p>
<ul><li itemprop="description">Self-help information for users supplied by the Service Desk, usually as part of the Support Pages on the intranet.
</li></ul>
</div><!-- end of schema.org/ItemList --><p></html>
<p>&nbsp;</p>
<p>&nbsp;</p>


== Checklists | KPIs ==
==<span id="Checklists_.7C_KPIs">Templates | KPIs</span>==


* [[ITIL KPIs Service Operation#ITIL KPIs Incident Management|Key Performance Indicators (KPIs) Incident Management]]
*[[ITIL KPIs Service Operation#ITIL KPIs Incident Management|Key Performance Indicators (KPIs) Incident Management]]
*[[ITIL-Checklists#Checklists for Service Desk and Incident Management|Checklists Incident Management]]:
*[[ITIL-Checklists#Incident Management / Service Desk|Incident Management templates and checklists]]:
** [[Checklist Incident Record]]
**[[Checklist Incident Record]]
** [[Checklist Incident Priority]], and
**[[Checklist Incident Priority]], and
** [[Checklist Initial Analysis of an Incident]]
**[[Checklist Initial Analysis of an Incident]]
** [[Checklist Incident Escalation]]
**[[Checklist Incident Escalation]]
** [[Checklist Closure of an Incident]]
**[[Checklist Closure of an Incident]]
** [[Checklist Incident Report]]
**[[Checklist Incident Report]]


<p>&nbsp;</p>
<p>&nbsp;</p>


== Roles | Responsibilities ==
==<span id="roles-responsibilities-matrix">Roles | Responsibilities</span>==


;<span id="Incident Manager">Incident Manager - Process Owner</span>
'''<span id="Incident-Manager">Incident Manager - Process Owner</span>'''
:The Incident Manager is responsible for the effective implementation of the [[Incident Management]] process and carries out the corresponding reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.
*The Incident Manager is responsible for the effective implementation of the Incident Management process and carries out the corresponding reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.
<br />


;<span id="1st Level Support">1st Level Support</span>
'''<span id="1st-Level">1st Level Support</span>'''
:The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also keeps users informed about their Incidents' status at agreed intervals.
*The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also keeps users informed about their Incidents' status at agreed intervals.
<br />


;<span id="2nd Level Support">2nd Level Support</span>
'''<span id="2nd-Level">2nd Level Support</span>'''
:2nd Level Support takes over Incidents which cannot be solved immediately with the means of 1st Level Support. If necessary, it will request external support, e.g. from software or hardware manufacturers. The aim is to restore a failed IT service as quickly as possible. If no solution can be found, the 2nd Level Support passes on the Incident to Problem Management.  
*2nd Level Support takes over Incidents which cannot be solved immediately with the means of 1st Level Support. If necessary, it will request external support, e.g. from software or hardware manufacturers. The aim is to restore a failed IT service as quickly as possible. If no solution can be found, the 2nd Level Support passes on the Incident to Problem Management.
<br />


;<span id="3rd Level Support">3rd Level Support</span>
'''<span id="3rd-Level">3rd Level Support</span>'''
:3rd Level Support is typically located at hardware or software manufacturers (third-party suppliers). Its services are requested by 2nd Level Support if required for solving an Incident. The aim is to restore a failed IT Service as quickly as possible.  
*3rd Level Support is typically located at hardware or software manufacturers (third-party suppliers). Its services are requested by 2nd Level Support if required for solving an Incident. The aim is to restore a failed IT Service as quickly as possible.
<br />


;<span id="Major Incident Team">Major Incident Team</span>
'''<span id="Major-Incident-Team">Major Incident Team</span>'''
:A dynamically established team of IT managers and technical experts, usually under the leadership of the Incident Manager, formulated to concentrate on the resolution of a Major Incident.
*A dynamically established team of IT managers and technical experts, usually under the leadership of the Incident Manager, formulated to concentrate on the resolution of a Major Incident.


<p>&nbsp;</p>
<p>&nbsp;</p>


{| border="1" cellpadding="5" cellspacing="0" style="text-align:center;" valign="top"
{| border="1" cellpadding="5" cellspacing="0" style="margin-left: auto; margin-right: auto; text-align:center;" valign="top"
|-
|-
| valign="top" colspan="8" style="background:#ffffdd;" align="center"| '''Responsibility Matrix: ITIL Incident Management'''
|style="vertical-align:top; text-align:center" colspan="8" style="background:#ffffdd;"| '''<span id="RACI-Matrix-Incident-Management">Responsibility Matrix: ITIL Incident Management</span>'''
|-
|-
! width="40%" align="center" style="background:#ffffee;" | ITIL Role / Sub-Process
!style="background:#ffffee; width: 40%; text-align:center" | ITIL Role / Sub-Process[[Incident Management#Sub-Processes| <small>[Details]</small>]]
! style="background:#ffffee;" | [[Incident Management#Incident Manager|Incident Manager]]
! style="background:#ffffee;" | [[#Incident-Manager|Incident Manager]]
! style="background:#ffffee;" | [[Incident Management#1st Level Support|1st Level Support]]
! style="background:#ffffee;" | [[#1st-Level|1st Level Support]]
! style="background:#ffffee;" | [[Incident Management#2nd Level Support|2nd Level Support]]
! style="background:#ffffee;" | [[#2nd-Level|2nd Level Support]]
! style="background:#ffffee;" | [[Incident Management#Major Incident Team|Major Incident Team]]
! style="background:#ffffee;" | [[#Major-Incident-Team|Major Incident Team]]
! style="background:#ffffee;" | Applications Analyst[[Incident Management#Team|<small>[3]</small>]]
! style="background:#ffffee;" | Applications Analyst[[#Team|<small>[3]</small>]]
! style="background:#ffffee;" | Technical Analyst[[Incident Management#Team|<small>[3]</small>]]
! style="background:#ffffee;" | Technical Analyst[[#Team|<small>[3]</small>]]
! style="background:#ffffee;" | IT Operator[[Incident Management#Team|<small>[3]</small>]]
! style="background:#ffffee;" | IT Operator[[#Team|<small>[3]</small>]]
|-
|-
| align="left" |[[#ITIL Incident Management Support|Incident Management Support]]
|style="text-align:left;" |Incident Management Support
| A[[Incident Management#Accountable|<small>[1]</small>]]R[[Incident Management#Responsible|<small>[2]</small>]]
| A[[Incident Management#Accountable|<small>[1]</small>]]R[[Incident Management#Responsible|<small>[2]</small>]]
| -
| -
Line 186: Line 240:
| -
| -
|-
|-
| align="left" |[[#Incident Management Categorization|Incident Logging and Categorization]]
|style="text-align:left;" |Incident Logging and Categorization
| A
| A
| R
| R
Line 195: Line 249:
| -
| -
|-
|-
| align="left" |[[#ITIL Incident Management 1st Level|Immediate Incident Resolution by 1st Level Support]]
|style="text-align:left;" |Immediate Incident Resolution by 1st Level Support
| A
| A
| R
| R
Line 204: Line 258:
| -
| -
|-
|-
| align="left" |[[#ITIL Incident Management 2nd Level|Incident Resolution by 2nd Level Support]]
|style="text-align:left;" |Incident Resolution by 2nd Level Support
| A
| A
| -
| -
| R
| R
| -
| -
| R[[Incident Management#Support Group|<small>[4]</small>]]  
| R[[#Support|<small>[4]</small>]]  
| R[[Incident Management#Support Group|<small>[4]</small>]]  
| R[[#Support|<small>[4]</small>]]  
| R[[Incident Management#Support Group|<small>[4]</small>]]  
| R[[#Support|<small>[4]</small>]]  
|-
|-
| align="left" |[[#Handling of Major Incidents|Handling of Major Incidents]]
| align="left" |Handling of Major Incidents
| AR
| AR
| R  
| R  
Line 222: Line 276:
| R
| R
|-
|-
| align="left" |[[#Incident Escalation|Incident Monitoring and Escalation]]
|style="text-align:left;" |Incident Monitoring and Escalation
| AR
| AR
| R
| R
Line 231: Line 285:
| -
| -
|-
|-
| align="left" |[[#ITIL Incident Management Closure|Incident Closure and Evaluation]]
|style="text-align:left;" |Incident Closure and Evaluation
| A
| A
| R
| R
Line 240: Line 294:
| -
| -
|-
|-
| align="left" |[[#Incident User Information|Pro-Active User Information]]
|style="text-align:left;" |Pro-Active User Information
| A
| A
| R
| R
Line 249: Line 303:
| -
| -
|-
|-
| align="left" |[[#ITIL Incident Management Reporting|Incident Management Reporting]]
|style="text-align:left;" |Incident Management Reporting
| AR
| AR
| -
| -
Line 268: Line 322:
<span id="Responsible">[2] ''R: Responsible'' according to the RACI Model: Those who do the work to achieve a task within Incident Management.</span>
<span id="Responsible">[2] ''R: Responsible'' according to the RACI Model: Those who do the work to achieve a task within Incident Management.</span>


<span id="Team">[3] see [[Roles within ITIL V3|&#8594; Role descriptions...]]</span>
<span id="Team">[3] see [[ITIL Roles|&#8594; Role descriptions...]]</span>


<span id="Support Group">[4] In cooperation, as required. 2nd Level Support Groups often include Applications Analysts and/ or Technical Analysts.
<span id="Support">[4] In cooperation, as required. 2nd Level Support Groups often include Applications Analysts and/ or Technical Analysts.</span>


<p>&nbsp;</p>
<p>&nbsp;</p>
Line 284: Line 338:


<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
==[ Infobox ]==
<html><table class="wikitable">
<tr>
<td>Link to this page:</td>
<td><a itemprop="url" href="https://wiki.en.it-processmaps.com/index.php/Incident_Management">https://wiki.en.it-processmaps.com/index.php/Incident_Management</a></td>
</tr>
<tr>
<td>Languages:</td>
<td><span itemprop="inLanguage" content="en">English</span> | <span><a itemprop="citation" class="external text" href="https://wiki.de.it-processmaps.com/index.php/Incident_Management" title="Incident Management">Deutsch</a></span> | <span><a itemprop="citation" class="external text" href="https://wiki.es.it-processmaps.com/index.php/ITIL_Gestion_de_Incidentes" title="Gestión de Incidentes">espa&#xf1;ol</a></span></td>
</tr>
<tr>
<td>Image:</td>
<td style="vertical-align:top"><a itemprop="primaryImageOfPage" href="https://wiki.en.it-processmaps.com/images/7/73/Incident-management-itil.jpg" title="Incident Management">ITIL Incident Management (.JPG)</a></td>
</tr>
<tr>
<td>Author:</td>
<td><span itemprop="author">Stefan Kempter</span>, <span itemprop="creator copyrightHolder publisher">IT Process Maps</span> &nbsp;&nbsp; <a rel="author" href="https://plus.google.com/111925560448291102517"><img style="margin:0px 0px 0px 0px;" src="/skins/Vector/images/itpm/bookmarking/gplus.png" width="16" height="16" title="By: Stefan Kempter | Profile on Google+" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a></td>
</tr>
</table>
<p><small>
<span itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="https://wiki.en.it-processmaps.com/index.php/Incident_Management#Process_Description" itemprop="url"><span itemprop="title">Process Description</span></a> ›
</span>
<span itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="https://wiki.en.it-processmaps.com/index.php/Incident_Management#Sub-Processes" itemprop="url"><span itemprop="title">Sub-Processes</span></a> ›
</span>
<span itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="https://wiki.en.it-processmaps.com/index.php/Incident_Management#Definitions" itemprop="url"><span itemprop="title">Definitions</span></a> ›
</span>
<span itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="https://wiki.en.it-processmaps.com/index.php/Incident_Management#Templates_.7C_KPIs" itemprop="url"><span itemprop="title">Templates</span></a> ›
</span>
<span itemscope="itemscope" itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="https://wiki.en.it-processmaps.com/index.php/Incident_Management#Roles_.7C_Responsibilities" itemprop="url"><span itemprop="title">Roles</span></a>
</span>
</small></p>
</div><!-- end of schema.org/WebPage --><p></html>


<!-- This page is assigned to the following categories: -->
<!-- This page is assigned to the following categories: -->
[[Category:ITIL V3]][[Category:ITIL 2011]][[Category:ITIL process]][[Category:Service Operation|Incident Management]][[Category:Incident Management|!]]
[[Category:ITIL V3]][[Category:ITIL 2011]][[Category:ITIL process]][[Category:Service Operation|Incident Management]][[Category:Incident Management|!]]
<!-- --- -->
<!-- --- -->

Revision as of 15:42, 13 December 2013

<seo metakeywords="itil incident management, incident management itil, incident itil" metadescription="Incident Management: ITIL process definition - Sub-processes - Terms - Additional information on Incident Management." />

DE - ES - Incident Managementdiese Seite auf Deutschesta página en español
DE - ES - Incident Management


 

Objective: ITIL Incident Management aims to manage the lifecycle of all Incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible.

Part of: Service Operation

Process Owner: Incident Manager

 

Process Description

Incident Management according to ITIL V3 distinguishes between Incidents (Service Interruptions) and Service Requests (standard requests from users, e.g. password resets). Service Requests are no longer fulfilled by Incident Management; instead there is a new process called Request Fulfilment.

There is a dedicated process in ITIL V3 for dealing with emergencies ("Handling of Major Incidents"). Furthermore a process interface was added between Event Management and Incident Management. Significant Events are triggering the creation of an Incident.

 

Incident Management ITIL
ITIL Incident Management

ITIL 2011 describes Incident Management in greater detail:

 

Guidance has been improved in Incident Management on how to prioritize an Incident (see Checklist Incident Prioritization Guideline).

Additional steps have been added to Incident Resolution by 1st Level Support to explain that Incidents should be matched (if possible) to existing Problems and Known Errors.

Incident Resolution by 1st Level Support and Incident Resolution by 2nd Level Support have been considerably expanded to provide clearer guidance on when to invoke Problem Management from Incident Management. The emphasis is now on restoring services as quickly as possible, and to seek the help of Problem Management if the underlying cause of an Incident cannot be resolved with a minor Change and/or within the committed resolution time.

The Incident Management sub-process Incident Closure and Evaluation now states more clearly that it is important to check whether there are new Problems, Workarounds or Known Errors that must be submitted to Problem Management.

The process overview of ITIL Incident Management is showing the most important interfaces (see Figure 1).

 

Sub-Processes

These are the ITIL Incident Management sub-processes and their process objectives:

 

Incident Management Support

  • Process Objective: ITIL Incident Management Support aims to provide and maintain the tools, processes, skills and rules for an effective and efficient handling of Incidents.


Incident Logging and Categorization

  • Process Objective: To record and prioritize the Incident with appropriate diligence, in order to facilitate a swift and effective resolution.


Immediate Incident Resolution by 1st Level Support

  • Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the IT service, where necessary with the aid of a Workaround. As soon as it becomes clear that 1st Level Support is not able to resolve the Incident itself or when target times for 1st level resolution are exceeded, the Incident is transferred to a suitable group within 2nd Level Support.


Incident Resolution by 2nd Level Support

  • Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to Problem Management.


Handling of Major Incidents

  • Process Objective: To resolve a Major Incident. Major Incidents cause serious interruptions of business activities and must be resolved with greater urgency. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to Problem Management.


Incident Monitoring and Escalation

  • Process Objective: To continuously monitor the processing status of outstanding Incidents, so that counter-measures may be introduced as soon as possible if service levels are likely to be breached.


Incident Closure and Evaluation

  • Process Objective: To submit the Incident Record to a final quality control before it is closed. The aim is to make sure that the Incident is actually resolved and that all information required to describe the Incident's life-cycle is supplied in sufficient detail. In addition to this, findings from the resolution of the Incident are to be recorded for future use.


Pro-Active User Information

  • Process Objective: To inform users of service failures as soon as these are known to the Service Desk, so that users are in a position to adjust themselves to interruptions. Proactive user information also aims to reduce the number of inquiries by users. This process is also responsible for distributing other information to users, e.g. security alerts.


Incident Management Reporting

  • Process Objective: ITIL Incident Management Reporting aims to supply Incident-related information to the other Service Management processes, and to ensure that that improvement potentials are derived from past Incidents.

 

Definitions

The following ITIL terms and acronyms (information objects) are used in the ITIL Incident Management process to represent process outputs and inputs:

 

Incident

  • An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).


Incident Escalation Rules

  • A set of rules defining a hierarchy for escalating Incidents, and triggers which lead to escalations. Triggers are usually based on Incident severity and resolution times. See also: Checklist Incident Priority


Incident Management Report

  • A report supplying Incident-related information to the other Service Management processes.


Incident Model

  • An Incident Model contains the pre-defined steps that should be taken for dealing with a particular type of Incident. This is a way to ensure that routinely occurring Incidents are handled efficiently and effectively.


Incident Prioritization Guideline


Incident Record

  • A set of data with all details of an Incident, documenting the history of the Incident from registration to closure. An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives). See also: ITIL Checklist Incident Record


Incident Status Information

  • A message containing the present status of an Incident sent to a user who earlier reported a service interruption. Status information is typically provided to users at various points during an Incident's lifecycle.


Major Incident


Major Incident Review

  • A Major Incident Review takes place after a Major Incident has occurred. The review documents the Incident's underlying causes (if known) and the complete resolution history, and identifies opportunities for improving the handling of future Major Incidents.


Notification of Service Failure

  • The reporting of a service failure to the Service Desk, for example by a user via telephone or e-mail, or by a system monitoring tool.


Pro-Active User Information

  • A notification to users of existing or imminent service failures even if the users are not yet aware of the interruptions, so that users are in a position to prepare themselves for a period of service unavailability.


Status Inquiry

  • An inquiry regarding the present status of an Incident or Service Request, usually from a user who earlier reported an Incident or submitted a request.


Support Request

  • A request to support the resolution of an Incident or Problem, usually issued from the Incident or Problem Management processes when further assistance is needed from technical experts.


User Escalation

  • Escalation regarding the processing of an Incident or Service Request, initiated by a user experiencing delays or a failure to restore their services.


User FAQs

  • Self-help information for users supplied by the Service Desk, usually as part of the Support Pages on the intranet.

 

Templates | KPIs

 

Roles | Responsibilities

Incident Manager - Process Owner

  • The Incident Manager is responsible for the effective implementation of the Incident Management process and carries out the corresponding reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.


1st Level Support

  • The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also keeps users informed about their Incidents' status at agreed intervals.


2nd Level Support

  • 2nd Level Support takes over Incidents which cannot be solved immediately with the means of 1st Level Support. If necessary, it will request external support, e.g. from software or hardware manufacturers. The aim is to restore a failed IT service as quickly as possible. If no solution can be found, the 2nd Level Support passes on the Incident to Problem Management.


3rd Level Support

  • 3rd Level Support is typically located at hardware or software manufacturers (third-party suppliers). Its services are requested by 2nd Level Support if required for solving an Incident. The aim is to restore a failed IT Service as quickly as possible.


Major Incident Team

  • A dynamically established team of IT managers and technical experts, usually under the leadership of the Incident Manager, formulated to concentrate on the resolution of a Major Incident.

 

Responsibility Matrix: ITIL Incident Management
ITIL Role / Sub-Process [Details] Incident Manager 1st Level Support 2nd Level Support Major Incident Team Applications Analyst[3] Technical Analyst[3] IT Operator[3]
Incident Management Support A[1]R[2] - - - - - -
Incident Logging and Categorization A R - - - - -
Immediate Incident Resolution by 1st Level Support A R - - - - -
Incident Resolution by 2nd Level Support A - R - R[4] R[4] R[4]
Handling of Major Incidents AR R - R - - R
Incident Monitoring and Escalation AR R - - - - -
Incident Closure and Evaluation A R - - - - -
Pro-Active User Information A R - - - - -
Incident Management Reporting AR - - - - - -

 

Remarks

[1] A: Accountable according to the RACI Model: Those who are ultimately accountable for the correct and thorough completion of the Incident Management process.

[2] R: Responsible according to the RACI Model: Those who do the work to achieve a task within Incident Management.

[3] see → Role descriptions...

[4] In cooperation, as required. 2nd Level Support Groups often include Applications Analysts and/ or Technical Analysts.

 

Example

The ITIL Process Map video shows samples of the ITIL process templates with contents from Service Operation and Incident Management processes, including the

  • high-level view of the ITIL Service Lifecycle (Level 0)
  • overview of the Service Operation process (Level 1)
  • overview of ITIL Incident Management (Level 2)
  • detailed process flow for the process "Incident Management: Incident Resolution by 1st Level Support" (Level 3)

 

 

[ Infobox ]

Link to this page:
Languages: English | Deutsch | español
Image: ITIL Incident Management (.JPG)
Author: , IT Process Maps   

 ›  ›  ›  ›