ITIL 2011

Foundation
Training

ITIL School of Excellence

1
 Agenda

Day 1
• History of ITIL, relevance in ITSM
• Service Lifecycle Approach
• Introduction to Service Strategy
• Introduction to Service Design

Day 2

• Introduction to Service Transition

• Introduction to Service Operation Processes and Functions
• Introduction to Continual Service Improvement

2
 Objectives

At the end of this module you will be able to

• History of ITIL, relevance in ITSM
• Service Lifecycle Approach
• Introduction to Service Strategy
• Introduction to Service Design
• Introduction to Service Transition
• Introduction to Service Operation Processes and
Functions
• Introduction to Continual Service Improvement

3
What is ITIL

Most widely recognized

best practices framework
for IT Service
Management in the world.

ISO/IEC 20000 is a
Provides best-practice
standard and ITIL
guidance to all types
offers a body of
knowledge useful for ITIL of service providers on
the provision of quality
achieving the
IT Services
standard.

It is not a standard; It is
guidance that should be
read, understood and
used to create value for
the Service Provider and
its customers

4
 Evolution of ITIL
The ITIL concept emerged in the 1980s, when the British government determined that the
level of IT service quality provided to them was not sufficient. The Central Computer and
Telecommunications Agency (CCTA), now called the Office of Government Commerce
(OGC), was tasked with developing a framework for efficient and financially responsible use
of IT resources within the British government and the private sector.
The earliest version of ITIL was actually originally called GITIM, Government Information
Technology Infrastructure Management.

• Focused on • Key updates to

• Focused on
• Focused on Business and IT the ITIL V3
Business and IT
IT Alignment content
Integration
Infrastructure through a • 5 Books
through a
Management process based • 26 Processes
Service
approach (Strategy
Lifecycle
• Library Management,
approach
contains 40 • Service Support BRM and
Books & Service • 5 Books Design Co-
Delivery (11 ordination
processes) • 24 Processes Processes
• 7 Books added) and
and 4 functions
4 functions
5
ITIL 2011 - Benefits
• Improve user productivity.

• Reduce IT costs and

justifies cost of IT quality

Tangible • Improve availability,

reliability and security of
Benefits mission critical IT services.

• Improve customer
satisfaction and
relationship between
Customer and Service
Provider

• Supports ability of IT to
measure and improve
internal performance.

• Identifies roles and

responsibilities clearly for
Intangible IT Service Management.
Benefits
• Learn from previous
experience

• Integrate and Standardize

processes

6
ITIL 2011 - Basic Concepts
Standard

A mandatory Requirement.

Examples include: ISO/IEC 20000 (an international Standard), an internal security Standard
for Unix configuration, or a government Standard for how financial Records should be
maintained.

The term Standard is also used to refer to a Code of Practice or Specification published by a
Standards Organization such as ISO or BSI.

Framework

A Framework is a structure or a skeleton that is used as the basis for something being
constructed.

Example: ITIL is a service Management Framework, CMMI is process maturity framework)

7
ITIL 2011 - Basic Concepts
Service
A means of delivering value to Customers by facilitating Outcomes Customers want to
achieve without the ownership of specific Costs and Risks.

Service Management
Service Management is a set of specialized organizational capabilities for providing value to
customers in the form of services.

Resources
A generic term that includes IT Infrastructure, people, money or anything else that might
help to deliver an IT Service. Resources are considered to be Assets (tangible) of an
Organization.

Capabilities
The ability of an Organization, person, Process, Application, Configuration Item or IT Service
to carry out an Activity. Capabilities are intangible Assets of an Organization.

8
ITIL 2011 - Basic Concepts
Process
A structured set of Activities designed to accomplish a specific Objective.
A process takes one or more defined inputs and turns them into defined outputs. Process
describes actions, dependencies and sequences.

Characteristics of Process:

• It has specific results.

• Results/ Outputs are measurable and are performance driven.
• It delivers value to customers (Internal or External)
• It responds to a specific event.

Process, once defined, should be documented and controlled. Once under control, they can
be repeated and managed.

Functions:
Functions are units of organizations specialized to perform certain types of work and be
responsible for specific outcomes. They are self-contained with capabilities and resources
necessary for their performance and outcomes.
Example: Service Desk, Finance, etc.,

9
ITIL 2011 - Basic Concepts
RACI Matrix:
A responsibility assignment matrix RACI describes the participation by various roles in
completing tasks or deliverables for a process. It is especially useful in clarifying roles and
responsibilities in cross-functional processes.

Responsible (R) – The Person who performs the activity

Accountable (A) – The Person who owns or is answerable for the completion of the activity
Consulted (C) - Those whose opinions are sought, typically subject matter experts; and with whom
there is two-way communication
Informed (I) - Those who are kept up-to-date on progress, often only on completion of the task or
deliverable; and with whom there is just one-way communication .

Sample RACI Chart – Incident Management Process

10
ITIL 2011 Framework & Processes
SERVICE SERVICE
SERVICE DESIGN
DESIGN
SERVICE STRATEGY
STRATEGY

1. 1.
1. Design
Design Coordination
Coordination
1. Strategy
Strategy Management
Management
2. 2.
2. Service
Service Catalog
Catalog Management
Management
2. Service
Service Portfolio
Portfolio
Management 3.
3. Service Level Management
Service Level Management
Management
3. 4.
4. Supplier
Supplier Management
Management
3. Financial
Financial Management
Management
4. 5.
5. Capacity
Capacity Management
Management
4. Demand
Demand Management
Management
5. 6.
6. Availability
Availability Management
Management
5. Business
Business Relationship
Relationship
Management 7.
7. IT
IT Service
Service Continuity
Continuity
Management
Management
Management
8.
8. Information
Information Security
Security
Management
Management

