Differences between Incident, Major Incident, Problem, Change, Release, and Service Request

This article first gives an overview of the ITIL definitions of these different classification of items, provides sample use cases, and provides additional notes regarding how these classifications manifest themselves within TeamDynamix.

ITIL Classification Definitions

Incident
An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted one or more Services is also an Incident. For example: Failure of one disk from a mirror set.
Major Incident
An event which has significant impact or urgency for the business/organisation and which demands a response beyond the routine incident management process.
A major incident will be an incident that is either defined in the major incident procedure or which:
  • may either cause, or have the potential to cause, impact on business critical services or systems (which can be named in the major incident procedure);
  • or be an incident that has significant impact on reputation, legal compliance, regulation or security of the business/organization.
Problem
A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.
Change
The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.
Release
A collection of hardware/software documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.​
Service Request
A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

Use Cases

A good simple use case for most of these would be that there are fifty Incidents of WiFi being interrupted. Those Incidents are then rolled up into a single Problem ticket about the lack of suitable WiFi infrastructure. A Change ticket could then be opened and the WiFi infrastructure is then changed/upgraded to be more resilient and reliable. A Release ticket could then be created and then the institution could then release new documentation and justification for the upgrade in WiFi infrastructure. Also, release the news that the new WiFi infrastructure should be more consistent, and that people should not worry, etc.

Use in TeamDynamix

As these definitions may not exactly suit a specific organization's processes, these various classifications can be renamed and turned on/off as necessary.

Please note that as of 9.1, Service Requests are items that have been associated with a ticketing workflow, and these items must be promoted to one of the 4 main classifications seen above. However, 9.2 sees Service Requests be made its own separate classification that can be created and used independently of a workflow.

The hierarchy of what can be used as parent/child tickets in TeamDynamix is as follows:

1 (highest) Release
2 Change
3 Problem
4 Major Incident
5a (lowest) Incident 5b (lowest) Service RequestFootnote 1

Footnote 1 - Service Requests can only be included in the hierarchy in versions 9.2 and up.

Note that a parent ticket can contain any of the child classifications below it. This means that a Release can contain any Problems, for example, without a Change between them in the hierarchy.

When a parent ticket, such as a Release, is updated, a technician can elect to update/close all the child tickets, such as Changes, Problems, Major Incidents, and Incidents/Service Requests. that are nestled within it.

When a ticket is converted to a project task, any existing parent linkage is removed, but children tickets will remain. However, updates made to the ticket based on the corresponding project task's status will not be cascaded to its children.

95% helpful - 40 reviews

Details

Article ID: 2568
Created
Wed 10/15/14 11:24 AM
Modified
Wed 9/19/18 10:11 AM