ITIL v3 (Information Technology Infrastructure Library)/Printable version

ITIL v3 (Information Technology Infrastructure Library)

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/ITIL_v3_(Information_Technology_Infrastructure_Library)

Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 License.

Introduction

The Information Technology Infrastructure Library (ITIL) is a collection of concepts and practices combined in a series of books to be applied in IT Service Management (ITSM), IT development and IT operations. At first it was created in late of 1980 by Central Computing and Telecommunication Agency (CCTA). The names ITIL and IT Infrastructure Library are registered trademarks of the United Kingdom's Office of Government Commerce (OGC).

ITIL can be classified as a collection of best practices, and its target is large companies, as well small ones.

ITILv3 in numbers:

• Five books - Strategy, Design, Transition, Operation and Continual Service Improvement (CSI)
• 84 checklists and document templates
• 23 overall process - two for Strategy, 10 for Design, seven for Transition, seven for Operation and four for CSI

History

Responding to growing dependence on IT, the UK Government's Central Computer and Telecommunications Agency (CCTA) in the 1980s developed a set of recommendations. It recognised that without standard practices, government agencies and private sector contracts were independently creating their own IT management practices.

The IT Infrastructure Library originated as a collection of books, each covering a specific practice within IT Service Management. ITIL was built around a process-model based view of controlling and managing operations often credited to W. Edwards Deming and his plan-do-check-act (PDCA) cycle.

After the initial publication in 1989-1996, the number of books quickly grew within ITIL v1 to over 30 volumes.

In 2000/2001, to make ITIL more accessible (and affordable), ITIL v2 consolidated the publications into eight logical "sets" that grouped related process-guidelines to match different aspects of IT management, applications, and services. However, the main focus was known as the Service Management sets (Service Support and Service Delivery), which were by far the most widely used, circulated, and understood of ITIL v2

In April 2001 the CCTA was merged into the Office of Government Commerce (OGC), an office of the UK Treasury. In 2006, the ITIL v2 glossary was published. In May 2007, this organisation issued the version 3 of ITIL (also known as the ITIL Refresh Project) consisting of 26 processes and functions, now grouped under only 5 volumes, arranged around the concept of Service life cycle structure. In 2009, the OGC officially announced that ITIL v2 would be withdrawn and launched a major consultation as per how to proceed.

Service

According to Wikipedia, service is "an intangible equivalent of an economic good". Customers "buy" a service when they:

• Don't want or can afford with service price; OR
• Don't want or can afford with risk.

Service price or risk can't be used as basis to define service value.

Service value

A service value is defined by fit to purpose (utility) and fit to use (warranty). Fit to purpose, or utility, means that service must fulfil customer needs. It doesn't matter that you rent a specialised black-and-white printer for half of the average market price if the user really needs a colour wax printer.

Fit for use, or warranty, means that service is available when a user needs it. A good example for this is a cell phone; it needs to be ready to use wherever you want to place a call. If connection keeps dropping every time, it is worthless. Warranty can be measured by availability, capacity, continuity and security.

Definition of commerce

Some definitions for better understanding of ITIL.

Portfolio

Portfolio comprises all services offered (current), retired, or to be offered. Current services are available in Catalog. Services being developed - to be offered - can be found in Pipeline. When a service ceases to be offered, it goes to Retired list.

Service Strategy

Service Strategy is the center and origin point of the ITIL Service Lifecycle. It provides guidance on clarification and prioritization of service-provider investments in services. More generally, Service Strategy focuses on helping IT organizations improve and develop over the long term. In both cases, Service Strategy relies largely upon a market-driven approach.

This is a view of ITIL where IT and business align their visions. Its key topics covered include service value definition, business-case development, service assets, market analysis, and service provider types. List of covered processes:

• Strategy Management
• Service Portfolio Management
• IT Financial Management
• Demand Management
• Business Relationship Management

Importance of this view is because this phase that is responsible to define service value. When defining a service is important to have in mind four Ps for strategy: Perspective, Position, Plan, Pattern.

Strategy activities are:

• Define market
• Develop strategic offer
• Develop strategic assets
• Prepare for execution