SERVICE
SERVICE OPERATION
OPERATION SERVICE
SERVICE TRANSITION
TRANSITION
1.
1. Event
Event Management
Management 1. Transition Planning
1. Transition Planning and
and
2.
2. Incident
Incident Management
Management Support
Support
3.
3. Request
Request Fulfilment
Fulfilment 2.
2. Change
Change Management
Management
4.
4. Problem
Problem Management
Management 3.
3. Service
Service Asset
Asset &
&
5.
5. Access
Access Management
Management Configuration Management
Configuration Management
4.
4. Release
Release & & Deployment
Deployment
Management
Management
CONTINUAL
CONTINUAL SERVICE
SERVICE IMPROVEMENT
IMPROVEMENT 5.
5. Service
Service Validation
Validation
6. Evaluation
6. Evaluation
Seven
Seven Step
Step Improvement
Improvement 7.
7. Knowledge
Knowledge Management
Management

11
 ITIL Exam Track

12
ITIL FOUNDATION CERTIFICATION

 Managed by APMG from April 08

 Multiple Choice Examination (1hr)

 65% required to pass (26 from 40)

 Pre-requisite for the Intermediate and Expert’s Certificates

13
 Service Strategy

14
Processes in Service Strategy

Service Strategy

• Strategy Management

• Service Portfolio Management

• Financial Management for IT Services

• Demand Management

• Business Relationship Management

15
 Service Strategy — Scope

– Internal and external service providers

– Profit and not-for-profit service providers

– Two aspects of strategy included:

• Defining a strategy whereby a service provider will deliver
services to meet a customer’s business outcomes
• Defining a strategy for how to manage those services

16
 Utility and Warranty

• Utility and Warranty define services and work together to

create value for the customer
• Utility
– What does the service
do?
– Functional requirements
– Features, inputs,
outputs…
– “fit for purpose”
• Warranty
– How well does the
service do it?
– Non-functional
requirements
– Capacity, performance,
availability…
– “fit for use”
17
 Utility and Warranty

• Utility and Warranty define services and work together to

create value for the customer
• Utility
– What does the service
do? UTILIT
Performance
Y T/F
– Functional requirements supported? OR
– Features, inputs, Constraints Fit for
removed? purpose
outputs… ?

– “fit for purpose”

• Warranty
– How well does the
service do it?
– Non-functional
© Crown Copyright 2011. Reproduced under licence from the Cabinet Office.
requirements
– Capacity, performance,
availability…
– “fit for use”
18
 Utility and Warranty

• Utility and Warranty define services and work together to

create value for the customer
• Utility
– What does the service
do? UTILIT
Performance
Y T/F
– Functional requirements supported? OR
– Features, inputs, Constraints Fit for
removed? purpose
outputs… ?

– “fit for purpose” Available Fit for

enough?
• Warranty Capacity
AND
use?

enough?
– How well does the Continuous T/F

enough?
service do it? Secure enough?
WARRANT
– Non-functional Y
© Crown Copyright 2011. Reproduced under licence from the Cabinet Office.
requirements
– Capacity, performance,
availability…
– “fit for use”
19
 Utility and Warranty

• Utility and Warranty define services and work together to

create value for the customer
• Utility
– What does the service
T: True
do? UTILIT F:
Performance
Y T/F False
– Functional requirements supported? OR
– Features, inputs, Constraints Fit for
removed? purpose
outputs… ?
AND
– “fit for purpose” Available Fit for
T/F

enough?
• Warranty Capacity
AND
use?
VALUE
enough?
– How well does the Continuous T/F
CREATE
enough?
Secure enough? D?
service do it? WARRANT
– Non-functional Y
requirements
– Capacity, performance,
availability…
– “fit for use”
20
 Assets, Resources and Capabilities

– Assets are the basis for value creation

– There are two types of asset
• Resources are direct inputs for production
• Capabilities are an organization’s ability to coordinate, control and deploy
resources to produce value

Capabilities Resources
A1 Management Financial capital
A2 Organization Infrastructure A8

A3 Processes Applications A7

A4 Knowledge Information A6

People (skills) People (#

employees)
21
 Service Portfolio Management — Summary

– Purpose
– Objectives
– Scope
– Service Portfolio

22
 Service Portfolio Management —Purpose and objectives

– Purpose: to ensure that the service provider has the right mix
of services to balance the investment in IT with the ability to
meet business outcomes.
– Objectives:
• To enable an organization to decide on which services to provide
• To maintain the definitive portfolio of services provided
• To enable the organization to evaluate how services enable them
to achieve their strategy, and to respond to changes
• To control which services are offered, under what conditions and
at what level of investment
• To track the investment in services throughout their lifecycle, thus
enabling the organization to evaluate its strategy, as well as its
ability to execute against that strategy
• To analyse which services are no longer viable and when they
should be retired.

23
 Service Portfolio Management — Scope

– All services the provider plans to delivered

– Services currently being delivered
– Withdrawn services
– Comparing investment in services with desired business
outcomes
– Evaluation of services throughout their lifecycles

24
 The Service Portfolio

Service portfolio

Service Retired
Service catalogue
pipeline services

Configuration management system

Supplier and contract Customer

Customer Application Project
management information agreement CMDB
portfolio portfolio portfolio
system portfolio

25
 Financial Management for IT Services — Summary

