OVERVIEW
The Information Technology Infrastructure Library (ITIL) provides definitions for the different classifications of events. This article discusses how the standard ITIL and classifications work within the TeamDynamix system.
DETAILS
ITIL Classification Definitions
Note:
These various classifications can be renamed and switch-on or turn-off as necessary.
Classification is in Red and highlighted in yellow, has been switched-on within SFU ServiceHub, as of June 24, 2024
Service Request – A request from a user for information, advice, a standard change or 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 a Request for Change (RFC) to be to be submitted.
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, the failure of one disk from a mirror set.
Major Incident – [Not switched-on yet] An event which significantly affects a business or organization, and which demands a response beyond the routine incident management process. A major incident is an incident that is either defined in the major incident procedure or which:
- Affects, or has the potential to affect services or systems that are critical to the business
- Has a significant effect on the reputation, legal compliance, regulation or security of the business/organization.
Problem – [Not switched-on yet] The cause of one or more incidents. The cause is not usually known when 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 affect IT services. This includes all IT services, configuration items, processes, documentation, etc.
Release – [Not switched-on yet] A collection of hardware or 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.
Use in TeamDynamix
- Let’s look at a hypothetical use case that covers most of these definitions:
- 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 can be changed or upgraded to be more resilient and reliable.
- A release ticket could then be created, and the institution could release new documentation and justification for the upgrade in WiFi infrastructure.
- The institution could release the communication or news that the new WiFi infrastructure should be more consistent, and that there is no cause for concern.
- In the below illustration, the interior blue sections of the pyramid show the hierarchy of what can be used as parent or child tickets in TeamDynamix.
-
A parent ticket can contain any of the child classifications below it. This means, for example, that a release can contain any problems, without a change between them in the hierarchy.
-
When a parent ticket (for example, a release) is updated, a technician can elect to update or close all the child tickets (for example, changes, problems, major incidents, and incidents or 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.
-
Lastly, per the outer edges of the diagram, any classification of a ticket may have a service knowledge article, asset or configuration item associated with it.