Service Strategy

Principles

When defining a service, strategist must have in mind list of principles, as stated below:

• Value creation
• Service assets
• Service provider types
• Service structure

Stages

Stages for definition of strategy are:

1. Define
2. Analyze
3. Approval
4. Charter

Service provider types

There are three types of service providers, that may include service provided as well providers for the service:

1. Internal service provider: exists within an organization and provides service solely for a unique business unit
2. Shared service unit: exists within an organization, but provides service for more than one business unit
3. External service provider: operates outside organization

Processes

Service strategy has two processes: Service Portfolio Management and IT Financial Management, as depicted below.

Service Portfolio Management

Owned by service portfolio manager, it is composed of four sub-processes:

• Strategic service assessment: assesses current service in the market.
• Service strategy definition: to define overall goals of the service, as well to define customer and customer segmentation.
• Service portfolio update: adjusts services offered in portfolio based on strategy definition.
• Strategic planning: defines, initiates and controls the program and projects required to execute Service Strategy.
• Demand Management: Service Strategy.

IT Financial Management

Owned by financial manager, it is composed of four sub-processes:

• Financial management support: defines necessary structure for management of financial planning data and costs.
• Financial planning: determines required financial resources over next planning period.
• Financial analysis and reporting: analysis of financial costs provisioning and service profitability.
• Service invoicing: issues invoices for the provisioned service.

Service Design

Another view of ITIL V3, Service Design volume has its main focus on definition of service itself, based on how it is expected to be from service strategy. Its goal is to design and develop IT services, no matter if it is design of a new service or improvement of an existing one.

Design of a service is not solely based on technology, but addresses a solution interacting largely with business and technical environments, and takes in consideration the whole supply chain required to support the planned service.

Processes for Service Design of ITIL V3 are:

• Design Coordination
• Service Catalogue Management
• Service Level Management (SLM)
• Availability Management
• Capacity Management
• IT Service Continuity Management (ITSCM)
• Information Security Management
• Supplier Management

Service Design

Principles and Key terms

Design of a service has the following principles:

• Portfolio service project
• Business requirements
• Technological project
• Processes project
• Measurement project, including IT-KGI, KGI and KPI

Key terms to design a service include:

• Critical success factor: how to define that service providing succeeds.
• Downtime: one of the key terms for warranty, means how many times a service was unavailable for the client.
• KPI: to define Key Performance Indicators for the service.
• Maintainability: how easy is to maintain service.
• OLA/UC: service agreement with internal or external suppliers.

Four Ps

Four Ps for Service Design are:

• People
• Process
• Product/technology
• Partners/suppliers

Delivery model options

List of delivery model strategies are:

• Insource: when service uses internal resources for all service phases.
• Outsource: this model is set through a well defined portion of service-design. It may use the ASP model, defined below.
• Co-source: it's a combination of insource and outsource.
• Partnership or multi-source: agreement between two or more organizations to work together providing service.
• Business Partner Outsourcing (BPO): relocates entire business function to an external organization that will provide and manage service. This model generally means a more operational partner, like accounting or call-center.
• Application Service Provider (ASP): through a formal agreement an organization provides computer-based software through a network. It is also known as on-demand software/applications.
• Knowledge Partner Outsourcing (KPO): service provided by a thinking partner, it is one step ahead of BPO. Generally provides a specific field expert-knowledge.
• Managed Service Provider (MSP): more broadly end-to-end service partner. This model is not defined in ITIL V3.

Partners agreement

Before closing an agreement with a customer, there is a need to close an agreement with partners. It is not possible to guarantee that a service will be able to return in one day, if that service requires an interaction with a supplier that needs two days.

ITIL defines two forms of agreement:

• Operational Level Agreement (OLA): an agreement between an IT service provider and an internal service provider (part of same the organization).
• Underpinning Contract (UC): an agreement between an IT service provider and an external service provider (outside of the organization).

Measurement

Design may measure a process service by:

• Progress: milestones & deliverables.
• Compliance: according to governance standards.
• Effectiveness: accuracy & correctness.
• Efficiency: optimized use of resources.

