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.