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

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.

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, the failure of one disk from a mirror set.

Major Incident – 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 – 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 – 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.​

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.

Use Cases

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 news that the new WiFi infrastructure should be more consistent, and that there is no cause for concern.

Use in TeamDynamix

Since these definitions may not perfectly suit the processes of a specific organization, these various classifications can be renamed and turned on or off as necessary.

Service requests have a separate classification that can be created and used independently of a workflow.

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 that a release can contain any problems, for example, 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. 

Common ITIL Terminology

Incident Management (IM) – The process responsible for managing the lifecycle of all incidents. The primary objective of incident management is to return the IT service to users as quickly as possible.

Asset Management (AM) – The process responsible for tracking and reporting the value and ownership of financial assets throughout their lifecycle. Asset management is part of an overall service asset and configuration management process.

Change Management (CM) – The process responsible for controlling the lifecycle of all changes. The primary objective of change management is to enable beneficial changes to be made with minimum disruption to IT services.

Standard Change (SC) – A change that is recurrent, well-known, has been proceduralized to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authority is effectively given in advance of implementation.

Change Advisory Board (CAB) – A group of people that advises the change manager on the assessment, prioritization and scheduling of changes. This board is usually made up of representatives from all areas within the IT service provider, business and third parties such as suppliers.

Emergency Change Advisory Board (ECAB) – An emergency meeting of the CAB, usually with a reduced number of members, to consider urgent, high impact changes. Its membership, which may change from occasion to occasion, therefore needs to represent the knowledge and authority required in these exceptional circumstances. In practice, members may make their decisions without a physical meeting.

Change Manager (CM) – The person responsible for the change management process.

Configuration Item (CI) – Any component that needs to be managed in order to deliver an IT service. Information about each CI is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by configuration management. CIs are under the control of change management. CIs typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.

Access Management (AM) – The process responsible for allowing users to make use of IT services, data or other assets. Access management helps to protect the confidentiality, integrity and availability of assets by ensuring that only authorized users can access or modify the assets. Access management is sometimes referred to as rights management or identity management.

Continual Service Improvement (CSI) – A stage in the lifecycle of an IT service and the title of one of the core ITIL books. Continual service improvement is responsible for managing improvement to IT service management processes and IT services. The performance of the IT service provider is continually measured, and improvements are made to processes, IT services and IT infrastructure in order to increase efficiency, effectiveness, and cost effectiveness.

Service Desk (SD) – The single point of contact between the service provider and users. A typical service desk manages incidents and service requests and handles communication with users.

Service Catalog (SC) – A document (printed or on the intranet or internet) produced by the IT department to keep its customers and users informed. It provides a brief overview, in business terms, of all the business and infrastructure services offered by the IT provider and may include service charges. This information, together with more detailed technical knowledge will be maintained for internal use.

Service Owner (SO) – The individual taking primary responsibility for a service, including its design, objectives and progression.

Information Technology Service Provider (ITSP) – An organization supplying services to one or more internal customers or external customers, and shared customers.

Service Level Agreement (SLA) – An agreement between an IT service provider and a customer. The SLA describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single SLA may cover multiple IT services or multiple customers.

Risk Management (RM) – Management of the risks to assets through the identification, selection and use of countermeasures, justified by the identified risks in terms of their potential impact upon services if failure occurs, and the reduction of those risks to an acceptable level.

Stakeholder – All people who have an interest in an organization, project, IT service, etc. Stakeholders may be interested in activities, targets, resources, or deliverables. Stakeholders may include customers, partners, employees, shareholders, owners, etc.

Service Knowledge Management System (SKMS) – A set of tools and databases that are used to manage knowledge and information. The SKMS includes the configuration management system, as well as other tools and database. The SKMS stores, manages, updates, and displays all information that an IT service provider needs to manage the full lifecycle of IT services.

Business Relations Management (BRM) – The process or function responsible for maintaining a relationship with the business. Usually includes:

  • Managing personal relationships with business managers
  • Ensuring that the information technology service provider (ITSP) is satisfying customers’ needs.
95% helpful - 42 reviews

Details

Article ID: 2568
Created
Wed 10/15/14 11:24 AM
Modified
Wed 6/9/21 10:45 AM

Related Articles (1)