A formal evaluation of a specified service or deliverable for the purposes of securing acceptance, usually conducted with representatives of the customer/user of the service.

A cost that can be associated directly with a specific activity, service, or product and which varies  with the output of that activity, service, or product.  See also Indirect Cost.

Architecture which addresses environmental factors relevant to provision of a service.  Data centers, for example are routinely architected to take advantage of energy, solar exposure, cooling, etc. factors.

The ability of a something (e.g. a service or Configuration Item) to create value by supporting or increasing the performance of an asset.

The ability of a something (e.g. a service or Configuration Item) to create value by operating at agreed levels of availability, capacity, continuity, and security.

A schedule that contains details of all approved changes and their proposed implementation dates.

A pre-defined set of steps for responding to an incident that has been seen before.  Incident Models typically cover workarounds, communication, risk management, escalation, etc.

The fundamental structure of and relationships between the data/information elements supporting a service.

Anything required for a process to operate and which contributes to generation of process output.

 

The defined interaction between two components, processes, services, Configuration Items, etc.

Procedural inormation, derived from other information and data, useful for specifying ways of achieving objectives.

Individual readings or samplings of performance taken according to defined metrics (specifications of what and how to take measurements).

A definition or specification of what to measure and how to take a particular measurement.

Cost resulting from running an IT Service.  Includes such items as staff costs, hardware, software, maintenance, electricity, etc.

A workload profile of one or more business activities.  Used in Demand Management.  Patterns of Business Activity are used to help the IT Service Provider understand and plan for different levels of business activity.

The activity responsible for managing effort around investigaion of the root cause of incidents.

The role accountable for management of the Problem Managemen process.  The Problem Manager may also be the owner of the Problem Manager process.

The process responsible for ensuring that the quality of a product, service or process will provide its intended value.

The sub-process or aspect of Problem Management charged with assisting with resolution of events and errors as they occur.

A Document containing the results or other output from a Process or Activity. Records are evidence of the fact that an activity took place and may be paper or electronic. For example, an audit report, an Incident Record, or the minutes of a meeting.

Duplication of a Configuration Item, service, process, etc. for the purpose of safeguarding levels of warranty or performance.  See Fault Tolerance.

The process responsible for supporting the success of authorized releases (bundles of changes) into the live environment.  Release and Deployment Management may involves planning, communications, release definition, acceptance, etc.

The activity within Release and Deployment Management responsible for determining the schedule, roles, activities, and content of specific releases.

Components of an IT Service that are normally Released together. A Release Unit typically includes sufficient components to perform a useful Function. For example, one Release Unit could be a Desktop PC, including Hardware, Software, Licenses, Documentation, etc.

A measure of how long a Configuration Item or IT Service can perform its agreed Function without interruption. Usually measured as MTBF (Mean Time Between Failure) or MTBSI (Mean Time Between System Interruptions). The term Reliability can also be used to state how likely it is that a Process, Function, etc. will deliver its required outputs.

A measure of the time taken to complete an Operation or Transaction. Used in Capacity Management as a measure of IT Infrastructure Performance, and in Incident Management as a measure of the time taken to acknowledge a user request for assistance.

Action taken to return an IT Service to normal operation after Repair and Recovery from an Incident. This is the primary Objective of Incident Management.

Uncertainty of outcome.

The initial steps of Risk Management. Risk analysis includes identification of assets, vulnerabilities associated with those assets, threats which might exploit specific vulnerabilities, and probabilities that specific threats will be realized.

The fundamental or original cause of a problem or error.

The fundamental structure of a service including its relationship to other supporting and dependent services.

The process responsible for managing both the financial attributes (information) and the configuration attributes of items involved in the delivery of a service.

The Activity responsible for understanding and managing capacity at a service level, e.g. as opposed to a component or business level.  Service Capacity Management is concerned with the end-to-end capacity of a given service.

A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is normally the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

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.

The primary role responsible for operational management of the Service Desk.

A model used during Service Strategy to identify market opportunities not already met by existing services.

A formal Plan to implement improvements to a Process or IT Service.  The SIP is one of the primary outputs of both Service Level Reviews and of Continual Service Improvement.

A set of tools and databases that are used to manage knowledge and information about services. The SKMS includes the Configuration Management System, as well as other tools and databases. The SKMS stores, manages, updates, and presents all information that an IT Service Provider needs to manage the full Lifecycle of IT Services.

A specific requirement for an aspect of an IT Service. SLRs are based on Business Objectives and are used to draft and negotiate agreed Service Level Targets.  Service Level Requirements may apply to either customers or providers.

A specific commitment that is documented as part of a Service Level Agreement. Service Level Targets are based on Service Level Requirements, and are needed to ensure that the IT Service design is Fit for Purpose. Service Level Targets should be measurable and are usually based on KPIs.

The role accountable for the performance of all services offered by a Service Provider.

The role accountable for the delivery and performance of a specific service.

A bundle consisting of one or more services and the Service Level Package which describes the performance levels under which the services will be delivered.

A database or structured Document listing all IT Services that are under consideration or Development, but are not yet available to Customers. The Service Pipeline provides a business view of possible future IT Services and is part of the Service Portfolio not normally published to Customers.

