ITIL v4

Components

ITIL 4 consists of two key components:

• The four dimensions model
• The service value system (SVS).

Four dimensions model

ITIL 4 defines four dimensions that should be considered to ensure a holistic approach to service management:

1. Organizations and people
2. Information and technology
3. Partners and suppliers
4. Value streams and processes.

These dimensions are applicable to the service value system in general and to specific services.

Service value system

The service value System (SVS) represents “how all the components and activities of an organization work together to facilitate value creation”. The ITIL 4 SVS includes several elements:

1. Guiding principles
2. Governance
3. Service value chain
4. Continual improvement
5. Practices.

Guiding Principals

1. Focus on value
   • Know how service consumers use each service.
   • Encourage a focus on value among all staff.
   • Focus on value during normal operational activity as well as during improvement initiatives.
   • Include a focus on value in every step of any improvement initiative.
2. Start where you are
   • Look at what exists as objectively as possible, using the customer or the desired outcome as the starting point.
   • When examples of successful practices or services are found in the current state, determine if and how these can be replicated or expanded upon to achieve the desired state.
   • Apply your risk management skills.
   • Recognize that sometimes nothing from the current state can be re-used.
3. Progress iteratively with feedback
   • Comprehend the whole, but do something.
   • The ecosystem is constantly changing, so feedback is essential.
   • Fast does not mean incomplete.
4. Collaborate and promote visibility
   • Collaboration does not mean consensus
   • Communicate in a way the audience can hear
   • Decisions can only be made on visible data
5. Think and work holistically
   • Recognize the complexity of the systems
   • Collaboration is key to thinking and working holistically
   • Where possible, look for patterns in the needs of and interactions between system elements
   • Automation can facilitate working holistically
6. Keep it simple and practical
   • Ensure value
   • Simplicity is the ultimate sophistication
   • Do fewer things, but do them better
   • Respect the time of the people involved
   • Easier to understand, more likely to adopt
   • Simplicity is the best route to achieving quick wins
7. Optimise and automate
   • Simplify and/or optimize before automating
   • Use automation to reduce toil: tasks which are manual, tactical, devoid of enduring value and/or linearly scaling
   • Define your metrics
   • Use the other guiding principles when applying this one

Governance

1. Direct: This involves the assignment of responsibility for organizational strategy and policies, and the direction of their preparation and implementation. Strategy sets the direction and prioritization for organizational activity including vision, mission and plans, while policies establish the requirements for behavior by those participating in organizational activities, whether they are staff, vendors or contractors.
2. Monitor: This involves determining whether the performance of the organization and its practices, products, and services is in line with the strategy and policies set in the direct activity.
3. Evaluate: This involves the performance of regular reviews of the organization, its strategy, portfolios, and relationships with other parties, accounting for changing external circumstances and stakeholder requirements.

Service value chain

• Plan: to ensure a shared understanding of the vision, current status, and improvement direction for all four dimensions and all products and services across the organization, including all planning activities
• output to Improve and Engage
• Improve: ensure continual improvement of products, services and practices across all value chain activities and the four dimensions of service management
• input from Deliver & Support and Engage
  • output to Design & Transition
• Engage: provide a good understanding of stakeholder needs, transparency, and continual engagement and good relationships with all stakeholders, including all interaction with external parties
• output to Improve
• Design & Transition: ensure that products and services continually meet stakeholder expectations for quality, costs and time to market
• input from Engage
  • output to Obtain/Build and Engage
• Obtain/Build: ensure that service components are available when and where they are needed and meet agreed specifications, including obtain new resources
• Deliver & Support: ensure that services are delivered and supported according to agreed specifications and stakeholders’ expectations
• input from Obtain/Build and Improve
  • output: new/improved services

Continual improvement

1. What is the vision?
2. Where are we now?
3. Where to be want to be?
4. How do we get there?
5. Take action
6. Did we get there?
7. Return to step 1.

ITIL 4 practices

The 34 ITIL 4 practices are grouped into three categories:

1. General management practices
2. Service management practices
3. Technical management practices

General management practices

The ITIL 4 general management practices include:

• Strategy management
• Portfolio management
• Architecture management
• Service financial management
• Workforce and talent management
• Continual improvement
• Measurement and reporting
• Risk management
• Information security management
• Knowledge management
• Organizational change management
• Project management
• Relationship management
• Supplier management

Service management practices

The service management practices in ITIL 4 include:

• Business analysis
• Service catalogue management
• Service design
• Service level management
• Availability management
• Capacity and performance management
• Service continuity management
• Monitoring and event management
• Service desk
• Incident management
• Service request management
• Problem management
• Release management
• Change enablement
• Service validation and testing
• Service configuration management
• IT asset management

Technical management practices

The ITIL 4 technical management practices include:

• Deployment management
• Infrastructure and platform management
• Software development and management

Service Strategy

Objective

The objective of ITIL Service Strategy is to decide on a strategy to serve customers. Starting from an assessment of customer needs and the market place, the Service Strategy lifecycle stage determines which services the IT organization is to offer and what capabilities need to be developed. Its ultimate goal is to make the IT organization think and act in a strategic manner.

Strategy Management for IT Services*

Objective

To assess the service provider’s offerings, capabilities, competitors as well as current and potential market spaces in order to develop a strategy to serve customers. Once the strategy has been defined, Strategy Management for IT Services is also responsible for ensuring the implementation of the strategy.

Definitions

Business Planning Information

• Business Planning Information includes important input from clients and external service providers, especially for devising the Service Strategy and looking for ways to improve services. This input will highlight, for example, planned business initiatives like the introduction of new product/ service offerings or the expansion into new markets, as well as information on the future development of business activity, especially expected increases in business transaction volumes. This information helps the service organization understand the businesses it serves and their plans for the future, allowing it to offer and develop the right set of services.

Service Strategy Plan

• The Service Strategy Plan (at times referred to as the Service Strategy) is about translating a big idea regarding customer needs into a distinctive and cost-effective set of connected capabilities and resources to satisfy those needs.

Strategic Action Plan

• The Strategic Action Plan sets out the steps required to implement the previously defined Service Strategy, defining specific tasks and responsibilities.

Strategic Service Assessment

• The Strategic Service Assessment is used to gain insight into a service provider’s weaknesses, strengths and opportunities prior to developing a Service Strategy.

Roles and Responsibilities

Service Strategy Manager - Process Owner

• The Service Strategy Manager supports the IT Steering Group in producing and maintaining the service provider’s strategy. This role is also responsible for communicating and implementing the service strategy.

IT Steering Group (ISG)

• The IT Steering Group (ISG) sets the direction and strategy for IT Services. It includes members of senior management from business and IT. The IT Steering Group reviews the business and IT strategies in order to make sure that they are aligned. It also sets priorities of service development programs/ projects.

KPIs

Service Portfolio Management*

Objective

To manage the service portfolio. Service Portfolio Management ensures that the service provider has the right mix of services to meet required business outcomes at an appropriate level of investment.

Definitions

Change Proposal

• A Change Proposal describes a proposed major Change, like the introduction of a new service or a substantial change to an existing service. The purpose of Change Proposals is to communicate a proposed major Change and assess its risk, impact and feasibility before design activities begin. Change Proposals are typically created in Service Portfolio Management.