– Purpose
– Objectives
– Scope
– Business case

26
 Financial Management for IT Services — Purpose and objectives

– Purpose: to secure the appropriate level of funding to design,

develop and deliver services that meet the strategy of the
organization
– Objectives:
• To identify, manage and communicate the cost of providing
services
• To evaluate the financial impact of new or changed strategies
• To secure funding to manage the provision of services
• To understand and balance expenses and income
• To manage and report expenditure on service provision on behalf
of the organization’s stakeholders
• To execute the financial policies and practices in service provision
• To account for money spent on the creation, delivery and support
of services
• Where appropriate, to define a framework to recover the costs of
service provision from the customer
27
 Financial Management for IT Services — Scope

Financial management consists of three main processes:

– Budgeting
• This is the process of predicting and controlling the income and
expenditure of money within the organization. Budgeting consists
of a periodic negotiation cycle to set budgets (usually annual) and
the monthly monitoring of the current budgets.
– Accounting
• This is the process that enables the IT organization to account
fully for the way its money is spent (particularly the ability to
identify costs by customer, by service and by activity). It usually
involves accounting systems, including ledgers, charts of
accounts, journals etc. and should be overseen by someone
trained in accountancy.
– Charging
• This is the process required to bill customers for the services
supplied to them. This requires sound IT accounting practices and
systems.
28
SS 03: Demand Management Process

Objectives:
 Define and analyze demand sources and demand patterns
 Ensure that services are designed to meet the patterns of business activity and the ability
to meet business outcomes
 Provide reliable planning data for Capacity Management to meet the demand for services

Iterative Process Activities

1. Identify Sources of demand forecasting
2. Analyze Demand Patterns and document Patterns of Business Activity
3. User Profiling
4. Matching User Profiles and PBA
5. Activity Based Demand Management
6. Develop Differential Offerings
7. Management of Operational Demands

29
Business Relationship Management–Basic concepts
Difference Between BRM and SLM
Business Relationship Management Service Level Management
Purpose Establish and maintain a constructive To negotiate SLA with customers
relationship between the service provider and and ensure that all Service
the customer based on the understanding the management processes, OLAs
customer and their business drivers and UCs are appropriate for the
agreed service level targets.
To Identify customer needs and ensure that the
service provider is able to meet these needs.

Focus Strategic and Tactical – The focus is on the Tactical and Operational – The
overall relationship with the customer and focus is on reaching the SLA
which services the service provider will deliver agreement and whether the
to meet customer needs. service provider was able to meet
those agreements

Primary Measure  CSAT Achieving agreed levels of service

which leads to customer
 Improvement in the customer’s intention to
satisfaction.
better use and pay for the service,

 Whether customers are willing to

recommend the service to other (potential)
customers.

30
Processes in Service Design

Service Design

• Design Coordination
• Service Catalog Management
• Service Level Management
• Availability Management
• Capacity Management
• IT Service Continuity Management
• Information Security Management
• Supplier Management

31
 Scope of Service Design — “The Four Ps”

People

Processes Products/
Technology

Partners/
Suppliers

32
 Design Coordination

– Purpose
– Objectives
– Scope

33
 Design Coordination – Purpose and Objectives

– Purpose: to ensure the goals and objectives of the SD stage are met
• Provides and maintains a single point of coordination and control for all
activities and processes within this stage
– Objectives:
• Ensure consistency across the five major aspects of SD
• Coordinate activities; manage schedules, resources, conflicts
• Plan and coordinate resources and capabilities required for design
• Produce SDPs and handover to Service Transition
• Manage interfaces between SD and SS, and ST
• Ensure design conformance with corporate requirements
• Ensure the use of standard design practices, where appropriate
• Monitor and improve the performance of the SD lifecycle stage,
including its activities and processes

34
 Design Coordination – Scope

– All activity into or out of the live environment

– Scale and complexity of design activity varies:

• Design coordination mostly focuses on projects and major

changes
– Organizations should define the criteria for design coordination
involvement
– Design coordination excludes responsibility for:
• Activities/processes outside SD stage of service lifecycle
• Designing the detailed service solutions or the production of individual parts
of SDPs

35
 Service Catalog Management

– Purpose
– Objectives
– Scope
– Service catalog

36
 Service Catalog Management —Purpose and objectives

– Purpose: to provide and maintain a single source of consistent

information on all services
• Includes operational services and those being prepared to run operationally

– Objectives:
• To manage the service catalog information
• To ensure accuracy of content
• To ensure availability to those with authorized access
• To ensure support for other service management processes which depend
on service catalog information

37
 Service Catalog Management — Scope

– Contribution to the definition of services and service packages

– Development and maintenance of service and service package
descriptions appropriate for the service catalog
– Interfaces, dependencies and consistency between the service catalog
and the overall service portfolio and CMS

•SCM process does not include

• Detailed attention to service asset and configuration information (SACM
process)
• Fulfillment of service requests (Request Fulfillment process)

38
SD 02: Service Catalogue Management
Definition – Service Catalogue: Formalized document which describes the total
(controlled) service offerings of an IT organization.

Service Catalogue has two major aspects:

The Business Service Catalogue: It contains
the details of all the IT Services delivered to
the customer, together with relationships to the
business units and the business process that
rely on the IT services. This the customer view
of the Service Catalogue.
The Technical Service Catalogue: It contains
details of all the IT Services delivered to the
customer, together with relationships to the
supporting services, shared services,
components and CIs necessary to support the
provision of the service to the business. This
should underpin the Business Service
Catalogue and not form part of the customer
view.

