Service Management Glossary
Jump to terms beginning with:
A defined search using the "Advanced Search" functionality where the user may set search parameters and search criteria.
See... Availability Management Database
The user who is currently assigned to a document. This is the user who is responsible for the Knowledge Document. The Assignee can be changed at any time.
Details that uniquely identify Configuration Items (CIs), such as location, version number, serial number, etc.
Any user who creates a new Knowledge Document. Upon creation, the "Owner" and "Assignee" fields automatically populates. Owner and Assignee can be changed but Author cannot. The Author does not have be the person who actually writes the Knowledge Document.
An automated means of collecting hardware and software details for populating the Configuration Management Database. This is
accomplished in both an agent-based or agentless method. Items collected can include, but are not limited to, CPU size, memory,
application version, and relationships between components.
Automated Standard Change (ASC)
A Change that not only meets the requirements of a Standard Change, but is also scheduled to reoccur on a daily or weekly basis.
Examples of these Changes are daily server reboots that are performed as part of a Problem Management (PM) workaround.
Go to the Change Management Process Summary> for details on Change categories.
Availability Management (AVM)
A component of ITIL Service Delivery. The goal of Availability Management is to optimize the ability of the IT infrastructure,
Service and support organization in their effort to deliver a cost-effective and sustained level of availability that enables the
business to meet its objectives.
Availability Management Database (AMD)
A unified or federated repository of data and information required to support key activities, such as report generation,
statistical analysis, and availability forecasting.
See... Availability Management
back to top
See... Business Impact Analysis
An internal message created and displayed within the ITSM system for the purpose of alerting support staff to significant
issues. See the Broadcast Policy for specific details.
Business Capacity Management
Part of the ITIL Capacity Management process. The focus of Business Capacity Management is to ensure that the future business
requirements for IT service are considered and understood, and that sufficient capacity to support the service is planned and
implemented in an appropriate time frame.
Business Impact Analysis (BIA)
The purpose of a BIA is to assess how much the organization stands to lose as a result of a disaster or other service disruption,
as well as the speed of escalation of these losses. This is done through identification of critical business processes and
potential damage or loss that may be caused to the organization as a result of such a disruption.
back to top
A component of ITIL Service Delivery. Capacity Management is comprised of three sub-processes: Business Capacity Management,
Service Capacity Management, and Resource Capacity Management. The goal of Capacity Management is to understand the business
required, the organizational operation, and the IT infrastructure, and to ensure that current and future capacity and performance
business requirements are met cost effectively.
CCTA Risk Analysis Management Methodology (CRAMM)
A process for identifying justifiable countermeasures to protect confidentiality, integrity, and availability. (CCTA stands for
the Central Computer and Telecommunications Agency and was a UK government group that helped develop the ITIL library. CCTA is now
part of the UK Office of Government Commerce, or OGC.)
The addition, modification or removal of an authorized service or service component and its associated documentation.
See... Component Failure Impact Analysis
Change Classification (Change Type)
The Change Classification or Change Type determines the process flow that will be followed for a particular change. Options include Normal, Standard, Emergency and Latent. Go to the Change Management Process Summary for details.
The person responsible for implementing some or all of an approved Request for Change (RFC).
The person who requests a Change.
The goal of the Change Management process is to ensure that standardized methods and
procedures are used for efficient and prompt handling of all Changes in order to minimize the Impact of Change-related Incidents
upon Service quality, and consequently improve the day-to-day operations of the organization. Go to the Change Management Process Summary for
details on Change Management.
The Change Manager is the person who with oversight responsibility and accountability for the Change Requests assigned to their Support Group.
Change Management Process Manager
The Change Management Process Manager is responsible for the overall operation of the Change Management Process throughout ITS.
See... Configuration Item
See... Incident Classification, Problem Classification, or Change Category.
See... Configuration Management Database
Component Failure Impact Analysis (CFIA)
During the design for availability activities, a report that predicts and evaluates the Impact on IT Service availability arising
from component failures within the proposed IT infrastructure and Service design.
Configuration Item (CI)
A component of an infrastructure or an item, such as a Request for Change (RFC), associated with an infrastructure, that is, or
will be, under the control of Configuration Management.
Configuration Item Level (CI Level)
The degree of detail selected to describe each Configuration Item (CI).
A component of ITIL Service Support. The goal of Configuration Management is to identify, record, and report on any IT component
that is under the scope and control of Configuration Management.
Configuration Management Database (CMDB)
A unified or federated repository of information related to all the components of an information system. It helps an organization
to understand the relationships between these components and track their configuration. Go to itSMF - An Introductory Overview of
ITIL for more information on CMDBs.
See...CCTA Risk Analysis Management Methodology
back to top
Definitive Hardware Store (DHS)
An area set aside for the secure storage of spare hardware.
Definitive Software Library
A secure software compound where all authorized versions of software are kept.
Only the Configuration Items (CIs) within the Release unit that have changed or are new since the last Full or Delta Release.
See... Definitive Hardware Store
back to top
A Change request that needs to be implemented prior to the review / approval process as defined by the Change Management process. A Change is deemed an emergency if it is being introduced in response to a service disruption or an imminent service disruption to a production service.
Normally a release containing the corrections to a small number of Known Errors.
The person who is using the hardware or software in question. End users contact ITS with Incidents or Service Requests. End users
can be ITS employees, if they are using a system supported by Service Management.
An Alert or notification created by an IT Service, CI or monitoring tool. Events typically require IT Operations personnel to take
actions, and often lead to incidents being logged
The process responsible for managing events throughout their lifecycle.
back to top
The function responsible for managing the physical environment where the IT infrastructure is located. Facilities Management
includes all aspects of managing the physical environment, for example power and cooling, building access management, and
All components of the Release unit are built, tested, distributed, and implemented together.
back to top
See... Service Desk
back to top
See... Incident Management
When assessing Impact, it is expected that all components related to the Service are identified and that Impact is assessed on the
business and IT performance. This often requires consideration of the number of users effected by the issue. Change Management is
not responsible for identifying the components and assessing Impact, only ensuring that it is done. The identification of Impacted
areas is the responsibility of Configuration Management. Assessing the Impact on Business and IT Performance is conducted by
Capacity Management. Go to the Change Management Process Summary for details on Change Impact levels.
An event that is not part of the standard operation of a Service and that causes, or may cause, an interruption to, or reduction
in, the quality of Service.
The Incident Assignee role is the Support Group member or individual responsible for doing the work involved in resolving an
Incident, Service Request, or Infrastructure Event. The Incident Assignee is responsible for ensuring that all work regarding the
incident meets ITS standards. Unlike the Incident Owner, the Incident Assignee will not have the ability to move an Incident
record to a status of “Closed,” but will use the status of “Resolved” to indicate that the work has been completed. Additionally,
the Incident Assignee that is responsible for the resolution of the Incident is responsible for ensuring that a Knowledge
Management (KM) document is created or updated, as necessary.
Incident Classification is accomplished by determining the Impact and Urgency, Service Type, Service and Configuration Item (CI) values.
In Incident Management (IM), the Incident Initiator is the individual who creates the Incident and starts the IM process.
Details the various stages of an Incident from beginning to restoration. Includes detection, diagnosis, repair, recovery, and
restoration. Go to the Tier I and Tier II ITS Support OLA for more information on the Incident Lifecycle.
Incident Management (IM)
A component of ITIL Service Support. The goal of the IM process is to restore normal Service as quickly as possible and to
minimize the adverse Impact of the Incident on business operation. The IM process is not necessarily concerned with finding the
root cause of the issue. Instead, the objective is to get the end user back up and running as quickly as possible. Go to the ITIL
Process Overviews for details on the IM process.
Incident Management Process Manager
See... Incident Manager
Incident Management (IM) Support Group
Support Groups are used in IM as a means of organizing staff members into logical groups for the purpose of managing and organizing end user support. For example, the ITS_Service_Desk_Tier 1, ITS_Data_Center_Operations, and all Tier III teams are considered Support Groups. They are used for assignment, escalation, and notification purposes.
Incident Management (IM) Support Group Administrator
In general, the Support Group Administrators will manage the membership and availability of the individual Support Groups within ITS.
The Support Group Administrator will monitor group membership and take necessary action to make modifications, as necessary. Additionally, the Support Group Administrator is responsible for the following: Making notifications regarding ITS service target requirements; playing a key role in managing the maintenance aspects of the KM documents. See the KM Process Document for details on the KM portion of the Support Group Administrator role.
The Incident Manager is responsible for the Incident Management (IM) process as well as for coordinating with the IM Process Owner
to ensure compliance, process maturity, and growth. Also for preparing management reports and conducting incident reviews. The
Incident Manager is responsible for ensuring that specific critical Incidents, Service Requests, or Events receive appropriate
handling and coordination with Problem Management (PM) or Change Management. When the Incident Manager is not available, the Unit
Manager must designate someone to fill this role. The Incident Manager is also referred to as the Incident Management Process
The Incident Owner is the Support Group member or individual ultimately accountable for ensuring that a specific Incident is satisfactorily completed through its lifecycle and that any service requirements are met. Unlike the Incident Assignee, the Incident Owner has the ability to move the incident record to the "Closed" status. Within the ITS IM process, there are two groups currently identified to fill this role. For Incidents and Service Requests, the ownership role will be filled by the ITS Service Center. For Infrastructure Events, the role will be filled by ITS Data Center Operations.
Information Technology Infrastructure Library (ITIL®)
ITIL is the most widely accepted approach to IT Service Management in the world. ITIL provides a cohesive set of best processes,
drawn from the international public and private sectors. ITIL is supported by a comprehensive qualifications scheme, accredited
training organizations, and implementation and assessment tools. The best-practice processes promoted in ITIL support and are
supported by the British Standards Institution's standard for IT Service Management (BS15000). (From the OGC ITIL Web site.)
Initiator scripts are used in Incident Management for the purpose of pre-defining specific questions that should be asked of the
customer on given incidents. They are made available by a combination of criteria such as support group membership, operation and
product catalog values.
See... Information Technology Infrastructure Library
ITSM is the authoritative software package use to facilitate and support the execution of the Incident, Problem, Change, and Knowledge Management processes within ITS.
back to top
When a Knowledge Document or topic is searched for, keywords are used to conduct a search for a similar topic or document already created. When creating a KM document, keywords can be added to improve the probability of locating a KM topic within the knowledge base.
See... Knowledge Management
The computerized collection, organization, and retrieval of knowledge. Within ITSM it is a collection of related experiences and their results, with the results related to problems and solutions.
A document that provides information that will help the end user resolve an incident. This may include a solution to a certain situation, a workaround, guidance to additional resources, or other information. Knowledge Documents can be stand-alone or may include attachments or links to supporting materials. Knowledge Documents reside within the KM system in ITSM and are searchable.
Knowledge Management (KM)
KKM is the process through which ITS will generate value from information that, when organized within the ITSM KM tool, will assist support staff to quickly respond to and resolve Incidents. The management of KM documentation will involve the creation, approval, and maintenance of KM documents. The KM process will support end users of ITS services and systems by providing access to a repository of searchable Incidents with solutions, instructions, and reference information to assist the end user with resolving issues.
Knowledge Management (KM) Coordinator
Oversees the general maintenance of the knowledge base. This includes sending Update Request to SGAs for scheduled reviews, responding to user Feedback, and processing requests for documents to be Retired and Cancelled.
Knowledge Management (KM) Process Manager
The KM Process Manager role is responsible for the KM process throughout ITS and for ensuring that the KM process supports the Service Desk staff, the Support Groups, the Incident Management (IM) processes, and the Problem Management (PM) processes.
Knowledge Management (KM) Support Group Administrator
Manages and monitors the Knowledge documents for his or her support group. This includes assigning and reviewing KM documents in ITSM.
There are 2 ways a Known Error record should be opened and recorded:
A Known Error does not “implement” the appropriate fix, but investigates what the fix should be. A Request for Change (RFC) may be raised to implement the proposed fix.
Known Error Assignee
The Known Error Assignee acts in a similar capacity as the Problem Assignee. This role is responsible for the continued
investigation associated with the Known Error. Refer to the Problem Management Process Summary for more details on the Known Error
back to top
- Problem that has a documented Root Cause OR when the cause of a problem is known.
- When a decision is made to release a product or service into a production environment that includes known deficiencies (open bugs or Testing Incidents (TI’s).
Maintenance done on systems from an internal focus. There are seven stages of Maintainability: anticipation of failure, detection
of failures, diagnosing of failures, resolution of failures, recovery from failures, restoration of the data and IT Service, and
the levels of preventive maintenance applied to prevent failures.
Normally containing a large area of new functionality, some of which may make intervening fixes to Problems redundant. A Major
Release or upgrade supersedes all preceding Minor and Emergency fixes.
A Maturity Assessment is the process of evaluating the maturity level of different aspects of implementation processes to identify
any strengths and weaknesses in the process and to recommend process improvements. In May of 2005, a maturity assessment was
conducted by Gartner recommending Incident Management (IM) and Problem Management (PM) across MAIS (now ITS).
Normally containing small enhancements and fixes, some of which may have already been issues as Emergency fixes. A Minor Release
or upgrade supersedes all preceding Emergency fixes.
back to top
See... Operating Level Agreement
Operating Level Agreement (OLA)
An internal agreement covering the delivery of Services that support the IT organization in their delivery of Services.
back to top
Includes at least two Releases. For example, a Delta Release and a Full Release may be grouped together.
See... Post Implementation Review
A Change handled in such a way that it meets the Change Management timelines required for analysis and approval. (Go to
Go to the Change Management Process Summary document for timeline information.) Planned Changes are often thought of as being proactively reviewed
and scheduled, thereby reducing the chance of Change-related Incidents and risk to the organization. Planned Changes include
Standard, Minor, Significant, or Major Changes.
See... Problem Management
Post Implementation Review (PIR)
Post Implementation Reviews are used to determine the effectiveness of an approved change based on established Change Management
policy. PIR’s are conducted via questionnaire and in-person meetings as needed, and may result in recommended improvements. Go to
the Go to the Change Management Process Summary for further details.
Priority is based on the Impact of the issue and the Urgency for the remedy. It is used to determine the sequence of activities.
Go to the Change Management Process Summary for details on Change Priority levels.
A Problem is an unknown underlying cause of one or more incidents, or from one single significant Incident, indicative of a single error, for which the cause is unknown.
The Problem Assignee is assigned by the Problem Coordinator and/or the Support Group Administrator. The Problem Assignee is responsible for leading the investigation, creating appropriate task assignments, and working with their Support Group Administrator and/or the Problem Coordinator to assess value in continued investigation.
Classification occurs by identifying what is driving the investigation, what the characteristics of the issue are and what service
or CI it is associated with. In ITSM this is accomplished by defining the "Investigation Driver," the Operational and Product
Manages and monitors the Problem records for the organization. This includes:
The Problem Initiator is the ITS staff member who initiates the Problem investigation.
Problem Management (PM)
A component of Information Technology Infrastructure Library (ITIL) Service Support. The goal of the PM process is to determine the root cause of Incidents to help eliminate or reduce the number of calls to the Service Center.
The difference between Incident Management and Problem Management is:
- Ensure Problem records progress through the Problem process in a timely and prioritized fashion
- Ensures that the information entered in the problem investigations and known errors are accurate and complete
- Periodically reviews problem investigations for which no root cause could not be found
The Problem Management process has both reactive and proactive aspects.
- Incident Management (IM) goal is to restore normal Service as quickly as possible
- Problem process is focused on performing root cause analysis and removing the Problem
Problem Management Process Manager
The Problem Management Process Manager role is Responsible for the overall Problem Management Lifecycle, including Continual Process Improvement throughout ITS and must coordinate with the Problem Coordinator and Support Group Admin(s) to ensure compliance, process maturity, and growth.
See... Incident Management Process Manager, Problem Management Process Manager, Knowledge Management Process Manager, or Change Management Process Manager.
The Process Owner role is responsible for maintaining full accountability for the Information Technology Infrastructure Library
(ITIL) process across the organization. For example, ITS has Process Owners for Change Management, Incident Management (IM),
Problem Management (PM), and Knowledge Management (KM). They are responsible for ensuring its viability, for championing the
process, and for assuring compliance with the policies. While Process Owners do not necessarily perform the work, they are 100
percent accountable for making sure that the works is completed.
Projected Service Availability (PSA)
A document containing details of changes to agreed Service Level Agreements (SLAs) and agreed serviceability due to currently
planned changes on the Forward Schedule of Change (FSC).
See... Projected Service Availability
back to top
- The reactive aspect is concerned with solving Problems in response to one or more Incidents.
- Proactive Problem Management Process is concerned with identifying and solving Problems and Known Errors before Incidents occur in the first place
Any process may have an interface with a separate, but defined, work process. We refer to that interfacing process as a Related
Relating to Configuration Items (CIs), a description of the interfaces that exist between Configuration Items (CIs) in the
Relating to ITSM, a connection between two ITSM records when Incidents, Problems, and Changes are caused by, fixed by, or
otherwise related to each other.
A component of the Information Technology Infrastructure Library (ITIL) Service Support. The goal of Release Management is to
provide a holistic view of Changes to an IT Service, and to ensure that all aspects of the Release, both technical and non-
technical, are considered together.
Defines the who, when, where, why, and how for Releases.
Describes the portion of the IT infrastructure that is normally released together. The unit may vary, depending on the types or
items of software and hardware.
Request for Change (RFC)
A document used to record details about a change requested via the Change Management Process.
Resource Capacity Management
Part of the Information Technology Infrastructure Library (ITIL) Capacity Management process. The goal of Resource Capacity
Management is to identify and understand the capacity and utilization of each of the component parts in the IT infrastructure.
Ensures the optimum use of the current hardware and software resources in order to achieve and maintain the agreed upon Service
Review, Ad hoc
A request for a review of a Knowledge Document. Usually the request results from the Feedback. This request is routed via the KM Process Coordinator.
A review that is set from the details screens. It concerns every document and the request routed to Support Group Manager
See... Request for Change
The underlying cause of an Incident or Problem.
back to top
Predefined scripts in ITSM are used in Incident Management (IM) to assist Tier I in the collection of initial support
Can be anything that has potential to disrupt business processes or inflict a negative Impact on business results. A Security
Incident is the materialization of a threat.
One or more IT systems that enable a business process.
Service Capacity Management
Part of the Information Technology Infrastructure Library (ITIL) Capacity Management process. The goal of Service Capacity
Management is to identify and understand the IT Services, their use of resources, working patterns, peaks and troughs, and to
ensure that the Services can and do meet their Service Level Agreement (SLA) targets.
Service Continuity Management (ITSCM)
A component of Information Technology Infrastructure Library (ITIL) Service Delivery. The goal of IT Service Continuity Management
(ITSCM) is to ensure that required IT technical and Service facilities can be recovered within the agreed and required time frame.
For ITS, many of the activities of the ITSCM processes are part of the Disaster Recovery and Business Continuity (DRBC) planning
Service Delivery (SD)
Consists of Service Level Management, Financial Management for IT Services, Capacity Management, and IT Service Continuity and Availability Management. These processes are principally concerned with developing plans for improving the quality of the IT
A component of the Information Technology Infrastructure Library (ITIL) Service Support. The goals of the Service Desk are to
provide a strategic single point-of-contact and to manage Incidents to resolution. In the ITIL framework, there are two processes
in an organization that communicate with customers and end users: Service Level Management and the Service Desk. At ITS, the
Service Desk process is carried out by the ITS Help Desk.
Service Improvement Program
A formal project undertaken within an organization to identify and introduce measurable improvements within a specified work area
or work process.
Service Level Agreement (SLA)
A written agreement between a Service provider and the customer(s) that documents agreed Service Levels for a Service.
Service Level Management
A component of the Information Technology Infrastructure Library (ITIL) Service Delivery. The goal of Service Level Management is
to maintain or improve Service quality and to meet customers' business objectives through an ongoing cycle of agreement,
monitoring, and reporting.
Any contact to the Service Desk about an event or need that is not a failure in the IT infrastructure. Service Requests may
include requests for information, moving equipment, requesting Configuration Items (CIs), and so on.
Service Support (SS)
The Service Support component of the Information Technology Infrastructure Library (ITIL) deals more with the day-to-day support
and maintenance processes of Incident Management, Problem Management, Change Management, Configuration Management and Release
Management plus the Service Desk function.
See... Service Delivery
A Significant Incident is one that has a significant impact on university operations by bringing a business process or service to a complete or potential stop. Incidents of this nature typically have a high Impact and Urgency value which assigns a Critical Priority to the incident
The Service Desk acts as a single point-of-contact for providing all first-line advice, guidance, and rapid restoration of normal
Service provision to customers.
A keyword search that returns Knowledge documents, Incident, Problem, and Known Error records
See... Service Level Agreement
See... Subject Matter Expert
See... Systems Outage Analysis
See... Knowledge document
See... Service Support
A Standard Change is a Change to the infrastructure that follows for an established path, is relatively common, and is the
accepted solution to a specific requirement or set of requirements. It is a documented and repeatable Change. A Standard Change
introduces minimal risk and Impact to the business of the University. The work instructions for executing the
Change must be fully documented. The testing requirements and any back out or contingency plans must be included in the
Subject Matter Expert (SME)
SMEs are any ITS Support Group member who contributes in-depth knowledge and input into the content of a Knowledge Management (KM) document. The SME ensures that the content is accurate and complete. SMEs review and respond to Incidents. KM will require that SMEs write, edit, and review assigned KM documents. Sometimes the author of a document will also be the SME.
Support Groups are used in Service Management as a means of organizing staff members into logical groups for the purpose of
managing and organizing end user support. (For specific information about how Support Groups operate for Incident Management (IM),
Knowledge Management (KM), and Problem Management (PM), refer to the IM, KM, or PM Process Summary documents.)
Support Group Administrator
For Service Management purposes, a Support Group Administrator is someone who leads a Support Group, manages group membership and
availability, ensures compliance with Operating Level Agreements (OLAs), and manages workflow and distribution of Knowledge
Management documents within the Support Group. Refer to the detailed description of the Support Group Manager role.
Systems Outage Analysis (SOA)
A structured approach to identify end-to-end availability improvement opportunities that deliver benefits to the user. Many
activities involved in the SOA are closely aligned with those of Problem Management. Note: ITS also uses the acronym "SOA" to
denote "Service Oriented Architecture".
back to top
The Task Assignee is responsible for completing the assigned task. As an example, a Task Assignee may be responsible for
investigating CPU utilization as part of a Problem Investigation. In Change Management, a Task Assignee may be asked to execute
one step or task within a Change request.
The Team Representatives are responsible for ensuring that the Knowledge Management (KM) process is working in their division.
This includes ensuring that their staff are performing the KM-related tasks they are responsible for within their division. The KM
Team Representatives will be required to take a broad view of the KM process for ITS and participate in decisions regarding KM
(standards, etc.). KM Team Representatives will be required to participate in monthly KM Team meetings to participate in
collaborative discussions impacting the KM process. Go to the KM Process Summary for details on the Team Representative role.
In Incident, Problem, Change, and management of people records, a template is used in ITSM to facility the pre-population of
fields. In Knowledge Management, the templates provide structure to solution entry types such as "how to" and "error."
back to top
See... Emergency Change.
Urgency is a representation of how quickly the issue must be resolved. Urgency is one element in determining Change Priority. It
may be equated to the business criticality of the issue depending on where the University is in the business cycle. (Go to the
Change Management Process Summary for details on Change Urgency levels.
back to top
Visibility Groups are used in ITSM Knowledge Management (KM) to restrict access to knowledge base content. Access must be
assigned by an administrator. Two visibility groups will exist: Internal and Self-Help. The Internal visibility group will include
all ITS Support Group members, and initially, be the only visibility group active in ITSM. The Self-Help visibility group
refers to end user access to KM documents.
Vital Business Function
The element of a business process supported by an IT Service and considered business-critical.
back to top
In ITSM, Watch List provides notification of changes in a KM document's status (e.g., updates, deletions). All ITS Support Group members can identify specific documents in which they wish to monitor and receive notifications regarding status.
back to top