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 Design Co-
& Service • 5 Books
Delivery (11 ordination
Processes
processes) • 24 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 STRATEGY SERVICE DESIGN

1. Strategy Management 1. Design Coordination

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

SERVICE OPERATION
SERVICE TRANSITION
1. Event Management
1. Transition Planning and
2. Incident Management
Support
3. Request Fulfilment
2. Change Management
4. Problem Management
3. Service Asset &
5. Access Management
Configuration Management
4. Release & Deployment
Management
CONTINUAL SERVICE IMPROVEMENT 5. Service Validation
6. Evaluation
Seven Step Improvement 7. Knowledge 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
Y
– Functional Performance T/F

supported? OR
requirements Constraints Fit for
– Features, inputs, 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
Y
– Functional Performance T/F

supported? OR
requirements Constraints Fit for
– Features, inputs, removed? purpose?

outputs…
– “fit for purpose” Available enough? Fit for
use?
Capacity enough?
• Warranty AND
Continuous enough? T/F
– How well does the
Secure enough?
service do it? 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:
Y
– Functional Performance T/F False
supported? OR
requirements Constraints Fit for
– Features, inputs, removed? purpose?

outputs… AND
T/F
– “fit for purpose” Available enough? Fit for
use?
Capacity enough?
• Warranty AND VALUE
Continuous enough? T/F
CREATE
– How well does the
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
Purpose Establish and maintain a constructive
relationship between the service provider and
the customer based on the understanding the
customer and their business drivers
To Identify customer needs and ensure that the
service provider is able to meet these needs.
Service Level Management
To negotiate SLA with customers
and ensure that all Service
management processes, OLAs
and UCs are appropriate for the
agreed service level targets.

Focus Strategic and Tactical – The focus is on the
overall relationship with the customer and
which services the service provider will deliver
to meet customer needs.
Primary Measure  CSAT
 Improvement in the customer’s intention to
better use and pay for the service,
Tactical and Operational – The
focus is on reaching the SLA
agreement and whether the
service provider was able to meet
those agreements
Achieving agreed levels of service
which leads to customer
satisfaction.

 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
Management.
software
Designing security controls and developing security plans.
Availability (accessibility):
Monitoring and managing all security breaches and
Ensuring that information and
vital IT services are available and handling security incidents, taking remedial action to
accessible when required. prevent recurrence wherever possible.

42
Information Security Management - Basic Concepts
Information Security Management Framework

43
 SD 04: Availability Management - Overview
Goal
To ensure that the level of service availability
delivered in all services is matched to or exceeds the
current and future agreed needs of the business, in a
cost-effective manner.
Definitions
 Service availability: Involves all aspects of service
availability and unavailability and the impact of
component availability, or the potential impact of
component unavailability on service availability.
 Component availability: Involves all aspects of
component availability and unavailability.
 Reliability: A measure of how long a service,
component or CI can perform its agreed function
without interruption.
 Maintainability: A measure of how quickly and
effectively a service, component /CI can be restored
to normal working after a failure.
 Serviceability: The ability of a third-party supplier to
meet the terms of their Contract.
44
Vital Business Function
A function of the Business Process,
which is critical to the success of the
Business. It is used to reflect the
critical elements of the Business
Process supported by an IT Service.
( E.g.. Cash dispensing in an ATM
Machine )
High availability
A characteristic of the IT service that
minimizes or masks the effects of IT
component failure to the users of a
service.
Fault tolerance
The ability of an IT service,
component or CI to continue to
operate correctly after failure of a
component part.
 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
implemented immediately.
Emergency Changes are disruptive and
prone to failure
E.g. the some ports in critical switch has
gone down. Therefore, a new switch needs
to be installed
54
There are other change types in used based on
the nature of the environment
Expedited Changes
Any change that has a strong business
justification to be done as early as possible and
that can be included for the CAB review without
following the standard lead times.
Change Management - Basic Concepts
Seven R’s of a Change

Change, Configuration, Release and Remediation Plan

Deployment
• Should be planned together
• Should have coordinated implementation
• Every change must have a roll back plan
• Sometime a change cannot be rolled back.
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

Service Operation Processes

• Event Management
• Service request Fulfilment
• Incident Management
• Problem Management
• Access Management

Service Operation Functions

• Service Desk
• Technical Management
• Operations Management
• Applications Management
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
E.g. Backup job completed indicates situation that 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).
Informational events are usually recorded for a pre- Typically this means that an OLA and SLA have
determined period for the above listed usage. been impacted.
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
granting authorized users the right to use a service,
while preventing access to non-authorized users. It
has also been referred to as Rights Management or
Identity Management in different organizations.
Scope:
• Access Management is effectively the execution
of both Availability and Information Security
Management, in that it enables the organization to
manage the confidentiality, availability and
integrity of the organization’s data and intellectual
property.
• Access Management ensures that users are given
the right to use a service, but it does not ensure
that this access is available at all agreed times –
this is provided by Availability Management.
• Access Management is a process that is executed
by all Technical and Application Management
functions and is usually not a separate function.
However, there is likely to
• be a single control point of coordination, usually in
IT Operations Management or on the Service
Desk.
85
 Access
Refers to the level and extent of a Service’s
functionality or data that a user is entitled to
use.
 Identity
Information about a User that distinguishes
them as an individual, and which verifies
their status within the organization. By
definition, the Identity of a user is unique to
that User.
 Rights (or privileges)
Refers to the actual settings whereby a
user is provided access to a Service or
group of Services. Typical rights, or levels
of access include read, write, execute,
change, delete.
 Services or Service groups:
Ability to grant each user (or group of
users) access to the whole set of Services
that they are entitled to use at the same
time.
 Directory Services
A specific type of tool that is used to
manage access and rights.
 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
A Metric that is used to help manage a
Process, IT Service or Activity.
The following four quadrants represent a
dashboard by which the Process Owner can
determine the health of a process.
KPI Categories:
Compliance KPIs: Are we doing it?
Quality KPIs: How well are we doing it?
Performance KPIs: How fast or slow are
we doing it?
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