39
SD 03: Service Level Management
Goal: To ensure that an agreed level of IT service is provided for all current IT
services, and that future services are delivered to agreed achievable targets.

Service Level Agreement (SLA): A written

agreement between an IT Service provider and
the Customers(s) defining key service targets
and responsibilities of both parties.

Operational Level Agreement (OLA): An

agreement between an IT Service provider and
another part of the same organization that
assists with the provision of services.

Underpinning Contract (UC): Is a contract

between an IT service provider and an external
supplier covering delivery of services that
support the IT organization in their delivery of
services.

40
 Elements of a typical SLA document

 Service Scope and description

 Service hours
 Measures of availability and reliability
 Support details – who to contact, when and how
 Respond and fix times
 Deliverables and time scales
 Change approval and implementation
 Reference to IT Service Continuity Plan
 Signatories
 Responsibilities of both parties
 Review process
 Glossary of terms

41
SD 07: Information Security Management
Goal
 The goal of the ISM process is to align IT security with business security and ensure that
information security is effectively managed in all service and Service Management activities.
 The ISM process should be the focal point for all IT security issues, and must ensure that an
Information Security Policy is produced, maintained and enforced that covers the use and
misuse of all IT systems and services.

Information is threatened in three Information Security Manager

main ways:  Communication and publicizing of the Information
Confidentiality: Protecting Security Policy to all appropriate parties.
sensitive information from  Identifying and classifying IT and information assets
unauthorized disclosure or (Configuration Items) and the level of control and
intelligible Interception.
protection required.
Integrity (accuracy):  Performing security risk analysis and risk management in
Safeguarding the accuracy and
conjunction with Availability and IT Service Continuity
completeness of information and
software Management.
 Designing security controls and developing security
Availability (accessibility):
plans.
Ensuring that information and
vital IT services are available and  Monitoring and managing all security breaches and
accessible when required. handling security incidents, taking remedial action to
prevent recurrence wherever possible.
42
Information Security Management - Basic Concepts
Information Security Management Framework

43
 SD 04: Availability Management - Overview
Goal Vital Business Function
To ensure that the level of service availability A function of the Business Process,
delivered in all services is matched to or exceeds the which is critical to the success of the
current and future agreed needs of the business, in a Business. It is used to reflect the
cost-effective manner. critical elements of the Business
Process supported by an IT Service.
Definitions ( E.g.. Cash dispensing in an
 Service availability: Involves all aspects of service ATM Machine )
availability and unavailability and the impact of
component availability, or the potential impact of High availability
component unavailability on service availability. A characteristic of the IT service that
 Component availability: Involves all aspects of minimizes or masks the effects of IT
component availability and unavailability. component failure to the users of a
 Reliability: A measure of how long a service, service.
component or CI can perform its agreed function
without interruption. Fault tolerance
 Maintainability: A measure of how quickly and The ability of an IT service,
effectively a service, component /CI can be restored component or CI to continue to
to normal working after a failure. operate correctly after failure of a
 Serviceability: The ability of a third-party supplier to component part.
meet the terms of their Contract.

44
 Availability Management - Basic Concepts
(Agreed Service Time (AST) – downtime)
Availability (%) = ————————————-------------—— X 100 %
Agreed Service Time (AST)
Early Incident Life Cycle

45
SD 05: Capacity Management - Overview

Goal: The goal of the

Capacity Management
process is to ensure
that cost-justifiable IT
capacity in all areas of
IT always exists and is
matched to the current
and future agreed
needs of the business,
in a timely manner.

46
Capacity Management – Sub-processes

Business Capacity Management

Focuses on current and future business requirements
Ex: Retailer plans a sales campaign- consider impact on his billing &
payment processing systems

Service Capacity Management

Focuses on the delivery of the existing services that support the
business (i.e., meet service SLAs)
Ex: Response time of the billing SW has been degrading over the last
few weeks- Investigate & fix

Component Capacity Management

Focuses on the IT components that underpin service provision
Ex: Frequent/ repeat alerts observed for CPU utilization on a DB
server

47
SD 06: IT Service Continuity Management
Goal
The goal of ITSCM is to support the overall Business Continuity Management
process by ensuring that the required IT technical and service facilities (including
computer systems, networks, applications, data repositories,
telecommunications, environment, technical support and Service Desk) can be
resumed within required, and agreed, business timescales.

Recovery Methods
 Immediate recovery – Automatic fail over, no loss of service
 Fast recovery – Service restored within 24 hours
 Intermediate recovery – Service restored in 24 to 72 hours
 Gradual recovery – Service restored after 72 hrs
 Manual Workarounds
 Reciprocal arrangements (Less Frequently used)
 Do nothing

48
SD 08: Supplier Management - Overview
Goal: The Goal of the Supplier Management process is to manage suppliers and
the services they supply, to provide seamless quality of IT service to the business,
ensuring value for money is obtained.

49
 Service Transition

50
Processes in Service Transition

Service Transition

• Transition planning and support

• Change Management
• Service Asset and Configuration Management
• Release and Deployment
• Service Validation and Testing
• Change Evaluation
• Knowledge Management

51
 ST 02: Change Management - Overview
Goal
The goal of the Change Management is to ensure that standardized methods and
procedures are used for efficient and prompt handling of all Changes, in order to minimize
the impact of Change-related Incidents upon service quality, and consequently to improve
the day-to-day operations of the organization.

Objective
The Objective of the Change Management process is to ensure that changes are
recorded and then evaluated, authorized, prioritized, planned, tested, implemented,
documented and reviewed in a controlled manner.