A service may be measured by three ways:

• Prerequisite For Success (PFS): an activity that needs to be completed. Generally a PFS is an input for another process.
• Critical Success Factor (CSF): what defines a service to achieve success.
• Key Performance Indicator (KPI): indicators to define that a service has achieved success.

ITIL V3 suggests only KPI, which was improved with elements based on COBIT recommendations.

Processes

Service design has 10 processes, as depicted below.

Service Catalogue Management

Ensures production and maintain of Service Catalogue with accurate information on all operational services and those being prepared to be run operationally. It contains information on all service Service Management processes: service details, current status and service's interdependencies.

There is a clear difference between Service Catalogue and Business Services (services visible to the customer, defined by SLAs) and Supporting Services (services visible only inside the IT organization, defined by OLAs and UCs).

No sub-processes are specified for Service Catalogue Management according to ITIL V3.

Service Level Management

Objective of SL management is 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 (OLA) and Underpinning Contracts (UC) are appropriate, and to monitor and report on service levels.

Service Level Management is the glue for Service Level Agreement (SLA), Service Improvement Process (SIP) and Service Level Requirements (SLR). SIP is an important part of Continuous Service Improvement (CSI) volume.

Service Level Requirements contains requirements from client viewpoint for a service and are the basis to reach a SLA. Requirements in SLR need to be defined in business terms, defining service level targets, mutual responsibilities, and other requirements specific to a certain customer or group of customers.

SLM Stages

SLM is defined through following stages:

1. Negotiation: where is defined SLR for service .
2. Finalization: where is defined SLA, after definition of OLA/UC.
3. Monitoring: service monitoring.
4. Report: service report, showing if service complies with SLA.
5. Revision: used as basis for SIP.

SLA Structure Levels

Structure levels for SLA may be:

• Corporation: when target is whole corporation.
• Client: when target is a specific client or group. E.g. financial department.
• Service: when target is not specific. E.g. is an internet service, when target is not solely a corporation nor specific client.
• Multilevel: SLA may be split into different levels, for different customers.

Risk Management