Service Charter

• The Service Charter is a high-level description of a new or substantially changed service and the approach to build that service. In particular, the Service Charter outlines the deliverables to be created during the service implementation project, the required resources, and an initial project schedule. Service Charters are passed to Service Design to initiate the detailed design of the new or changed service.

Service Model

• A Service Model is a high-level description of a service and the components required to deliver that service. The main purpose of Service Models is to facilitate an understanding of what service components, assets and other resources are necessary to create the service, including their interactions. Service Models are a valuable tool for understanding the impact of proposed new or changed services on other services at an early stage.

Service Portfolio

• The Service Portfolio represents a complete list of the services managed by a service provider; some of these services are visible to the customers, while others are not. It contains present contractual commitments, new service development, and ongoing service improvement plans initiated by Continual Service Improvement. It also includes third-party services which are an integral part of service offerings to customers. The Service Portfolio is divided into three phases: Service Pipeline, Service Catalogue, and Retired Services.

Service Portfolio Review Report

• A document containing the results and findings from a Service Portfolio Review. This report is an important input to the strategic service assessment.

Roles and Responsibilities

Service Portfolio Manager - Process Owner

• The Service Portfolio Manager decides on a strategy to serve customers in cooperation with the IT Steering Group, and develops the service provider’s offerings and capabilities.

IT Steering Group (ISG)

• The IT Steering Group (ISG) sets the direction and strategy for IT Services. It includes members of senior management from business and IT. The IT Steering Group reviews the business and IT strategies in order to make sure that they are aligned. It also sets priorities of service development programs/ projects.

Financial Management for IT Services*

Objective

To manage the service provider’s budgeting, accounting and charging requirements.

Definitions

Budget Request

• A request for a budget, typically issued from any of the Service Management processes at the same time when compiling a Request for Change. An approved Budget Request means that the required financial resources for implementing a Change are approved by Financial Management.

Budget Allocation

• A budget allocated by the Financial Manager to implement a Change. Budget Allocations are issued in response to Budget Requests originating from any Service Management process in conjunction with Requests for Change.

Cost Data for Service Provisioning

• The cost for providing a service, calculated by Financial Management as a basis for calculating the price a customer is expected to pay for a service.

Financial Analysis

• The Financial Analysis is an important input to the Portfolio Management process. It contains information on the costs for providing services and provides insight into the profitability of services and customers.

Financial Data Categories

• Various categories are used to structure financial data, as a means to gain insight into the underlying costs of service provisioning and service profitability.

Indirect Cost Allocation Table

• A table used to allocate indirect costs that are shared among multiple services, defining the rules how those costs are spread among the services.

Invoice

• The invoice for the delivery of a service or product.

IT Budget

• The IT Budget is an annual financial plan that provides a forecast of expected expenditures and allocates financial resources to the various service management processes and organizational units within the IT organization.

Roles and Responsibilities

Financial Manager - Process Owner

• The Financial Manager is responsible for managing an IT service provider’s budgeting, accounting and charging requirements.

KPIs

Demand Management

Objective

To understand, anticipate and influence customer demand for services. Demand Management works with Capacity Management to ensure that the service provider has sufficient capacity to meet the required demand.

Definitions

Pattern of Business Activity (PBA)

• Patterns of Business Activity (PBA) are workload profiles describing the demand for particular services. PBAs are an important tool used by Demand Management for anticipating and influencing service demand.

Roles and Responsibilities

Demand Manager - Process Owner

• The Demand Manager is responsible for understanding, anticipating and influencing customer demand for services. The Demand Manager works with capacity management to ensure that the service provider has sufficient capacity to meet the required demand.

Business Relationship Management*

Objective

To maintain a positive relationship with customers. Business Relationship Management identifies the needs of existing and potential customers and ensures that appropriate services are developed to meet those needs.

Definitions

Complaint Status Information

• A message containing the present status of a complaint, typically sent to a customer who earlier made a complaint.

Complaints and Compliments

• Complaints and compliments from the customer side which are addressed in the Business Relationship Management process.

Complaints Log

• The Complaints Log contains the full history of all received customer complaints, complete with activities triggered by those complaints.

Customer Portfolio

• The Customer Portfolio is used to record all customers of the IT service provider. The Customer Portfolio is the Business Relationship Manager’s view of the customers who receive services from the IT service provider.

Customer Survey Questionnaire

• A questionnaire for surveying customer satisfaction, aimed at getting insight into overall customer satisfaction and customers’ views on specific (aspects of) services.

Customer Survey Response

• The response to a service provider’s customer survey, typically a completed questionnaire.

Desired Service Outcomes

• The desired outcomes of a service, stated in the language of the customer. Based on this information, more detailed documents are created to specify the requirements in the service provider’s language.

Outline of Service Requirements

• The desired outcome of a service, stated in terms of required service functionality (utility) and service levels (warranty). Based on this information, detailed service requirements are specified during the Service Design stage.

Roles and Responsibilities

Business Relationship Manager - Process Owner

• The Business Relationship Manager is responsible for maintaining a positive relationship with customers, identifying customer needs and ensuring that the service provider is able to meet these needs with an appropriate catalogue of services. The Business Relationship Manager works closely with the Service Level Manager.

Customer

• Someone who buys IT services. The Customer of an IT service provider is the person or group who defines and agrees the service level targets.

KPIs

Service Design

Objective

The objective of ITIL Service Design is to design new IT services. The scope of the Service Design lifecycle stage includes the design of new services, as well as changes and improvements to existing ones.

Design Coordination*

Objective

To coordinate all service design activities, processes and resources. Design coordination ensures the consistent and effective design of new or changed IT services, service management information systems, architectures, technology, processes, information and metrics.

Definitions

Service Design Package (SDP)

• The Service Design Package builds upon the Service Level Requirements. It further specifies the requirements from the viewpoint of the client and defines how these are actually fulfilled from a technical and organizational point of view

Service Design Policy

The Service Design Policy provides guidance on how to ensure that a consistent approach is applied to all design activities. In particular, the Service Design Policy specifies which projects or Changes are required to undergo the formal Service Design stage, and who needs to be involved in Service Design to ensure that all relevant aspects are considered.

Roles and Responsibilities

Service Design Manager - Process Owner

• The Service Design Manager is responsible for producing quality, secure and resilient designs for new or improved services. This includes producing and maintaining all design documentation.

Service Catalogue Management (SCM)

Objective

To ensure that a Service Catalogue is produced and maintained, containing accurate information on all operational services and those being prepared to be run operationally. Service Catalogue Management provides vital information for all other Service Management processes: Service details, current status and the services’ interdependencies.

Definitions

Required Modifications to Service Catalogue

• A request from a Service Management process to change the Service Catalogue. This request is sent to Service Catalogue Management if new services or service attributes must be recorded.

Service Catalogue

• A database or structured document with information about all live 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.

Roles and Responsibilities

Service Catalogue Manager - Process Owner

• The Service Catalogue Manager is responsible for maintaining the Service Catalogue, ensuring that all information within the Service Catalogue is accurate and up-to-date.