Purpose
• Standardized methods and procedures are used for efficient and prompt handling of
changes.
• All changes to service assets and configuration items are recorded on the
configuration management system.
• Overall business risk is optimized.

52
Change Management - Basic Concepts
 Service Change
The addition, modification or removal of authorized, planned or supported service or service
component and its associated component.

 RFC
A formal proposal for a Change to be made. An RFC includes details of the proposed Change,
and may be recorded on paper or electronically.

 Change Advisory Board (CAB)

A body that exists to support the
authorization of changes and to
assist Change Management in
the assessment and prioritization
of changes.

E-CAB
Emergency Change Advisory Board.

53
Change Management - Basic Concepts
Change Types
Standard Changes
Routine Changes that follow an
established procedure & do not disrupt It
services
E.g. updating the Anti-Virus software is a
standard Change

Normal Changes
Model of changes that must go through
assessment, authorization and Change
Advisory Board (CAB) agreement before
implementation.

Emergency Changes Note:

Crucial to an organization and have to be There are other change types in used based on
implemented immediately. the nature of the environment
Emergency Changes are disruptive and Expedited Changes
prone to failure Any change that has a strong business
E.g. the some ports in critical switch has justification to be done as early as possible and
gone down. Therefore, a new switch needs that can be included for the CAB review without
to be installed following the standard lead times.
54
Change Management - Basic Concepts
Seven R’s of a Change

Change, Configuration, Release and Remediation Plan

Deployment
• Every change must have a roll back plan
• Should be planned together • Sometime a change cannot be rolled back.
• Should have coordinated implementation In such cases, its needs to have an
alternate viable remediation plan

55
Change Management - Basic Concepts
Change Models

• Predefined way or procedure for handling known type or complexity

• Automated as far as possible

• Allow for scalability to create a new model

Forward Schedule of Changes (FSC)

• Contains details of all approved changes and their implementation dates for an
agreed period

• Detailed short term schedules and less detailed for longer term planning

Change, Configuration, Release and Deployment

Projected Service Availability (PSA)
• To determine the best time for a change implementation

• Both the FSC and PSA are agreed with the customers

56
Change Management – Process Flow

57
 Change Model and Authority for a Change Type

Change Type Change Model Change Authority

• Must test
• Change Advisory Board
Normal Changes • Must have back-out plan
• Assessed at regular intervals (CAB)

• Repetitive
Standard • Low-risk • Pre-approved (and
Changes • Well-tested delegated)
• Defined outcomes

• Should test
• Should have back-out plan • Emergency Change
Emergency
• Implemented quickly after the Advisory Board (CAB)
Changes
approval

58
Change Management - Roles
Change Manager

 Responsible for main activities of the

process – Process Owner Change Advisory Board (CAB) Activities
 Control RFC
 Coordinate and runs the CAB meetings
 Authorize changes based on input and
advice from CAB
 Produces Change Schedule
 Co-ordinates change
build/test/implementation
 Reviews / Closes Changes

Change Advisory Board (CAB)

 Supports the Change Manager

 Consulted on significant changes

Emergency CAB (ECAB)

 Subset of the standard CAB

 Membership depends on specific changes
59
ST 03: Service Asset & Configuration Mgmt Process
Objectives
 Identify, control, record, report, audit and verify service assets and configuration items,
including versions, baselines, constituent components, their attributes, and Relationships.
 Establish and maintain an accurate and complete Configuration Management System as a
part of the overall Service Knowledge Management System.

Asset: Any component of a

business process that has a
financial value is called as an
Asset.
Configuration Item: Any
service component that needs to
be monitored, managed and
controlled under Configuration
Management is called as a
configuration item.
A CI may or may not have a
financial attribute to it but an
asset must have a financial
value attributed to it.

60
Service Asset & Configuration Mgmt Process
SACM Process activities
Management and Planning -> Identification -> Control -> Status Accounting ->
Verification and Auditing

61
ST 04: Release and Deployment Management
This Process aims to build, test and deliver the capability to provide the
services specified by service design and that will accomplish the
stakeholders requirements and deliver the intended objectives

Release Unit: A ‘release unit’ describes the portion of a service or IT infrastructure

that is normally released together according to the organization’s release policy.
Factors considered while formation of Release Units
 The ease and amount of change necessary to release and deploy a release unit
 Amount of resources and time needed to build, test, distribute and implement a release unit
 Complexity of interfaces between proposed unit and rest of the services and IT infrastructure
 The storage available in the build, test, distribution and live environments

Release Rollout Methods

Big Bang : The new or changed service is deployed to all the user areas in one operation.
Used when introducing an Application change and consistency of service across the
Organization.
Phased Approach: The service is deployed to a part of the user base initially, and then this
operation is repeated for subsequent part of the user base via a scheduled rollout plan.
62
Release and Deployment Management Process

Change Management oversee the entire release cycle and authorize each
stage of release.

63
 ST 06: Change Evaluation - Overview
Goal: To set stakeholder expectations correctly on the outcomes against the plan.

Evaluation Report
The evaluation report contains the following sections.
Risk profile - A representation of the residual risk left after a change has been
implemented and after countermeasures have been applied.
Deviations report - The difference between predicted and actual performance following
the implementation of a change.
A qualification statement (if appropriate) - Following review of qualification test results
and the qualification plan, a statement of whether or not the change has left the service in a
state whereby it could not be qualified.

