Term
|
Definition
| Any Resource or Capability. Assets of a Service Provider include anything that could contribute to the delivery of a Service. Assets can be one of the following types: Management, Organisation, Process, Knowledge, People, Information, Applications, Infrastructure, and Financial Capital. |
|
|
Term
|
Definition
| Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service. |
|
|
Term
|
Definition
| Justification for a significant item of expenditure. Includes information about Costs, benefits, options, issues, Risks, and possible problems. |
|
|
Term
|
Definition
| The ability of an Organisation, person, Process, Application, Configuration Item or IT Service to carry out an Activity. Capabilities are intangible Assets of an Organisation. |
|
|
Term
|
Definition
| A Change that must be introduced as soon as possible. For example to resolve a Major Incident or implement a Security patch. The Change Management Process will normally have a specific Procedure for handling Emergency Changes. |
|
|
Term
|
Definition
| A Change that has not been pre-approved. |
|
|
Term
|
Definition
| A pre-approved Change that is low Risk, relatively common and follows a Procedure of Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request. |
|
|
Term
|
Definition
| Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs. |
|
|
Term
| Configuration Management System |
|
Definition
| The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. Configuration Management is part of an overall Service Asset and Configuration Management Process. |
|
|
Term
|
Definition
| A legally binding Agreement between two or more parties. |
|
|
Term
|
Definition
| One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored. The DML may also contain associated CIs such as licenses and documentation. The DML is a single logical storage area even if there are multiple locations. All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System. Only software from the DML is acceptable for use in a Release. |
|
|
Term
|
Definition
A change of state which has significance for the management of a Configuration Item or IT Service.
The term Event is also used to mean an Alert or notification created by any IT Service, Configuration Item or Monitoring tool. Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged. |
|
|
Term
|
Definition
| Ensuring that Policies and Strategy are actually implemented, and that required Processes are correctly followed. Governance includes defining Roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified. |
|
|
Term
|
Definition
| A measure of the effect of an Incident, Problem or Change on Business Processes. Impact is often based on how Service Levels will be affected. Impact and Urgency are used to assign Priority. |
|
|
Term
|
Definition
| An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set. |
|
|
Term
|
Definition
| A Problem that has a documented Root Cause and a Workaround. Known Errors are created and managed throughout their Lifecycle by Problem Management. Known Errors may also be identified by Development or Suppliers. |
|
|
Term
| Known Error Database (KEDB) |
|
Definition
| A database containing all Known Error Records. This database is created by Problem Management and used by Incident and Problem Management. The Known Error Database is part of the Service Knowledge Management System. |
|
|
Term
| Operational Level Agreement (OLA) |
|
Definition
An Agreement between an IT Service Provider and another part of the same Organisation. An OLA supports the IT Service Provider's delivery of IT Services to Customers. The OLA defines the goods or Services to be provided and the responsibilities of both parties. For example there could be an OLA
•
between the IT Service Provider and a procurement department to obtain hardware in agreed times
•
between the Service Desk and a Support Group to provide Incident Resolution in agreed times. |
|
|
Term
|
Definition
| A Category used to identify the relative importance of an Incident, Problem or Change. Priority is based on Impact and Urgency, and is used to identify required times for actions to be taken. For example the SLA may state that Priority2 Incidents must be resolved within 12 hours. |
|
|
Term
|
Definition
| A warning that a threshold has been reached, something has changed, or a Failure has occurred. Alerts are often created and managed by System Management tools and are managed by the Event Management Process. |
|
|
Term
|
Definition
| A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation. |
|
|
Term
|
Definition
| The formal documentation of the overarching strategy for releases and was derived from the Service Design phase of the Service Lifecycle. It is the governing policy document for the process and must accommodate the majority of releases being implemented. |
|
|
Term
|
Definition
| 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 different Release Unit may be the complete Payroll Application, including IT Operations Procedures and User training. |
|
|
Term
|
Definition
| A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an Organisation. |
|
|
Term
|
Definition
| A possible Event that could cause harm or loss, or affect the ability to achieve Objectives. A Risk is measured by the probability of a Threat, the Vulnerability of the Asset to that Threat, and the Impact it would have if it occurred. |
|
|
Term
|
Definition
| Any Capability or Resource of a Service Provider. |
|
|
Term
|
Definition
| A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is 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. |
|
|
Term
|
Definition
| The addition, modification or removal of an authoraized, planned or supported service or service component and its associated documentation. |
|
|
Term
|
Definition
| Document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement. |
|
|
Term
| Service Knowledge Management System (SKMS) |
|
Definition
| A set of tools and databases that are used to manage knowledge and information. 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. |
|
|
Term
| Service Level Agreement (SLA) |
|
Definition
An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.
See Operational Level Agreement. |
|
|
Term
|
Definition
| The Service Lifecycle describes the life of an IT service, from planning and optimizing the IT service to align with the business strategy, through the design and delivery of the IT service, to its ongoing operation and support. The Service Lifecycle consists of five phases; Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. |
|
|
Term
|
Definition
| The complete set of Services that are 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 Catalogue (Live or available for Deployment); and Retired Services. |
|
|
Term
|
Definition
| A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. |
|
|
Term
|
Definition
| 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 Organisations. |
|
|
Term
|
Definition
| A measure of how long it will be until an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the financial year. Impact and Urgency are used to assign Priority. |
|
|
Term
|
Definition
| Functionality offered by a Product or Service to meet a particular need. Utility is often summarised as "what it does". |
|
|
Term
|
Definition
| A promise or guarantee that a product or Service will meet its agreed Requirements. |
|
|
Term
|
Definition
| Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record. |
|
|
Term
|
Definition
| The four steps of the Deming cycle are? |
|
|
Term
• Technology
• Process
• Service |
|
Definition
| List the three types of metrics in continual service improvement: |
|
|
Term
• Define what you SHOULD measure
• Define what you CAN measure
• Gather the data
• Process the data
• Analyze the data
• Present and use the information
• Implement corrective action |
|
Definition
| List the seven steps of the improvement process. |
|
|
Term
• Change Management
• Service Asset & Configuration
• Release & Deployment |
|
Definition
| List the processes in Service Transition: |
|
|
Term
| package, build, test and deploy |
|
Definition
| Service Transition is the management & coordination of processes, systems, & functions to ___ , ___, ___ & ___ a release into production & establish the service specified in the requirements |
|
|
Term
| 7 R's of Change Management |
|
Definition
1. Who RAISED the change?
2. What is the REASON for the change?
3. What is the RETURN required from this change?
4. What are the RISKS involved in the change?
5. What RESOURCES are required to deliver the change?
6. Who is RESPONSIBLE for the build, test and implementation of the change?
7. What is the REALTIONSHIP between this change an other change? |
|
|