Service Level Management (SLM)*

Objective

To negotiate Service Level Agreements with the customers and to design services in accordance with the agreed service level targets. Service Level Management is also responsible for ensuring that all Operational Level Agreements and Underpinning Contracts are appropriate, and to monitor and report on service levels.

Definitions

Customer Agreement Portfolio

• While the Service Catalogue holds a complete list of the services managed by the service provider, the Customer Agreement Portfolio contains all Service Agreements which provide the framework for delivering services to specific customers.

Operational Level Agreement (OLA)

• An agreement between an IT service provider and another part of the same organization. An OLA supports the IT service provider’s delivery of 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.

Outline of Service Requirements

• The desired outcome of a service, stated in terms of required service functionality (utility) and service levels (warranty). Based on this information, detailed service requirements are specified during the Service Design stage.

Service Acceptance Criteria (SAC)

• A set of criteria used for service acceptance testing to ensure that an IT service meets its functionality and quality requirements and that the service provider is ready to operate the new service when it has been deployed.

Service Level Agreement (SLA)

• 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 services or multiple customers.

Service Level Report

• The Service Level Report gives insight into a service provider’s ability to deliver the agreed service quality. To this purpose, it compares the agreed and actually achieved service levels, and also includes information on the usage of services, ongoing measures for service improvement, and any exceptional events. A Service Level Report is issued by the service provider for its customers, IT management and other Service Management processes. A similar report is also created by an external service supplier to document its achieved service performance.

Service Level Requirements (SLR)

• The Service Level Requirements document contains the requirements for a service from the client viewpoint, defining detailed service level targets, mutual responsibilities, and other requirements specific to a certain (group of) customers. As the service enters new stages of its life cycle, the SLR document evolves into a draft Service Level Agreement.

SLM Document Templates

• Templates for the various documents used within Service Level Management, e.g. Service Level Requirements, Service Level Agreements, Operational Level Agreements, Underpinning Contracts, Service Acceptance Criteria, …

Roles and Responsibilities

Service Level Manager - Process Owner

• The Service Level Manager is responsible for negotiating Service Level Agreements and ensuring that these are met. He makes sure that all IT Service Management processes, Operational Level Agreements and Underpinning Contracts are appropriate for the agreed service level targets. The Service Level Manager also monitors and reports on service levels.

Service Owner

• The Service Owner is responsible for delivering a particular service within the agreed service levels. Typically, he acts as the counterpart of the Service Level Manager when negotiating Operational Level Agreements (OLAs). Often, the Service Owner will lead a team of technical specialists or an internal support unit.

KPIs

Risk Management*

Objective

To identify, assess and control risks. This includes analyzing the value of assets to the business, identifying threats to those assets, and evaluating how vulnerable each asset is to those threats.

Definitions

Business Impact and Risk Analysis

• Business Impact Analysis (BIA) and Risk Analysis are concepts associated with Risk Management. Their ultimate goal is to identify which risks must be managed and addressed by risk mitigation measures.

Process and Asset Valuation

• An estimate of the value a process or other asset represents for the business. This value is an important input for Risk Analysis.

Risk Management Policy

• The Risk Management Policy describes and communicates the organization’s approach to managing risk. Most importantly, it defines how risk is quantified and who is in charge of specific risk management duties. The Risk Management Policy is maintained by the Risk Manager role, but to be effective it needs the backing of senior management.

Risk Register

• The Risk Register is a tool used by the Risk Management process to keep an overview of identified risks and corresponding counter measures. The Risk Register is sometimes referred to as the Risk Log.

Roles and Responsibilities

Risk Manager - Process Owner

• The Risk Manager is responsible for identifying, assessing and controlling risks. This includes analyzing the value of assets to the business, identifying threats to those assets, and evaluating how vulnerable each asset is to those threats.

Capacity Management*

Objective

To ensure that the capacity of IT services and the IT infrastructure is able to deliver the agreed service level targets in a cost effective and timely manner. Capacity Management considers all resources required to deliver the IT service, and plans for short, medium and long term business requirements.

Definitions

Capacity Management Information System

• A virtual repository of all Capacity Management data, usually stored in multiple physical locations.

Capacity Plan

• A Capacity Plan is used to manage the resources required to deliver IT services. The plan contains scenarios for different predictions of business demand, and costed options to deliver the agreed service level targets.

Capacity Report

• The Capacity Report provides other Service Management processes and IT Management with information related to service and resource utilization and performance.

Event Filtering and Correlation Rules

• Rules and criteria used to determine if an Event is significant and to decide upon an appropriate response. Event Filtering and Correlation Rules are typically used by Event Monitoring systems. Some of those rules are defined during the Service Design stage, for example to ensure that Events are triggered when the required service availability is endangered.

Roles and Responsibilities

Capacity Manager - Process Owner

• The Capacity Manager is responsible for ensuring that services and infrastructure are able to deliver the agreed capacity and performance targets in a cost effective and timely manner.
• He considers all resources required to deliver the service, and plans for short, medium and long term business requirements.

KPIs

Availability Management*

Objective

To define, analyze, plan, measure and improve all aspects of the availability of IT services. Availability Management is responsible for ensuring that all IT infrastructure, processes, tools, roles etc. are appropriate for the agreed availability targets.

Definitions

Availability Design Guidelines

• The Availability Design Guidelines define from a technical point of view how the required availability levels can be achieved, including specific instructions for application development and for externally sourced infrastructure components.

Availability Guidelines for the Service Desk

• Rules produced by Availability Management on how to manage Incidents causing unavailability, to prevent minor Incidents from becoming major Incidents.

Availability Management Information System

• A virtual repository of all Availability Management data, usually stored in multiple physical locations.

Availability Plan

• The Availability Plan contains detailed information about initiatives aimed at improving service and/ or component availability.

Availability/ ITSCM/ Security Testing Schedule

• A schedule for the regular testing of all availability, continuity and security mechanisms, jointly maintained by Availability, IT Service Continuity and Information Security Management.

Availability Report

• The Availability Report provides other Service Management processes and IT Management with information related to service and infrastructure component availability.

Event Filtering and Correlation Rules

• Rules and criteria used to determine if an Event is significant and to decide upon an appropriate response. Event Filtering and Correlation Rules are typically used by Event Monitoring systems. Some of those rules are defined during the Service Design stage, for example to ensure that Events are triggered when the required service availability is endangered.

Maintenance Plan/ SOP

• Maintenance Plans are part of the operational documentation for applications and infrastructure components, which are sometimes known as Standard Operating Procedures (SOP). They define the frequency and scope of preventative maintenance. Maintenance Plans/ SOPs are typically extracted from technical or administration manuals to define in a concise manner the tasks to be carried out as part of standard operations.

Recovery Plan

• Recovery Plans are created mainly by Availability Management and IT Service Continuity Management. The plans contain specific instructions for returning specific services and/or systems to a working state, which often includes recovering data to a known consistent state.

Technical/ Administration Manual

• A document describing the procedures required to run and maintain a type of application or infrastructure component.

Test Report

• A Test Report provides a summary of testing and assessment activities. A Test Report is created for example during Release tests in the Service Transition stage or during tests carried out by Availability, IT Service Continuity or Information Security Management.

