ITIL Concept

Service Design:

Availability Management  (1.8 MB PDF)

Capacity Management  (1.8 MB PDF)

Service Catalog Management  (308 KB PDF)

Service Level Management  (1.3 MB PDF)

Service Transition:

Change Management  (1.2 MB PDF)

Release and Deployment Management  (743 KB PDF)

Service Asset and Configuration Management  (122 KB PDF)

Service Validation and Testing  (1.5 MB PDF)

Service Operations:

Event Management  (1.3 MB PDF)

Incident Management  (705 KB PDF)

Knowledge Management  (1.4 MB PDF)

Problem Management  (1.1 MB PDF)

Request Fulfillment  (292 KB PDF)

Service Strategy Processes (5) 1. Strategy management for IT services (New) 2. Service portfolio management 3. Financial management for IT services 4. Demand management 5. Business relationship management (New) Service Design Processes (8) 1. Design coordination (New) 2. Service catalogue management 3. Service level management 4. Availability management 5. Capacity management 6. IT service continuity management (ITSCM) 7. Information security management 8. Supplier Management Service Transition Processes (7) 1. Transition planning and support 2. Change management 3. Service asset and configuration management 4. Release and deployment management 5. Service validation and testing 6. Change evaluation (Renamed) 7. Knowledge management

Service Operation Processes (5) 1. Event management 2. Incident management 3. Request fulfillment 4. Problem management 5. Access management

Continual Service Improvement Processes (1)

1.Seven-step improvement process

**Service Operation Functions (4) 1. Service Desk 2. Technical Management 3. IT Operations Management 4. Application Management

Service Strategy Processes- 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 process 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.

As per ITIL 2011, the following processes are part of the ITIL stage Service Strategy:

Strategy Management for IT Services Process 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.

Service Portfolio Management

Process 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.

Demand Management Process 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.

Financial Management for IT Services Process Objective: To manage the service provider's budgeting, accounting and charging requirements.

Business Relationship Management Process 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.

Strategy Management for IT Services Process 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.

Sub-Processes

These are the Strategy Management for IT Services sub-processes and their process objectives:

Strategic Service Assessment

Process Objective: To assess the present situation of the service provider within its current market spaces. This includes an assessment of current service offerings, customer needs and competing offers from other service providers.

Service Strategy Definition

Process Objective: To define the overall goals the service provider should pursue in its development, and to identify what services will be offered to what customers or customer segments, based on the results of the Strategic Service Assessment.

Service Strategy Execution

Process Objective: To define and plan strategic initiatives, and ensure the implementation of those initiatives.

Definitions

The following ITIL terms and acronyms (information objects) are used in Strategy Management for IT Services to represent process outputs and inputs:

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

Responsibility Matrix: ITIL Strategy Management

ITIL Role | Sub-Process Service Strategy Manager IT Steering Group

Strategic Service Assessment A[1]R[2] R

Service Strategy Definition AR R

Service Strategy Execution AR -

ITIL KPIs Strategy Management for IT Services and Service Portfolio Management

Key Performance Indicator (KPI)

Definition

Number of Planned New Services

Percentage of new services which are developed following a strategic review

Number of Unplanned New Services

Percentage of new services which are developed without being triggered by strategic reviews

Number of Strategic Initiatives Number of strategic initiatives launched from the

Service Portfolio Management process

Number of new Customers Number of newly won customers

Number of lost Customers Number of customers which were lost to competing

service providers

ITIL KPIs Financial Management

Key Performance Indicator (KPI)

Definition

Adherence to Budgeting Process Percent of projects using the standard IT budgeting

process

Cost-/ Benefit Estimation Percent of project files containing cost-/ benefit

estimates

Post Implementation Review Percent of projects where costs and benefits are

verified after implementation

Adherence to Approved Budget Percent of IT expenses exceeding the approved budget

Adherence to Project Resources Percent of expenses exceeding the planned budget for a

project

Proposals for Cost Optimization Number of proposals by Financial Management for the

optimized use of financial resources

ITIL KPIs Business Relationship Management

Key Performance Indicator (KPI)

Definition

Number of Customer Complaints

Number of received customer complaints

Number of accepted Customer Complaints

Number of received customer complaints which were accepted as justified

Number of Customer Satisfaction Surveys

Number of formal Customer Satisfaction Surveys

carried out during the reporting period

Percentage of returned Questionnaires

Percentage of questionnaires returned, in relation to all questionnaires being sent out

Customer Satisfaction per Service

Average measured customer satisfaction for each Service (including standard deviation), determined by means of Customer Satisfaction Surveys.