Evaluation Principles
The following principles shall guide the execution evaluation process:
• As far as is reasonably practical, the unintended as well as the intended effects of a change
need to be identified and their consequences understood and considered.
• A service change will be fairly, consistently, openly and, wherever possible, objectively
evaluated.
The evaluation process uses the Plan–Do–Check–Act (PDCA) model to ensure consistency
across all evaluations.

64
 ST 07: Knowledge Management - Overview
Goal: To enable organizations to improve the quality of management decision making by
ensuring that reliable and secure information and data is available throughout the service lifecycle.

1. Knowledge Identification:
Identify and Plan for the capture of relevant knowledge and the consequential information
and data that will support it
2. Knowledge Capture
• Create the relevant knowledge and categorize the knowledge by creating a taxonomy
• Designing a systematic process for organizing, distilling, storing and presenting
information in a way that improves people's comprehension in a relevant area
• Accumulating knowledge through process and workflow
• Capturing External knowledge and adapting it - Data, Information and knowledge from
employees websites, databases, suppliers and partners.
3. Knowledge Maintenance
• Reviewing stored knowledge to ensure that it is still relevant and correct
• Updating, purging and archiving knowledge.
4. Knowledge Transfer
Retrieving, sharing and utilizing the knowledge through problem solving, dynamic learning,
strategic planning and decision making.

65
 Service Operation

66
Processes and Functions in Service Operation

67
Service Operation - Basics
Incident
An unplanned interruption or degradation of performance of a service is called an Incident.
Failure of a Configuration Item that has not yet affected Service is also an Incident.

Service Request
A request from a User for information, or advice, or for a Standard Change or for Access to an
IT Service.

Problem
An underlying cause of one or more incidents is called a Problem.

Change
The addition, modification or removal of anything that could have an effect on IT Services is
called a change.

Event
A change of state which has significance for the management of a Configuration Item or IT
Service.
68
SO 01: Event Management - Overview

Purpose
The purpose of event management is to manage events throughout their lifecycle. The activities
are to detect events and determine appropriate control action.

Objectives

• Detect all changes of state that have significance for the management of a CI or IT service
• Determine the appropriate control action for events and ensure these are communicated to
the appropriate functions
• Provide the trigger, or entry point for the execution of many service operation processes and
operations management activities
• Provide a basis for service assurance, reporting and service improvement
Monitoring Scope
Configuration Items:
■ Environmental conditions (e.g. fire and smoke ● Some CIs will be included because they need to stay
detection) in a constant state (e.g. a switch on a network needs to
stay on and Event Management tools confirm this by
■ Software license monitoring for usage to ensure
monitoring responses to ‘pings’).
optimum/legal license utilization and allocation
● Some CIs will be included because their status needs
■ Security (e.g. intrusion detection) to change frequently and Event Management can be
■ Normal activity (e.g. tracking the use of an used to automate this and update the CMS (e.g. the
application or the performance of a server). updating of a file server).
69
Event Management - Basic Concepts
Alert - A warning that a threshold has been reached, something has changed, or a Failure has
occurred. Alerts are often created and managed by System Management tools and are
managed by the Event Management Process

Threshold - The value of a Metric that should cause an Alert to be generated, or management
action to be taken. For example ‘Priority 1 Incident not solved within four hours’, ‘more than five
soft disk errors in an hour’, or ‘more than 10 failed changes in a month’.
E.g. CPU Utilization, Security Intrusion, a batch job completed

Types of Events
Information Warning
An event which is only meant to provide information A warning is an event that is generated when a service or
device has reached a threshold that indicates situation that
E.g. Backup job completed must be checked and appropriate actions taken to prevent an
exception.
Usage
E.g. Network traffic reaching a congestion point
– To check status of activity, device
– To get statistics
Exception
– Input to investigations Event which indicates that a service or a device is
behaving abnormally (against a defined behavior).
Typically this means that an OLA and SLA have
Informational events are usually recorded for a pre- been impacted.
determined period for the above listed usage. E.g. Hdd1 in RAID has failed
70
Event Management - Process Flow

71
SO 02: Incident Management - Overview
Objectives

 Restore normal Service operation as soon as possible.

 Minimize the adverse impact on business operations.

 Ensure Service quality and availability are maintained

 An Incident can be defined as an unplanned interruption to an IT service or

reduction in the quality of an IT service.
˗ Failure of a configuration item that has not yet impacted service is also an
incident, for example failure of one disk from a mirror set.
 To restore NORMAL service operation as quickly as possible
• NORMAL means as agreed in SLA
 To log & Track incidents wherever applicable (e.g. Proactive measure)
 To deal with all incidents consistently
 To assist Problem Management team as required
 To assist Service Desk/ Release Team for any RFCs

72
Incident Management – Process Flow

73
 Incident Management – Key Concepts

Sample Priority Matrix

 Priority = Impact X Urgency

 Impact: Evidence of effect upon
business activities
 Urgency: Evidence of effect upon
business deadlines

Escalation
• Functional Escalation: Through various functions or support group
levels
• Hierarchical Escalation: Through organizational hierarchy

74
 Incident Management - Activities

Incident Categorization

Part of the initial logging must

be to allocate suitable
incident categorization coding
so that the exact type of
the call is recorded.

This will be important later

when looking at incident
types/frequencies to establish
trends for use in Problem
Management, Supplier
Management and other ITSM
activities.

75
 Incident Management - Activities
Investigation and Diagnosis: This investigation includes:
■ Establishing exactly what has gone wrong or being sought by the user
■ Understanding the chronological order of events
■ Confirming the full impact of the incident, including the number and range of users
affected
■ Identifying any events that could have triggered the incident (e.g. a recent change,
some user action?)
■ Knowledge searches looking for previous occurrences by searching previous
Incident/Problem Records and/or Known Error Databases or
manufacturers’/suppliers’ Error Logs or Knowledge Databases.