Roles and Responsibilities

Availability Manager - Process Owner

• The Availability Manager is responsible for defining, analyzing, planning, measuring and improving all aspects of the availability of IT services. He is responsible for ensuring that all IT infrastructure, processes, tools, roles etc. are appropriate for the agreed service level targets for availability.

KPIs

IT Service Continuity Management (ITSCM)*

Objective

To manage risks that could seriously impact IT services. ITSCM ensures that the IT service provider can always provide minimum agreed Service Levels, by reducing the risk from disaster events to an acceptable level and planning for the recovery of IT services. ITSCM should be designed to support Business Continuity Management.

#### Definitions

Availability/ ITSCM/ Security Testing Schedule

• A schedule for the regular testing of all availability, continuity and security mechanisms, jointly maintained by Availability, IT Service Continuity and Information Security Management.

Business Continuity Strategy

• An outline of the approach to ensure the continuity of Vital Business Functions in the case of disaster events. The Business Continuity Strategy is prepared by the business and serves as a starting point for producing the IT Service Continuity Strategy.

Disaster Recovery Invocation Guideline

• A document produced by IT Service Continuity Management with detailed instructions on when and how to invoke the procedure for fighting a disaster. Most importantly, the guideline defines the first steps to be taken by 1st Level Support after learning that a (suspected) disaster has occurred.

Index of Disaster-Relevant Information

• A catalogue of all information that is relevant in the event of disasters. This document is maintained and circulated by IT Service Continuity Management to all members of IT staff with responsibilities for fighting disasters.

IT Service Continuity Report

• The IT Service Continuity Report is created at regular intervals and provides other Service Management processes and IT Management with information related to disaster prevention.

IT Service Continuity Plan

• IT Service Continuity Plans underpin the ITSCM Strategy, describing how continuity is ensured for specific disaster events and services. It specifies the measures to enhance the resilience of services and describes how to effectively respond to a disaster event. ITSCM Plans usually include references to more detailed Recovery Plans with specific instructions for returning systems to a working state.

IT Service Continuity Strategy

• The IT Service Continuity Strategy contains an outline of the approach to ensure the continuity of vital services in the case of disaster events. It includes a list of Vital Business Functions and applied risk reduction or recovery options. The IT Service Continuity Strategy should be based on a Business Continuity Strategy. The ITSCM Strategy is underpinned by more detailed ITSCM Plans, describing how continuity is ensured for specific disaster events and services.

Recovery Plan

• Recovery Plans are created mainly by Availability and IT Service Continuity Management. The plans contain detailed instructions for returning specific services and/or systems to a working state, which often includes recovering data to a known consistent state.

Test Report

• A Test Report provides a summary of testing and assessment activities. A Test Report is created for example during Release tests in the Service Transition stage or during tests carried out by Availability, IT Service Continuity or Information Security Management.

Roles and Responsibilities

IT Service Continuity Manager - Process Owner

• The IT Service Continuity Manager is responsible for managing risks that could seriously impact IT services.
• He ensures that the IT service provider can provide minimum agreed service levels in cases of disaster, by reducing the risk to an acceptable level and planning for the recovery of IT services.

KPIs

Information Security Management*

Objective

To ensure the confidentiality, integrity and availability of an organization’s information, data and IT services. Information Security Management usually forms part of an organizational approach to security management which has a wider scope than the IT Service Provider.

Definitions

Availability/ ITSCM/ Security Testing Schedule

• A schedule for the regular testing of all availability, continuity and security mechanisms, jointly maintained by Availability, IT Service Continuity and Information Security Management.

Event Filtering and Correlation Rules

• Rules and criteria used to determine if an Event is significant and to decide upon an appropriate response. Event Filtering and Correlation Rules are typically used by Event Monitoring systems. Some of those rules are defined during the Service Design stage, for example to ensure that Events are triggered when the required service availability is endangered.

Information Security Policy

• The Information Security Management Policy describes and communicates the organization’s approach to managing information security. It includes references to more specific Underpinning Information Security Policies which, for example, set binding rules for the use of systems and information.

Information Security Report

• The Information Security Report provides other Service Management processes and IT Management with information related to Information Security issues.

Security Advisories

• A list of known security vulnerabilities compiled from input by third-party product suppliers. The list contains instructions for preventive measures and for the handling of security breaches once they occur.

Security Alert

• A warning produced by Information Security Management, typically released when outbreaks of security threats are foreseeable or already under way. The aim is to make sure that users and IT staff are able to identify any attacks and take appropriate precautions.

Security Management Information System (SMIS)

• A virtual repository of all Information Security Management data, usually stored in multiple physical locations.

Test Report

• A Test Report provides a summary of testing and assessment activities. A Test Report is created for example during Release tests in the Service Transition stage or during tests carried out by Availability, IT Service Continuity or Information Security Management.

Underpinning Information Security Policy

• Underpinning Information Security Policies are specific policies complementing the main Information Security Policy by setting binding rules for the use of systems and information as well as for the use and delivery of services, with the aim of improving information security.

Roles and Responsibilities

Information Security Manager - Process Owner

• The Information Security Manager is responsible for ensuring the confidentiality, integrity and availability of an organization’s assets, information, data and IT services. He is usually involved in an organizational approach to Security Management which has a wider scope than the IT service provider, and includes handling of paper, building access, phone calls etc., for the entire organization.

KPIs

Compliance Management

Objective

To ensure IT services, processes and systems comply with enterprise policies and legal requirements.

Definitions

Compliance Register

• The Compliance Register is a tool used by the Compliance Management process to keep an overview of all compliance requirements and the measures applied to ensure their enforcement.

Compliance Review

• The Compliance Review documents the results of regular process and system compliance assessments. In particular, it contains any identified deviations from compliance requirements, as well as measures to correct the situation.

Enterprise Policies and Regulations

• A set of binding enterprise policies and regulations which are an important input for the Compliance Management process.

Roles and Responsibilities

Compliance Manager - Process Owner

• The Compliance Manager’s responsibility is to ensure that standards and guidelines is followed, or that proper, consistent accounting or other practices are being employed.
• This includes to make sure that external legal requirements are fulfilled.

Architecture Management

Objective

To define a blueprint for the future development of the technological landscape, taking into account the service strategy and newly available technologies.

Definitions

Application Framework

• Application Frameworks aim to promote the re-use of components and the standardizing of technologies on which applications are based. For this reason, they have to be planned and managed separately from software development projects – but must be carefully aligned with the needs of software developers. Application Frameworks define classes of applications, typically with common non-functional requirements.

Change Request to Enterprise Architecture

• A request to change or extend the Enterprise Architecture, usually issued from the Service Design process when the introduction or modification of a service is not possible within the constraints of the existing application, infrastructure and information/ data architectures.

Enterprise Architecture (EA)

• An Enterprise Architecture (EA) is a description of the essential components of a business, including their interrelationships. In most cases, an EA covers the following domains: Business, Information, Applications and Technology.

Roles and Responsibilities

Enterprise Architect - Process Owner

