|Activity||A set of actions designed to achieve a particular result. Activities are usually defined as part of processes or plans, and are documented in procedures.|
|Client||A generic term that means a customer, the business or a business customer.|
|Function||A team or group of people and the tools or other resources they use to carry out one or more processes or activities (e.g.: Service Desk).|
|Functional Escalation||Transferring an incident, problem or change to a technical team with a higher level of expertise to assist in an escalation.|
|Hierarchal Escalation||Informing or involving more senior levels of management to assist in an escalation.|
|Impact||A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.|
|ITIL®||ITIL® (Information Technology Infrastructure Library) is a framework of good practices in IT Service Management. It provides guidance on the provision of quality IT services, and on the processes, functions and other capabilities needed to support them.|
|Priority||A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. For example, the service level agreement may state that Priority 2 incidents must be resolved within 12 hours.|
|Process||A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs. It may include any of the roles, responsibilities, tools and management controls required to reliably deliver the outputs. A process may define policies, standards, guidelines, activities and work instructions if they are needed.|
|Resolution||Action taken to repair the root cause of an incident or problem, or to implement a workaround.|
|Role||A set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function. One person or team may have multiple roles – for example, the roles of configuration manager and change manager may be carried out by a single person. Role is also used to describe the purpose of something or what it is used for.|
|Service||A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.|
|Single Point of Contact||Providing a single consistent way to communicate with an organization or business unit. For example, a single point of contact for an IT service provider is usually called a service desk.|
|Support Hours||The times or hours when support is available to the users. Typically these are the hours when the service desk is available. Support hours should be defined in a service level agreement, and may be different from service hours. For example, service hours may be 24 hours a day, but the support hours may be 07:00 to 19:00.|
|Urgency||A measure of how long it will be until an incident, problem or change has a significant impact on the business. For example, a high-impact incident may have low urgency if the impact will not affect the business until the end of the financial year. Impact and urgency are used to assign priority.|
|User||A person who uses the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly.|
|Escalation||An activy that obtains additional resources when these are needed to meet service level targets or customer expectations. There a two types of escalation: functional or hierarchal.|
|Service Desk||The single point of contact between the service provider and the users. A typical service desk manages incidents and service requests, and also handles communication with the users.|
|First, second or more support levels||The first, second or more support levels in a hierarchy of support groups involved in the resolution of incidents. Each level contains more specialist skills, or has more time or other resources.|
|Incident||An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident.|
The process responsible for managing the lifecycle of all incidents. Incident management ensures that normal service operation is restored as quickly as possible and the business impact is minimized.
|Major Incident||The highest category of impact for an incident. A major incident results in significant disruption to the business.|
|Request Fulfilment||The process responsible for managing the lifecycle of all service requests.|
|Request Model||A repeatable way of dealing with a particular category of service request. A request model defines specific agreed steps that will be followed for a service request of this category. Request models may be very simple, with no requirement for authorization, or may be more complex with many steps that require authorization|
|Service Request (SR)||A formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user. Service requests are managed by the request fulfilment process, usually in conjunction with the Service Desk.|
|Known Error||A problem that has a documented root cause and a workaround. Known errors are created and managed throughout their lifecycle by problem management.|
The process responsible for managing the lifecycle of all problems. Problem management proactively prevents incidents from happening and minimizes the impact of incidents that cannot be prevented.
|Proactive Problem Management||Part of the problem management process. The objective of proactive problem management is to identify problems that might otherwise be missed. Proactive problem management analyses incident records, and uses data collected by other IT service management processes to identify trends or significant problems.|
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.
|Workaround||Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available – for example, by restarting a failed configuration item. Workarounds for problems are documented in known error records. Workarounds for incidents that do not have associated problem records are documented in the incident record.|
|Back-out||An activity that restores a service or other configuration item to a previous baseline. Back-out is used as a form of remediation when a change or release is not successful.|
|Change||The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.|
|Change Advisory Board (CAB)||A group of people that support the assessment, prioritization, authorization and scheduling of changes. A change advisory board is usually made up of representatives from: all areas within the IT service provider; the business; and third parties such as suppliers.|
|Change Management||The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.|
|Change Model||A repeatable way of dealing with a particular category of change. A change model defines specific agreed steps that will be followed for a change of this category. Change models may be very complex with many steps that require authorization (e.g. major software release) or may be very simple with no requirement for authorization (e.g. password reset).|
|Change Schedule||A document that lists all authorized changes and their planned implementation dates, as well as the estimated dates of longer-term changes. A change schedule is sometimes called a forward schedule of change, even though it also contains information about changes that have already been implemented.|
|Emergency Change||A change that must be introduced as soon as possible – for example, to resolve a major incident or implement a security patch. The change management process will normally have a specific procedure for handling emergency changes.|
|Emergency Change Advisory Board (ECAB)||A subgroup of the change advisory board that makes decisions about emergency changes. Membership may be decided at the time a meeting is called, and depends on the nature of the emergency change.|
|Normal Change||A change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process.|
|Standard Change||A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request.|
|Request for Change (RFC)||A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself.|
Service Asset & Configuration Management
|Asset Management||A generic activity or process responsible for tracking and reporting the value and ownership of assets throughout their lifecycle.|
|Attribute||A piece of information about a configuration item. Examples are name, location, version number and cost. Attributes of CIs are recorded in a configuration management database (CMDB).|
|CI Type||A category that is used to classify configuration items. The CI type identifies the required attributes and relationships for a configuration record. Common CI types include hardware, software, document, etc.|
|Configuration Item (CI)||Any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by service asset and configuration management. Configuration items are under the control of change management. They typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.|
|Configuration Management Data Base (CMDB)||
A database used to store configuration records throughout their lifecycle. The configuration management system maintains one or more configuration management databases, and each database stores attributes of configuration items, and relationships with other configuration items.
|Configuration Record||Set of attributes and relationships about a CI. Configuration records are stored in a configuration management database (CMDB). Note that it is configurations records that describe CIs that are stored in a CMDB, not the CIs themselves.|
|Service Asset||Resource or capability that could contribute to the delivery of a service. By example, a service asset can include a virtual server, a physical server, a software licence, a piece of information stored in a service management system, or some knowledge in the head of a senior manager.|
|Service Asset & Configuration Management||
The process responsible for ensuring that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.
Service Level Management
|Service Level Agreement (SLA)||
An agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer.
|Service Level Management||The process responsible for negotiating achievable service level agreements and ensuring that these are met. It is responsible for ensuring that all IT service management processes, operational level agreements and underpinning contracts are appropriate for the agreed service level targets. Service level management monitors and reports on service levels, holds regular service reviews with customers, and identifies required improvements.|
|Alert||A notification that a threshold has been reached, something has changed, or a failure has occurred. Alerts are often created and managed by system management tools and are managed by the event management process.|
A change of state that has significance for the management of an IT service or other configuration item. The term is also used to mean an alert or notification created by any IT service, configuration item or monitoring tool.
|Event Management||The process responsible for managing events throughout their lifecycle.|
|Monitoring||Repeated observation of a configuration item, IT service or process to detect events and to ensure that the current status is known.|
|Proactive Monitoring||Monitoring that looks for patterns of events to predict possible future failures.|
|Reactive Monitoring||Monitoring that takes place in response to an event. For example, submitting a batch job when the previous job completes, or logging an incident when an error occurs.|
Thank you, your message has been sent.