Resolution and Recovery: When a potential resolution has been identified, this
should be applied and tested. Sufficient testing must be performed to ensure that
recovery action is complete and that the service has been fully restored to the
user(s).
Closure: The Service Desk should check that the incident is fully resolved and that
the users are satisfied and willing to agree the incident can be closed. The Service
Desk should
also check the following:
Incident Categorization, Incident documentation, Check if it is an Ongoing or
recurring problem?, user satisfaction survey and formal closure.
76
SO 03: Problem Management
Objectives

 To minimize the adverse impact of Incidents and Problems on the business that are caused by
errors within the IT Infrastructure.

 To prevent recurrence of Incidents related to errors.

Scope:

 Problem Management includes the activities required to diagnose the root cause of incidents
and to determine the resolution to those problems.

 It is also responsible for ensuring that the resolution is implemented through the appropriate
control procedures, especially Change Management and Release Management.

 Problem Management will also maintain information about problems and the appropriate
workarounds and resolutions, so that the organization is able to reduce the number and impact
of incidents over time.

 In this respect, Problem Management has a strong interface with Knowledge Management,
and tools such as the Known Error Database will be used for both.

77
 Problem Management
• A “Problem" is underlying cause of one or more incidents.
• It is logged when the root cause is not usually known.
• Examples:
– Several incidents relating to job failures - Investigations reveal issue with
connectivity or server issues
– Testing or UAT not done – could lead to potential incidents. Identify this and
correct it. Create a problem ticket

Problem Management is of two types :

1. Reactive Problem Management

Resolution of underlying cause(s).
Problem Management, which is generally executed as part of Service Operation.
2. Proactive Problem Management
Prevention of future problems.
Problem Management which is initiated in service Operation, but generally
driven as part of Continual Service improvement

78
Problem Management – Basic concepts
Error
An Incident or Problem for which the root cause is
known.

Known Error
An Incident or Problem for which the root cause is
known and for which a workaround or permanent
solution has been identified.

Root Cause
The underlying or original cause of an Incident or
Problem.

Known Error Database (KEDB)

The purpose of a Known Error Database is to allow storage of previous knowledge of Incidents
and problems – and how they were overcome – to allow quicker diagnosis and resolution, if
they recur.

The Known Error Database is used at the Initial Diagnosis activity in the Incident Management
process to see if any Incidents with the same or similar symptoms already exist.

79
 Problem Management – Major Activities

Problem Control

The aim of Problem control is to identify the root cause, such as the CIs that are at fault, and
to provide Incident Management with information and advice on Workarounds when available.

Note: Problem control focuses on turning Problems into Known Errors. All Problem
records should be recorded in a known error database.

Error Control

The objective of error control is to be aware of errors, to monitor them and to eliminate them
when feasible and cost-justifiable.

Note: Error control focuses on resolving Known Errors structurally through the Change
Management process.

80
 Problem Management – Process Flow

81
 Problem Management - Roles
Problem Manager
 Single point of coordination and owner of the Problem Management process.
 Accountable for the Major Problem Reviews and closure of the actions.
 Ownership and protection of the known error database.
 Liaison with all the technical support groups including vendors for swift resolution of
problems within agreed timelines.

Problem Solving / Technical Support Groups

 Record Problems & Identification of root cause.

 Providing workaround or permanent fix.
 Liasoning with third party vendors for problem resolution.
 Updation of Known Errors, Workarounds and Permanent Fixes in KEDB.
 Raise Request for Change.
 Updation of problem records in CMS.
 Participate in Major Problem Reviews.
 Communicate on availability of Known Errors, Workarounds and Permanent Fixes to
Incident Staff.

82
 SO 04: Request Fulfilment
Objectives:
 To provide a channel for users to request and receive standard services for which a pre-
defined approval and qualification process exists.
 To provide information to users and customers about the availability of services and the
procedure for obtaining them.
 To source and deliver the components of requested standard services (e.g. licenses and
software media).
 To assist with general information.

Request Models
 Predefined steps to consistently handle frequent requests.
 Predefined requests are normally pre- approved changes also call standard change
Some Service Requests will frequently occur and will require handling in a consistent manner
to meet agreed Service levels. To assist this, predefined Request Models (which typically
include some form of pre-approval by Change Management) are created.
E.g. Password reset, User Queries, IMAC Requests from End users

Menu Selection
Request Fulfilment offers great opportunities for self-help practices where users can generate a
Service Request using technology that links into Service Management tools.
Ideally, users should be offered a ‘menu’-type selection via a web interface, so that they can
select and input details of Service Requests from a pre-defined list.
83
 Request Fulfilment - Process Flow

84
 SO 05: Access Management - Overview
Objectives: Access Management is the process of  Access
granting authorized users the right to use a service, Refers to the level and extent of a Service’s
while preventing access to non-authorized users. It functionality or data that a user is entitled
has also been referred to as Rights Management or to use.
Identity Management in different organizations.  Identity
Information about a User that distinguishes
Scope: them as an individual, and which verifies
• Access Management is effectively the execution their status within the organization. By
of both Availability and Information Security definition, the Identity of a user is unique to
Management, in that it enables the organization that User.
to manage the confidentiality, availability and  Rights (or privileges)
integrity of the organization’s data and intellectual Refers to the actual settings whereby a
property. user is provided access to a Service or
• Access Management ensures that users are group of Services. Typical rights, or levels
given the right to use a service, but it does not of access include read, write, execute,
ensure that this access is available at all agreed change, delete.
times – this is provided by Availability  Services or Service groups:
Management. Ability to grant each user (or group of
• Access Management is a process that is users) access to the whole set of Services
executed by all Technical and Application that they are entitled to use at the same
Management functions and is usually not a time.
separate function. However, there is likely to  Directory Services
• be a single control point of coordination, usually in A specific type of tool that is used to
IT Operations Management or on the Service manage access and rights.
Desk.
85
 Service Operation - Functions