Service Portfolio Management Process 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.

Sub-Processes

These are the ITIL Service Portfolio Management sub-processes and their process objectives:

-Define and Analyze new or changed Services Process Objective: To define the desired outcomes of a proposed new or changed service, analyze the impacts on existing services in the Service Portfolio, and determine the assets required to offer the service.

-Approve new or changed Services Process Objectives: To submit a formal Change Proposal to Change Management, and to initiate the design stage for the new or changed service if the Change Proposal is authorized.

-Service Portfolio Review Process Objectives: To assess the Service Portfolio at regular intervals in order to ensure the service provider offers economically viable services which are aligned with the Service Strategy. This process also keeps the Service Portfolio up to date

Definitions

The following ITIL terms and acronyms (information objects) are used in Service Portfolio Management to represent process outputs and inputs:

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. (Note: New output in ITIL 2011.)

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. (Note: New output in ITIL 2011.)

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 (see also: ITIL Checklist Service Portfolio).

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

Responsibility Matrix: Service Portfolio Management

ITIL Role | Sub-Process Service

Portfolio Manager

IT Steering Group

Financial Manager[3]

Service Owner[3]

Applications Analyst[3]

Technical Analyst[3]

Define and Analyze new or changed Services

A[1]R[2] R R R R R

Approve new or changed Services

AR - - - - -

Service Portfolio Review

Service Portfolio - Contents

For each service the Service Portfolio defines:

Name

Current lifecycle status of the service

(e.g., "Proposed", "Defined", "Chartered", "Designed", "Built", "Tested", "Released", "Operational", "Retired")

Service Type

1. Customer-facing service (services delivered to the customers) or supporting/technical service (invisible to the customers, used to underpin customer-facing services)

2. Internal/ external: Internally provided service or a service sourced from an external service supplier

Service Owner

(responsibility for service provisioning)

Customers

(customers currently using this service)

Contacts and procedures for signing up to the service

1. e.g. contact details of the responsible Service Level Manager 2. Procedure for signing up

Description/ desired customer outcome