• The Enterprise Architect is responsible for maintaining the Enterprise Architecture (EA), a description of the essential components of a business, including their interrelationships.
• Bigger organizations may opt to introduce specialist EA roles like Business Architect, Application Architect, Information Architect, or Infrastructure Architect.

Supplier Management

Objective

To ensure that all contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.

Definitions

Purchase Order

• An order for purchasing items from a supplier. If the order is for an externally supplied Supporting Service it is accompanied by an Underpinning Contract defining service level targets.

Purchase Request

• A request to purchase a service or a product from an external supplier, issued for example from Release Management during Service Build. Processing of a Purchase Request will generally proceed only if the requester also holds an approved budget for the purchase.

Standard Terms and Conditions

• A set of terms and conditions which are routinely attached to contracts and orders when procuring services or products.

Supplier and Contract Management Information System (SCMIS)

• The Supplier and Contract Management Information System is database or structured document used to manage suppliers and contracts throughout their lifecycle. The SCMIS contains key attributes of all contracts with suppliers, and should be part of the Service Knowledge Management System.

Supplier and Contract Review Meeting Minutes

• The Supplier and Contract Review Meeting Minutes document achieved vs. agreed supplier performance. They also contain any identified supplier weaknesses and problems, as well as suggestions on how the situation could be improved.

Supplier Evaluation

• The resulting document from the Supplier Evaluation process, describing in detail the criteria used for evaluating and selecting a suitable supplier.

Supplier Service Level Report

• The Supplier Service Level Report gives insight into a service provider’s external supplier’s ability to deliver the agreed service quality. To this purpose, it compares the agreed and actually achieved service levels, and also includes information on the usage of services, ongoing measures for service improvement, and any exceptional events.

Supplier Strategy

• The Supplier Strategy sets guidelines for the procurement of services and goods. It typically includes criteria for the selection of suitable suppliers and a list of preferred suppliers.

Underpinning Contract (UC)

• A contract between an IT service provider and a third party. The third party provides supporting services that enable the service provider to deliver a service to a customer. Therefore, Underpinning Contracts must be aligned with the customer-facing Service Level Agreements.

Roles and Responsibilities

Supplier Manager - Process Owner

• The Supplier Manager is responsible for ensuring that value for money is obtained from all suppliers.
• He makes sure that contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.

KPIs

Service Transition

Objective

The objective of ITIL Service Transition is to build and deploy IT services. The Service Transition lifecycle stage also makes sure that changes to services and service management processes are carried out in a coordinated way.

Change Management/Enablement*

Objective

To control the lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT services.

Definitions

CAB Agenda Template

• The CAB Agenda lists the topics for discussion in a CAB meeting.

Change

• The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.

Change Evaluation Report

• Certain types of major Changes, like the introduction of a new service or a substantial change to an existing service, require formal Change evaluations before being authorized. The results of a formal Change evaluation are documented in a Change Evaluation Report. Change evaluations may be used at different points in a Change’s lifecycle, for example before authorizing the Change/ Release build or during the Post Implementation Review (PIR).

Change Management Policy

• The decision to authorize or reject a proposed Change is based on the completed Change Assessment. In particular, the assessment is about properly understanding the risks associated with the implementation of a Change. In this context, the Change Management Policy specifies the levels of authorization required to authorize different types of Changes and other rules for assessing Changes.

Change Model

• Change Models describe procedures for the handling of recurring Changes. While Change Models can be created for Changes of any scale, they are often used to define Standard Changes (low-risk, pre-authorized Changes like installing additional hardware on a client PC).

Change Proposal

• A Change Proposal describes a proposed major Change, like the introduction of a new service or a substantial change to an existing service. The purpose of Change Proposals is to communicate a proposed major Change and assess its risk, impact and feasibility before design activities begin. Change Proposals are typically created in Service Portfolio Management.

Change Record

• The Change Record contains all the details of a Change, documenting the lifecycle of a single Change. It is usually created on the basis of a preceding Request for Change (RFC).

Change Schedule

• A Document that lists all approved Change Proposals and Changes and their planned implementation dates. A Change Schedule is sometimes called a Forward Schedule of Change (FSC).

Emergency Change

• A Change that must be introduced as soon as possible - for example, to resolve a major incident or implement a security patch.

Projected Service Outage (PSO)

• The Projected Service Outage (PSO) document lists any expected deviations from the service availability agreed in SLAs.

Request for Change (RFC)

• A formal request for a Change to be implemented. An RFC, specifying the details of the proposed Change, must be submitted to Change Management for every non-standard Change.

RFC Template

• A template to be used when formally requesting a Change. An RFC includes details of the proposed Change, and may be recorded on paper or electronically.

Roles and Responsibilities

Change Manager - Process Owner

• The Change Manager controls the lifecycle of all Changes.
• His primary objective is to enable beneficial Changes to be made, with minimum disruption to IT services.
• For important Changes, the Change Manager will refer the authorization of Changes to the Change Advisory Board (CAB).

Change Advisory Board (CAB)

• A group of people that advises the Change Manager in the assessment, prioritization and scheduling of Changes.
• This board is usually made up of representatives from all areas within the IT organization, the business, and third parties such as suppliers.

Emergency Change Advisory Board (ECAB)

• A sub-set of the Change Advisory Board who makes decisions about high impact Emergency Changes.
• Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.

KPIs

Change Evaluation*

Objective

To assess major Changes, like the introduction of a new service or a substantial change to an existing service, before those Changes are allowed to proceed to the next phase in their lifecycle.

Definitions

Change Evaluation Report

• Certain types of major Changes, like the introduction of a new service or a substantial change to an existing service, require formal Change evaluations before being authorized. The results of a formal Change evaluation are documented in a Change Evaluation Report. Change evaluations may be used at different points in a Change’s lifecycle, for example before authorizing the Change/Release build or during the Post Implementation Review.

Roles and Responsibilities

Change Manager - Process Owner

• The Change Manager controls the lifecycle of all Changes. His primary objective is to enable beneficial Changes to be made, with minimum disruption to IT services. For important Changes, the Change Manager will refer the authorization of Changes to the Change Advisory Board (CAB).

Project Management (Transition Planning and Support)*

Objective

To plan and coordinate the resources to deploy a major Release within the predicted cost, time and quality estimates.

Definitions

Data for Project Plan Update

• Current information related to project progress and resource consumption. This information is sent from various Service Transition processes to Project Management as input for Project Control and Project Reporting.

Project Charter

• The Project Charter is a statement of the scope, objectives and participants in a project. It outlines the project objectives, identifies the main stakeholders, defines the authority of the Project Manager and the resources at his disposal, and lists any constraints and assumptions affecting the project.

Project History Log

• A document recording important events during the course of the project, e.g. decisions, escalations and changes to the project scope.

Project Plan (Service Transition Plan)

• A Project Plan (in ITIL also referred to as Service Transition Plan) is a formal, approved document showing the major deliverables, milestones, activities and resources for a project, used to guide both project execution and project control.

Project Portfolio Status Report

• The Project Portfolio Status Report is an overall summary of all planned or ongoing projects, listing key project data like milestones and current project status.

Roles and Responsibilities

Project Manager - Process Owner

• The Project Manager is responsible for planning and coordinating the resources to deploy a major Release within the predicted cost, time and quality estimates.

