|
Practice
|
Term |
Definition |
| Change Enablement |
Change |
The addition, modification, or removal of anything that could have a direct or indirect effect on services. |
| Change Enablement |
Change advisory board |
A group that helps the change manager assess, prioritize, and schedule changes. There may also be a smaller emergency change advisory board. |
| Change Enablement |
Change authority |
A person or group responsible for authorizing a change. |
| Change Enablement |
Change coordinator |
The individual or group responsible for managing the change or maintenance activity. On a change, the Responsible is the change coordinator; on a maintenance activity, the Responsible is the change implementer. |
| Change Enablement |
Change model |
A repeatable approach to the management of a type of change. |
| Change Enablement |
Change requestor |
The individual requesting the change - not necessarily the person submitting the RFC. May be a non-CIT individual such as a functional unit Director or may be someone within CIT as part of the service delivery team. The requestor will be notified at creation and once the change is approved and scheduled. |
| Change Enablement |
Change schedule |
A calendar that shows planned and historical changes. |
| Change Enablement |
Emergency change |
A change that must be implemented as soon as possible; for example, to resolve a Major Incident or implement a security patch. The process for assessment and authorization is expedited to ensure they can be implemented quickly. As far as possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented, and sometimes it will be necessary to implement the change with less testing due to time constraints. |
| Change Enablement |
Maintenance activity (MA) |
A discrete work block representing the actual activity required to complete a change. For all Normal changes there should be at least one MA. These are created by the change coordinator and completed by the change implementer(s). |
| Change Enablement |
Normal change |
These are changes that need to be scheduled, assessed, and authorized following a process. Change models based on the type of change determine the roles for assessment and authorization. Some normal changes are low risk, and the change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change. Other normal changes are quite significant and the change authority could be as high as senior leadership. Initiation of a normal change is triggered by the creation of a change request. |
| Change Enablement |
Request for change (RFC) |
A formal request to change one or more configuration items. |
| Change Enablement |
Standard change |
A low-risk, pre-authorized change that is well understood and fully documented, and which can be implemented without needing additional authorization. When the procedure for a standard change is created or modified, there should be a full assessment and authorization as for any other change. This risk assessment does not need to be repeated each time the standard change is implemented; it only needs to be done if there is a modification to the way it is carried out. |
| Incident Management |
Incident |
An unplanned interruption to a service or reduction in the quality of a service. |
| IT Asset Management |
IT Asset Management Practice (ITAM) |
The practice of planning and managing the full lifecycle of all IT assets (ITILv4). |
| Knowledge Management |
Content Owner |
The person responsible for the accuracy, usability, and information in a piece of managed content. |
| Knowledge Management |
Service Knowledge Management System(s) (SKMS) |
The SKMS is a central repository of data, information, and knowledge that an IT organization needs to deliver services. |
| Knowledge Management |
Content Type |
A category for describing a type of content in order to assign it appropriate access controls, retention policy, and review cycles. |
| [] |
High Severity |
A major incident with wide-reaching or severe consequences, such as an outage of a mission critical or critical service or its components. |
| [] |
Major Incident |
An unplanned interruption to a service or reduction in the quality of a service that requires an elevated level of response from the IT organization due to size or scope of their impact. |
| Measurement and Reporting |
CIO Dashbaord |
CIO dashboards display KPI in support of faster, better decision making. CIO dashboards must provide realistic, accurate, and actionable information to ensure the right decisions are made. Effective CIO dashboards link business functions and value to IT capabilities. Only then can you begin to understand the impact of IT investment decisions on the health and performance of your business. There are three specific issues that the ideal CIO dashboard must address. They must show business leaders not just the costs but the benefits of spending on IT; measure and communicate how IT is helping deliver agility; and make a direct connection between IT investments and customer satisfaction. |
| Measurement and Reporting |
SLA/SLR |
Service Level Agreement/Service Level Requirement. An SLR is a broad statement from a customer to a service provider describing their service expectations. A service provider prepares an SLA based on the requirements from the customer. Customer requirements (as a result of fulfilling customer business needs) are the basis for the service. By documenting the customer’s requirements, the SLR is produced. The SLR is made in the form of a document that will serve as the basis for the future SLA. The SLR should describe the service, i.e., how the service should deliver what was required by the customer (defined as warranty of the service), e.g., the capacity of the storage to satisfy the customer’s requirement for e-mail service. (See also: Service Level Agreement (SLA) in the Service Level Management practice glossary.) |
| Measurement and Reporting |
AOP |
Annual Operating Priorities. |
| Measurement and Reporting |
CSF/SLO |
Critical Success Factor/Service Level Objectives. A CSF is a critical factor or activity required for ensuring the success of a company or an organization. A service-level objective (SLO) is a key element of a service-level agreement (SLA) between a service provider and a customer. SLOs are agreed upon as a means of measuring the performance of the Service Provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding. A necessary precondition for the achievement of intended results (ITILv4 definition). |
| Measurement and Reporting |
CTQ |
Critical to Quality; these are the key attributes of a product or service that your customers have defined as being important. |
| Measurement and Reporting |
Time-to-value |
Period between information generation and improvement from decisions based on that information. |
| Measurement and Reporting |
KPI |
Key Performance Indicator. An important metric used to evaluate the success in meeting an objective (ITILv4 definition). Key performance indicators define a set of values against which to measure. These raw sets of values, which can be fed to systems that aggregate the data, are called indicators. There are two categories of measurements for KPIs. 1. Quantitative facts without distortion from personal feelings, prejudices, or interpretations presented with a specific value – objective- preferably numeric measured against a standard. 2. Qualitative values based on or influenced by personal feelings, tastes, or opinions and presented as any numeric or textual value that represents an interpretation of these elements. |
| Portfolio Management |
IT Service |
A service based on the use of information technology (ITILv4). |
| Portfolio Management |
Service |
A means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks (ITILv4). Services are typically not named after specific products or applications. Multiple related services are grouped in a service category. Examples of services appearing in a communication and collaboration service category might include collaboration, conferencing, and e-mail and calendaring. |
| Portfolio Management |
Service Portfolio |
A complete set of products and services that are managed throughout their lifecycles by an organization (ITILv4). |
| Problem Management |
Incident root cause |
An underlying issue that made an incident, or multiple incidents, occur. |
| Problem Management |
Known error |
a KB article or other documentation about a problem that has a known root cause. These articles are created and managed in the TDX knowledgebase and usually have instructions for what to do if the issue is encountered, including the documented workaround if there is one. When investigating incidents and problems, CIT staff may search the known errors to see if a solution or workaround already exists. |
| Problem Management |
Problem |
A cause, or potential cause, of one or more incidents (ITILv4) |
| Problem Management |
Workaround |
A workaround is temporary solution to a problem. It provides the ability to restore service (or partial service) for the customer, potentially through alternative means. Once an acceptable workaround is in place, associated incidents can be resolved. When a full resolution isn’t available, a workaround eliminates or reduces the impact of the issue. (ITILv3) A solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Some workarounds reduce the likelihood of incidents. (ITILv4) |
| Release Management |
Development Work Order |
A Work Order for the development or customization of an application or system, typically issued from Release Management. |
| Release Management |
Installation Work Order |
A Work Order for the installation of an application, system or infrastructure component, typically issued from Release Management. |
| Release Management |
Release |
A version of a service or other configuration item, or a collection of configuration items, that is made available for use (ITIL v4 definition). |
| Release Management |
Release Policy |
A set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact (see also: ITIL Checklist Release Policy). |
| Release Management |
Release Record |
A Release Record contains all details of a Release, documenting the history of the Release from the first planning stages to closure. |
| Release Management |
Release Unit |
A Release Unit is a set of new, changed and/or unchanged Configuration Items, which are tested and introduced into the live environment together to implement one or several approved Changes. |
| Service Configuration Management |
Asset Register |
A database or list of assets, capturing key attributes such as ownership and financial value. The term asset is typically used within the financial space to understand assets associated with costs. Assets are just one type of a CI.An inventory of IT Assets that need to be tracked; this inventory should be able to be referenced by the service configuration database for service dependency mapping. |
| Service Configuration Management |
Configuration Item (CI) |
Any component that needs to be managed in order to deliver an IT service (ITILv4). |
| Service Configuration Management |
Configuration Management Database (CMDB) |
A database used to store configuration records throughout their lifecycle. The CMDB also maintains the relationships between configuration items. (ITILv4) |
| Service Configuration Management |
Configuration Management System (CMS) |
A set of tools, data, and information that is used to support service configuration management (ITILv4). |
| Service Configuration Management |
Configuration Record |
A record containing the details of a configuration item (CI). Each configuration record documents the lifecycle of a single CI. Configuration records are stored in a configuration management database. (ITILv4) |
| Service Configuration Management |
Configuration Type |
A category applied to similar configuration items (assets) to represent them in logical groups, with meta-data fields/attributes that apply to assets/CIs of that type. |
| Service Configuration Management |
IT Asset |
Any financially valuable component that can contribute to the delivery of an IT product or service (ITILv4). |
| Service Configuration Management |
Service Configuration Management Practice |
The practice of ensuring that accurate and reliable information on all service and service offerings, and ensuring that it is available to the relevant audience (ITILv4). |
| Service Catalog Management |
Product/Service Portfolio |
The complete set of services that is managed by a service provider. The service portfolio is used to manage the entire lifecycle of all services, and includes three categories: service pipeline (proposed or in development), service catalog (live or available for deployment), and retired services.
The product/service portfolio is the complete set of products and/or services that are managed by the organization, and it represents the organization’s commitments and investments across all its customers and market spaces. It also represents current contractual commitments, new product and service development, and ongoing improvement plans initiated as a result of continual improvement. The portfolio may also include third-party products and services, which are an integral part of offerings to internal and external customers. |
| Service Catalog Management |
Service Catalog |
A database or structured document with information about all live IT services, including those available for deployment. The service catalog is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business; and supporting services required by the service provider to deliver customer-facing services.
An IT service catalog is a subset of an enterprise service catalog and is defined by the Information Technology Infrastructure Library Service Design to be an exhaustive list of IT-only services that an organization provides or offers to its employees or customers. The catalog is the only part of the Service Portfolio that is published to customers and is used to support the sale and/or delivery of IT services. |
| Service Catalog Management |
Service Offerings |
A formal description of one or more services, designed to address the needs of a target consumer group. A service offering may include goods, access to resources, and service actions. |
| Service Catalog Management |
Service |
A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.
Services are typically not named after specific products or applications. Multiple related services are grouped in a service category. Examples of services appearing in a communication and collaboration service category might include collaboration, conferencing, and e-mail and calendaring. |
| Service Continuity Management |
Business Continuity Plan (BCP) |
is a document that outlines how a business will continue operating during an unplanned disruption of service. |
| Service Continuity Management |
Business Continuity Planning |
the process of creating systems of prevention and recovery to deal with potential threats to a company. In addition to prevention, the goal is to enable ongoing operations before and during execution of disaster recovery. |
| Service Continuity Management |
Business Impact Analysis (BIA) |
A key activity in the practice of service continuity management that identifies vital business functions (VBFs) and their dependencies. These dependencies may include suppliers, people, other business processes, and IT services. BIA defines the recovery requirements for IT services. These requirements include RTOs, RPOs, and minimum target service levels for each IT service. |
| Service Continuity Management |
Disaster |
A sudden unplanned event that causes great damage or serious loss to an organization. It results in an organization failing to provide critical business functions for some predetermined minimum period of time. (The Business Continuity Institute) |
| Service Continuity Management |
Disaster recovery (DR) plans |
A set of clearly defined plans related to how an organization will recover from a disaster/service disruption as well as return to a pre-disaster condition; considering the four dimensions of service management: Organizations & people, Information & technology, partners & suppliers, value streams & processes. |
| Service Continuity Management |
Recovery Point Objective (RPO) |
The point to which information used by an activity must be restored to enable the activity to operate on resumption. |
| Service Continuity Management |
Recovery Time Objective (RTO) |
The maximum acceptable period of time following a service disruption that can elapse before the lack of business functionality severely impacts the organization. This represents the maximum agreed time within which a product or an activity must be resumed, or resources must be recovered. |
| Service Level Management |
Memorandum of Understanding (MOU) |
A document describing the broad outlines of an agreement that two or more parties have reached. |
| Service Level Management |
Operational Level Agreement (OLA) |
A contract that defines how various IT Groups within a company plan to deliver service or a set of services. This type of agreement is between and IT service provider and another part of the same organization. An underpinning contract is with a third party and supports delivery of an IT service to a customer. |
| Service Level Management |
Service Level Agreement (SLA) |
An agreement between a vendor/supplier and a customer; this term also gets used in service management suites as the measurable target applied to tickets in order to meet contractual agreements at a tactical level. (See also: SLA/SLR in the Metrics & Reporting practice glossary.) |
| Service Level Management |
Service Level Expectations (SLE) |
A document defining the terms and definitions of a service, includes service level targets, responsibilities, and costs. |
| Service Level Management |
Service Level Targets (SLT) |
Response and resolution targets applied in the ticketing system as outlined in service level agreements and expectation documents. |
| Program Management |
ITSM Program |
A number of projects, processes and activities that are planned and managed together to achieve an overall set of related objectives and other outcomes as related to the management of IT services. |
| Program Management |
ITSM Program Manager |
The person who is held accountable for ensuring that the right processes and service management practices are in place for the organization, oversees the program’s road map, process maturity, and evaluates program to ensure that it provides expected value to the organization in meeting its goals and compliance requirements. |
| Program Management |
ITSM Steering Committee |
A group of cross-division representatives and advisers who have been asked to govern the service management program and provide it with direction, Chaired by the program manager the committee is consulted on program, process, resource, tool, and communication decisions. The committee decides on improvement priorities and makes recommendations as to practical implementation and oversight strategies. |
| Program Management |
Policy |
Formally documented management expectations and intentions, used to direct decisions and activities. (ITILv4) |
| Program Management |
Practice |
A set of organizational resources designed for performing work or accomplishing an objective. (ITILv4) |
| Program Management |
Procedure |
A documented way to carry out an activity or a process. (ITILv4) |
| Program Management |
Process |
A set of interrelated or interacting activities that transform inputs into outputs. A process takes one or more defined inputs and turns them into defined outputs. Processes define the sequence of actions and their dependencies. (ITILv4) |
| Program Management |
Process Coordinator |
A process coordinator oversees the day to day operations of a process and its procedures across the organization to ensure that the process is followed and that process users know how to perform daily associated tasks. |
| Program Management |
Process Owner |
The person who is held accountable for ensuring that a process is fit for purpose. The process owner's responsibilities include sponsorship, design, managing process changes and continual improvement of the process and its metrics. |
| Program Management |
Service Line Owner |
A service line owner oversees the strategic direction of a service line to ensure that services deliver value to the organization; services are grouped into service lines to ensure value without duplication across the organization. |
| Program Management |
Service Management |
A set of specialized organizational capabilities for enabling value for customers in the form of services. (ITILv4) |
| Program Management |
Service Delivery Manager |
The person responsible for the technical delivery of the currently offered service on a daily basis. This resource oversees the key functions within the IT department and ensures that service level targets are met by coordinating service support and ensuring that procedures are in place to meet the service level agreements as outlined by the service owner. They are responsible for overseeing the support delivered by all support teams involved in the support model for the service. |
| Program Management |
Service Owner |
The service owner is the individual is responsible for a service throughout its service lifecycle; this resource may be a CIT resource, a business functional resource, or a unit IT resource. The service owner is accountable for the service within the organization regardless of where the technology components or professional capabilities reside. This person is responsible for outlining service levels and planning for future improvements to service offerings. |
| Program Management |
Operating Model |
An operating model refers to the way in which an organization structures and manages its key components to deliver value. It encompasses the fundamental elements that define how an organization operates, including its processes, structure, people, technology, and culture. The operating model provides a blueprint for how an organization's resources are organized and utilized to execute its business strategy and deliver products or services. |
| Service Request Management |
Service Request |
A request from a user or a user's authorized representative that initiates a service action which has been agreed as a normal part of service delivery. |
| Portfolio Management |
Service |
Business capabilities at a high level; intangible. Designed by the service provider to meet a customer's needs or support their business processes. It is the means by which value is delivered to the customer without the ownership of specific costs or risks. Services are typically described in terms of outcomes or benefits they provide to customers. Characterized by utility (fit for purpose; the functionality provided) and warranty (fit for use; how well it functions). Services can range from basic customer support to complex business process outsourcing. |
| Portfolio Management |
Service Offering |
Specific package or bundle that a service provider presents to customers. It outlines the features, functionalities, and terms of delivery for a particular set of services. Service offerings are often tailored to meet the diverse needs and preferences of different customer segments. Designed based on customer requirements, market demand, and the service provider's capabilities. It may include various service levels, pricing options, service level agreements (SLAs), and other terms and conditions. |
| Portfolio Management |
Product |
Tangible or intangible entity developed by a service provider to support the delivery of services or to enable customers to achieve specific objectives. Products often include software applications, hardware devices, tools, or platforms that facilitate service delivery. Serve as enablers for delivering services efficiently and effectively. They may be developed in-house or procured from external vendors. |