1. Business justification (value added from a business point of view) 2. Business processes/ activities on the customer side supported by the service 3. Desired outcome in terms of utility (example: "Field staff can access enterprise applications xxx

and yyy without being constrained by location or time") 4. Desired outcome in terms of warranty (example: "Access is facilitated worldwide in a secure and

reliable manner")

Offerings and packages, variations

1. e.g. different Service Level packages on offer 2. e.g. different coverage of time zones 3. e.g. different coverage of geographical regions

Costs and pricing

1. Available pricing schemes for the service provision 2. Rules for penalties/ charge backs

Dependencies

1. Services 1. Required Infrastructure Services (Infrastructure Services on which this service depends) 2. Supported services (other services which depend on this service)

2. Components/ Configuration Items (major CIs like on which this service depends)

Planned changes to the service

(if any)

1. References to relevant plans (e.g. Service Strategy Plan, Strategic Action Plans, entries in the CSI Register)

2. Business case/ cost-benefit analysis 3. Priority of the envisaged change 4. Risks associated with the envisaged change 5. Time schedule and status information

The Service Portfolio is divided into three sections: Service Pipeline, Active Services (Service Catalogue), and Retired Services. Services should be clustered according to Lines of Service based on common business activities they support. Only active services are visible to customers.

Demand Management Process 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.

The role Demand Manager has been introduced to perform the activities in the Demand Management process.

Financial Management for IT Services

Process Objective: To manage the service provider's budgeting, accounting and charging requirements.

Sub-Processes

No sub-processes are specified for ITIL Demand Management.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Demand Management to represent process outputs and inputs:

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. (Note: New output in ITIL 2011.)

Sub-Processes

These are the ITIL Financial Management sub-processes and their process objectives:

Financial Management Support

Process Objective: To define the necessary structures for the management of financial planning data and costs, as well as for the allocation of costs to services.

Financial Planning

Process Objective: To determine the required financial resources over the next planning period ("IT Budget"), and to allocate those resources for optimum benefits.

Financial Analysis and Reporting

Process Objective: To analyze the structure of service provisioning cost and the profitability of services. The resulting financial analysis allows Service Portfolio Management to make informed decisions when deciding about changes to the Service Portfolio.

Service Invoicing

Process Objective: To issue invoices for the provision of services and transmission of the invoice to the customer.

Definitions

The following ITIL terms and acronyms (information objects) are used in Financial Management for IT Services to represent process outputs and inputs:

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 (see also: ITIL Checklist Financial Analysis).

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.

Business Relationship Management Process 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.

Service Design

Process Objective: To design new IT services. Its scope includes the design of new services, as well as changes and improvements to existing ones.

As per ITIL 2011, the following processes are part of the ITIL stage Service Design:

Design Coordination Process 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.

Service Catalogue Management Process 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.

Service Level Management Process 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.

Risk Management Process 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.

Capacity Management Process 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.

Availability Management Process 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.

IT Service Continuity Management

Process 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.

Information Security Management Process 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.

Compliance Management Process Objective: To ensure IT services, processes and systems comply with enterprise policies and legal requirements.

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

Supplier Management Process Objective: To ensure that all contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.

Design Coordination

Overview

Objective: ITIL Design Coordination aims 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.

Part of: Service Design

Process Owner: Service Design Manager

Process Description

ITIL Design Coordination

Design Coordination has been added as a new process, in line with the latest ITIL 2011 guidance. Design Coordination is now responsible for coordinating the design activities carried out by other Service Design processes.

In the previous ITIL version, some of these tasks were carried out as part of Service Level Management, which is why the sub-processes Decomposition of Business Service into Supporting Services, Technical and Organizational Service Design and RFC Compilation and Submission have been moved from Service Level Management to Design Coordination.

The process overview of ITIL Design Coordination is showing the most important interfaces (see Figure 1).

Sub-Processes

These are the ITIL Design Coordination sub-processes and their process objectives:

Design Coordination Support

Process Objective: To coordinate and develop Service Design resources and capabilities, and to ensure that a consistent approach to designing new or changed services is adopted across all service transition projects.

Service Design Planning

Process Objective: To plan design activities in detail, making sure that all relevant aspects are considered during service design.

Service Design Coordination and Monitoring

Process Objective: To coordinate the design activities performed by various Service Design processes, and to determine if the new or changed service can be provided economically. This process is also responsible for deciding if the clients' requirements can be fulfilled or must be renegotiated.

Technical and Organizational Service Design

Process Objective: To determine how a new service will be provided from an IT perspective. In particular, this means to specify any technical infrastructure to be created, as well as required organizational changes. The resulting Service Design Package contains all relevant information for Service Transition.

Service Design Review and RFC Submission

Process Objective: To submit the Service Design Package to a final review and initiate the implementation of the service by submitting a formal Request for Change.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Design Coordination to represent process outputs and inputs:

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 (see also: ITIL Checklist Service Design Package).

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.

Service Catalogue Management Process 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.

Sub-Processes

No sub-processes are specified for Service Catalogue Management.

Definitions

The following ITIL terms and acronyms (information objects) are used in Service Catalogue Management to represent process outputs and inputs:

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.

Service Level Management Process 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

Sub-Processes

These are the Service Level Management sub-processes and their process objectives:

Maintenance of the SLM Framework

Process Objective: To design and maintain the underlying structure of the Customer Agreement Portfolio, and to provide templates for the various SLM documents.

Identification of Service Requirements

Process Objective: To capture desired outcomes (requirements from the customer viewpoint) for new services or major service modifications. The service requirements are to be documented and submitted to an initial evaluation, so that alternatives may be sought at an early stage for requirements which are not technically or economically feasible.

Agreements Sign-Off and Service Activation

Process Objective: To have all relevant contracts signed off after completion of Service Transition, and to check if Service Acceptance Criteria are fulfilled. In particular, this process makes sure that all relevant OLAs are signed off by their Service Owners, and that the SLA is signed off by the customer.

Service Level Monitoring and Reporting

Process Objective: To monitor achieved service levels and compare them with agreed service level targets ("Service Level Report"). This information is circulated to customers and all other relevant parties, as a basis for measures to improve service quality.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Service Level Management to represent process outputs and inputs:

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 (see also: ITIL Checklist SLA - OLA).

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 (see also: ITIL Checklist SLA - OLA).

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, ...

Checklists | KPIs

Key Performance Indicators (KPIs) Service Level Management Checklists Service Level Management :

o Checklist Service Level Agreement (SLA) - Operational Level Agreement (OLA) , and o Checklist Service Level Requirements (SLR) o Checklist Service Level Report o Checklist Protocol SLA Review

Risk Management

Process 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.

Sub-Processes

These are the ITIL Risk Management sub-processes and their process objectives:

Risk Management Support

Process Objective: To define a framework for Risk Management. Most importantly, this process specifies how risk is quantified, what risks the organization is willing to accept, and who is in charge of the various Risk Management duties.

Business Impact and Risk Analysis

Process Objective: To quantify the impact to the business that a loss of service or asset would have, and to determine the likelihood of a threat or vulnerability to actually occur. The result of the "Business Impact and Risk Analysis" is the Risk Register, a prioritized list of risks which must be subsequently addressed.

Assessment of Required Risk Mitigation

Process Objective: To determine where risk mitigation measures are required, and to identify Risk Owners who will be responsible for their implementation and ongoing maintenance.

Risk Monitoring

Process Objective: To monitor the progress of counter measure implementation, and to take corrective action where necessary

Capacity Management Process 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.

Sub-Processes

These are the Capacity Management sub-processes and their process objectives:

Business Capacity Management

Process Objective: To translate business needs and plans into capacity and performance requirements for services and IT infrastructure, and to ensure that future capacity and performance needs can be fulfilled.

Service Capacity Management

Process Objective: To manage, control and predict the performance and capacity of operational services. This includes initiating proactive and reactive action to ensure that the performances and capacities of services meet their agreed targets.

Component Capacity Management

Process Objective: To manage, control and predict the performance, utilization and capacity of IT resources and individual IT components.

Capacity Management Reporting

Process Objective: To provide other Service Management processes and IT Management with information related to service and resource capacity, utilization and performance (see "Capacity Report").

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Capacity Management to represent process outputs and inputs:

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. (see: ITIL Checklist Capacity Plan)

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.

Note: The output "Event Filtering and Correlation Rules" has been added in ITIL 2011, to emphasize that (some) Event filtering and correlation rules should be designed by Capacity Management to support the detection of capacity issues.

Availability Management Process 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.

Sub-Processes

These are the ITIL Availability Management sub-processes and their process objectives:

Design Services for Availability

Process Objective: To design the procedures and technical features required to fulfill the agreed availability levels.

Availability Testing

Process Objective: To make sure that all availability, resilience and recovery mechanisms are subject to regular testing.

Availability Monitoring and Reporting

Process Objective: To provide other Service Management processes and IT Management with information related to service and component availability. This includes comparing achieved vs. agreed availability and the identification of areas where availability must be improved.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Availability Management to represent process outputs and inputs:

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.

Note: The output "Event Filtering and Correlation Rules" has been added in ITIL 2011, to emphasize that (some) Event filtering and correlation rules should be designed by Availability Management to support the detection of availability issues.

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.

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

Sub-Processes

No sub-processes are specified for ITIL Architecture Management.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Architecture Management to represent process outputs and inputs:

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

ITIL KPIs Service Level Management

Key Performance Indicator (KPI)

Definition

Services covered by SLAs Number of services covered by SLAs

Services covered by OLAs/ UCs Number of Services where SLAs are backed up by

corresponding OLAs/ UCs

Monitored SLAs Number of monitored Services/ SLAs, where weak-

spots and counter-measures are reported

SLAs under Review Number of Services/ SLAs which are regularly

reviewed

Fulfilment of Service Levels Number of Services/ SLAs where the agreed service

levels are fulfilled

Number of Service Issues Number of issues in the service provision, which are

identified and addressed in an improvement plan

ITIL KPIs Capacity Management

Key Performance Indicator (KPI)

Definition

Incidents due to Capacity Shortages

Number of incidents occurring because of insufficient service or component capacity

Exactness of Capacity Forecast Deviation of the predicted capacity development from

actual course

Capacity Adjustments Number of adjustments to service and component

capacities due to changing demand

Unplanned Capacity Adjustments

Number of unplanned increases to service or component capacity as result of capacity bottlenecks

Resolution Time of Capacity Shortage

Resolution time for identified capacity bottlenecks

Capacity Reserves Percentage of capacity reserves at times of normal and

maximum demand

Percentage of Capacity Monitoring

Percentage of services and infrastructure components under capacity monitoring

ITIL KPIs Availability Management

Key Performance Indicator (KPI)

Definition

Service Availability Availability of IT Services relative to the availability

agreed in SLAs and OLAs

Number of Service Interruptions Number of service interruptions

Duration of Service Interruptions

Average duration of service interruptions

Availability Monitoring Percentage of services and infrastructure components

under availability monitoring

Availability Measures Number of implemented measures with the objective

of increasing availability

ITIL KPIs IT Service Continuity Management

Key Performance Indicator (KPI)

Definition

Business Processes with Continuity Agreements

Percentage of business processes which are covered by explicit service continuity targets

Gaps in Disaster Preparation

Number of identified gaps in the preparation for disaster events (major threats without any defined counter measures)

Implementation Duration

Duration from the identification of of a disaster-related risk to the implementation of a suitable continuity mechanism

Number of Disaster Practices Number of disaster practices actually carried out

Number of identified Shortcomings during Disaster Practices

Number of identified shortcomings in the preparation for disaster events which are identified during practices

ITIL KPIs Information Security Management

Key Performance Indicator (KPI)

Definition

Number of implemented Preventive Measures

Number of preventive security measures which were implemented in response to identified security threats

Implementation Duration Duration from the identification of a security threat to

the implementation of a suitable counter measure

Number of major Security Incidents

Number of identified security incidents, classified by severity category

Number of Security-related Service Downtimes

Number of security incidents causing service interruption or reduced availability

Number of Security Tests Number of security tests and trainings carried out

Number of identified Shortcomings during Security Tests

Number of identified shortcomings in security mechanisms which were identified during tests

ITIL KPIs Supplier Management

Key Performance Indicator (KPI)

Definition

Number of agreed UCs Percentage of contracts underpinned by UCs

Number of Contract Reviews Number of conducted contract and supplier reviews

Number of identified Contract Breaches

Number of contractual obligations which were not fulfilled by suppliers (identified during contract reviews)

Service Transition

Process Objective: To build and deploy IT services. This process also makes sure that changes to services and Service Management processes are carried out in a coordinated way.

Change Management Process 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.

Change Evaluation Process 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.

Project Management (Transition Planning and Support)

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

Application Development Process 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.

Release and Deployment Management Process 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.

Service Validation and Testing Process 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.

Service Asset and Configuration Management Process Objective: To maintain information about Configuration Items required to deliver an IT service, including their relationships.

Knowledge Management Process 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.

Change Management:These are the ITIL Change Management sub-processes and their process objectives:

Change Management Support

Process Objective: To provide templates and guidance for the authorization of Changes, and to supply the other IT Service Management processes with information on planned and ongoing Changes.

Assessment of Change Proposals

Process Objective: To asses Change Proposals which are typically submitted for significant Changes by Service Strategy. The purpose of assessing Change Proposals is to identify possible issues prior to the start of design activities.

RFC Logging and Review

Process Objective: To filter out Requests for Change which do not contain all information required for assessment or which are deemed impractical.

Assessment and Implementation of Emergency Changes

Process Objective: To assess, authorize and implement an Emergency Change as quickly as possible. This process is invoked if normal Change Management procedures cannot be applied because an emergency requires immediate action.

Change Assessment by the Change Manager

Process Objective: To determine the required level of authorization for the assessment of a proposed Change. Significant Changes are passed on to the CAB for assessment, while minor Changes are immediately assessed and authorized by the Change Manager.

Change Assessment by the CAB

Process Objective: To assess a proposed Change and authorize the Change planning phase. If required, higher levels of authority (e.g. IT Management) are involved in the authorization process.

Change Scheduling and Build Authorization

Process Objective: To authorize detailed Change and Release planning, and to assess the resulting Project Plan prior to authorizing the Change Build phase.

Change Deployment Authorization

Process Objective: To assess if all required Change components have been built and properly tested, and to authorize the Change Deployment phase.

Minor Change Deployment

Process Objective: To implement low-risk, well-understood Changes which do not require the involvement of Release Management.

Post Implementation Review and Change Closure

Process Objective: To assess the course of the Change implementation and the achieved results, in order to verify that a complete history if activities is present for future reference, and to make sure that any mistakes are analyzed and lessons learned.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Change Management to represent process outputs and inputs:

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 (see also: ITIL Checklist Request for Change - RFC).

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.

Project Management (Transition Planning and Support) Process Objective: To plan and coordinate the resources to deploy a major Release within the predicted cost, time and quality estimates.

Sub-Processes

These are the ITIL Project Management (Transition Planning and Support) sub-processes and their process objectives:

Project Initiation

To define stakeholders, responsibilities and resources available to the project, as well as documenting risks, constraints and assumptions affecting the project.

Project Planning and Coordination

To make sure service transitions projects are planned in accordance with the organization's Project Management guidelines, and to coordinate activities and resources across projects. This process is not responsible for detailed planning of project phases but triggers planning activities performed by other processes.

Project Control

To monitor project progress and resource consumption, to expedite progress when required and to initiate corrective action if required.

Project Reporting and Communication

To provide an overall summary of all planned or ongoing Service Transition projects as information for customers and other Service Management processes.

Definitions

The following ITIL terms and acronyms (information objects) are used in the ITIL Project Management process to represent process outputs and inputs:

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.

Service Asset and Configuration Management Process Objective: To maintain information about Configuration Items required to deliver an IT service, including their relationships.

ITIL V3 introduces the Configuration Management System (CMS) as a logical data model, encompassing several Configuration Management Databases (CMDB).

Sub-Processes

These are the ITIL Configuration Management sub-processes and their process objectives:

Configuration Identification

Process Objective: To define and maintain the underlying structure of the CMS (the Configuration Model), so that it is able to hold all information on Configuration Items (CIs). This includes specifying the attributes describing CI types and their sub-components, as well as determining their interrelationships.

Configuration Control

Process Objective: To ensure that no Configuration Items are added or modified without the required authorization, and that such modifications are adequately recorded in the CMS.

Note: ITIL Configuration Control is mainly concerned with reviewing modifications to the Configuration Management System (CMS), to make sure the information stored in the CMS is

complete and the modification was done by an authorized party. Other processes also support the objectives of Configuration Control: Configuration Identification defines who is authorized to make certain changes to the CMS. In a broader sense, Change Management and Release Management with their defined procedures also help to ensure that no unauthorized changes occur.

Configuration Verification and Audit

Process Objective: To perform regular checks, ensuring that the information contained in the CMS is an exact representation of the Configuration Items (CIs) actually installed in the live production environment.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Confoguration Management to represent process outputs and inputs:

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. (See also: ITIL Checklist CMS - CMDB).

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.

Release and Deployment Management Process 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.

Knowledge Management Process 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.

-No sub process

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.

Sub-Processes

These are the ITIL Release Management sub-processes and their process objectives:

Release Management Support

Process Objective: To provide guidelines and support for the deployment of Releases.

Release Planning

Process Objective: To assign authorized Changes to Release Packages and to define the scope and content of Releases. Based on this information, the Release Planning process develops a schedule for building, testing and deploying the Release.

Release Build

Process Objective: To issue all necessary Work Orders and Purchase Requests so that Release components are either bought from outside vendors or developed/ customized in-house. At the end of this process, all required Release components are ready to enter the testing phase.

Release Deployment

Process Objective: To deploy the Release components into the live production environment. This process is also responsible for training end-users and operating staff and circulating information/ documentation on the newly deployed Release or the services it supports.

Early Life Support

Process Objective: To resolve operational issues quickly during an initial period after Release deployment, and to remove any remaining errors or deficiencies.

Release Closure

Process Objective: To formally close a Release after verifying if activity logs and CMS contents are up to date.

Definitions

The following ITIL terms and acronyms (information objects) are used in ITIL Release Management to represent process outputs and inputs:

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 (see also: ITIL Checklist Release Policy).

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.

TIL KPIs Change Management

Key Performance Indicator (KPI)

Definition

Number of Major Changes Number of major changes assessed by the CAB

(Change Advisory Board)

Number of CAB Meetings Number of CAB (Change Advisory Board) meetings

Time for Change Approval/ Rejection

Average time from registering an RFC with Change Management until a decision on the RFC is reached

(i.e. until it is either approved or rejected)

Change Acceptance Rate Number of accepted vs. rejected RFCs

Number of Emergency Changes Number of Emergency Changes assessed by the ECAB

(Emergency Change Advisory Board)

ITIL KPIs Project Management (Transition Planning and Support)

Key Performance Indicator (KPI)

Definition

Number of Projects Number of major release rollouts under the control of

Project Management

Percentage of Projects with Project Charters

Percentage of projects which are started with a signed Project Charter in place

Number of Changes to Project Charter

Number of changes to the Project Charter after project start

Adherence to Project Budget Actual vs. planned consumption of financial and

personnel resources

Project Delays Actual vs. planned project completion dates

ITIL KPIs Release and Deployment Management

Key Performance Indicator (KPI)

Definition

Number of Releases Number of releases rolled out into the productive

environment, grouped into Major and Minor Releases

Duration of Major Deployments Average duration of major deployments from

clearance until completion

Number of Release Backouts Number of releases which had to be reversed

Proportion of automatic Release Distribution

Proportion of new releases distributed automatically

Service Operation

Process Objective: To make sure that IT services are delivered effectively and efficiently. This includes fulfilling user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks.

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

Incident Management Process 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.

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

Access Management Process 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.

Problem Management Process 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.

IT Operations Control Process 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.

Facilities Management Process 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.

Application Management Application Management is responsible for managing applications throughout their lifecycle.

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

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

Sub-Processes

These are the ITIL Event Management sub-processes and their process objectives:

Maintenance of Event Monitoring Mechanisms and Rules

Process Objective: To set up and maintain the mechanisms for generating meaningful Events and effective rules for their filtering and correlating.

Event Filtering and 1st Level Correlation

Process Objective: To filter out Events which are merely informational and can be ignored, and to communicate any Warning and Exception Events.

2nd Level Correlation and Response Selection

Process Objective: To interpret the meaning of an Event and select a suitable response if required.

Event Review and Closure

Process Objective: To check if Events have been handled appropriately and may be closed. This process also makes sure that Event logs are analyzed in order to identify trends or patterns which suggest corrective action must be taken.

Definitions

The following ITIL terms and acronyms (information objects) are used in the ITIL Event Management process to represent process outputs and inputs:

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

Incident Management Process 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.

Sub-Processes

These are the ITIL Incident Management sub-processes and their process objectives:

Incident Management Support

Process Objective: ITIL Incident Management Support aims to provide and maintain the tools, processes, skills and rules for an effective and efficient handling of Incidents.

Incident Logging and Categorization

Process Objective: To record and prioritize the Incident with appropriate diligence, in order to facilitate a swift and effective resolution.

Immediate Incident Resolution by 1st Level Support

Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the IT service, where necessary with the aid of a Workaround. As soon as it becomes clear that 1st Level Support is not able to resolve the Incident itself or when target times for 1st level resolution are exceeded, the Incident is transferred to a suitable group within 2nd Level Support.

Incident Resolution by 2nd Level Support

Process Objective: To solve an Incident (service interruption) within the agreed time schedule. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to Problem Management.

Handling of Major Incidents

Process Objective: To resolve a Major Incident. Major Incidents cause serious interruptions of business activities and must be resolved with greater urgency. The aim is the fast recovery of the service, where necessary by means of a Workaround. If required, specialist support groups or third-party suppliers (3rd Level Support) are involved. If the correction of the root cause is not possible, a Problem Record is created and the error-correction transferred to Problem Management.

Incident Monitoring and Escalation

Process Objective: To continuously monitor the processing status of outstanding Incidents, so that counter-measures may be introduced as soon as possible if service levels are likely to be breached.

Incident Closure and Evaluation

Process Objective: To submit the Incident Record to a final quality control before it is closed. The aim is to make sure that the Incident is actually resolved and that all information required to describe the Incident's life-cycle is supplied in sufficient detail. In addition to this, findings from the resolution of the Incident are to be recorded for future use.

Pro-Active User Information

Process Objective: To inform users of service failures as soon as these are known to the Service Desk, so that users are in a position to adjust themselves to interruptions. Proactive user information also aims to reduce the number of inquiries by users. This process is also responsible for distributing other information to users, e.g. security alerts.

Incident Management Reporting

Process Objective: ITIL Incident Management Reporting aims to supply Incident-related information to the other Service Management processes, and to ensure that that improvement potentials are derived from past Incidents.

Definitions

The following ITIL terms and acronyms (information objects) are used in the ITIL Incident Management process to represent process outputs and inputs:

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. See also: Checklist Incident Priority

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). See also: ITIL Checklist Incident Record

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.