KPIs

Application Development

Objective

To make available applications and systems which provide the required functionality for IT services. This process includes the development and maintenance of custom applications as well as the customization of products from software vendors.

Definitions

User Manual

• A document for end-users, describing how to use an application or system.

Technical/ Administration Manual

• A document describing the procedures required to run and maintain a type of application or infrastructure component.

Roles and Responsibilities

Application Developer - Process Owner

• The Application Developer is responsible for making available applications and systems which provide the required functionality for IT services. This includes the development and maintenance of custom applications as well as the customization of products from software vendors.

Release and Deployment Management*

Objective

To plan, schedule and control the movement of releases to test and live environments. The primary goal of Release Management is to ensure that the integrity of the live environment is protected and that the correct components are released.

Definitions

Development Work Order

• A Work Order for the development or customization of an application or system, typically issued from Release Management.

Installation Work Order

• A Work Order for the installation of an application, system or infrastructure component, typically issued from Release Management.

Release Policy

• A set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact.

Release

• A Release (also referred to as a Release Package) consists of a single Release Unit or a structured set of Release Units.

Release Record

• A Release Record contains all details of a Release, documenting the history of the Release from the first planning stages to closure.

Release Unit

• A Release Unit is a set of new, changed and/or unchanged Configuration Items, which are tested and introduced into the live environment together to implement one or several approved Changes.

Roles and Responsibilities

Release Manager - Process Owner

• The Release Manager is responsible for planning and controlling the movement of Releases to test and live environments. His primary objective is to ensure that the integrity of the live environment is protected and that the correct components are released.

KPIs

Service Validation and Testing*

Objective

To ensure that deployed Releases and the resulting services meet customer expectations, and to verify that IT operations is able to support the new service.

Definitions

Development/ Installation QA Documentation

• A documentation of tests and quality assurance measures applied during the development or installation of applications, systems and other infrastructure components (e.g. component tests, code walk-throughs, …). A complete Development/ Installation Quality Assurance (QA) Documentation testifies that the required QA measures were applied prior to handing a Release component over to Release Management.

Test Model

• A Test Model is created during the Release planning phase to specify in detail the testing approach used for deploying a Release into the productive environment. It is an important input for the Project Plan. Most importantly, this document defines the required quality assurance checkpoints during the Release deployment, as well as the required test scripts.

Roles and Responsibilities

Test Manager - Process Owner

• The Test Manager ensures that deployed Releases and the resulting services meet customer expectations, and verifies that IT operations is able to support the new service.

Service User

• A person who uses one or several IT services on a day-to-day basis. Service Users are distinct from Customers, as some Customers do not use IT services directly.

KPIs

Service Asset and Configuration Management*

Objective

To maintain information about Configuration Items required to deliver an IT service, including their relationships.

Definitions

Change Request to CMS Structure

• A request from a Service Management process to change the CMS structure. This request is sent to Configuration Management if new CIs or attributes must be recorded but the CMS’s structure is not adequate for holding the new data.

CMS/ CMDB

• The Configuration Management System (CMS) is a set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships. A CMS may manage more than one physical Configuration Management Databases (CMDBs). Its underlying structure is defined by the Configuration Model, a logical model of the IT organization’s service assets.

CMS Change Policy

• A set of rules defining who is authorized to modify the structure and contents of the CMS.

Configuration Audit Report

• A report summarizing the results of a CMS audit, highlighting revealed differences between CMS records and actually installed CIs.

Configuration Item (CI)

• Configuration Items (CIs) can be of various types: the CMS almost always covers services and IT infrastructure, but might also cover other item types like policies, project documentation, employees, suppliers, … Configuration Items are characterized by their attributes (recorded in the CI’s Configuration Record) and their relationships to other CIs.

Definitive Media Library (DML)

• The Definitive Media Library (DML) is the secure logical library in which the definitive authorized versions of all media CIs are stored and protected. The DML typically consists of one or more software file-storage areas, as well as physical stores holding, for example, master copies on CD/DVD.

Roles and Responsibilities

Configuration Manager - Process Owner

• The Configuration Manager is responsible for maintaining information about Configuration Items required to deliver IT services.
• To this end he maintains a logical model, containing the components of the IT infrastructure (CIs) and their associations.

KPIs

Knowledge Management

Objective

To gather, analyze, store and share knowledge and information within an organization. The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.

Definitions

Service Knowledge Management System (SKMS)

• The Service Knowledge Management System (SKMS) is the central repository of the data, information and knowledge that the IT organization needs to manage the lifecycle of its services. Its purpose is to store, analyze and present the service provider’s data, information and knowledge. The SKMS is not necessarily a single system – in most cases it will be a federated system based on a variety of data sources.

Roles and Responsibilities

Knowledge Manager - Process Owner

• The Knowledge Manager ensures that the IT organization is able to gather, analyze, store and share knowledge and information. His primary goal is to improve efficiency by reducing the need to rediscover knowledge.

Service Operation

Objective

The objective of ITIL Service Operation is to make sure that IT services are delivered effectively and efficiently. The Service Operation lifecycle stage includes the fulfilling of user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks.

Event Management*

Objective

To make sure CIs and services are constantly monitored, and to filter and categorize Events in order to decide on appropriate actions.

Definitions

Event

• see Event Record

Event Categorization Scheme

• The Categorization Scheme for Events supports a consistent approach to dealing with specific types of Events. Ideally, this scheme should be harmonized with the schemes to categorize CIs, Incidents and Problems.

Event Filtering and Correlation Rules

• Rules and criteria used to determine if an Event is significant and to decide upon an appropriate response. Event Filtering and Correlation Rules are typically used by Event Monitoring systems. Some of those rules are defined during the Service Design stage, for example to ensure that Events are triggered when the required service availability is endangered.

Event Record

• A record describing a change of state which has significance for the management of a Configuration Item or service. The term Event is also used to mean an alert or notification created by any IT service, Configuration Item or monitoring tool. Events often require IT operations personnel to take actions, and may lead to Incidents being logged.

Event Trends and Patterns

• Any trends and patterns identified during analysis of significant Events, which suggest that improvements to the infrastructure are needed.

Roles and Responsibilities

IT Operations Manager - Process Owner

• An IT Operations Manager will be needed to take overall responsibility for a number of Service Operation activities. For instance, this role will ensure that all day-to-day operational activities are carried out in a timely and reliable way.

IT Operator

• IT Operators are the staff who perform the day-to-day operational activities.
• Typical responsibilities include: Performing backups, ensuring that scheduled jobs are performed, installing standard equipment in the data centre.

Incident Management*

Objective

To manage the lifecycle of all Incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible.

Definitions

Incident

• An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).

Incident Escalation Rules

• A set of rules defining a hierarchy for escalating Incidents, and triggers which lead to escalations. Triggers are usually based on Incident severity and resolution times.

Incident Management Report

• A report supplying Incident-related information to the other Service Management processes.

Incident Model

• An Incident Model contains the pre-defined steps that should be taken for dealing with a particular type of Incident. This is a way to ensure that routinely occurring Incidents are handled efficiently and effectively.

Incident Prioritization Guideline