86
 Service Desk - Basic Concepts

 Functional Unit and Single point of contact for IT users on a day-by-day basis.
 Deals with all user issues (incidents, requests, standard changes).
 Co-ordinates actions across IT Organization to meet user requirements.

Different types of Service Desk are :

1. Local
2. Centralized
3. Virtualized

87
Service Desk - Overview
The primary goal of the Service Desk is to restore normal service to the users as quickly as
possible.

Roles and Responsibilities:

 Logging and Categorizing Incidents, Service Requests and some categories of Change.

 First line investigation and diagnosis.

 Timely Escalation.

 Communication with Users and IT Staff.

 Closing Incidents, Service Requests etc.

 Ensure Customer Satisfaction.

 Update the CMS as and when required & Generate MIS.

88
 IT Operations Management

Roles and Objectives :

1. IT Operations Control

 Maintains stability of day-to-day processes and activities

 Provides regular scrutiny and recommendations to achieve improved Service at reduced
costs, whilst maintaining stability
 Diagnoses and resolves IT operations failures
 Responsible for the daily operational activities needed to manage and maintain the IT
infrastructure

2. Facilities Management

 Management of physical IT environment, usually datacenters or computer rooms

E.g. Console Management, Backup and Restore, Maintenance activities

89
 Technical Management

Roles and Objectives :

1. Provides detailed technical hands-on skills and resources to support the IT

Infrastructure

 Custodian of technical knowledge and expertise related to managing the IT infrastructure.

 Provides resources to support the IT Service Management Lifecycle.

2. Helps plan, implement and maintain a stable technical infrastructure to support the
organization’s Business Processes

E.g. Server Management, Storage Management, Database Management

90
 Application Management
Roles and Objectives :

1. Responsible for managing applications throughout their Lifecycle; also supports and
maintains operational applications

 Custodian of technical knowledge and expertise related to managing applications.

 Provides the actual resources to support the IT Service Management Lifecycle

2. Supports the organization’s business processes through Applications Management

E.g. SAP Application Management, Finacle Application Management,

Oracle Apps Management

91
 Continual Service Improvement

92
ITIL 2011 - Basic Concepts
Critical Success Factor:
Something that must happen if a Process, Project, Plan, or IT Service is to succeed. KPIs are
used to measure the achievement of each CSF.

For example a CSF of "protect IT Services when making Changes" could be measured by KPIs
such as "percentage reduction of unsuccessful Changes", "percentage reduction in Changes
causing Incidents" etc.

KPI
KPI Categories:
A Metric that is used to help manage a
Process, IT Service or Activity. Compliance KPIs: Are we doing it?
Quality KPIs: How well are we doing it?
The following four quadrants represent a Performance KPIs: How fast or slow are
dashboard by which the Process Owner can we doing it?
determine the health of a process. Value KPIs : Is what we are doing making
a difference?

Metric

Something that is measured and reported to

help manage a Process, IT Service or
Activity.
93
 Continual Service Improvement - Overview
Goal: The primary aim of CSI is to continually align and realign IT services
to the changing business needs by identifying and implementing
improvements to IT services that support business processes.

CSFs (Critical Success Factors) CSI approach

determine the success or failure of a
Service strategy
Baseline - A beginning point for
highlighting improvement is to
establish baselines as markers or
starting points for later comparison.
KPIs (key performance indicators)
are defined during Service Design
and Service Transition. The
provision of KPIs is essential to
supporting CSI. These KPIs become
the data inputs to analyze and
identify improvement opportunities.

94
 7-Step Improvement Process

95
 CSI - Measurement & Metrics

Three types of metrics to support the CSI activities:

 Technology metrics
These metrics are often associated with component and application-
based metrics such as performance, availability etc.
 Process metrics
 These metrics are captured in the form of CSFs, KPIs and activity
metrics for the service management processes.
 These metrics can help determine the overall health of a process.
 Four key questions that KPIs can help answer are around Quality,
Performance, Value and Compliance of following the process. CSI
would use these metrics as input in identifying improvement opportunities
for each Process.
 Service metrics
 These metrics are the results of the end-to-end service.
 Component metrics are used to compute the service metrics.

96
 ITIL V3 Summarization
Technical
Management
IT Operations
Management
Knowledge Technical
Supplier Management
Management Management
Service Catalogue
Evaluation Service Desk
Management
Information Security Service Validation & Request Fulfillment
Management Testing Mgmt
IT Service Continuity Transition Planning
Strategy Generation Event Management
Management and Support
Release &
Demand Management Capacity Management Asset Management
Deployment Mgmt
Service Portfolio Availability Service Asset & Problem
Management Management Configuration Mgmt. Management
Service Level
Finance Management Change Management Incident Management
Management

Service Service Service Service

Strategy Design Transition Operation

Continual Service Improvement

7 Step Improvement Process
Service Reporting Service Measurement

Key ITIL V3 Process ITIL V3 Function

97