ITS Administrative Computing

Systems

Services

System Overviews

Help


Password Reset

Submit a service request online

Service Management Glossary

Jump to terms beginning with:

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z 


Advanced Search
A defined search using the "Advanced Search" functionality where the user may set search parameters and search criteria.
AMD
See... Availability Management Database
Assignee
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.
Attributes
Details that uniquely identify Configuration Items (CIs), such as location, version number, serial number, etc.
Author
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.
Auto Discovery
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.
AVM
See... Availability Management
back to top

BIA
See... Business Impact Analysis
Broadcast Message
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

Capacity Management
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.)
Change
The addition, modification or removal of an authorized service or service component and its associated documentation.
CFIA
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.
Change Implementer
The person responsible for implementing some or all of an approved Request for Change (RFC).
Change Requester
The person who requests a Change.
Change Management
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.
Change Manager
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.
CI
See... Configuration Item
Classification (Classify)
See... Incident Classification, Problem Classification, or Change Category.
CMDB
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).
Configuration Management
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.
CRAMM
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.
Delta Release
Only the Configuration Items (CIs) within the Release unit that have changed or are new since the last Full or Delta Release.
DHS
See... Definitive Hardware Store
back to top

Emergency Change
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.
End User
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.
Event
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
Event Management
The process responsible for managing events throughout their lifecycle.
back to top

Facilities Management
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 environmental monitoring.
Full Release
All components of the Release unit are built, tested, distributed, and implemented together.
back to top

Help Desk
See... Service Desk
back to top

IM
See... Incident Management
Impact
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.
Incident
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.
Incident Assignee
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
Incident Classification is accomplished by determining the Impact and Urgency, Service Type, Service and Configuration Item (CI) values.
Incident Initiator
In Incident Management (IM), the Incident Initiator is the individual who creates the Incident and starts the IM process.
Incident Lifecycle
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.
Incident Manager
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 Manager.
Incident Owner
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 Script
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.
ITIL
See... Information Technology Infrastructure Library
ITSM
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

Keyword
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.
KM
See... Knowledge Management
Knowledge base
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.
Knowledge Document
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.
Known Error
There are 2 ways a Known Error record should be opened and recorded:
  1. Problem that has a documented Root Cause OR when the cause of a problem is known.
  2. 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).
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 Assignee role.
back to top

Maintainability
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.
Major Release
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.
Maturity Assessment
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).
Minor Release
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

OLA
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

Package Release
Includes at least two Releases. For example, a Delta Release and a Full Release may be grouped together.
PIR
See... Post Implementation Review
Planned Change
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.
PM
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
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.
Problem
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.
Problem Assignee
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.
Problem Classification
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 catalog values.
Problem Coordinator
Manages and monitors the Problem records for the organization. This includes:
  • 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
Problem Initiator
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:
  • 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
The Problem Management process has both reactive and proactive aspects.
  • 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
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.
Process Manager
See... Incident Management Process Manager, Problem Management Process Manager, Knowledge Management Process Manager, or Change Management Process Manager.
Process Owner
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).
PSA
See... Projected Service Availability
back to top

Related Process
Any process may have an interface with a separate, but defined, work process. We refer to that interfacing process as a Related Process.
Relationships
Relating to Configuration Items (CIs), a description of the interfaces that exist between Configuration Items (CIs) in the infrastructure. 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.
Release Management
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.
Release Policy
Defines the who, when, where, why, and how for Releases.
Release Unit
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 levels.
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.
Review, Scheduled
A review that is set from the details screens. It concerns every document and the request routed to Support Group Manager
RFC
See... Request for Change
Root Cause
The underlying cause of an Incident or Problem.
back to top

Script
Predefined scripts in ITSM are used in Incident Management (IM) to assist Tier I in the collection of initial support information.
Security Incident
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.
Service
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 efforts.
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 Services delivered.
Service Desk
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.
Service Request
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.
SD
See... Service Delivery
Significant Incident
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
Single Point-of-Contact
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.
Simple Search
A keyword search that returns Knowledge documents, Incident, Problem, and Known Error records
SLA
See... Service Level Agreement
SME
See... Subject Matter Expert
SOA
See... Systems Outage Analysis
Solution
See... Knowledge document
SS
See... Service Support
Standard Change
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 documentation.
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 Group
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

Task Assignee
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.
Team Representative
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.
Template
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

Unplanned Change
See... Emergency Change.
Urgency
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
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

Watch
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