The Process responsible for managing the Service Portfolio. Service Portfolio Management governs the procedures by which services are modeled, evaluated, and recorded in the Service Portfolio.

The role accountable for management of the Service Portfolio.

An organization supplying Services to one or more internal or external Customers. Service Provider is often used as an abbreviation for IT Service Provider. See also Type I Service Provider, Type II Service Provider, Type III Service Provider.

A request from a user for information, advice, a standard change, or access to an IT service.  Service Requests do not include requests for incident support.

The title of one of the five core ITIL volumes and a stage in the Service Lifecycle.  Service Strategy is also the name of a specific process within the Service Strategy lifecycle phase.  The purpose of Service Strategy is to manage investments in IT services and to establish an overall Strategy for IT Service Management.

The title of one of the five core ITIL volumes and a stage in the Service Lifecycle.  The purpose of Service Transition is to faciltate the introduction of new and changed services into the live environment.

The ability of an asset, service, or Configuration Item to be supported by a third-party supplier as a means of ensuring its agreed levels of Availability, Reliability, Security, etc.

A Service Provider which offers services to multiple business units wtihin a single organization.

A technique involving creation of a detailed model to predict the behavior of a Configuration Item or IT Service.  Simulation Models can be very accurate but are expensive and time consuming to create.  A Simulation Model is often created by applying artificial workloads to actual Configuration Items.  They are used in Capacity Management when accurate results are important.

The current state of a Configuration Item or the performance of a Configuration Item as captured by a discovery tool or measurement tool. Also used as a synonym for Benchmark. See also Baseline.

All people who have an interest in an Organization, Project, IT Service, etc.  Stakeholders may be interested in the Activities, targets, Resources, or Deliverables. Stakeholders may include Customers, Partners, employees, shareholders, owners, etc.

The operational condition of a service asset or record.  Status is used to describe the position of the item within its defined lifecycle.  Services, for example, might be described as having status options such as proposed, defined, evaluated, approved, chartered, designed, built, tested, etc.

The activity responsible for determining, recording, and reporting the operational condition of Configuration Items, services, etc.

A framework or collection of decisions intended to support the long term success and growth of an entity or organization.

A third party responsible for supplying goods or Services that are required to deliver IT services. Examples of suppliers include commodity hardware and software vendors, network and telecom providers, and outsourcing Organizations.

The process responsible for ensuring that Contracts with Suppliers support the needs of the Business, and that all Suppliers meet their contractual commitments.

A number of related things that work together to achieve an overall objective.

The fundamental organization of infrastructure or technical components related to a system or service.

A temporary team of technical support staff convened to monitor the behavior and performance of an IT Service and make recommendations for improvement.  Technical Observation Posts are one of the techniques used in Continual Service Improvement, Problem Management, and Availability Management.

The portion of the Service Catalog containing services that support business services, but which are generally not themselves accessed directly by users and customers.  

A set of related Metrics, in which improvements to one metric have a negative effect on another metric. Tension Metrics are designed to ensure that an appropriate balance is achieved.

The pre-defined value of a metric that should trigger an alert or cause management action to be taken.

Any change in the state of an IT service or other asset.

A contract between an IT Service Provider and a third party. The third party provides goods or Services that support delivery of an IT Service to a Customer.  The Underpinning Contract defines targets and responsibilities that are required to meet agreed Service Level Targets in an SLA.

Any entity that consumes a service.  Users are distinct from Customers, as some Customers do not use the IT Service directly.

Functionality offered by a Product or Service to meet a particular need. The Utility of a service may be best understood as ‘what the service does’.

A linear sequence of processes or entities that together create a product or service of value to a Customer.  Each step of the sequence builds on the previous steps and contributes to the overall product or Service.

An informal measure of Cost Effectiveness.  Value for Money is often based on a comparison with the Cost of alternatives.

The difference between a planned value and the actual measured value.  Commonly used in Financial Management, Capacity Management and Service Level Management, but could apply in any area where Plans are in place.

An activity that ensures a new or changed IT Service, Process, Plan, or other Deliverable is complete, accurate, Reliable and matches its design specification. See also Acceptance.

A clearly defined and numbered release.  Version is used to identify a specific Baseline of a Configuration Item. Versions typically use a naming convention that enables the sequence or date of each Baseline to be identified.  For example, "Payroll Application Version 3" contains updated functionality from Version 2.

The most comprehensive and highly level description of an intended future state of a thing.  Vision is usually defined by the top-level management responsible for the thing in question.

The business-critical element of a business process.

A weakness that could be exploited by a Threat. For example an open firewall port, a password that is never changed, or a flammable carpet.  A missing Control is also considered to be a Vulnerability.

A type of notification that acknowledges that the pre-determined threshold for operation or performance has been exceeded.

Explanatory, strategic, or justificatory information.  Wisdom is the highest level in the DIKW Knowldge Management hierarchy and generally provides guidance as to 'why' specific actions are or are not taken.

A predefined technique for reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available.  For example, a workaround may consist of restarting a failed Configuration Item to restore service without addressing the reason for its failure.  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.