ITIL KPIs Incident Management

Key Performance Indicator (KPI)

Definition

Number of repeated Incidents Number of repeated Incidents, with known resolution

methods

Incidents resolved Remotely

Number of Incidents resolved remotely by the Service Desk

(i.e.without carrying out work at user's location)

Number of Escalations Number of escalations for Incidents not resolved in the

agreed resolution time

Number of Incidents Number of incidents registered by the Service Desk grouped into categories

Average Initial Response Time

Average time taken between the time a user reports an Incident and the time that the Service Desk responds to that Incident

Incident Resolution Time Average time for resolving an incident grouped into categories

First Time Resolution Rate

Percentage of Incidents resolved at the Service Desk during the first call

grouped into categories

Resolution within SLA

Rate of incidents resolved during solution times agreed in SLA

grouped into categories

Incident Resolution Effort Average work effort for resolving Incidents grouped into categories

ITIL KPIs Problem Management

Key Performance Indicator (KPI)

Definition

Number of Problems

Number of Problems registered by Problem Management

grouped into categories

Problem Resolution Time Average time for resolving Problems grouped into categories

Number of unresolved Problem Number of Problems where the underlying root cause

is not known at a particular time

Number of Incidents per Known Problem

Number of reported Incidents linked to the same Problem after problem identification

Time until Problem Identification

Average time between first occurance of an Incident and identification of the underlying root cause

Problem Resolution Effort Average work effort for resolving Problems grouped into categories

Study on Vendor Products

BMC- Readmy suits 8, cmdb Atrium,

HP

IBM- Netcol,

CA

Job description

Design, deploy and integrate Service Management tools for the IT Shared Services project

Integrate existing BU Service Management tools and work with peer architects to come up with a viable solution.

Planning, managing, and participating in the diagnosis, detailed design, and deployment of Service Management related processes and technologies.

Performing technology evaluation and selection efforts.

Direct as well as perform project steps and technical hands-on tasks within a team environment.

Exercises significant independent judgment while working through both an architectural approach and detailed project plan steps.

Produce and update project related documentation – problem statement documentations, technical details for self-service automation, and business process flows.

Provides recommendations surrounding process improvements and policies.

        Qualifications

7-10 years’ experience in architecting solutions based on ITIL standards.

7-10 years’ experience in the usage and incorporation of monitoring tools in to service center offerings

7-10 years’ experience in leading or supporting business development activities from medium to large opportunities

Deep expertise with IT architectural, development and operational methodologies

Full lifecycle CMS/CMDB/Configuration Management design and deployment experience

Experience implementing ITSM or IT Operations related software solutions is desired e.g BMC Remedy, HP Service Manager, IBM Tivoli etc.

Knowledge and experience with industry standard methodologies

ITIL v3 Foundations Certification preferred.

CMDB

Configuration management databaseFrom Wikipedia, the free encyclopedia

A configuration management database (CMDB) is a repository of information related to all the components

of an information system. It contains the details of the configuration items (CI) in the IT infrastructure. Although

repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems

from ITIL. In the ITIL context, a CMDB represents the authorized configuration of the significant components of

the IT environment. A CMDB helps an organization understand the relationships between these components

and track their configuration. The CMDB is a fundamental component of the ITIL framework's Configuration

Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB

from other sources, such as Asset Management, in such a way that the source of the data retains control of the

data. Federation is usually distinguished from Extract, transform, load (ETL) solutions in which data is copied

into the CMDB.

The CMDB records CIs and details about the important attributes and relationships between CIs. Configuration

managers usually describe CIs using three configurable attributes:

1. Technical

2. Ownership

3. Relationship

A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs

(auto-discovery) and track changes as they happen.

CMDBs contain metadata, and thus the concept overlaps with that of a metadata repository which are both

used in running large IT organizations. Configuration management addresses how the data is to be kept up to

date, which has historically been a weakness of metadata repositories.

The CMDB module with the Tracker, Wiki, Search and Report components is a flexible framework for

Incident Management,

Problem Management,

Knowledge Management,

Asset management,

Change Management,

Service Desk and

Reporting

CMDB VS CMS

CMDB - (Service Transition) A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

CMS - (Service Transition) A set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes.

There are a couple of points to take away from these definitions:

1. CMDB is a database only, while the CMS also includes tools2. CMS maintains one or more CMDBs3. CMS is used by all IT Service Management processes 

Activities

The information in the CMDB is used for five basic activities:

1. Planning: The CM plan covers the next three to six months in detail, and the following twelve months in outline. It is reviewed at least twice

a year and will include a strategy, policy, scope, objectives, roles and responsibilities, the CM processes, activities and procedures, the

CMDB, relationships with other processes and third parties, as well as tools and number of CI categories to track in the CMDB determines

the scope. The detail of the CI information is the depth.

2. Identification: The selection, identification and labeling of all CIs which creates a parts list of every CI in the system. This covers the

recording of information about CI's, including hardware and software versions, documentation, ownership and other unique identifiers. CIs

should be recorded at a level of detail justified by the business need, typically to the level of "independent change". This includes defining

the relationships of the CIs in the system.

3. Control: This gives the assurance that only authorized and identifiable CIs are accepted and recorded from receipt to disposal. It ensures

that no CI is added, modified, replaced or removed without the appropriate controlling documentation e.g. approved Requests for Change

of a CI, updated specification. All CIs will be under Change Management (ITSM) control.

4. Monitoring: Concerned with each CI throughout its life-cycle. It enables changes to CIs and tracking of their records through various

statuses, e.g. ordered, received, under test, live, under repair, withdrawn or for disposal.

5. Verification: The reviews and audits that verify the physical existence of CIs, and checks that they are correctly recorded in the CMDB and

parts list. It includes the process of verifying Release Management (ITSM) and CM documentation before changes are made to the live

environment.

Change:

Incident Process(BMC)

Problem management (BMC)

Solution design:

Enterprise architectureEnterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating

and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution.[1]

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of

business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding,

architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.[2]