• The Incident Prioritization Guideline describes the rules for assigning priorities to Incidents, including the definition of what constitutes a Major Incident. Since Incident Management escalation rules are usually based on priorities, assigning the correct priority to an Incident is essential for triggering appropriate escalations. See also: Checklist Incident Prioritization Guideline

Incident Record

• A set of data with all details of an Incident, documenting the history of the Incident from registration to closure. An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives).

Incident Status Information

• A message containing the present status of an Incident sent to a user who earlier reported a service interruption. Status information is typically provided to users at various points during an Incident’s lifecycle.

Major Incident

• Major Incidents cause serious interruptions of business activities and must be solved with greater urgency. See also: Checklist Incident Priority: Major Incidents.

Major Incident Review

• A Major Incident Review takes place after a Major Incident has occurred. The review documents the Incident’s underlying causes (if known) and the complete resolution history, and identifies opportunities for improving the handling of future Major Incidents.

Notification of Service Failure

• The reporting of a service failure to the Service Desk, for example by a user via telephone or e-mail, or by a system monitoring tool.

Pro-Active User Information

• A notification to users of existing or imminent service failures even if the users are not yet aware of the interruptions, so that users are in a position to prepare themselves for a period of service unavailability.

Status Inquiry

• An inquiry regarding the present status of an Incident or Service Request, usually from a user who earlier reported an Incident or submitted a request.

Support Request

• A request to support the resolution of an Incident or Problem, usually issued from the Incident or Problem Management processes when further assistance is needed from technical experts.

User Escalation

• Escalation regarding the processing of an Incident or Service Request, initiated by a user experiencing delays or a failure to restore their services.

User FAQs

• Self-help information for users supplied by the Service Desk, usually as part of the Support Pages on the intranet.

Roles and Responsibilities

Incident Manager - Process Owner

• The Incident Manager is responsible for the effective implementation of the Incident Management process and carries out the corresponding reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.

1st Level Support

• The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also keeps users informed about their Incidents’ status at agreed intervals.

2nd Level Support

• 2nd Level Support takes over Incidents which cannot be solved immediately with the means of 1st Level Support. If necessary, it will request external support, e.g. from software or hardware manufacturers. The aim is to restore a failed IT service as quickly as possible. If no solution can be found, the 2nd Level Support passes on the Incident to Problem Management.

3rd Level Support

• 3rd Level Support is typically located at hardware or software manufacturers (third-party suppliers). Its services are requested by 2nd Level Support if required for solving an Incident. The aim is to restore a failed IT Service as quickly as possible.

Major Incident Team

• A dynamically established team of IT managers and technical experts, usually under the leadership of the Incident Manager, formulated to concentrate on the resolution of a Major Incident.

KPIs

Request Fulfilment*

Objective

To fulfill Service Requests, which in most cases are minor (standard) Changes (e.g. requests to change a password) or requests for information.

Definitions

Request for Service

• A formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user. The details of a Request for Service are recorded by Request Fulfilment in a Service Request Record.

Service Request Model

• A (Service) Request Model defines specific agreed steps that will be followed for a Service Request of a particular type (or category).

Service Request Record

• A record containing all details of a Service Request. Service Requests are formal requests from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user.

Service Request Status Information

• A message containing the present status of a Service Request sent to a user who earlier reported requested a service. Status information is typically provided to users at various points during a Service Request’s lifecycle.

Roles and Responsibilities

Incident Manager - Process Owner

• The Incident Manager is responsible for the effective implementation of the Incident Management process and carries out the respective reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.

1st Level Support

• The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also processes Service Requests and keeps users informed about their Incidents’ status at agreed intervals.

Service Request Fulfilment Group

• Service Request Fulfilment Groups specialize on the fulfilment of certain types of Service Requests. Typically, 1st Level Support will process simpler requests, while others are forwarded to the specialized Fulfilment Groups.

Access Management*

Objective

To grant authorized users the right to use a service, while preventing access to non-authorized users. The Access Management processes essentially execute policies defined in Information Security Management. Access Management is sometimes also referred to as Rights Management or Identity Management.

Definitions

Access Rights

• A set of data defining what services a user is allowed to access. This definition is achieved by assigning the user, identified by his User Identity, to one or more User Roles.

Request for Access Rights

• A request to grant, change or revoke the right to use a particular service or access certain assets.

User Identity Record

• A set of data with all the details identifying a user or person. It is used to grant rights to that user or person.

User Identity Request

• A request to create, modify or delete a User Identity.

User Role

• A role as part of a catalogue or hierarchy of all the roles (types of users) in the organization. Access rights are based on the roles that individual users have as part of an organization.

User Role Access Profile

• A set of data defining the level of access to a service or group of services for a certain type of user (User Role). User Role Access Profiles help to protect the confidentiality, integrity and availability of assets by defining what information computer users can utilize, the programs that they can run, and the modifications that they can make.

User Role Requirements

• Requirements from the business side for the catalogue or hierarchy of user roles (types of users) in the organization. Access rights are based on the roles that individual users have as part of an organization.

Roles and Responsibilities

Access Manager - Process Owner

• The Access Manager grants authorized users the right to use a service, while preventing access to non-authorized users.
• The Access Manager essentially executes policies defined in Information Security Management.

1st Level Support

• The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also processes Service Requests and keeps users informed about their Incidents’ status at agreed intervals.

Problem Management*

Objective

To manage the lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the impact of incidents that cannot be prevented. Proactive Problem Management analyzes Incident Records, and uses data collected by other IT Service Management processes to identify trends or significant Problems.

Definitions

Known Error

• A Known Error is a problem that has a documented root cause and a Workaround. Known Errors are managed throughout their lifecycle by the Problem Management process. The details of each Known Error are recorded in a Known Error Record stored in the Known Error Database (KEDB). As a rule, Known Errors are identified by Problem Management, but Known Errors may also be suggested by other Service Management disciplines, e.g. Incident Management, or by suppliers.

Known Error Database (KEDB)

• The Known Error Database (KEDB) is created by Problem Management and used by Incident and Problem Management to manage all Known Error Records.

Problem

• A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created.

Problem Management Report

• A report supplying Problem-related information to the other Service Management processes.

Problem Record

• The Problem Record contains all details of a Problem, documenting the history of the Problem from detection to closure.

Suggested new Known Error

• A suggestion to create a new entry in the Known Error Database, for example raised by the Service Desk or by Release Management. Known Errors are managed throughout their lifecycle by Problem Management.

Suggested new Problem

• A notification about a suspected Problem, handed over to Problem Management for further investigation, possibly leading to the formal logging of a Problem.

Suggested new Workaround

• A suggestion to enter a new Workaround in the Known Error Database, for example raised by the Service Desk or by Release Management. Workarounds are managed throughout their lifecycle by Problem Management.

Workaround

• Workarounds are temporary solutions aimed at reducing or eliminating the impact of Known Errors (and thus Problems) for which a full resolution is not yet available. As such, Workarounds are often applied to reduce the impact of Incidents or Problems if their underlying causes cannot be readily identified or removed.

Roles and Responsibilities

Problem Manager - Process Owner