This process is about identification, assessing and controling risks through analyzing asset`s value, threats and how vulnerable each asset is to those threats.

Risk Management is composed of Business Impact and Risk Analyzes, Assessment of Required Risk Mitigation and Risk Monitoring.

<Risk Management is not a part of ITIL V3>

Capacity Management

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.

Common metrics

Service-level agreements can contain numerous service performance metrics with corresponding service level objectives. A common case in IT Service Management is a call center or service desk. Metrics commonly agreed to in these cases include:

• ABA (Abandonment Rate): Percentage of calls abandoned while waiting to be answered.
• ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be answered by the service desk.
• TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g., 80% in 20 seconds.
• FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the use of a callback or without having the caller call back the helpdesk to finish resolving the case.
• TAT (Turn Around Time): Time taken to complete a certain task.

Uptime Agreements are another very common metric, often used for data services such as shared hosting, virtual private servers and dedicated servers. Common agreements include percentage of network uptime, power uptime, amount of scheduled maintenance windows, etc.

Many SLAs track to the ITIL specifications when applied to IT services.

Availability Management

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 are:

• Design Services for Availability
• Availability Testing
• Availability Monitoring and Reporting

Measurement

Some availability measurements, that may be included in SLA:

• Mean-Time-Between-Failure (MTBF): elapsed time between a service gets up and down.
• Mean-Time-To-Repair (MTTR): elapsed time to repair a configuration item or IT service.
• Mean-Time-Between-System-Incidents (MTBSI): elapsed time between detection of two consecutive incidents.
• Mean-Time-To-Restore-Service (MTRS): elapsed time from the detection of an incident until it gets up.

Based on terminology above,

MTBSI = MTBF + MTRS

, and availability can be calculated by

A = MTBF / (MTBF + MTTR)

.

MTRS is different from MTTR in the way that MTTR would mean time to repair a configuration item, and MTRS would mean time to restore service after repair. E.g. MTTR=time to change CPU of a node, MTRS=time to restore all services provided by that node.

IT Service Continuity Management

IT Service Continuity Management (ITSCM) aims to manage risks that could seriously impact IT services. This ITIL process 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.

Service Transition

The role of Service Transition is to deliver services that are required by the business for the operational use.

Service Operation

Operation is where service value is realized. This view handles a service after it has been deployed and is active to the customer. It is mainly about handling user requests, fixing services carrying operation problem tasks. Service Operations consists of 5 Processes and 4 Functions

Processes:

• Event Management
• Incident Management
• Request Fulfillment
• Access Management
• Problem Management

Functions:

• Service Desk
• IT Operations Management
• IT Facilities Management
• Application Management

Service Operation

Principles

• Internal view x external view: internal IT view is the way components are managed to deliver a service. External business view is the way a client sees a service. There is an eternal conflict between this two views in a company and there is a need to try to achieve a balance between them.
• Stability x responsiveness: no matter how a good service is provided, there will be always a need to change something. Considering that every change is a potential risk in service stability, a change would not be good. But business needs changes, and they are going to happen anyway. Balance here is to change services without losing stability. These changes may be at several levels, as technology, capacity management, grow strategy, problems experienced.
• Quality of service x cost of service
• Reactive x proactive: management that is solely reactive is not effective, but management that is overly proactive is not effective either. When staff are too proactive, this may result in increased expense and distracted staff.

Key terms

Some key terms needed for Service Operations:

• Event or Alert: a change in state that has significance for management.
• Incident: an unplanned interruption in service or loss of quality.
• Failure: a loss of ability to operate service. Normally a failure results in an incident.
• Error: a design malfunction that causes a failure.
• Problem: A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created
• Known error: a problem that has documented root cause or a workaround.
• Request For a Change (RFC): formal request for a change to be made.

Processes

Event management

Event or alert is any change in state that may have implications in how service is perceived by customer. These events are a signal that service has been interrupted or there is a loss of quality. Since warranty is one of two axis for service quality, this processes is one of most important of ITIL.

The process works on filter and categorization of events and to decide on appropriate actions.

Sub processes are:

• Maintenance of Event Monitoring Mechanisms and Rules
• Event Filtering and Categorization
• Event Correlation and Response Selection
• Event Review and Closure

Incident Management

Objective of this process is to manage the lifecycle of all Incidents. Incident Management ensures that normal service operation is restored as quickly as possible and the business impact is minimized.

Incident management may be used to handling of failures, providing answers to users questions/queries (usually by Helpdesk/Service Desk). It is questions or queries made by users (many times by service desk). Its important to realize that not all events are incidents.

When correction of an incident by second level a Problem Record is created and the error-correction transferred to Problem Management.

Subprocesses are:

• Incident Management Support
• Incident Logging and Categorization
• Immediate Incident Resolution by 1st Level Support
• Incident Resolution by 2nd Level Support
• Handling of Major Incidents
• Incident Closure and Evaluation
• Incident Monitoring and Escalation
• Pro-Active User Information
• Incident Management Reporting

Request Fulfilment

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

In ITIL 2011, Request Fulfilment has been completely revised. To reflect the latest guidance Request Fulfilment now consists of five sub-processes, to provide a detailed description of all activities and decision points. Request Fulfilment now contains interfaces with Incident Management - if a Service Request turns out to be an Incident and with Service Transition - if fulfilling a Service Request requires the involvement of Change Management.

The Sub-Processes are;

Request Fulfilment Support Process Objective: To provide and maintain the tools, processes, skills and rules for an effective and efficient handling of Service Requests.

Request Logging and Categorization Process Objective: To record and categorize the Service Request with appropriate diligence and check the requester's authorization to submit the request, in order to facilitate a swift and effective processing.

Request Model Execution Process Objective: To process a Service Request within the agreed time schedule.

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

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

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 executes policies defined in IT 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 minimise the impact of incidents that cannot be prevented. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management processes to identify trends or significant Problems.

IT Operations Management

Process Objective: To monitor and control the IT services and IT infrastructure. The process IT Operations Management 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.