• The Problem Manager is responsible for managing the lifecycle of all Problems.
• His primary objectives are to prevent Incidents from happening, and to minimize the impact of Incidents that cannot be prevented.
• To this purpose he maintains information about Known Errors and Workarounds.

KPIs

IT Operations Control

Objective

To monitor and control the IT services and their underlying infrastructure. The process IT Operations Control executes day-to-day routine tasks related to the operation of infrastructure components and applications. This includes job scheduling, backup and restore activities, print and output management, and routine maintenance.

Roles and Responsibilities

IT Operations Manager - Process Owner

• An IT Operations Manager will be needed to take overall responsibility for a number of Service Operation activities. For instance, this role will ensure that all day-to-day operational activities are carried out in a timely and reliable way.

IT Operator

• IT Operators are the staff who perform the day-to-day operational activities. Typical responsibilities include: Performing backups, ensuring that scheduled jobs are performed, installing standard equipment in the data center.

Facilities Management

Objective

To manage 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.

Roles and Responsibilities

Facilities Manager - Process Owner

• The Facilities Manager is responsible for managing the physical environment where the IT infrastructure is located.
• This includes all aspects of managing the physical environment, for example power and cooling, building access management, and environmental monitoring.

Application Management

Objective

Application Management is responsible for managing applications throughout their lifecycle.

Definitions

Skills Inventory

• The Skills Inventory identifies the skills required to deliver IT services (now and in future), as well as the individuals who possess those skills. The Skills Inventory is the basis for developing training plans for individual employees.

Roles and Responsibilities

Applications Analyst - Process Owner

• The Applications Analyst is an Application Management role which manages applications throughout their lifecycle. There is typically one Applications Analyst or team of analysts for every key application. This role plays an important part in the application-related aspects of designing, testing, operating and improving IT services. It is also responsible for developing the skills required to operate the applications required to deliver IT services.

Technical Management

Objective

Technical Management provides technical expertise and support for the management of the IT infrastructure.

Roles and Responsibilities

Technical Analyst - Process Owner

• The Technical Analyst is a Technical Management role which provides technical expertise and support for the management of the IT infrastructure. There is typically one Technical Analyst or team of analysts for every key technology area. This role plays an important part in the technical aspects of designing, testing, operating and improving IT services. It is also responsible for developing the skills required to operate the IT infrastructure.

Continual Service Improvement

Service Review

Objective

To review business services and infrastructure services on a regular basis. The aim of this process is to improve service quality where necessary, and to identify more economical ways of providing a service where possible.

Definitions

Service Review Report

• A document containing the results and findings from a Service Review. This report is an important input for the definition of improvement initiatives.

Suggested Service Improvement

• Suggestion for improving service quality or economics, handed over from other Service Management processes to the Continual Service Improvement process. Suggestions may originate from anywhere within or outside of the IT organization, and may include suggestions for improving the way a service is provided or for modifying service agreements (SLAs, OLAs and UCs).

Roles and Responsibilities

CSI Manager - Process Owner

• The Continual Service Improvement (CSI) Manager is responsible for managing improvements to IT Service Management processes and IT services. He will continually measure the performance of the service provider and design improvements to processes, services and infrastructure in order to increase efficiency, effectiveness, and cost effectiveness.

KPIs

Process Evaluation*

Objective

To evaluate processes on a regular basis. This includes identifying areas where the targeted process metrics are not reached, and holding regular benchmarkings, audits, maturity assessments and reviews.

Definitions

Change Request to Process Architecture

• A request to change or extend the Process Architecture, usually issued from the Service Design process when the introduction or modification of a service is not possible within the constraints of the existing process framework.

KPI Target Value

• The to-be value of a Key Performance Indicator (KPI). It is the responsibility of the Process Owners to manage and optimize processes so that KPI targets are achieved.

Process Architecture

• An overview of all processes and process interfaces, used as a tool to make sure that all processes within an organization cooperate in a seamless way. The Process Architecture is part the Enterprise Architecture.

Process Assessment Guideline

• A guideline describing the four most-often used approaches to evaluate the underlying service management processes: Process Maturity Assessments, Benchmarks, Audits and Process Reviews.

Process Design

• The description of a process including its inputs and outputs, activities, and responsibilities. Process Designs are under the control of Process Management.

Process Evaluation Program

• The purpose of the Process Evaluation Program is to make sure all relevant processes and areas of the organization are subject to regular Process Maturity Assessments, Benchmarks, Audits and/ or Process Reviews, as appropriate.

Process Evaluation Report

• The results from a Process Maturity Assessment, Benchmarking, Audit, or Process Review, including identified shortcomings and areas which must be addressed by improvement initiatives.

Process Metric (KPI)

• Process Metrics (Key Performance Indicators – KPIs) define what is to be measured and reported to help manage a process.

Seven-Step Improvement Guideline

• The Seven-Step Improvement approach (7-Step Improvement) is presented in the ITIL books as the Seven-Step Improvement Process. Rather than a process it is in fact the description of a methodology which can be universally applied to identify shortcomings in services and processes and to implement improvements.

Suggested Process Improvement

• Suggestion for improving Service Management processes, handed over to the Continual Service Improvement process. Suggestions for process improvements may originate from anywhere within the IT organization.

Roles and Responsibilities

Process Architect - Process Owner

• The Process Architect is responsible for maintaining the Process Architecture (part of the Enterprise Architecture), coordinating all changes to processes and making sure that all processes cooperate in a seamless way.
• This role often also supports all parties involved in managing and improving processes, in particular the Process Owners. Some organizations combine this role with the Enterprise Architect role.

Process Owner

• A role responsible for ensuring that a process is fit for purpose. The Process Owner’s responsibilities include sponsorship, design, and continual improvement of the process and its metrics.
• In larger organizations there might be separate Process Owner and Process Manager roles, where the Process Manager has responsibility for the operational management of a process.

KPIs

Definition of CSI Initiatives

Objective

To define specific initiatives aimed at improving services and processes, based on the results of service reviews and process evaluations. The resulting initiatives are either internal initiatives pursued by the service provider on his own behalf, or initiatives which require the customer’s cooperation.

Definitions

CSI Register

• The CSI Register is used to record and manage improvement opportunities throughout their lifecycle. The addition of new entries to the CSI Register is typically triggered by Continual Service Improvement (see also: ITIL Checklist CSI Register).
• Please note: The CSI Register was referred to as the Service Improvement Plan (SIP) within ITIL V3 (2007).

Roles and Responsibilities

CSI Manager - Process Owner

• The Continual Service Improvement (CSI) Manager is responsible for managing improvements to IT Service Management processes and IT services. He will continually measure the performance of the service provider and design improvements to processes, services and infrastructure in order to increase efficiency, effectiveness, and cost effectiveness.

KPIs

Monitoring of CSI Initiatives

Objective

To verify if improvement initiatives are proceeding according to plan, and to introduce corrective measures where necessary.

Roles and Responsibilities

CSI Manager - Process Owner

• The Continual Service Improvement (CSI) Manager is responsible for managing improvements to IT Services. He will continually measure the performance of the service provider and design improvements to processes, services and infrastructure in order to increase efficiency, effectiveness, and cost effectiveness.