Student Guide r3.4

ITIL Foundations based on Version 3 – Student Guide – R3.
Foundations
Course for IT
Service
Management
(Based on ITIL® V3)
Participant Workbook
V3.4
Course Description:
ITIL v3 Foundations is an intensive three-day course. Success in the one hour multiple-choice examination at the
end of the course will lead to award of the Foundation Certificate in IT Service Management. This interactive
computer based training course is expected to take approximately 20 hours to complete.
Objectives:
 Provides an essential level of knowledge in the following areas:

 Service Management as a practice
 Service Lifecycle
 Key Principles and Models
 General Concepts and Definitions
 Selected Processes
 Selected Roles
 Selected Functions
 Technology and Architecture
 ITIL v3 Qualification scheme
 Prepares students to pass the ITIL Foundation exam.
 Helps students leverage ITIL concepts and practices in their daily work.
 Certification Exam from EXIN or ISEB
This document is provided as a printable version of the course to support the students need for distance learning
when access to a computer is not convenient.
Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Copyright © 2008 Dream Catchers, Inc. All rights reserved.
ITIL Foundations based on Version 3 – Student Guide – R3.4

Learning Objectives
Notes:
 To provide a basic understanding of the ITSM framework
as described by the IT Infrastructure Library (ITIL) The exam is a one hour (maximum), „closed book‟
 To understand how ITSM can be used to enhance the exam. The exam will be proctored. The proctor will
quality of IT service management within an organization
 To enable comprehension and / or awareness of key provide you everything you need for the exam,
areas of the 5 ITIL core books: including:
Service Strategy

 Exam Paper (questions)
 Service Design
 Service Transition  Answer sheet
 Service Operation  Pencils
 Continual Service Improvement
 To prepare to sit the ITIL Foundation Exam
 Format
 40 Multiple Choice Questions (26 correct to pass)
Notes:
ITSM as a Practice
 Understand the Difference
between ITIL and ITSM
 Business Issues and Drivers for
ITSM
 Value of IT Service Management
 Key Concepts of IT Service
Management
Market Drivers / Issues for IT

 Business reliance on IT is growing
Notes:
Considerations:
 There is a higher demand for Notes regarding IT Performance (from Gartner):
 Increasing regulatory business
tangible, real business value control and reporting
 Business enterprises require the requirements (e.g. SOX)  38% - no consistency in the delivery
ability to plan, monitor and  Global 24 / 7 operations are a
manage the value they get from IT must of changes
 IT must help the business define
and manage its own business
 Perception of IT Service quality
= poor or unclear
 29% - more than half the IT effort
value by providing the framework  Infrastructure behavior is
unpredictable and impact on
spent is on firefighting
and mechanisms for measuring,
articulating and controlling
the business is intangible  Up to 75% of calls to the Service Desk
 The valuable use of IT and
business value – top to bottom
resources is hard to define are due to failed changes
 Major commercial failures are
The Value Equation*
at risk from IT failures  Up to 50% of calls to the Service Desk
 Budgets are being tightly
justified are repeat incidents
Get Pay
 Competition (e.g. outsourcing)
is increasing
 Less than 35% of IT organizations
*for non-MBAs produce business focused metrics
 50% of IT organizations produce only
IT performance metrics

IT‟s Key: Managing to Business Value

Notes:
What May be Value (indicators): What is NOT Value?
 Quality  P&E Ratio
 Risk Management  Share price
 Compliance  Rating
 Market  Flexibility
penetration  Security
 Time to market System
Availability
Managing Value means:

Project
 Understanding how the business “on budget”
delivers and manipulates value “on time”
Status
 Linking business value drivers to IT
services that deliver value
 Designing, operating and Deliverables
optimizing services to ensure the
realization of value
What is IT Service Management (ITSM)?

Notes:
Service management is a set of specialized Challenges include:
organizational capabilities for providing value
to customers in the form of services. ■ Intangible nature of the output and intermediate
 ITSM transforms resources and capabilities into value-adding products of service processes: difficult to measure,
services
 Capabilities represent a service organization‟s capacity, control, and validate (or prove).
competency and confidence for action
 Incorporates functions and processes across a service lifecycle
■ Demand is tightly coupled with customer‟s assets:
users and other customer assets such as processes,
Customer Service Provider applications, documents and transactions arrive with
demand and stimulate service production.
© Crown copyright 2007
Reproduced under license from OGC
■ High-level of contact for producers and consumers
of
services: little or no buffer between the customer, the
front-office and back-office.
■ The perishable nature of service output and service
capacity: there is value for the customer in receiving
assurance that the service will continue to be supplied
with consistent quality. Providers need to secure a
steady supply of demand from customers.
(ITIL text)

IT Service Management Goals

Notes:
 Align IT services with the current and future business
needs of the customers
Also referred to as BITA (Business IT Alignment)
 Improve the quality of IT services – in whatever way

the customer expresses „quality‟, e.g.,
 Dependability
 Timeliness
 Accuracy of predictions
 Reduce the long term cost of

service provision
i.e. more for the same
or less cost
What is ITIL?
Notes:
 A set of books describing
accepted world-wide „best The UK‟s Office of Government Commerce (OGC) has
practice‟ for quality IT Service
Management documented a set of processes and procedures for the
 Originally developed in the 1980s delivery and support of high quality IT services,
in the UK with public
and private sector contributions designed and managed to meet the needs of an
 OGC - Office of Government organization.
Commerce owns the copyright
 Used as the foundation ISO 20000 Its full title is ITIL Service Management Practices. The
 Maintained by the itSMF (the IT original meaning of the words behind the initials is
Service Management Forum) unimportant and not used any longer.
representing IT Service
Management professionals world- It is described not as a Standard or a methodology but
wide
 Common language
as a description of good practice to be adopted by an
organization and adapted to meet its specific needs.
Reasons for Adoption in North America

Notes:
3%
17% IT Accountability /
IT Governance / Transparency
Compliance
35%
Improve Quality of
IT Services
20%
Cost Reduction /
Increase Efficiencies
25%
IT and Business
Alignment Source: CMP Research, 2006

Integration of the 5 Core Books

Notes:
Requirements The business/customers
Service Objectives from

Strategy Resource & Requirements
Policies constraints
Strategies
Service
Design SDPs
Standards
Solution Architectures
Service Portfolio
Service Catalog
Designs
Service
Transition Tested SKMS
Transition solutions
Plans
Service Operational
Operation services
Continual Service
Improvement Improvement
actions & plans

Good Practice
Notes:
Standards Employees
KEY: Good practices are in wide industry use
Industry practices
(Aggregate)
Customers
(Generate)
because they work.

Enablers
Sources
Academic research Suppliers

Training and education Advisors Good practice results from a combination of effects.
Internal experience Technologies
Public frameworks and standards (such as ITIL) are
attractive when compared with proprietary knowledge
Substitutes Competition deeply embedded in organizations and therefore
Scenarios
Drivers
(Filter)
(Filter)
Regulators Compliance difficult to adopt, replicate, or transfer even with the

Commitments
Customers cooperation of the owners. Best practice often
Knowledge fit for business objectives,
presents a generic view of proven quality practices,
context, and purpose but it is unlikely that every organization can, or will
wish to, implement a solution in an identical way. Thus
organizations adapt and adopt, developing good
practice within their own enterprise – which may feed
back into the evolution/improvement of best practice.
Publicly available frameworks and standards such as
ITIL, COBIT, CMMI, PRINCE2, ISO 9000, ISO/IEC
20000, and ISO/IEC 27001 are validated across a
diverse set of environments rather than the limited
experience of a single organization or person.
(ITIL text)
What is a „Service‟?
Notes:
A service is a means of delivering value to
Definition
customers by facilitating outcomes customers

want to achieve without the ownership of
specific costs and risks.
Performance Service
potential potential
Customer Provider
+ +
Capabilities + Capabilities
Service
– Risks Costs
+ –
Resources Resources
Demand Idle
capacity
enhance the performance of tasks

reduce the effect of constraints

Service Assets
Notes:
Service assets are used to create value in the Capabilities focus on the soft assets of the
form of goods and services
organization and resources on the hard, tangible
 Resource assets such as, money, hardware, software and
 The term „resource‟ is a generic term that includes IT information. Capabilities like management,
Infrastructure, people, money or anything else that might
help to deliver an IT service organization, people, and knowledge are used to
 Resources are considered to be assets of an organization transform resources into valuable services.
 Capability Capabilities represent an organization‟s ability to do
 Capability refers to the ability of a service organization, something, i.e. coordinate, control, and deploy
person, process, application, configuration item or IT service
to carry out an activity resources to produce value. Capabilities are:
 Capabilities are intangible assets of an organization • experience-driven, knowledge-
intensive, information-based
• embedded within an organization‟s
people, systems, processes, and
technologies.
Assets are used to create value throughout the entire
Service Lifecycle.
• These are an important part of the
overall concept of People, Process,
Products, and Partners found in
Service Design, and in the need to not
only manage the technology, but the
organization, knowledge , skills and
competencies needed to provide
service to the business.
• The assets are important also in
testing and change and release
management in Service Transition.
• In Service Operation, the assets are
managed through the operation
processes that are executed by the
Service Desk, second and third line
support and the technology and
application management functions.
(ITIL text)
Service Management Key Concepts (1)

Notes:
Process A set of co-ordinated activities
combining resources and capabilities to Although ITIL recognizes a distinct difference between
produce an outcome that creates value processes and functions,, it is possible in many
for the customer
organisations for a process and a function to have the
Function Units of organizations specialized to
perform certain types of work and
same name (e.g. Change Management, Problem
responsible for specific outcomes Management, Security Management)
Role A position, responsibility or duty Functions
• provide structure and stability to
organizations
• are self-contained units with their own
capabilities and resources
• rely on processes for cross-functional
coordination and control

Service Management Key Concepts (2)

Notes:
Customer Someone who buys goods or services -
the customer is the person or group that
defines and agrees the service level
targets
User A person who uses the IT service on

a day-to-day basis
Provider A company or unit of a company that

provides IT services to customers
Supplier A third party responsible for supplying

goods or services that are required to
deliver IT services
Generic Process Model

Notes:
Process
Process
Policy Process A process is a structured set of activities designed to
Owner Objectives
Process Process
accomplish a specific objective. A process takes
Documentation Feedback inputs and produces defined outputs. A process may
Control
define policies, standards, guidelines, and work
Triggers Process instructions.
Activities, Roles
Procedures, Metrics, A process
INPUTS Improvement OUTPUTS
 Has defined information inputs and
outputs
Resources Enablers Capabilities
 Consumes resources
 Subject to management controls over
Reproduced under license from OGC time, cost and quality
 Need to balance benefits against risks
 Process defines what is to be
achieved
 Procedures define how the objectives
are to be achieved
Measures should help to determine value for money
• Economy = Cost of inputs to an
activity, resources needed to deliver a
service
• Efficiency = Ratio of inputs to outputs
– “bang per buck”
• Effectiveness = Cost of outputs from
an activity and the conformance of
those outputs to the specifications
Processes must be audited for quality – when
implemented, regularly and when process failures are

discovered
People and tools enable processes – tool
specification, design / build and implementation follow
process design
Process control is the activity of planning and
regulating a process, with the objective of performing
the process in an effective, efficient, and consistent
manner.
(ITIL text)
Process Characteristics
Notes:
 Measurable
 Performance driven All processes must have certain characteristics.
 Managers measure cost and
quality Measurable - We must be able to measure the
 Practitioners measure duration process. The performance of the process is incredibly
and productivity
 Specific Results important. Managers will want to measure the cost
 Individually identifiable and and quality. People involved operationally with the
accountable
 Delivers to Customers (of processes)
process are concerned with how long it takes and how
 It must meet their expectations easy it is.
 Responds to Specific Events
 Should be traceable to a Specific results - The reason a process exists is to
specific trigger deliver a specific result. This result must be
individually identifiable and countable.
Customers - Every process delivers its primary results
to a customer or stakeholder. They may be internal or
external to the organization but the process must meet
their expectations.
Responds to a specific event - While a process may
be ongoing or iterative, it should be traceable to a
specific trigger.
Specific Roles
Notes:
ITIL describes several key roles
that assist in the provision of
quality services:
 Service Owner - providing
focus for their Services
 Process Owner - for every
Process - Service
Management, IT and
Business
 Process Manager - for each
process

Service Owner
Notes:
 Initiation, transition and ongoing Service Owner responsible for specific service. Not
maintenance
 Prime contact for service responsible for execution of design, transition or
related issues operation activities.
 Ensure service delivery meets
customer requirements Service Owner should represent their service in
 Identify service improvements Change Advisory Board (CAB) meetings.
and raise Requests for Change
 Liaise with Process Owners throughout the

Service Management lifecycle
 Effective reporting and monitoring
 Accountable to the IT Director for the delivery
of the service
Process Owner
Notes:
 Define process strategy,
policy and standards The process owner is not responsible for executing
 Assist with process design activities within the process.
 Ensure process
documentation is available
and current
 Audit the process for
efficiency, effectiveness and
compliance
 Communicate information to
ensure awareness
 Provide resources and
training
 Provide input to Service
Improvement Programs
Process Manager
Notes:
 Responsible for the operational
management of a process
 Responsibilities include planning
and coordinating all activities
required to carry out, monitor and
report on the process
 There may be several Process
Managers for one process (e.g.
regional Change Managers)
 The Process Manager role is often
assigned to the person who carries
out the Process Owner role, but the
two roles may be separate in larger
organizations

RACI Model
Notes:
Responsible: The person or Consulted: Involved through
people responsible for input of knowledge and The RACI matrix documents the roles and
getting the job done information relationships of stakeholders in a process or activity. It
Accountable: Only 1 person Informed: Receiving is used to clarify to all involved which activities and
can be accountable for information about process
each task execution and quality
roles they are expected to fulfil, as well as identifying
any gaps in process delivery and responsibilities. It is
especially helpful in clarifying the associated staffing
model.
IT Service Management Reusable Concepts

Notes:
Business Cases Means of quantitatively
supporting action or decision Business cases are developed to support:
(for services, changes, • The definition of services (in terms of the
improvements, etc.)
value for both customers and the provider
Models Templates for common activities
or structures (for changes, • Requests for Change (RFCs)
incidents, configurations, etc.) • Improvements to services and service
Packages Complete descriptions and management processes
specifications (for releases,
designs, etc.) Examples of Models in ITIL include:
Baselines Descriptions of a state at a • Incident Models
particular point in time (for • Change Models
services, configurations, process
performance, etc.) • Request Models
• Configuration Models
• Service Models
Examples of Packages in ITIL include:
• Service Package
• Service Level Package
• Service Design Package
• Release Package
The Business Case

Notes:
Business Case
A decision support and Dimensions Business Cases are used heavily in both Service
planning tool that projects
the likely consequences of
Qualitative Strategy and Continual Service Improvement.
a business action Quantitative
Conceptually, business cases are considered in all
A. Introduction phases of the lifecycle of a service – for example:
The business objectives addressed by the service • As justification for requested changes
B. Methods and assumptions
Defines the boundaries of the business case, such as • As a component of a Capacity Plan
time period, whose costs and whose benefits
C. Business impacts
• As a component of an Availability Plan
The financial and non-financial business case results • As a consideration in implementing a
D. Risks and contingencies
The probability that alternative results will emerge structural problem resolution
E. Recommendations
Specific actions recommended See also reference to business cases for Continual
Service Improvement (page 166).

Managing Risk
Notes:
Risk management analysis
An uncertainty of Define
outcome, Framework
whether positive
opportunity or
negative threat Embed & Identify
Review Risks
business Gain Identify

operations Assurance Owners
customer
assets
demand Implement Evaluate
risk Responses Risks
ITSM
Set Risk
supply Levels
risk
service
assets Identify
service Responses
operations
Notes:
The Service Lifecycle

 The Integrated Service Lifecycle
 Objectives of each of the Service
Lifecycle Phases
 Value of each of the Service
Lifecycle Phases
The Service Lifecycle

Notes:


The Lifecycle Approach

Notes:
Business
STRATEGY need
IMPROVEMENT DESIGN
Requirements
Business need definition
Optimization Design Evaluation
Operation Develop, Procurement

build and test
Deployment
OPERATION
Retirement
TRANSITION

Service Strategy - Overview

Notes:
How to design, develop, and implement service Service Strategy is about ensuring that organizations
Purpose
management not only as an organizational are in a position to handle the costs and risks
capability but as a strategic asset
associated with their Service Portfolios, and are set up
not just for operational effectiveness but also for
Organizations use the Processes
guidance to set objectives distinctive performance.
and expectations of  Financial Management
performance towards serving  Service Portfolio Setting policies and objectives is a primary concern of
customers and market spaces, Management (including
and to identify, select, and methods) Service Strategy.
prioritize opportunities.  Demand Management
This volume of ITIL encourages readers to stop and
think about why something is to be done before
Primary deliverable: chartered service with business case
thinking of how. Answers to the first type of questions
SS are closer to the customer‟s business.
Topics covered in Service Strategy include the
development of markets, internal and external, service
assets, Service Catalogue, and implementation of
strategy through the Service Lifecycle. Financial
Management, Service Portfolio Management,
Organizational Development, and Strategic Risks are
among other major topics.
Service Design - Overview

Notes:
Purpose
A holistic approach to all aspects of the design The key message from Service Design is that new or
of new or changed service for introduction
into the live environment
changed services, processes, technology such as
monitoring systems should not be implemented in
The 5 Aspects Processes isolation. Service Design is required to enable the
 Service solutions  Service Catalog Management
continuation of all current operational aspects
 ITSM systems and tools  Service Level Management considering the impact of changes on these at the
 Capacity Management
 Technology architecture
& management systems
 Availability Management outset and not as an afterthought when the change is
 Service Continuity Management
 Processes (ITSM)  Information Security Management about to go live.
 Metrics and methods  Supplier Management
Service Design relates to significant change rather
Primary deliverable: Service Design Package than everyday (simple) changes. The classification of
SD
significant must be determined by each adopting
organization.

Service Transition - Overview

Notes:
Purpose
Assist organizations seeking to plan and manage

service changes and deploy service releases into
the production environment successfully
Processes
 Transition Planning & Support
Primary deliverable:
 Change Management
established (changed)
 Service Asset & Configuration
service, implemented and
Management
transitioned according to
 Release & Deployment the specifications in the
Management
Service Design Package
 Service Validation & Testing
 Evaluation
 Knowledge Management
ST
Service Operation - Overview

Notes:
Coordinate and carry out the activities and
Purpose
processes required to deliver and manage services

at agreed levels to business users and customers
(including the ongoing management of technology
to deliver and support services)
ITSM Functions Processes

 Service Desk  Event Management
 Technical Management  Incident Management
 Application Management
 Request Fulfillment
 IT Operations Management
(incl. Operations Control and  Problem Management
Facilities Management)  Access Management
Primary deliverable: intended

business outcomes
SO
Continual Service Improvement - Overview

Notes:
Continually align and realign IT services to the Learning and Improvement is a primary concern of
Purpose
changing business needs by identifying and Continual Service Improvement.

implementing improvements to IT services that
support business processes
 The overall health of ITSM as a discipline

 The continual alignment of the portfolio of IT
services with the current and future business needs
 The maturity of the enabling IT processes required
to support business processes in a continual service
lifecycle model
Primary deliverable: business justified improvement
CSI

37
Notes:
Foundations Course for ITSM (ITIL v3)

Service Strategy
 Activities of Service Strategy
 Key concepts
 Objectives of Service Strategy
processes
course v 3.4
© Dream Catchers, Inc.
Goals, Purpose & Scope of Service Strategy

Notes:
How to design, develop, and implement service
Purpose
management not only as an organizational

The guidance answers questions of the following kind:
capability but as a strategic asset • What services should we offer and to
whom?
 Principles useful for developing
policies, guidelines and processes Scope
• How do we differentiate ourselves
 The development of
 Value creation from competing alternatives?
 Markets (internal and external)
 Service assets  Service Assets • How do we truly create value for our
 Implementation strategy  Service Provider Types customers?
 Setting objectives and  Service Structures
expectations of performance
 Principles for strategy
• How do we capture value for our
towards serving customers and
market spaces  Key activities stakeholders?
 Identifying, selecting and
prioritizing opportunities
• How can we make a case for strategic
investments?
SS
• How should we define service quality?
• How do we efficiently allocate
resources across a portfolio of
services?
Approaches to value creation include:
• Minding the gap between the
customers perception and the defined
business outcomes
• Creating a marketing mindset
• Framing the value of services in terms
of utility and warranty that clearly
define the output that the customer
can expect
Once service management is viewed as patterns of
collaborative exchanges, rather than an assembly line,
it is apparent that it is more useful to think of service
management as a value network or net. In
constructing and analyzing the dynamics of a service
structure, Service Strategy answers critical questions
regarding services:
• Who are all the participants in the
service?
• What are the overall patterns of
exchange or transactions?
• What are the impacts or deliverables
of each transaction on each
participant?
• What is the best way to generate
value?
Organizations already practicing ITIL may use this
publication to guide a strategic review of their ITIL-
based service management capabilities and to
improve the alignment between those capabilities and
their business strategies. This volume of ITIL
encourages readers to stop and think about why
something is to be done before thinking of how.
The Activities of Service Strategy

Notes:
 Understand the customer
Define the
Market  Understand the opportunity
 Clarify and visualize
 Understand market space

Develop the
Offerings  Define outcome-based services
 Service Portfolio, Catalog and Pipeline
 Customer and service assets
Develop the
Assets  Service Management as an asset
 Enhancing performance and potential
 Assessment and objectives
Prepare for
Execution  Prioritizing
 Potential, expansion and growth
SS
Utility & Warranty

Notes:
From the customer‟s perspective, the business value of a
service is created by the combination of two elements: For a service to offer value to a customer, it must meet
 Utility - the functionality offered by a product or service its purpose (utility) and perform within stated
from the customer‟s perspective (Fitness for Purpose)
 Warranty - a promise or guarantee that a product or
parameters (warranty).
service will meet its agreed requirements (expressed in a
formal agreement e.g. Service Level Agreement or
These two aspects of a service are key to how the
Contract (Fitness for Use) Service Lifecycle works in all other stages.
• The concepts of utility and warranty
Performance supported?
Constraints removed?
OR
Fit for are used within Service Design as a
purpose?
Available enough?
AND Value-created starting point for defining functional
Fit for
Capacity enough?
Continuous enough?
AND use? and performance design
Secure enough? specifications - in other words, how
SS
the business will use the service
(utility) and what the SLA will be for its
performance (warranty).
• Within Service Transition, utility and
warranty translates to testing and
validation processes such as user
testing (utility) and availability testing
(warranty).
• The link to Service Operation is seen
in the definition and management of
events, incidents, problems, and
access, all of which can report
exceptions to (or meeting the
expectations of) utility and warranty.

Service Portfolio Management

Notes:
To govern investments in service management A Service Portfolio describes a provider‟s services in
Goal
dynamically across the enterprise and

manage them in the provision of value terms of business value.
 Understand the
By considering services as a system for creating and
customer‟s business and capturing value, regardless of sourcing or
defining business “The value of a
services Service Portfolio underpinnings, the line between IT Services and
strategy is
 Aligning IT services and demonstrated business services begins to blur.
business services through the ability to
anticipate change A Service Portfolio describes a provider‟s services in
 Linking IT service assets while maintaining
to higher-level business traceability to strategy terms of business value. It articulates business needs
services – Business and planning.” and the provider‟s response to those needs.. By acting
Service Management
as the basis of a decision framework, a Service
SS Portfolio either clarifies or helps to clarify the following
strategic questions:
• Why should a customer buy these
services?
• Why should they buy these services
from us?
• What are the pricing or chargeback
models?
• What are our strengths and
weaknesses, priorities and risk?
• How should our resources and
capabilities be allocated?
ITSM means thinking of IT as a cohesive set of
business resources and capabilities. These resources
and capabilities are managed through processes and
ultimately represented as services.
Business perspectives often do not easily relate to IT
infrastructure. A strategy aimed at this challenge is
Business Service Management (BSM). Business
Service Management is the ongoing practice of
governing, monitoring and reporting on IT and the
business service it impacts. BSM differs from previous
strategic methods by offering a holistic top-down
approach aimed at aligning the IT infrastructure with
the business.
BSM sets forth a model for developing business-
focused metrics, enabling adaptation to future needs
as driven by the business requirements. The
cornerstone to BSM is the ability to link service assets
to their higher-level business services.
(from ITIL text)

Service Lifecycle within the Service Portfolio

Notes:
Included in the Service Pipeline is the „Requirements
Catalog‟
Service Service Portfolio
Lifecycle
Services under
development, build or
test
Service Status:
Requirements „The Requirements Catalog is the central repository of
Defined
Analyzed
Service Pipeline Customer/support
team viewable section
the users‟ requirements, and all the requirements
Approved
Chartered of the Service Portfolio should be documented here, following the analysis of
Designed
Developed Service the list defined above. The Requirements catalog
Built Catalog
Test should form part of the overall Service Pipeline within
Released
Operational the overall Service Portfolio. Each requirement that
Retired
Retired Services Services no longer live
has been analyzed is documented using a standard
template …‟ Service Desk § 5.1.5.1
SS A Service Catalog is also a collection of Lines of
Service (LOS), each under the control of a Product
Manager. Definition of a Line of Service: A core or
supporting service that has multiple service packages.
Each LOS provides a combination of utility and
warranty most preferred by a segment of customers.
Customer segments are defined in terms of business
outcomes. Each LOS has one or more service
offerings. Business Relationship Managers help
represent the interests of customer segments to
Product Managers and vice versa.
Demand Management Objectives

Notes:
Visualize the customer‟s business activity and The primary goal of Demand management is to help
Goal
plans in terms of the demand for required

supporting services ensure the ability to supply services (via capacity).
Demand Management is most tightly integrated with
 Understand the
customer‟s business to
Capacity Management and seeks to eliminate excess
identify, analyze and capacity. (ITIL text)
codify patterns of
business activity (PBAs) &
User Profiles
 Reduce the risk of
uncertainty in demand
 Avoid excess capacity
that generates cost
without creating value
SS
Demand Management Concepts

Notes:
 Challenges in Managing Demand for Services
 Demand “pulls” capacity – capacity can not be
Demand Management techniques such as off-peak
stored to meet future demand pricing, volume discounts and differentiated service
 Excess capacity increases costs without increasing levels can influence the arrival of demand in specific
value
patterns. However, demand still pulls capacity.
 Insufficient capacity will result in unmet demand /
poor service Key Demand Management concepts include the
 Activity-based Demand Management – Analyzing and
tracking Patterns of Business Activity (PBAs) helps
following:
predict demand for services • Activity-based demand management
 Business Activity Patterns – can be determined based • Patterns of business activity (PBAs)
on User Profiles, consisting of one or more PBAs
 PBAs and User Profiles are documented and subject to
• User profiles (UPs)
change control • Differentiated offerings
SS • Differentiated service levels
Patterns of demand generated by the customer's
business are driven by patterns of business activity.

User profiles may refer to applications or processes as
well as to user roles in the more traditional sense
(from ITIL text)
Financial Management Objectives

Notes:
Bring to the enterprise the core capabilities of
Goal
operational visibility, insight and superior

decision making
 Financial Management provides the

business and IT with the
quantification, in financial terms, of:
 the value of IT services
 the value of the assets underlying
services
 the qualification of operational
forecasting
 A key source of input for Business
Cases
SS
Service Strategy - Review

Notes:
How to design, develop, and implement service
Purpose
management not only as an organizational capability

but as a strategic asset
 Service assets for value 4 Main Activities

creation:  Define the market
 Resources – tangible assets
 Develop the offerings
 Capabilities – intangible
assets  Develop strategic assets
 Value to the business is  Prepare for execution

defined by:
 Utility - Fit for Purpose Processes
 Warranty – Fit for Use  Service Portfolio
 Service portfolio and Management
Service lifecycle  Demand Management
 Patterns of business activity  Financial Management
SS
47
Notes:
Foundations Course for ITSM (ITIL v3)
Service Design
 Objectives & scope
 Value of Service Design
 The 4 P’s of Service Design
 5 major aspects of design
 In depth look at Service Level
Management
 Objectives and concepts for
other Service Design processes
course v 3.4

Service Design – Goals

Notes:
A holistic approach to all aspects of the design
Purpose
Satisfy the business needs - design services to satisfy

of new or changed service for introduction into
the live environment business objectives, coordinating all design activities
for IT services to ensure consistency and business
 Design services to satisfy the business objectives
 Design for efficient development / enhancement
focus.
 Design effective service lifecycle processes Cost effective design - design services that can be
 Identify and manage risks
 Define measures for design effectiveness
efficiently developed as well as enhanced, considering
 Produce and maintain plans, policies, architectures, long-term cost of providing the service as well.
frameworks, documents, etc.
 Design for security, resilience, reliability, etc. Relevant process throughout the Service Lifecycle -
 Assist in efforts to develop standards and policies design efficient and effective processes for design,
 Contribute to improvement efforts transition, operation and improvement of high quality
SD IT services along with supporting tools (especially the
Service Portfolio), systems and information, to
manage services through their lifecycle.
Service Design - Value to the Business

Notes:
 Reduced Total cost of ownership (TCO)
 Improved quality and consistency of service An investment in Service Design will pay off in less
 Easier implementation of new/ changed services risk and lower long-term costs of the services. Yet
 Alignment and effective performance of services often this is overlooked in the rush to market.
 Improved governance and decision making
 Effective IT and IT Service Management processes
SD
Service Design Scope

Notes:
 New or changed services (requirements extracted from
the Service Portfolio) The scope of Service Design incorporates the five
 Service Management systems and tools, especially the aspects of design (see page 53).
Service Portfolio, including the Service Catalog
 Technology architecture and management systems
 The processes required
 Measurement methods and metrics
Strategy  Service Level  Continuity Portfolio

 Service Catalog  Supplier
Transition  Availability  Security
 Capacity Service
Operation Catalog
Architecture Measures
Improvement
SD

The 4 P‟s of Service Design

Notes:
 Objectives
 Staffing levels
 Inputs / Outputs
 Skill sets The 4 P‟s represent the four major areas that need to
 Ownership
 Training
 Activities
 Communication
be considered in the design of effective service
 Measurements
People management.
Products/
As processes are designed, it is important that quality
Processes be "baked in". There will never be another opportunity
Technology
to make up for what is omitted in this phase and
 Specialist suppliers
Partners/ certainly quality will never be less expensive to obtain.
 Appropriate & Suppliers  Tools to assist in
documented service generation For new or changed services:
 Technology that
agreements
 Communication increase • supporting processes should be
channels efficiency defined and documented
• they should be streamlined for
SD
effectiveness
• as requirements change, they should
be realigned
• activities must be measurable or
opportunities for improvement are lost
Products (or Technology) designed to be used to
deliver service and information to the right person in
the right place at the right time. The Design phase is
the most effective and economical time to assure
quality.
Partners are a critical element of Service Design.
Specialist suppliers will often be needed to provide
some aspects of a service. These may be available
internally or external providers may have to be
identified.
Whether with internal or external suppliers, there must
be clear agreements and contracts in place to assure
the needed levels of service support. Communication
is an important aspect of maintenance of good
relationships with suppliers so it is important that
channels be clear and used regularly.
(from ITIL text)
5 Key Aspects of Service Design

Notes:
1. Designing Service Solutions -
including all of the functional Good Service Design brings a consistent and holistic
requirements, resources and
capabilities needed and agreed „The main problem approach to the design of new and changed services,
2. Service management system today is that
organizations often assuring integration in 5 key areas.
and tools - especially the Service
Portfolio only focus on the • Designing Service Solutions:
functional
3. Management and technology requirements. A requirements are taken from the
architectures and tools design or
4. Processes needed to design, architecture by
Service Portfolio and a solution is
transition, operate and improve definition needs to designed conforming to constraints
the services consider all design
5. Measurement systems, methods aspects.‟ identified in Service Strategy.
and metrics for the services, the • SM Systems and Tools, esp. the
architectures and their
constituent components and the Service Portfolio: not only must the
processes
new service integrate with existing
SD
services but the tools must be capable
of supporting the new service.

• The Technology Architectures &

Management Systems: must either be
capable of supporting the new service
or changes must be made to the
existing systems or to the new
service.
• Processes: all IT & SM processes
must be capable of supporting the
new service or either the service
change will need to be amended or
the processes revised.
• Measurement Methods & Metrics:
must either exist or be added to
support the new reporting needs or
those needs must be revised.
(from ITIL text)
ASPECT
Designing Service Solutions Approach
Notes:
1
 Create a repeatable process

 Ensure cost, quality and functionality Slide acronyms:
 Iterative and incremental • Reqs – requirements for the service
 Assisted by Project Management
• SDP – Service Design Package
sample approach
• SAC – Service Acceptance Criteria
Pilot Live
• SLR – Service Level Requirements
SAC SAC
• SLA – Service Level Agreement
Design SDP Transition Operation
• SLM – Service Level Management
SLR SLA
SLR = Service Level Requirements

Service Design is constrained by several factors:
SDP = Service Design Package
SAC = Service Acceptance Criteria
SLA = Service Level Agreement
SD
ASPECT
The Service Design Package (SDP)
Notes:
1
 Defines all aspects of IT service throughout lifecycle

 Created for new services, major change, retirement This is a key document which enables all the various
Contents: design activities to be recorded and progressed
 Service requirements through the life of the service. It is initially created for
 Service design each new service and then updated associated with
 Organizational readiness major changes and at the retirement of the service.
assessment
 Service lifecycle plan Service Requirements include:
 Service program, service
transition plan
• Business Requirements
 Service operational • Service Applicability
acceptance plan • Service contacts
 Service acceptance
criteria Service Design includes:
SD • Service Functional Requirements
• Service Level Requirements
• Service and Operational Management
Requirements
• Service Design and Topology
(from ITIL text)

ASPECT
Designing the Service Portfolio and Contents
Notes:
2
 Captures details for all Services go through numerous states through their
Service Portfolio services
 Access to information
lifecycle. The Service Portfolio, which is a subset of
controlled the Service Knowledge Management System (SKMS),
Requirements
Defined Service
contains services in all their phases, but only the
Analyzed
Approved
Pipeline
Service Catalog subset will be accessible to the
Chartered Requirements are recorded
Designed considered and prioritized customer. Once chartered, resources and budget will
Developed forming the Service Pipeline
Built
Service
Catalog
be allocated and the service enters the Service
Test
Released
Services with status between Catalog.
Operational
Retired chartered and operational
Retired Services (different status while The data held in the Service Catalog should answer a
undergoing changes ?)
customer's questions such as why they would buy this
SD
service from you and what are pricing and chargeback
models if applicable.
(ITIL text)
ASPECT
Architectural Relationships
Notes:
3
Business Enterprise Architectural design activities within IT provide overall

Architecture Architecture defined
Delivery by Gartner strategic „blueprints‟ for the development and
Feedback &
Monitoring
„… translating
business vision
deployment of the IT infrastructures. Enterprise
Service
Architecture
Service
Portfolio
and strategy
into effective
architecture should be integrated with the business
Supported enterprise change,
by creating,
architecture and should include architectures for:
by
Application
communicating • Applications
Data and improving key
Architecture Architecture principles and
models that
• Data/information
Using describe the
enterprise‟s future
• IT infrastructure
Infrastructure
Service
states and • Environments
Architecture Knowledge
enable its
evolution.‟
Mgt System Service Architecture translates applications
SD
infrastructure, organization and support activities into a
set of services.
Application Architecture provides a blueprint for
development and deployment of individual
applications, maps business and functional
requirements onto applications and shows
interrelationships between applications.
Data / Information Architecture describes the logical
and physical data assets of the enterprise and the
data management resources.
IT Infrastructure Architecture describes the structure,
functionality and geographic distribution of the
hardware, software and common components
supporting overall architecture.
(from ITIL text)

ASPECT
Technology Architecture
Notes:
3
 Technology needed to provide the service (e.g.

invoicing service) In addition to technology needed to provide the
 Technology to support the service (e.g. end-to-end services, IT must now also consider technology to
transaction timing monitors)
support the service using technical solutions to assist
Business Requirements
their processes. Tools should provide cost effective
Design top down
solutions and benefits to the business as well as to IT
Implement bottom up
People, Roles & Activities
services.
Processes & Procedures
Management Tools
Technology
Integrated end-to-end
SD
ASPECT
Process Design
Notes:
4
Process Models A process is a structured set of activities designed to

 Improve understanding accomplish a specific objective. Processes should be
 Articulate key features defined, documented and controlled so that they can
Process Controls be repeated and become manageable. (ITIL text)
 Defined and
documented
 Enables consistent
approach
 Allows measurement
 Proves effectiveness and
efficiency
SD
ASPECT
Measurement Systems, Methods and Metrics
Notes:
5
„If you cannot measure it, how can you manage it?‟ Degrees of control over processes can be defined and
then process measurement and metrics can be built in
Measurement should: to the process to control and improve the process.
 Encourage that business
objectives are met
Perspectives:*
Metrics are powerful tools. They will change the way
 Assist in behavioural people behave and can have tremendous influence
change  Customer
Measure for:  Business over how things are done. But like any powerful tool,
 Innovative you must know how to use it or that power may be
 Knowing what is
 Financial
happening used destructively.
 Identification of * From the Balanced Scorecard
excellence Before deciding what to measure, consider how the

 Need for improvement measurement can encourage business objectives
SD being met and assist behavioral change in the desired
direction.
Measurement should be used to assist understanding
and to identify excellence as well as areas for
improvement.
Measurement Systems and Metrics Design should
include measures for:
• Progress – milestones achieved
• Compliance – process conformance
• Effectiveness – results against
objectives
• Efficiency – process productivity and

resource utilization
(from ITIL text)
ASPECT
Measurement Design Criteria
Notes:
5
Metric: Something measured and reported on to

help manage a process, service, activity, etc.
Fit for purpose - these will be metrics to the customer
showing whether SLA's were met which are quite
Guidelines:
different than metrics to be used for process tuning.
 Fit for purpose Business
 Not over or under Not over or under engineered & right the first time - it
engineered
 Require minimal re- IT
is much easier and cheaper to design right than to
engineering correct later
 Effective and efficient
Overall
solutions
Service
Process Align to current level of capability - as the organization
 Align to current level of matures, it may move from simple metrics to higher
capability
Specific
 Stick to key performance Metrics
Component levels of sophistication
indicators (KPIs)
KPI - specific metric type that shows how well a
SD
service or process is performing; a "report card"

Metrics can be consolidated in the areas where
information is required leading to good decisions
based on sound information. Ultimately, business
decisions will be made based on metrics derived from
data at lower levels. It is important that those metrics
be accurate and reliable, without gaps or
inconsistencies.
Management will not have time or even necessarily
understand minute low-level data but should be
provided with a top-level dashboard view summarizing
information of value to them.
Service Design Processes

Notes:
 Service Level Management
 Service Catalog
Management
 Capacity Management
 Availability Management
 IT Service Continuity
Management
 Information Security
Management
 Supplier Management
SD

Service Level Management - Objectives

Notes:
“Service Level Management negotiates, agrees and
documents appropriate IT service targets with
representatives of the business, and then monitors and
produces reports on the service provider’s ability to
deliver the agreed level of service.”
 Define, document, agree, monitor, measure, report and

review the level of IT service provision
 Provide and improve relationships with the business and
customers
 Monitor and improve levels of customer satisfaction
 Develop specific and measurable targets
 Define levels of service clearly and unambiguously
 Proactively improve service levels where cost justifiable
SD
Service Level Management - Scope

Notes:
 Provide key interface between the business and IT
service provider Analysis of the cost and impact of service breaches
 Negotiate and agree on Service Level Agreements for provides valuable input and justification of SIP
current services in conjunction with Operational Level
Agreements and Contracts activities and actions. The constant need for
 Capture Service Level Requirements for future business improvement needs to be balanced and focused on
needs and changes
those areas most likely to give the greatest business
 Investigate and eradicate poor service
 Create and manage Service Improvement Plans
benefit. Reports should also be produced on the
progress and success of the SIP, such as the number
of SIP actions that were completed and the number of
actions that delivered their expected benefit. (from ITIL
text)
SD
Service Level Management – Key Documents

Notes:
Service Level A written agreement between the
Agreement customers and the IT service provider A rule of thumb for SLAs - "If something cannot be
(SLA) that quantitatively details the IT service, measured, it should not be documented.“
documents service level targets, and
specifies the responsibilities of the IT Wording of an SLA should be clear and concise, with
service provider and the customer
any ambiguous terms defined, so that all parties will
Operational Underpinning agreement between an IT understand it. It will generally be written in business
Level service provider and another part of the
Agreement same organization that assists with
language, while OLA's may use technical language
(OLA) provision of services and Contracts may contain legal terminology.
Underpinning Legally binding agreement between an
The customer's relationship with IT is defined through
Contract (UC) IT service provider and a third party the SLA or Service Level Agreement. The customer's
(supplier)
interest is in the overall level of service it receives from
SD IT at the service level vs. the component level. A
customer's SLA should focus on whether a service
was available and of sufficient quality.
However, IT services rely upon many suppliers and
providers and it is important to have underpinning
agreements to assure service can be delivered. These
agreements may be at more of a component level. If
the agreement is with another provider within the
same organization it is referred to as an OLA or
Operational Level Agreement. If it is with an external,
3rd party supplier, it is called a UC or Underpinning
Agreement

The Service Level Management process will work with

the Supplier Management process with respect to the
creation of Underpinning Contracts.
(from ITIL text)
Service Level Management - Structure

Notes:
Customer Customer Customer Customer
Service Level Agreement
Service A Service B Service C
IT Infrastructure
Operational Level Agreements Underpinning Contracts
Internal Organization External Organization
SD
Service Level Management Process

Notes:
Customer Service
SLRs Standards &

SLAs Reports
Templates
Determine, Assist with

Monitor Review &
Document Service
& Report Improve
& Agree Catalog
Service
Develop Improve
Review SLAs, Catalog
Contacts & Customer
OLAs & UCs
Relationship Satisfaction
UCs Supplier
Support OLAs
Team
SD
Service Level Management - Activities

Notes:
 Determine SLA structure
 Customer-based SLM structure options include the following.
 Service-based • Service-based SLA - This is where an
 Multi-level SLA covers one service, for all the
 Produce Service Level Requirements (SLRs)
customers of that service – for
 Manage customer relationships & satisfaction
example, an SLA may be established
 Provide service reporting – including SLAM charts
for an organization‟s e-mail service –
 Conduct Service Reviews
 Initiate improvements (via Service Improvement Plans)
covering all the customers of that
 Conduct annual SLA reviews (including revisiting OLAs
service.
and contracts) • Customer-based SLA - This is an
agreement with an individual
customer group, covering all the
SD
services they use.
• Multi-level SLAs - Some organizations
have chosen to adopt a multi-level

SLA structure. For example, a three-
layer structure as follows:
• Corporate level: covering all
the generic SLM
• Customer level: covering all
SLM issues relevant to the
particular customer group or
business unit
• Service Level: covering all
SLM issues relevant to the
specific service, in relation to
a specific customer group
(one for each service covered
by the SLA)
It can be difficult to draw out requirements to be
included in the SLR, as the business may not know
what they want and they may need help in
understanding and defining their needs, particularly in
terms of capacity, security, availability and IT service
continuity. The requirements initially expressed may
not be those ultimately agreed. Several iterations of
negotiations may be required before an affordable
balance is struck between what is sought and what is
achievable and affordable.
SLA Monitoring (SLAM) charts at the front of a service
report to give an „at-a-glance‟ overview of how
achievements have measured up against targets.
These are most effective if color coded (Red, Amber,
Green, and sometimes referred to as RAG charts as a
result).
(from ITIL text)
Service Level Management - KPIs

Notes:
„Key Performance Indicators (KPIs) and metrics … should be
developed from the service, customer and business perspective
and should cover both subjective and objective measurements.‟
KPIs should cover:

 Success of SLM
 How many services have
agreements
 Time to create agreements
 % of review meetings held on
scheduled date
 Success of services delivered
 % reduction in SLA breaches
 Breaches caused by OLA issues
 Breaches caused by contract issues
SD

Service Level Management - Key Challenges

Notes:
 Identifying the correct Key challenges of SLM implementation include:
customer • Identifying the correct customer: the
 No prior experience of customer must have authority to make
Service Level Management
 Drafting SLAs agreements for services
 Gathering initial baseline • Lack of prior experience: when first
information
 Ensuring agreement is
implementing, a customer should be
signed chosen based on relationship and
 Gaining Service Desk and opportunity, who will be willing to work
support groups „buy in‟
with a draft SLA while baseline
 Advertising SLAs
metrics are acquired and experience
is gained
SD
• Before go live, the agreement must be
signed
• The Service Desk represents a great
opportunity to build support and even
enthusiasm for the process, but if the
Service Desk does not promote and
use SLA's, they have little likelihood of
success
• Be sure SLA's are well communicated
to both users and IT support staff and
that the Service Desk particularly is
well-trained on expectations of them
Service Level Management - Interfaces

Notes:
Service Level Management is a source of valuable
information to all processes, providing the Service Level
Requirements by which success may ultimately be measured
as well as Service Improvement Plans identified in reviews. In
return, SLM needs input from the processes regarding the
ability and cost to perform to these requirements.
Strong interfaces exist with:

Service Portfolio Management & Service Catalog Management
 providing SLM with details of current and planned services
 receiving information on changing customer needs or plans
Change Management
 provides a vehicle for all changes
 receiving information regarding upcoming business changes
Configuration Management
 providing SLM with a complete view of services offered

Service Level Management - Interfaces

Notes:
Strong interfaces exist with (cont.):
Availability Management & Capacity Management
 Availability Management in particular, along with Incident
Management, are key focus areas for SLAs and as such have
very strong ties to SLM
Incident Management & Problem Management

 provide SLM with information on the performance of the
processes themselves
 provide SLM with information to identify weaknesses in
performance of the services
 receive information on business requirements in order to better
prioritize and evaluate performance
Service Catalog Management - Objectives

Notes:
Manage the information contained within the
Purpose
Service Catalog, and to ensure that it is accurate

and reflects the current details, status, interfaces and
dependencies of all services that are being run, or
being prepared to run, in the live environment.
 Define the service within the Service Catalog

 Produce and maintain the Service Catalog
 Ensure interfaces, dependencies and consistency
between
 the Service Catalog and the Service Portfolio
 all services and supporting services
 all services, and supporting components and items
SD
Service Catalog Management - Basic Concepts

Notes:
services delivered to the
The Service Catalog can contain more than one view.
customer, including The business may not require a view into the technical
Business Business Business
Process Process Process
relationships to the
business units and the details that support the service and the technicians
business process
Business Service Catalog may not necessarily require a view into the business
Service A Service B
information.
Technical Service Catalog

Services are entered into the catalog once they at
services delivered to the chartered status.
customer, including
SW HW App Data relationships to the
supporting services, Each Service should be held as a Configuration Item
shared services,
components and items
to ensure the effective recording of incidents,
problems, RFCs, etc. against services.
SD
The Service Catalog is subject to Change

Management.
(from ITIL text)

Capacity Management - Objectives

Notes:
 Create the Capacity Plan
 Provide advice and guidance to
IT and the business regarding
performance and capacity
issues
 Ensure performance meets or
exceeds targets
 Assist Incident and Problem
Management on capacity
related issues
 Assist in Change Management
assessment of impact on
capacity and performance
 Proactively look for cost effective
solutions to enhance
performance
SD
Capacity Management - Basic Concepts

 Business Capacity
Notes:
Management (BCM)
 Aligning IT to business plans
The Service Design process of Capacity Management
Review Reports
and strategy focuses on assuring sufficient capacity is available to
Current
 Modeling
BCM
 Service Capacity keep services running at agreed levels.
Improve
Management (SCM)
 Ensuring capacity underpins Capacity Management is divided into 3 sub-processes,
service CMIS*
 Managing demand
SCM
Agree &
Document
each with a different focus:
 Tuning • Business Capacity Management -
 Component Capacity Plan focused on current and future
Management (CCM) CCM Plan
 Understanding technical business requirements
components Tools
 Analyzing future technologies
Forecast • Service Capacity Management -
 Tuning
*Capacity Management Information System
focused on delivery of existing
SD
services that support the business
• Component Capacity Management -
focused on the performance of the
individual components comprising the
service. Overlaps in some areas with
Service Capacity Management, but
with a different emphasis.
Data from Capacity Management is stored in the
Capacity Management Information System (CMIS)
(from ITIL text)
Capacity Management - Activities

Notes:
Tuning The iterative activities of Capacity Management are
1
monitor, analyze, tune and implement. Components
Implementation Analysis and services should be monitored with the data
analyzed and reported on, resulting in improvements
Monitoring
as identified and implemented as appropriate. The
improvements continue to be monitored. (ITIL text)
Resource
Resource SLM
Utilization
SLM CMIS Exceptions
Utilization
Thresholds Exceptions
Thresholds
Changes to capacity are changes, and thus are

1
implemented through Change Management
SD

Availability Management - Objectives

Notes:
 Create and maintain the “The main objective of Availability Management is to
Availability Plan
 Provide advice and
ensure that service availability matches or exceeds the
guidance for service agreed needs of the business”
design, transition, operation
and improvement The distinct objectives of Availability Management are
 Assist with availability
related incidents and
designed to achieve the main objective stated above.
problems
 Assess the impact of
changes
 Produce cost effective
proactive measures
 Measure and monitor
SD
Availability Management – Concepts

Notes:
Availability = the ability of an IT Service, component
or configuration item to perform its Service availability is sometimes referred to as „end to
required function when required end‟ availability, i.e. the end to end provision of service
Managing Availability means …. aligned to Service Level Agreements. This is the
 Intentionally defining „availability‟ based on business availability which the customer is directly concerned
value and requirements with.
 Looking at all aspects of „availability‟
 Monitoring „availability‟ Component Availability is the IT side. Capability of
 Driving capability and improvement into „availability‟ single infrastructure components to support the
Service Availability
required agreed levels.
Availability
Component Availability
SD
Availability Management – Terms

Notes:
Reliability How long a service or component
Actual Down Time (ADT) does not include planned
performs without interruption
Fault Tolerance The ability of a service to mask

downtime (i.e. pre-determined and agreed to outages
(component) failure for maintenance periods, etc.)
Maintainability How quickly a component can be
restored to an operational state
Serviceability Ability of a third-party to meet their

contract terms
Calculating Availability
Agreed Service Time (AST) Actual Down Time (DT)

x 100
Agreed Service Time (AST)
SD

Availability Management Process

Notes:
Reactive Activities AMIS*
Monitor,
Measure, Analyze
Analyze, Failures & Reports
Report, Remediation
Review
Availability
Plan
Manage Plan &

Risk Design Design
Criteria
Implement Testing
Review &
Counter- Schedule
Measures Test
Proactive Activities *Availability Management

Information System
SD
The Expanded Incident Lifecycle

Notes:
MTBSI In order to meet its objective of optimal Availability, the
MTBF
Availability Management process focuses on
MTRS
maximizing uptime, known as MTBF and minimizing
downtime, known as MTRS. The total cycle is called
detect diagnose repair recover time between system incidents and is measured from
incident restore incident start to the next incident start.
In order to improve the MTRS, Availability
MTRS Mean time to restore service („downtime‟) Management considers the Availability Incident
MTBF Mean time between failures („uptime‟) Lifecycle from an extended viewpoint. The incident
MTBSI Mean time between system incidents lifecycle is broken up into 5 parts: Detect, Diagnose,
SD
Repair, Recover and Restore. Improvement in any of
these phases will result in shortening MTRS or
downtime.
(from ITIL text)
IT Service Continuity Management - Objectives

Notes:
 Maintain IT service continuity ITSCM provides an invaluable role in supporting the
and recovery plans that Business Continuity Planning process. In many
support overall Business
Continuity Plans (BCPs) organizations, ITSCM is used to raise awareness of
 Conduct Business Impact continuity and recovery requirements and is often
Analysis (BIA) used to justify and implement a Business Continuity
 Conduct Risk Assessments
Planning process and Business Continuity Plans.
 Provide advice and guidance
on recovery issues ITSCM should be driven by business risk as identified
 Support the business with by Business Continuity Planning, and ensures that the
appropriate recovery
mechanisms
recovery arrangements for IT services are aligned to
identified business impacts, risks and needs.
SD
The first real ITSCM task is to produce an ITSCM
strategy that underpins the BCM strategy and its
needs.
The Business Continuity Strategy should principally
focus on business processes and associated issues
(e.g. business process continuity, staff continuity,
buildings continuity). Once the Business Continuity
Strategy has been produced, and the role that IT
services has to provide within the strategy has been
determined, an ITSCM strategy can be produced that

supports and enables the Business Continuity
Strategy.
(from ITIL text)
IT Service Continuity Management - Concepts

Notes:
Business IT Service Continuity Management, or ITSCM, is a
Continuity Policy setting
Management Initiation* Scope Service Design process focusing on disaster recovery.
Initiate a project
IT Service Continuity must be based on the Business
Strategy
Requirements
Business Impact Analysis
Risk Assessment
Continuity Plan for understanding of which services
& Strategy* IT Service Continuity Strategy
must be restored in given timescales.
Develop IT Service Continuity Plans
Develop IT plans, recovery plans The Business Continuity Strategy and Plans will form
Plans Implementation* and procedures
Organization planning
Testing strategy
the basis for ITSCM requirements and strategy and
Education, awareness and training
implementation.
On Going Review and audit
Invocation*
Operation* Testing
Change Management
Invocation in the event of a crisis must be based upon
* = Stages of the ITSCM lifecycle authorized roles and defined requirements.
SD
Any IT Service Continuity Plan must include plans for

return to ongoing operations after invocation.
(from ITIL text)
Information Security Management - Objectives

Notes:
 Align with business security objectives and processes
 Protect information, including
 Business transactions
 Exchanges of information between organizations
 Ensure confidentiality, integrity and availability
Framework for Managing Information Security
Maintain Plan
I
Control
Evaluate Implement
SD

Information Security Management - Concepts

Notes:
Security The Information Security Policy should be widely
 Information Security Policy
Policy Enforce available to all customers and users, and their
Risk &
 Strategy Vulnerability
compliance should be referred to in all SLRs, SLAs,
 Organizational Monitor contracts and agreements.
structure & Manage Report
 Security controls The Information Security Policy should have the full
Report &
 Management of risks Review
Control & support of top executive IT management and ideally
Mitigate
 Process management
the support and commitment of top executive business
 Communications
 Training and
management. The policy should cover all areas of
Security Management
awareness Information System (SMIS)
security, be appropriate, meet the needs of the
business and should include:
SD
 An overall Information Security Policy
 Use and misuse of IT assets policy
 An access control policy
 A password control policy
 An e-mail policy
 An internet policy
 An anti-virus policy
 An information classification policy
 A document classification policy
 A remote access policy
 A policy with regard to supplier access of IT
service, information and components
 An asset disposal policy
(from ITIL text)
Supplier Management - Objectives

Notes:
 Manage supplier relationships and performance
 Negotiate and monitor contract performance The process should be set up to facilitate the
 Create Supplier Policy monitoring and control of the suppliers as well as
 Create and maintain Supplier and Contract Database formal processes for engaging new supplier
(SCD)
organizations. There should be guidelines set up and
Contracts adhered to for contractor negotiations so that the
Manager
Purchasing
Supplier Mgt
Process Owner
process can be as transparent as possible.
Legal NOTE: There is an overlap between Service Level
Supplier Supplier
Manager Manager Management and Supplier Management with respect
to the negotiation of contracts with suppliers.
Supplier
Supplier Supplier
(from ITIL text)
SD

Supplier Management - Basic Concepts

Notes:
Supplier Strategy
& Policy
All Supplier Management process activity should be
driven by a supplier strategy and policy from Service
Strategy. In order to achieve consistency and
Evaluate
effectiveness in the implementation of the policy a
Categorize &
Supplier and Contracts Database (SCD) should be
Establish
Maintain
Supplier & established, together with clearly defined roles and
Contract
Database responsibilities.
Manage
Basic activities of Supplier Management include:
Renew / • Evaluation of new suppliers and
Terminate
contracts
SD
• Establish new suppliers and contracts
• Supplier and contract management
and performance evaluation
• Contract renewals and terminations
• Supplier categorization and
maintenance of the Supplier and
Contract DB
(from ITIL text)
Summary of Service Design Processes

Notes:
New
Requirements
Strategy SDP
Analyze Design Evaluate Prepare Develop

Requirements Solution Solution Solution Solution
Architectures Service
Measurement
Portfolio
Methods Design
Catalog SLM CAP AVAIL ITSCM SEC SUPP
SD
Service Design - Review

Notes:
A holistic approach to all
 Goals
Purpose
aspects of the design of new or

changed service for  Value to the Business
introduction into the live  4 P‟s of Service Design
environment  Design aspects
 The Service Design
Package
Processes
 Service Catalog Management
The 5 Aspects
 Service Level Management
 Capacity Management  Service solutions
 Availability Management  ITSM systems and tools
 Technology architecture
 Service Continuity Management
& management systems
 Information Security Management  Processes (ITSM)
 Supplier Management  Metrics and methods
SD

Notes:
Service Transition
 Key terminology and concepts
 Service Asset and Configuration
Management (SACM) in depth
 Change Management in depth
 Objectives and basic concepts for
 Release and Deployment
Management
 Highlight other processes
Service Transition
Notes:
Purpose
Provide guidance on the Service Transition provides guidance on
development and
improvement of capabilities • Moving new and changed services
for transitioning new and
changed services into into production
operations
• Testing
Scope • The transfer of services to or from an
Management and co- external service provider
ordination of the processes,
systems and functions to
package, build, test and
• Retirement of services
deploy a release into
production, and establish (from ITIL text)
the service specified in the
customer and stakeholder
requirements
ST
Scope of Service Transition

Notes:
Change Management
Service Asset and Configuration Management

There may be situations when some activities do not
apply to a particular transition. For example the
Transition Planning & Support
transfer of a set of services from one organization to
Service or Change Evaluation
another may not involve release planning, build, test
Service
Strategy
Service
Design
Plan and
prepare
release
Build and
Test
Service
Testing and
Pilots
Plan and
Prepare for
Deployment
Transfer
Deploy
Retire
Review &
Close
Service
Operation and acceptance. The following lifecycle processes in
Release and Deployment Management this publication support all lifecycle stages:
Service Validation and Testing • Change Management
Knowledge Management
• Service Asset and Configuration
ITIL process that supports whole service lifecycle
Management
Focus of activity related to service transition • Knowledge Management
ITIL process in other core publication
ST
Service Transition uses all the processes described in
the other ITIL publications as it is responsible for
testing these processes, either as part of a new or
changed service or as part of testing changes to the
Service Management processes. Service level
management is important to ensure that customer
expectations are managed during Service Transition.
Incident and problem management are important for
handling incidents and problems during testing, pilot
and deployment activities.
The following activities are excluded from the scope of
Service Transition best practices:

• Minor modifications to the production

services and environment, e.g.
replacement of a failed PC or printer,
installation of standard software on a
PC or server, or a new user
• Ongoing Continual Service
Improvements that do not significantly
impact the services or service
provider‟s capability to deliver the
services, e.g. request fulfillment
activities driven from Service
Operations.
(from ITIL text)
Service Transition Goals and Objectives

Notes:
Goals
 Set customer expectations
More details regarding goals:
 Enable integration • Set customer expectations on how the
 Reduce performance variation performance and use of the new or
 Reduce known errors and
minimize risk changed service can be used to
 Ensure proper use of services enable business change
Objectives • Enable the business change project or
 Provide clear and customer to integrate a release into
comprehensive plans
 Plan and manage the resources
their business processes and services
 Increase satisfaction • Reduce variations in the predicted
 Increase use of services and actual performance of the
transitioned services
ST
• Reduce the known errors and
minimize the risks from transitioning
the new or changed services into
production
• Ensure that the service can be used in
accordance with the requirements and
constraints specified within the service
requirements.
(from ITIL text)
Service Transition Value to the Business

Notes:
Enables the service provider to:
 Handle high volumes of change and releases across its Additional points of value:
customer base • Competitive edge – Ability to adapt
 Align the new or changed service with the customer‟s
business requirements and business operations quickly to new requirements and
 Ensure that customers and users can use the new or market developments
changed service in a way that maximizes value to the • Management of mergers, de-mergers,
business operations
acquisitions, transfer of services
• Success rate of changes and releases
for the business
• Predictions of service levels and
warranties for new / changed services
• Confidence in the degree of
ST
compliance with business and
governance requirements during

change
• Variation of actual against estimated
and approved resource plans and
budgets
• Productivity of business and customer
staff because of better planning and
use of new and changed services
• Timely cancellation or changes to
maintenance contracts for hardware
and software when components are
disposed or de-commissioned
• Understanding of the level of risk
during and after change, e.g. service
outage, disruption and re-work
(from ITIL text)
Service Transition Processes & Roles

Notes:
Process Owner
 Transition Planning and
responsible for ensuring that
Support all activities defined within
 Change Management the process are undertaken
 Service Asset and
Configuration Service Owner
Management
responsible to the customer
 Release and Deployment for the initiation, transition
Management and ongoing maintenance
and support of a particular
 Service Validation and service
Testing
 Evaluation
 Knowledge Management “These owner roles are not
necessarily a person dedicated
for each process or service.”
ST
Service Asset & Configuration Mgt Objectives

Notes:
define and control the components of services and
Purpose
infrastructure and maintain accurate configuration The purpose of SACM is to:

information on the historical, planned and current • Protect the integrity of service assets
state of the services and infrastructure
and configuration items (CI)
Configuration Management enables • Place IT assets and designated CIs
 Compliance with corporate under configuration management
governance
• Ensure the integrity of assets and
 Control of asset base
 Cost optimization
configurations by maintaining a
 Effective change and release complete Configuration Management
management System (CMS)
 Faster incident and problem
resolution
• Support processes through accurate
information
ST
• Provide a logical model of the IT
infrastructure correlating IT services
and IT components (physical, logical,
etc) needed to deliver these services
(from ITIL text)

Key Concepts for SACM

Notes:
 Service Asset &
Configuration Mgt Policies The CMS holds all the information for CIs within the
 Configuration Model designated scope. Some of these items will have
 Configuration Items (CIs) related specifications or files that contain the contents
 Attributes of the item, e.g. software, document or photograph.
 Configuration Management
System (CMS)
The CMS maintains the relationships between all
 Configuration Management
service components and any related incidents,
Database (CMDB) problems, known errors, change and release
 Definitive Media Library documentation and may also contain corporate data
(DML)
about employees, suppliers, locations and business
 Configuration Baselines
units, customers and users.
 Snapshot
ST At the data level, the CMS may take data from several
physical CMDBs, which together constitute a
federated CMDB. Other data sources will also plug
into the CMS such as the definitive media libraries.
The CMS will provide access to data in asset
inventories wherever possible rather than duplicating
data.
A configuration baseline is the configuration of a
service, product or infrastructure that has been
formally reviewed and agreed on, that thereafter
serves as the basis for further activities and that can
be changed only through formal change procedures. It
captures the structure, contents and details of a
configuration and represents a set of configuration
items that are related to each other.
(from ITIL text)
Configuration Items
Notes:
A Configuration Item (CI) is an asset, service
component or other item which is, or will be, under the Organization CIs include strategy and internal policies
control of configuration management.
Internal CIs include tangible and intangible assets
Configuration Item categories:
such as software for individual projects
 Service lifecycle CIs - plans, business case, SDP External CIs include external customer agreements,
 Service CIs releases for suppliers or sub-contractors
 Service capability assets - people, knowledge
 Service resource assets - systems, data, facilities, capital
 Organization CIs – business strategies and policies
 Internal CIs
 External CIs
 Interface CIs – required to deliver end-to-end service
across a service provider interface
ST

Configuration Model
Notes:
Banking Understanding the relationships between the
Core Service
Serviced by
components will enable other processes to access
Supported
Application Hosting Service valuable information that will enable:
E-banking
Support Service
by
Application
Hosted
Messaging
Data
services
• Assessing the impact of proposed
Web changes
services
Availability • Assessing the impact and cause of
Uses
incidents and problems
Technical Infrastructure Service
User
experience
Business
logic Network
• Planning and designing new or
Authentication
topology
changed services
Network
service • Planning technology refreshes and
software upgrades
ST
• Planning release packages and

migrating services
• Optimizing utilization of assets
(from ITIL text)
SACM - Activity Model

Notes:
Management Configuration identification covers all aspects of
and planning
naming and labelling assets, defining classes and
Configuration types of assets and how they are to be grouped and
Management System
identification
classified, together within ownership of the CI at
Configuration
Configuration different stages of the Lifecycle.

control
Configuration control ensures that there are adequate
Status control mechanisms so that information is kept
reporting
accurate and up-to-date. It is particularly important to
Verification ensure that the logical and physical information
and audit
matches.
ST Each CI can posses a number of different states
through which in can pass. The status links to the use
that can be made of the item at that point in time.
Verification and audit ensures that regular reviews are
performed to ensure conformity between the
documented baselines and the actual environment.
(from ITIL text)

Platform for Release & Deployment

Notes:
Definitive Media Library and CMDB
 CIs are stored The Definitive Media Library (DML) is the secure
DML in the DML library in which the definitive authorized versions of all
Physical
 Information
CIs
about CIs is in
media CIs are stored and protected. The Definitive
Electronic
CIs the CMDB Media Library (DML) stores the definitive, approved
versions of all software CIs along with associated
Test licenses and documentation. The DML, therefore,
CMDB Build
stores:
Release
Record
DML
• Master copies of all controlled
Prod
software in an organization, including
Software Distribution
Prod
Prod • master copies of versions that
have passed quality
ST
assurance checks
• definitive copies of purchased
software (along with licence
documents or information), as
well as software developed on
site.
• master copies of controlled
documentation for a system (in
electronic form)
NOTE: Business application data would not be stored
in the Definitive Media Library.
The exact configuration of the DML is defined during
the planning activities.
Definitive versions of electronic media, including
software, are captured in a Definitive Media Library
prior to release into the service operations readiness
test environment.
Only software from the DML is authorized for use in a
release. Software in the DML is under Change and
Release & Deployment Management and information
about it is recorded in the CMS.
This library may in reality consist of one or more
software libraries or file-storage areas, separate from
development, test or live file-store areas.
(from ITIL text)

Configuration Baseline
Notes:
A configuration baseline is the configuration of a
service, product or infrastructure that has been
formally reviewed and agreed on.
Configuration Baseline
 Serves as the basis for further activities
 Build a service component from a defined set of inputs
 Change or rebuild a specific version
 Assemble all relevant components for a release
 Basis for audit and back out
 Can be changed only through formal change procedures
Snapshot
 Documents a state, which may contain faults and is not
necessarily agreed on
 May be used for comparison to a baseline
ST
Service Asset and Configuration Mgt - Interfaces

Notes:
Service Asset and Configuration Management gives insight
to all processes regarding assets and their relationships.

Financial Management
 SACM provides financial information critical to determine cost of
services and cost allocation
Availability Management
 SACM assists in detection of points of failure
Change Management
 SACM provides information needed to assess impact of changes
IT Service Continuity Management
 SACM provides information on assets supporting services, allowing
ITSCM to plan for continuity and to assess the state to restore to
Incident Management and Problem Management
 Provides and maintains key diagnostic information as well as
providing data to the Service Desk
Change Management – Scope & Objective

Notes:
To ensure that changes are recorded, evaluated,
Purpose
authorized, prioritized, planned, tested, Some changes may be defined to lie outside the
implemented, documented and reviewed in a scope of Change Management. These may be wider
controlled manner
organizational and/or business changes, that would
Service Change
Sources of Change give rise to RFCs that relate to services. Or they may
The addition,  Legal/regulatory
modification or include operational changes, such as printer repairs,
 Organizational policy and
removal of any may be deemed outside the scope. (from ITIL text)
standards
authorized,
 Business, customer and user
planned or
activity analysis
supported service
or service  New service
component and its  Updates to existing portfolio
associated  Sourcing model
documentation  Technology innovation
ST

Change Management Concepts

Notes:
The Truths of Change
Change is an everyday part of life.
The only constant in life is change!
Change = Risk
Changes should be managed to:

 Optimize risk exposure (supporting the risk profile
required by the business)
 Minimize the severity of any impact and disruption
 Be successful at the first attempt
ST
Change Types
Notes:
Normal Change
 Requires full assessment and authorization Once the approach to manage standard changes has
Standard Change
been agreed, standard change processes and
 A change for which the approach is pre-authorized and
associated change workflows should be developed
has an accepted and established procedure to provide and communicated. A change model would normally
a specific change requirement
be associated with each standard change to ensure
 Approval granted by the delegated authority
consistency of approach.
Emergency Change
 Changes intended to repair an error in an IT service that is All changes, including standard changes, will have
negatively impacting the business to a high degree details of the change recorded.
 May have different authorization and may be
documented retrospectively Emergency change is reserved for changes intended
 Should be kept to an absolute minimum to repair an error in an IT service that is negatively
ST impacting the business to a high degree. Changes
intended to introduce immediately required business
improvements are handled as normal changes,
assessed as having the highest urgency.
(from ITIL text)
Normal Change Process

Notes:
RFC Record &
Review RFC When conducting the impact and resource
Assess and Evaluate
assessment for RFCs referred to them, Change
Change Management, CAB, ECAB or any others who are
Management System
involved in this process should consider relevant

Configuration
Authorize Change
items, including:
Plan Updates
• the impact that the change will make
* Includes Build
& Test
on the customer‟s business operation
Coordinate
Implementation *
• the effect on the infrastructure and
customer service, as defined in the
Evaluation Review and close
Report change record
service requirements baselines,
service model, SLA, and on the
ST
capacity and performance, reliability

and resilience, contingency plans, and
security
• the impact on other services that run
on the same infrastructure (or on
projects)
• the impact on non-IT infrastructures

within the organization – for example,

security, office services, transport,
customer help desks
• the effect of not implementing the
change
• the IT, business and other resources
required to implement the change,
covering the likely costs, the number
and availability of people required, the
elapsed time, and any new
infrastructure elements required
• the current change schedule (CS) and
projected service outage (PSO)
• additional ongoing resources required
if the change is implemented
• impact on the continuity plan, capacity
plan, security plan, regression test
scripts and data and test environment,
Service Operations practices.
(from ITIL text)
Standard Changes
Notes:
Elements
 Defined trigger
 Tasks are well-known, Create RFC
documented and
proven requested
 Authority is effectively
given in advance Assign for Work
 Budgetary approval
pre-ordained or within implemented
control of requestor
Review and close
 Risk – usually low; change record
always well
understood closed
ST
Emergency Changes
Notes:
 Response to errors causing
significant negative Defined authorization levels will exist for an
business impact
 Goal: as few emergency
emergency change, and the levels of delegated
changes as possible authority must be clearly documented and understood.
 Differences in approach: In an emergency situation it may not be possible to
 Authorization must be
clearly defined and convene a full CAB meeting. Where CAB approval is
documented (ECAB
advises) required, this will be provided by the Emergency CAB
 Build, test and implement (ECAB).
path is accelerated (full
testing may be foregone
as necessary) Not all emergency changes will require the ECAB
 Some documentation may involvement; many may be predictable both in
be completed after the
change is implemented occurrence and resolution and well understood
ST
changes available, with authority delegated, e.g. to
Operations teams who will action, document and
report on the emergency change.
It may not be possible to update all Change
Management records at the time that urgent actions

are being completed (e.g. during overnight or weekend

working). It is, however, essential that temporary
records are made during such periods, and that all
records are completed retrospectively, at the earliest
possible opportunity.
(from ITIL text)
The 7 “Rs” of Change Management

Notes:
 Who raised the change? (requested it)
 What is the reason for it?
The questions posed by the 7 R‟s of Change must be
 What is return required?
answered for all changes. Without this information, the
 What are the risks involved? impact assessment cannot be completed, and the
 What resources are required to deliver it? balance of risk and benefit to the live service will not
 Who is responsible for build, test and be understood. This could result in the change not
implementation?
delivering all the possible or expected business
 What is the relationship with other
changes? benefits or even of it having a detrimental, unexpected
effect on the live service.
 Must be answered for all changes
 Balance risk and benefit to live service (from ITIL text)
 Help assure delivery of expected business benefits
 Reduce risk of detrimental effects on live service
ST
Remediation Planning
Notes:
 All changes should include
a Remediation Plan,
considered and tested
prior to implementing the
change
 Back-out plan to restore to
previous, baselined state if
possible
 Where back-out is not an
option, may entail:
 More change
 Invoke continuity plan in
extreme situations
ST
Change Advisory Board (CAB)

Notes:
A body that exists to support the authorization As and when a CAB is convened, members should be
CAB
of changes and to assist Change Management

in the assessment and prioritization of changes chosen who are capable of ensuring that all changes
within the scope of the CAB are adequately assessed
 Change Manager
from both a business and a technical viewpoint. The
 Customers ECAB
 User managers / reps
CAB may be asked to consider and recommend the
 A smaller adoption or rejection of changes appropriate for higher
 Service operations organization
 Application development with authority to level authorization and then recommendations will be
make
 IT technical staff emergency submitted to the appropriate change authority. To
decisions
 Process managers (e.g. Problem)  Meets as achieve this, the CAB needs to include people with a
 Office services staff needed
clear understanding across the whole range of
 Contractors or 3rd parties
stakeholder needs. (from ITIL text)
ST

Change Management Roles

Notes:
Change Authority
 May be a role, person or a group of people
 The culture of the organization dictates, to a large extent,
the manner in which changes are authorized
Change Manager
 Receives, logs and allocates a priority to all RFCs
 Chairs and facilitates CAB meetings
 Authorizes acceptable changes
 Issues change schedules, via the Service Desk
 Coordinate change building, testing and implementation
 Updates the change log with all progress
 Reviews all implemented changes
 Analyzes change records to determine any trends
ST
Change Management Metrics & Challenges

Notes:
Metrics
 Number of successful changes
 Number of failed changes
 Service disruptions caused by poor change
 Unplanned changes
 Change request backlog and why
Challenges
 The distribution of stakeholders, participants, et al.
 Balancing risk and need
 Balancing stability and responsiveness
 Balancing control and bureaucracy
 Culture
 Using the right measurements
ST
Change Management - Interfaces

Notes:
Change Management oversees changes needed for
each process.

 SACM provides information needed to assess impact of changes
 SACM helps assure all assets impacted by a change are noted
 SACM tracks change work flow
Capacity (and Demand), Availability and Security Management
 provide CAB with relevant information to assist in assessment
 all process related changes must go through Change Management
 ITSCM changes must be updated through Change Management to
assure accuracy and awareness to stakeholders
Problem Management
 RFCs required to handle problem fixes
 Problem management is major contributor to CAB

Release and Deployment Management

Notes:
To build, test and deliver the capability to provide
Purpose
the services specified by Service Design and that The scope of Release and Deployment Management
will accomplish the stakeholders‟ requirements and includes the processes, systems and functions to
deliver the intended objectives
package, build, test and deploy a release into
Release production and establish the service specified in the
A collection of Key Outcomes
hardware, software,  Services / changes established
Service Design package before final handover to
documentation, into production service operations. (from ITIL text)
processes or other  Effective use of services
components  Realization of business value by
required to customer
implement one or  Satisfied customers, users and staff
more approved  Effective and efficient service
changes to IT operations
services
ST
Release and Deployment - Objectives

Notes:
 Provide clear and comprehensive plans enabling
change projects to align their activities Well-planned and implemented release and
 Ensure release packages can be built, installed, tested deployment will make a significant difference to an
and deployed efficiently
 Ensure new or changed services meet the utility, organization‟s service costs. A poorly designed
warranty and service levels release or deployment will, at best, force IT personnel
 Ensure knowledge transfer enabling full utilization by the to spend significant amounts of time troubleshooting
consumer
 Ensure knowledge and skills transfer to support staff
problems and managing complexity. At worst, it can
enabling full delivery and support of the service cripple the environment and degrade the live services.
 Minimize unpredicted impact
 Satisfy customers and users
Effective Release and Deployment Management
enables the service provider to add value to the
business by:
ST
• Delivering change, faster and at
optimum cost and minimized risk
• Assuring that customers and users
can use the new or changed service
in a way that supports the business
goals
• Improving consistency in
implementation approach across the
business change, service teams,
suppliers and customers
• Contributing to meeting auditable
requirements for traceability through
Service Transition.
(from ITIL text)

Release and Deployment - Concepts

Notes:
Release Unit
A portion of a service or infrastructure that is normally
released together
Release Package
A single Release Unit or a structured set of release units
Release Options
 Big-bang – to all users at once
 Phased – partial then scheduled roll-out
 Incremental changes to all users
 Unit by unit
 Element by element
 Combinations of these
 Push vs. pull
 Automation vs. manual
ST
Release and Deployment - Basic Process

Notes:
Plan and prepare release
Build and test
Service testing and pilots
Plan and prepare deployment
Transfer, deploy, retire
Review and close Early Life Support
ST
Knowledge Management
Notes:
Purpose
Ensure that the right information is delivered to

the appropriate place or competent person at
the right time to enable informed decision
 Enable the service provider to be more efficient, improve

quality of service, increase satisfaction and reduce the
cost of service
 Ensure staff have a clear and common understanding of
the value that their services provide to customers and
the ways in which benefits are realized from the use of
those services
 Ensure that, at a given time and location, service
provider staff have adequate information
ST

DIKW Model
Notes:
“The quality and relevance of
knowledge rests on the
accessibility, quality and
continued relevance of the
underpinning data and
Wisdom information.”
Context
Knowledge
Why?
Information
How?
Who, What,
When, Where?
Data
Understanding
ST
Managing Knowledge through the SKMS

Notes:
Service Knowledge Management System (SKMS)
Presentation Layer
(Search, Browse, Store, Retrieve, Update, Publish, Subscribe, Collaborate)
Knowledge Processing Layer
(Query and analysis, reporting, Performance management, Modelling, Monitoring)
Configuration Management System (CMS)

Information Integration Layer
Service Management Knowledge Base
Integrated Asset and Configuration Information
Data and Information sources DML1 CMDB1

Change data Release data
Documents DML2
Application data CMDB2
ST
Additional Service Transition Processes

Notes:
Transition Planning & Support
 Plan and coordinate the resources to ensure that the
requirements in the service design are effectively realized
 Identify, manage and control the risks of failure and disruption
across transition activities
Service Validation & Testing
 Ensure that a release will deliver the expected outcomes
 Validate that a service is fit for purpose and fit for use
 Confirm that the customer and stakeholder requirements for
the new or changed service are correctly defined and
remedy any errors or variances
Evaluation
Provide a consistent and standardized means of determining
the performance of a service change in the context of existing
and proposed services and IT infrastructure
ST

Service Transition – Review

Notes:
Purpose
Assist organizations seeking to plan and manage service

changes and deploy service releases into the production
environment successfully
Processes
Key Concepts
 Change Management
 Goals & objectives
 Value to the business  Service Asset & Configuration
Management
 7 R‟s of change
 Release & Deployment
 Types of changes
Management
 Release options
 Transition Planning & Support
 CI types
 Service Validation & Testing
 Technologies – CMS, CMDB,
DML, SKMS  Evaluation
ST
Notes:
Service Operation Service Operation is the bread and butter phase for all
 Key terminology and concepts IT Services. Based on requirements identified in
 Incident Management (in depth)
 Problem Management (in depth) Service Strategy, we have now designed our services,
 Objectives and basic concepts for
 Event Management
transitioned them in and are ready to start deriving the
 Request Fulfilment value.
 Access Management
 Service Desk function
 Role, objectives and overlaps:
 Technical Management
 Application Management
 IT Operations Management
Service Operation - Principles & Purpose

Notes:
Service Operation concerns
The Service Operation phase is concerned with
 Managing day-to-day activities and technology
 Executing processes to optimize cost and quality delivery and support of services. The scope of this
 Enabling the business to meet its objectives phase includes:
 Effective functioning of components • Principles - using a balanced
approach to the many competing
 Coordinate and carry out the activities and needs of running services.
processes required to deliver and manage
• The Organization of Service
Purpose
services at agreed levels to business users and

customers Operation - focusing on the many
 Also responsible for ongoing management of roles involved in support of
the technology
operations.
• The Services Themselves - any
SO
activity undertaken as part of a
service, regardless of who performs it.
This may be the service provider, an
external supplier, or even a user or
customer.
• Service Management Processes - of
course the Service Operation
processes are within Service
Operation scope but many of the
other ITIL processes, including those
introduced in other phases, are either
in constant use in Service Operation

or influenced by outputs from this

phase. One example of this is
Availability Management, introduced
in Service Design but of vital
importance to Service Operation.
• Technology - because all services
require technology in some way for
delivery, the technology itself must be
included in management of services.
Infrastructure management is a
significant consideration of Service
Operation.
• People - those who drive demand for
services and products as well as
those who determine how this
demand will be met. Failure to
recognize the importance of this
component will undermine any
Service Management project.
(from ITIL text)
Service Operation - Value to the Business

Notes:
‘Service Operation is where the value By ITIL definition, a Service is a means of delivering
is seen’ value to customers by facilitating outcomes customers
A means of delivering value to customers by
want to achieve without the ownership of specific costs
Service
facilitating outcomes customers want to and risks.
achieve without the ownership of specific
costs and risks. It is apparent by this definition, that Service Operation
is the phase in which value to the business is realized.
 Services run within budget and ROI targets Service Strategy, Service Design and Service
 Design flaws fixed and unforeseen requirements
satisfied
Transition considered the value proposition and
 Efficiency gains achieved assured this value could be derived but within Service
 Services optimized Operation value is seen through:
SO
• Services running within budget and
ROI targets
• Design flaws fixed and the satisfaction
of unforeseen requirements
• Gains to efficiency
• Optimization of services
(from ITIL text)

Communication
Notes:
Not a process, but is required for
effective Service Operation Good communication is essential for successful
1. Must have an intended Service Operation, just as it is for any other phase of
purpose or action
2. Audience should be involved
the lifecycle.
in determining need
Considerations
 Routine operational communication
 Communication between shifts
 Performance reporting
 Communication in projects
 Communications related to changes
 Communications related to exceptions or to emergencies
 Training for new or customized processes and service designs
 Communication of strategy and design to operational teams
SO
Service Operation - Processes

Notes:
The processes of Service Operation are:
• Event Management - which monitors
 Event Management all events that occur throughout the IT
 Incident Management Infrastructure to allow for normal
 Problem Management operation and also to detect and
 Access Management escalate exception conditions.
• Incident Management - concentrates
on restoring the service to users as
quickly as possible in order to
minimize business impact.
• Problem Management - involves root-
SO
cause analysis to determine and
resolve the cause of events and
incidents. It also includes pro-active
activities and Known Error
Management.
• Access Management - the process of
granting authorized users the rights to
use a service while restricting access
to non-authorized users.
• Request Fulfillment - involves the
management of customer or user
requests that do NOT result from an
unexpected delay or disruption.
Other processes introduced in other Service
Management phases still have a significant role in
Service Operation:
• Financial Management
• Availability Management
• IT Service Continuity Management
• Capacity Management
• Change Management
• Service Asset and Configuration
Management
• Release and Deployment
Management
• Knowledge Management

(from ITIL text)
Event Management
Notes:
 To detect events, make sense of them, and
3 suggested categories of events are:
Purpose
determine appropriate control action

 To act as a basis for automating routine • Informational - an event that does not
operations management activities require action nor represent an
Types of Events Notes
exception. These may be used to
 Informational  There is no definitive rule check status, confirm completion,
about delineation
 Warning  Each relies on the sending
generate statistics or assist
and receipt of a message
 Exception investigations. Examples: user logs
Key Roles on, job in a batch queue completes,
 Service Desk device comes online, transaction
 Technical and Application Management completes successfully.
 IT Operations
• Warning - event that is generated
SO
when a threshold is approached such
as when memory utilization is at 65%
and increasing where 75% will break
the OLA. Warnings allow action to be
taken to prevent an exception.
• Exception - when a service or device
is operating abnormally, probably
meaning OLA & SLA breached and
business is impacted, such as when a
server is down or excess users have
logged on.
Event Management – Key Terms

Notes:
Event
any detectable or discernible
occurrence (including a
change of state) that has
significance for the
management of a
configuration item or service
Alert
A warning that a
threshold has been
reached, something has
changed, or a failure has
occurred
SO

Incident Management - Overview

Notes:
“An unplanned interruption to an IT Failure of a Configuration Item that has not yet
Incident service or reduction in the quality of impacted service is also an incident. For example
an IT service”
failure of one disk from a mirror set.
Incident Management
The process of dealing with all
incidents including failures,
questions or queries reported by
users (via Service Desk), by
technical staff or automatically
detected and reported by event
monitoring tools
SO
Incident Management - Scope & Objectives

Notes:
To restore normal service operation as quickly as
Objective
possible and minimize the adverse impact upon

business operations, thus ensuring that the best
possible levels of service quality and availability are
maintained
Scope Notes
 Not all events are incidents
 Any event which disrupts
 Service requests are not
or could disrupt a service incidents
– including user reported
ones
 Incidents can also be “Normal service
reported/logged by operation” means
technical staff within agreed service
levels (in SLAs)
SO
Incident Management – Process (1)

Notes:
Web User Call Identification The Incident Management process may be triggered
by any number of notifications, whether through Event
Event Staff
Logging Management, web interface, user phone call, email or
another means.
Categorization The Service Desk logs the incident, categorizes the
incident, and makes a determination whether this is a
Service
Request?
Yes Request
Fulfillment
Service Request and should be fulfilled through
No
Request Fulfillment process.
Prioritization A
If not, the incident will be prioritized based upon
impact and urgency. (from ITIL text)
SO

Incident Management - Process (2)

Notes:
Major Yes Major Incident
A Incident? Procedure The Service Desk will determine whether this is a
No Major Incident. If it is a Major Incident, it will fall under
Initial Diagnosis the Major Incident procedure. If not, the Service Desk
will perform an initial diagnosis.
Yes
Escalation* Escalation*? The Service Desk will next determine whether
No
escalation is needed. There are 2 types of escalation
Investigation & in the Incident Management process; hierarchical and
Diagnosis
functional.
* Functional or Hierarchic
Resolution &
Recovery
Close Hierarchical Escalation refers to the more traditional
escalation to management and should be performed
SO when called for by the process, for instance when a
user is very upset or when SLAs are threatened.
Functional Escalation refers to reassignment of an
incident to another IT technician whether because
additional expertise is needed or because the Service
Desk can not resolve the incident within SLAs.
Whether or not an incident is escalated, it will continue
through investigation and diagnosis and then on to
resolution and recovery.
Investigation & diagnosis and resolution & recovery
may be performed by technicians not part of the
Service Desk staff, but the incident must be returned
to the Service Desk for final closure. The Service Desk
will verify closure with the user, assure the incident
record is properly updated and finally will close the
incident.
(from ITIL text)
Incident Management - Prioritization

Notes:
 Priority = Impact + Urgency
 Impact = Effect of the incident on the business Priority is based upon 2 inputs - urgency and impact.
 Urgency = A measure of how long it will be until the business Impact refers to the impact on the business while
experiences significant impact
urgency refers to how quickly that impact will be felt or
Sample model
is already being experienced. Impact and urgency
Impact
Priority should be defined as unambiguously as possible, such
Resolution High Medium Low
time as Low Impact affects 1 or very few users in non-
1 2 3 critical tasks. The example given in the chart above is
High
< 1 hour < 8 hours < 24 hours
one way in which impact and urgency could be used to
Urgency
2 3 4
Medium
< 8 hours < 24 hours < 48 hours determine impact, although an organization would
Low
3 4 5 assign its own timescales to the given priorities.
< 24 hours < 48 hours Planned
SO

Incident Management - Other Concepts

Notes:
A workaround is a way of reducing or eliminating the
 Workarounds - reduce or
eliminate the impact impact of an incident or problem for which a full
 Timescales - agreed for all resolution is not yet available.
incident handling stages
Timescales must be agreed for all incident handling
 Incident models - standard
responses formulated to deal stages – based upon agreed response times and
with common incidents resolution targets documented in SLAs. These must
 Major incidents - highest be reflected as targets within OLAs and underpinning
category of impact for an
incident
Contracts. All support groups must be aware of these
timescales and tools may be used to automate
escalation.
SO Incident models define the specific steps to be taken
associated with recurring incidents that have standard
responses defined. Tools can be used to manage the
process and ensure that a consistent approach is
always followed.
Major incidents represent the highest category of
impact for an incident. A major incident results in
significant disruption to the business. Special
procedures need to be followed to ensure that all
resources are available to deal with the incident
speedily. Each organization defines what constitutes a
major incident.
(from ITIL text)
Incident Management - Metrics

Notes:
 Number of incidents
 Breakdown by stage
 Incident backlog
 Number and percentage of major
incidents
 Mean time to resolve by impact
code
 Percentage handled within SLA
 Number and percentage of
incidents handled per SD agent
 Number and percentage handled
remotely
March
January
February
 Number of incidents per incident

model
 Incident occurrence by time of day
SO

Incident Management – Challenges

Notes:
 Early detection ability
Common challenges for implementation of effective
 Need for logging and use Incident Management include:
of self-help • Unable to detect incidents early - this
 Availability of problem and can be overcome through education
known error information
(and relevant knowledge) of users and effective Event
 Integration into Management
Configuration
Management System • Self-help not used or incidents not
 Integration into Service logged - which can be offset through
Level Management
process
training technicians and user to log all
incidents and by provision of and
education in the use of web-based
SO
self-help capabilities
• Lack of Problem and Known Error
information due to immature or non-
existent Problem Management
Process
• Lack of Integrated Configuration
Management System (CMS) enabling
improved 1st line support
• Not integrated into SLM process,
which impedes ability to assess
impact and priority of incidents as well
as to escalate properly
(from ITIL text)
Incident Management - Interfaces

Notes:
Incident Management provides information useful to
other processes in assessing and addressing issues related
to the respective processes.

 SACM provides information to assess and work incidents, including
users affected, faulty equipment, and routing
 Incident Management maintains status of faulty Cis
 Incident Management helps audit infrastructure
Change Management
 receives incident information on incidents resolved by or resulting
from changes
 Incident Management resolves incidents caused by failed change
Capacity Management
 receives incident information pointing to capacity related issues
 helps develop workarounds for capacity related incidents

Incident Management – Interfaces (cont‟d)

Notes:
 uses incident data to determine availability of services
 uses incident data to assess where the incident lifecycle can be
improved
 receives information on the performance of the processes
themselves
 receives information to identify weaknesses in performance of the
services
 provides information on business requirements in order to better
prioritize and evaluate performance
Problem Management
 receives information to assist in assessing and resolving problems
 provides workarounds to reduce impact of incidents and fixes to
prevent recurring incidents
Problem Management
Notes:
 To prevent problems and resulting incidents from It is important to understand the distinction between
Objective
happening
 Eliminate recurring incidents
incidents and problems.
 To minimize the impact of incidents that cannot It is important to understand that not all incidents
be prevented
should initiate problem management. Problem
records may be generated as a result of analysis of
events or incidents, from proactive trend analysis, or
The unknown simply be reported from a variety of sources.
Problem cause of one or
more incidents
SO
Problem Management – Key Concepts

Notes:
 Known Errors - A problem that
has a documented root cause
and a workaround (or
permanent solution) identified
 Known Error Database (KEDB) –
Stores known errors
 Workaround – Allows restoration
of service, leading to closure of
incidents
 Resolution – removes the root
cause of a problem and
involves change, release and
deployment processes
SO

Problem Management - Process Activities

Notes:
 Detection
Detection may occur in many ways including detection
 Logging by the Service Desk from a major incident or by
 Categorization & prioritization analysis of data to identify trends frequently recurring
 Investigation & diagnosis incidents
 Identification of Workaround
 Create Known Error record Logging to include all relevant details and cross-
 Initiate Change Management referencing incident records
 Resolution (via Change
Management) Categorizing should use the same coding system as
 Closure incidents for meaningful analysis and Management
 Major Problem Review Information
Prioritization includes impact and urgency but will also
SO
consider severity of the problem and resources
needed to resolve it
Diagnosis may use techniques such as Ishikawa
Diagrams, Pareto and brainstorming
Identification of workarounds allows more rapid
restoration of service
Once diagnosis is complete and a workaround or
resolution identified a Known Error record should be
recorded in the Known Error Database
A Request for Change will be submitted to correct
Known Errors
Resolution will involve Change Management and
Release & Deployment Management
Once a solution has been released and accepted, the
Problem record will be closed
A Major Problem Review will be performed to allow
capture of process improvement opportunities as well
as to acknowledge what was done well
(from ITIL text)
Problem Management - Interfaces

Notes:
Problem Management provides information useful to other
processes in assessing and addressing problems related to
the respective processes.

Incident Management
 provides information to assist in assessing and resolving problems
 helps reduce incident impact (workarounds) and occurrence (fixes)
Financial Management
 helps assess impact of resolutions or workarounds
 receives information on cost of resolution and prevention
 SACM provides information to assess and work problems
 may hold Known Error DB and integrate with problem records
Change Management
 Problem Management submits RFCs for resolutions or workarounds
 Change Management monitors progress
 Problem Management contributes to CAB as well as assessment of
success of changes

Problem Management – Interfaces (cont‟d)

Notes:
Release and Deployment Management
 rolls out problem fixes into live environment
 assists in transfer of known errors from development to live KEDB
 Problem Management assists in resolving problems caused during
release
 proactive problem management assists in reduction of downtime
Capacity Management
 problem information assists in evaluating Capacity Plan
 some problems require Capacity Management input
 Capacity Management helps evaluate proactive measures
 Problem Management may be entry point if not resolved before
major impact to business
 Problem Management contributes to improved Service Levels
 provides Problem Management with parameters
 receives information forming basis of some SLA review components
Request Fulfilment - Overview

Notes:
A request from a user for information, The term service request describes requests for
advice, for a standard change or for
Service access to an IT service, e.g. to reset a standard services by users. Many are actually small
Request password or to provide standard IT
changes – low risk, frequently occurring, low cost, etc
services for a new user
(e.g. password reset, software installation on a single
Objectives PC) – or information requests.
 Provide a regular channel for users to request and Changes of core service functionality are not service
receive standard services
 Provide information to users about service availability
requests.
and access requests
Service Requests are usually handled by a Service
 Source and deliver components of standard services
 Assist with general information, complaints or
Desk, and do not require an RFC to be submitted.
comments related to service requests (from ITIL text)
SO
Access Management – Objectives & Roles

Notes:
 Execute the policies and actions defined in Access Management does NOT define policies around
Objective
Security and Availability Management

 Provide the right for users to be able to use a
who receives what access. Confidentiality, Integrity
service or group of services and Availability requirements are set by Information
Security and Availability Management process. Access
Roles
Access Management Management grants or restricts access based on
 Service Desk
Process of granting  Technical and those requirements.
authorized users the right to Application
use a service, while Management Access Management does not require a new function.
preventing access to non-  IT Operations
authorized users Management
Access Management may be executed by Technical
and Application Management functions and is
Sometimes called Rights Management or
Identity Management
generally coordinated in IT Operations Management or
SO
the Service Desk. A Service Request through the
Service Desk may initiate Access Management.
(from ITIL text)

Access Management - Concepts

Notes:
 Access: the level and extent of
a service‟s functionality or data
that a user is entitled to use
 Identity: the information about
them that distinguishes them as
an individual and verifies their
status within the organization
 Rights (privileges): settings
whereby a user is provided
access – read, write, execute,
change, delete
 Service groups: aggregation of
a set of users accessing a
common set of services
 Directory services: a specific
type of tool used to manage
access and rights
SO
Access Management - Process Activities

Notes:
Requesting Access - often through a Service Request
 Requesting access through the Service Desk or Request Fulfillment or by
 Verification Human Resources upon hiring or change of position.
 Providing rights
 Monitoring identity status Verification - that the user is who they claim to be and
 Logging and tracking that they have a right to that access
access
 Removing or restricting Providing of Rights - is executed by Access
rights Management upon completion of verification, often
generating requests to other involved departments
Monitoring Identity Status - as users' roles change,
access should be changed accordingly. Likely
SO
changes should be monitored for automatically, such
as job changes, retirement, dismissal.
Logging and Tracking Access - Access Management
is responsible for ensuring rights, once granted (by
Information Security Management) are properly used.
Note that access to this information should be
restricted.
Removing or Restricting Rights - Decisions made by
other parts of the organization, but executed by
Access Management (much as granting of access was
done)
(from ITIL text)

Service Operation - Functions

Notes:
Logical functions to perform specific activities and
processes – not necessarily mapping on to
Operations Control refers to overseeing the execution
organizational structures or individuals and monitoring of IT operational events and activities.
IT Operations
Facilities Management refers to the management of
Service Desk Management the physical IT environment such as a data center.
Technical Application
Management Management
Operations Control
Facilities Management
SO
Service Desk – Objectives & Responsibilities

Notes:
 The primary aim of the Service Desk is to restore the
As the single point of contact for an IT service
Objective
„normal service‟ to users as quickly as possible (in the

widest possible sense) provider, the Service Desk provides a single
 Fixing a technical fault, it could equally involve fulfilling
a service request or answering a query
consistent way to communicate with an organization or
business unit. (from ITIL text)
 Logging all incidents/service requests, allocating
categorization and prioritization codes
 First line investigation and diagnosis
 Resolving incidents/service requests
 Escalation as necessary
 Closing all resolved incidents and requests
 Conducting customer satisfaction surveys
 Communication with users - progress, information
 Updating Configuration Management System as agreed and
authorized
SO
Service Desk – Types

Notes:
 Local – co-located with users Types of Service Desks include:
 Centralized – central location,  Local - Situated in the same location as the
enabling greater efficiency
and cost-effectiveness users it serves
 Virtual – achieves  Centralized – Has a central location, enabling
centralization virtually.
greater efficiency and cost-effectiveness
 Follow-the-sun – utilizes
support groups around the  Virtual – Achieves centralization virtually.
world to assure seamless, 24 X Members may be located in numerous
7 support
 Specialized – allows certain
locations
types of calls to automatically  Follow-the-sun – Utilizes support groups
route to specialist groups around the world to assure seamless, 24 X 7
support. Passes incidents, problems, etc
SO
between groups in different time zones
 Specialized – Allows certain types of calls to
automatically route to specialist groups
(based, for example, on specific platforms,
applications, business units, etc)
Special consideration should be given to the following
staffing points:
• Making sure that staffing is at an
adequate level to meet SLAs and that
staffing levels conform to the likely
needs of specific days and times
• Skill levels should be mixed at any

given point to assure needed

expertise is at hand at all times
• Training is critical to Service Desk
success including use of tools,
awareness of business services as
they relate to IT, strong
communication and customer service
skills, knowledge of SLAs
(from ITIL text)
Technical Management - Objectives & Role

Notes:
Objectives
Help plan, implement and maintain a stable technical
infrastructure to support the organization‟s business
processes through:
 A well designed and highly resilient, cost-effective
technical topology
 The use of adequate technical skills to maintain the
infrastructure in optimum condition
 The swift use of technical skills to diagnose and resolve
any technical failures
Role
 Custodian of technical knowledge and expertise
related to managing the IT Infrastructure
 Provides the resources to support the IT management
lifecycle
SO
Application Management - Objectives & Role

Notes:
Objectives
 To support the organization‟s business processes by
Application Management is responsible for managing
helping to identify functional and manageability applications throughout their lifecycle. The Application
requirements for application software
 To assist in the design and deployment of applications
Management function is performed by any
 To assist in the ongoing support and improvement of department, group or team involved in managing and
applications
supporting operational applications. Application
Role
Management also plays an important role in the
 Contributes to the decision on whether to buy an design, testing and improvement of applications that
application or build it
 Custodian of technical knowledge and expertise
form part of IT services. As such, it may be involved in
relating to the management of applications development projects, but is not usually the same as
 Provides resources to support the Service Management
Lifecycle the Applications Development teams. (from ITIL text)
SO
IT Operations Management – Objectives & Role

Notes:
Objectives
 To maintain the „status quo‟ to achieve stability of the
organization‟s day-to-day processes and activities
 To regularly scrutinize and improve service at reduced
cost, while maintaining stability
 To swiftly apply operational skills to diagnose and resolve
any IT operations failures that occur
Role
 Executes the ongoing activities and procedures required
to manage and maintain the IT infrastructure to deliver
and support IT services at the agreed service levels
 Continually adapts to business requirements and
demand
SO

Operations Control and Facilities Management

Notes:
Operations Control
 Oversees execution and monitoring of operational activities Facilities Management also includes the coordination
and events in the IT Infrastructure. of large-scale consolidation projects, e.g. Data Center
 Assisted by Operations Bridge or Network Operations
Center. consolidation or server consolidation projects. In cases
 Executes routine tasks from all technical areas. where the management of a data center is outsourced,
 Specific tasks: Facilities Management is responsible for the
 Console Management
 Job Scheduling
management of the outsourcing contract. (from ITIL
 Backup and Restore text)
 Print and Output Management
Facilities Management
Manages physical IT environment (Data Center)including
recovery sites, power and cooling.
Service Operation - Function Overlaps

Notes:
Ops Mgt Tech Mgt App Mgt
management of IT
infrastructure
application
maintenance & support
design, testing and
improvement of CIs
IT Operations
Management
Technical Application
Management Management
SO
Common Service Operation Activities

Notes:
 Security Management & Service
Operation
 Facilities and Data Center
Management
 Internet / Web Management
 Middleware Management
 Desktop Support
 Directory Services Management
 Database Administration
 Storage and Archive
 Network Management
 Server Management & Support
 Mainframe Management
 IT Operations
 Improvement of Operational Activities
SO

Service Operation – Review

Notes:
Coordinate and carry out the activities and processes
Purpose
required to deliver and manage services at agreed levels to

business users and customers (including the ongoing
management of technology to deliver and support services)
 Purpose & value

Processes
 Achieving balance
 Communication  Incident Management
 Realization of service value  Event Management
Functions  Problem Management
 Access Management
 Service Desk
 Technical Mgt
 Applications Mgt
 IT Operations Mgt - IT Operations Control & Facilities Mgt
SO
161
Foundations Course for ITSM (ITIL v3) Notes:
Continual Service
Improvement
 Importance of Continual Service
Improvement
 Continual Service Improvement
Model
 Deming Cycle
 Measurement
 Governance
 The 7 step improvement process
course v 3.4
CSI and the ITIL Core

Notes:
CSI exists in all

phases of
the Service
Management
Lifecycle
CSI

CSI Objectives & Scope

Notes:
Objectives
 To ensure that Service
Management processes continue
to support the business
 To monitor service level
achievements and where
necessary enhance processes
Scope
 The health of the ITSM discipline is
maintained
 The service portfolio is aligned to
current and future business needs
 The continual maturing of IT
service processes
CSI
Purpose of Continual Service Improvement

Notes:
 Validate services delivered
remain in line with ever CSI provides guidance on
changing business needs
 Align and realign IT with the
• how to improve process efficiency and
business effectiveness
 Identification and • how to improve services
implementation of
improvements • the improvement of all phases of the
 Consider processes throughout service lifecycle
the service lifecycle
 Improve effectiveness and • the measurement of processes and
efficiency of existing processes
services
 Understand cost implications
 Ensure all processes contain (from ITIL text)
goals, objectives and are
measurable
CSI
Return on Investment for CSI

Notes:
“The Business Case should articulate the reason for
undertaking a service or process improvement initiative.”
„ROI‟ - Amount of gain taking into account the
investment required (financially oriented)
Investment Cost Benefit
money an organization pays to
what an organization „VOI‟ - Additional advantages not focussed on
improve services and service ROI can gain in a return
management processes monetary gain (e.g. competitive advantage, credibility,
customer loyalty, etc.)
VOI Business Case
the business value  „As-is‟ & „to-be‟ states
that service
 Clearly defined success criteria
improvement
brings (beyond  Balanced focus – people,
financial) process & technology
CSI

Continual Service Improvement Model

Notes:
What is the Vision and business
vision? objectives
Where are Assessments

we now?
Improvement
Continuous
Where do we Measurable
want to be? Targets
How do we Process
get there? Improvement
How do we know Metrics &

we‟ve arrived? Measurements
CSI
The Deming Cycle

Notes:
Plan Establish objectives and processes necessary to
deliver results in accordance with the specifications Dr. W. Edwards Deming is considered the father of
Do
modern quality control
Implement the processes
Check Monitor, evaluate and

From Wikipedia.com: PDCA should be repeatedly
report the outcome implemented, as quickly as possible, in upward spirals
Act Apply actions to the that converge on the ultimate goal, each cycle closer
outcome for necessary Continuous
than the previous. This approach is based on the
improvement improvement over time
understanding that our knowledge and skills are

 Used to control and manage quality always limited, but improving as we go. Often, key
 Repeatable, but allows for periods of stabilization
 Supports identification and implementation of improvements
information is unknown, or unknowable. Rather than
 Relies on a process led approach enter "analysis paralysis" to get it perfect the first time,
CSI
it is better to be approximately right than exactly
wrong. Over time and with better knowledge and skills,
PDCA will help define the ideal goal, as well as help
get us there.”
In Six Sigma programs, this cycle is called "Define,
Measure, Analyze, Improve, Control" (DMAIC).
Continual Service Improvement Metrics

Notes:
metrics often associated with
Technology
components and applications –
Metrics
e.g. performance, availability, etc
captured in the form of CSFs, KPIs

Process
and activity metrics for the service
Metrics
management processes *
the results of the end-to-end

Service
service (component metrics are
Metrics
used to compute service metrics)
*
key questions that KPIs can help answer: quality,
performance, value and compliance
CSI

KPIs and the Improvement Process

Notes:
 KPIs may change over time It is recommended that in the early stages of a CSI
 Should be fit for purpose and use Scope
program only two to three KPIs for each CSF are
 Tension metrics allow balance  Quality
 Performance defined, monitored and reported on. As the maturity of
 Resources – people and money  Value
 Features  Compliance a service and service management processes
 Schedule increase, additional KPIs can be added.
 Should focus on results, not efforts Based on what is important to the business and IT
KPI Metric
management the KPIs may change over a period of
CSF time.
KPI Metric
Objective Key questions for KPIs include:
CSF
 What does the performance indicator really tell
CSI us about goal achievement?
 How easy is it to interpret the performance
indicator?
 Does it help us to decide on a course of
action?
 When do we need the information?
 To what extent is the performance indicator
stable and accurate?
 How easy is it to change the performance
indicator itself?
 To what extent can the performance indicator
be measured now?
 Who owns this KPI?
Requirements for IT services and IT components
determine how processes in the lifecycle are
measured and managed, and thus how the
performance and growth of professionals should be
measured.
(from ITIL text)
CSI - Why Do We Measure?

Notes:
Validate Monitoring and measuring to
Validate Direct
validate previous decisions
Strategy Targets &
Vision Metrics “The metrics tell us that we
were we right to …”
Measurement Framework
“Our numbers show we are
realizing value from …”
Justify Intervene
Direct Monitoring and measuring to
Factual Changes &
Evidence Corrective Actions set direction for activities in
order to meet set targets
CSI
The most prevalent reason for
monitoring and measuring
“The metrics reveal that we
are meeting our targets …”
“The numbers show that we
are not adequately …”
Justify Monitoring and measuring to
justify, with factual evidence

or proof, that a course of
action is required
“The metrics are clear, we
must … “
“According to the numbers
collected, we should …”
Intervene Monitoring and measuring to
identify a point of intervention
including subsequent
changes and corrective
actions
“Based on the metrics, our
best option is to …”
“The numbers suggest that
we should …”
(from ITIL text)
CSI - Baselines
Notes:
 A baseline provides:
 A clear starting point for
later comparison
 An initial data point to
determine if a service or
process needs to be
improved
 Baselines need to be
documented
 Baselines should be
established at all levels
 Strategic goals and
objectives
 Tactical process maturity
 Operational metrics and
KPIs
CSI
CSI - Governance
Notes:
“Governance is back with a vengeance.”
Enterprise governance describes a framework that
covers both the corporate governance and the
Enterprise Governance
business management aspects of the organization.
a framework that covers Corporate Governance
both the corporate Enterprise governance considers the whole picture to
governance and the promoting corporate
business management fairness, transparency ensure that strategic goals are aligned and good
aspects of the organization and accountability
management is achieved.
IT Governance Corporate governance is about promoting corporate
the leadership, organizational structures
and processes that ensure that IT sustains fairness, transparency and accountability.
and extends the organization‟s strategies
and objectives IT governance an integral part of enterprise
governance and consists of the leadership,
CSI organizational structures and processes that ensure
that the organization‟s IT sustains and extends the
organization‟s strategies and objectives.
The new reality of IT is one in which IT must comply
with new rules and legislation and continually
demonstrate their compliance through successful

independent audits by external organizations, while

simultaneously and increasingly being called upon to
do more with less. These challenges fit perfectly into
the basic premise of ITIL, in which IT is recognized as
a service business. This continual drive toward
greater business value with greater internal efficiency
is at the heart of CSI, and within the scope of IT
governance.
(from ITIL text)
The 7 Step Improvement Process

Notes:
1 The 7 Step Improvement Process can most accurately
Identify - Vision, Define what you
Strategy & Goals should measure be described as a process for defining what is to be
measured, gathering the data, processing the data
7 2
Implement Define what you and using it to take corrective action.
corrective action can measure
Goals What you measure will dictate how well you can make
6 3
Present and use Gather the data
decisions, see improvement opportunities and identify
the information
trends. The primary focus should be on business
focused metrics, not only those related to the
5 4
Analyze the data Process the data operational environment. The differences between
technology, process and service metrics must be
CSI
understood, as well how data, information and
knowledge support the objectives of making wise
decisions.
(from ITIL text)
Key Roles for Continual Service Improvement

Notes:
Service Manager
 Understand business and commercial strategy
 Manage the full lifecycle of products and services
 Manage customer relationships
 Recognize new opportunities
Continual Service Improvement Manager

 Responsible for all improvement initiatives
 Communicate CSI vision
 Provide resources
 Coordinate with Service Owners
 Prioritize required improvements
 Ensure service requirements are defined, and supported
by service improvement plans, metrics & measurements
 Lead, mentor, and influence
CSI

Continual Service Improvement - Review

Notes:
Purpose
Continually align and realign IT services to the changing

business needs by identifying and implementing
improvements to IT Services that support business processes
The 7 Step
 Purpose & scope Improvement Process
 Business case for improvement
 Deming cycle  Define what you
should measure
 Used to control and manage
quality  Define what you can
measure
 Plan, do, check, act
 Gathering the data
 CSI model
 Processing the data
 Measurement:
 Analyzing the data
 Baselines
 Presenting and using
 Types of metrics – technology,
the information
process & service
 Implementing
 Roles for CSI corrective action
CSI
Notes:
Service Management tools are a great boon to Service
Service Management Management processes, but it is important to
Technology understand the requirements of the process before the
 Service Automation Assists with: tool is selected. The tool should support the
 Service Design processes, not the other way around. Where possible,
 Service Transition
 Service Operation
purchase an integrated tool to support as many
 Continual Service Service Management processes as practical.
Improvement
Interfaces between the tools must also be given
consideration.
Service Design Tools

Notes:
Tools exist to assist with design of services and their
 Hardware and software
design associated components, including:
 Environmental design • Hardware and software design
 Process design • Environmental design
 Data design
• Process design
 Service lifecycle
management • Data design
• Management of all stages of the
Service design tools can provide a Service Lifecycle
significant aid for all 5 aspects of
design. These tools can help:
• Speed up the design process
• Ensure standards and conventions
are followed
• Offer prototyping, modeling and
simulation facilities
• Enable examination of "what if"
scenarios
• Allow interfaces and dependencies to
be checked and correlated
• Validate designs to assure they meet
intended requirements
(from ITIL text)

Service Transition Tools

Notes:
 Application management
Technology plays a major role in Service Transition
tools and should be designed into solutions. Service
 Service dashboards and Transition is supported by both:
reporting tools
• Enterprise-wide tools supporting
 Data mining tools
 Measurement and systems and processes within which
reporting systems Service Transition delivers support
 Test management and (Application Management tools,
testing tools
 Deployment and logistics
Service Dashboards & Reporting
systems tools)
• Tools targeted specifically at
supporting Service Transition or parts
of Service Transition (Data Mining
tools, Measurement and Reporting
Systems, Test Management and
Testing tools, Deployment and
Logistics Systems and tools)
There are a number of tools to support specific
Service Transition processes of Change, Service
Asset and Configuration Management, Release and
Deployment Management.
(from ITIL text)
Service Operation Tools

Notes:
Integrated technology is needed to support Service
 Self help functionality Operation, including the following core functionality:
 Workflow/process control • Web-based front-end allowing menu-
engine driven Self-Help and Service
 Integrated and verified CMS
 Control of user „desktop‟
Requests and directly interfacing to
 Diagnostic scripting the back-end process-handling
 Reporting and dashboard software
capability • Workflow or process control engine
allowing control of processes. This
gives the ability to pre-define and
automatically manage responsibilities,
timescales, escalation paths and
alerting
• Integrated Configuration Management
System allowing the organization's IT
Infrastructure assets, components,
services and other CIs to be held
along with relationships in a
centralized location
• Remote control capability allowing
Service Desk and other technicians to
perform investigation and make
corrections to users' PCs remotely
• Diagnostic utilities allowing creation
and use of diagnostic scripts to assist
in early diagnosis of incidents

• Data should be readily retrievable and

useable in reporting formats
compatible with standard packages
and capable of being displayed in
dashboards for see-at-a-glance
visibility of overall performance
(from ITIL text)
Continual Service Improvement Tools

Notes:
Software vendors now provide tools and suites of tools
 Systems and network
management to provide integration between processes and their
 Event Management associated record types, providing valuable inputs to
 Incident/Problem CSI. (from ITIL text)
Management
 Service request and
fulfilment
 Performance management
 Security Management
 Financial Management
Notes:
ITIL Qualification
 ITIL certification model
 Migration / upgrade from ITIL
version 2
 Rapid advancement to ITIL
Expert
ITIL Version 3 Certification Scheme - Overview

Notes:
 Multiple levels of certification
 Foundation
 Intermediate
 Lifecycles
 Capabilities
 Expert
 Credit based scheme
 Credits gained from previous version 2 awards
 Modular in design
 Oriented to support individual career paths
 Provides for on-demand examinations
 Version 2 to version 3 bridging courses available

Training Certification Model for ITIL V3

Notes:
For additional information on combining v2 and v3
ITIL Master credits, go to http://www.itil-
officialsite.com/itilmapping/v2/map.asp
ITIL Expert
5 Capability Modules:
Managing Across the Lifecycle
• Planning, Protection and Optimization
3 3 3 3 3 4 4 4 4 • Service Offerings and Agreements
SS SD ST SO CSI PPO SOA RCV OSA
• Release, Control and Validation
Lifecycle Modules Capability Modules
• Operational Support and Analysis
2
ITIL V3 Foundation Certificate in IT Service Management
Managing Across the Lifecycle focuses on the
ancillary knowledge required to implement and
manage the necessary skills associated with the use
of the Lifecycle practices and includes:
• Introduction to IT Service Management Business &
Managerial Issues
• Managing the Planning and Implementation of IT
Service Management
• Management of Strategic Change
• Risk Management
• Managerial Functions
• Understanding Organizational Challenges
• Lifecycle Project Assessment
• Understanding Complementary Industry Guidance


Student Guide r3.4

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Student Guide r3.4

Încărcat de

Drepturi de autor:

Formate disponibile

ITIL Foundations based on Version 3 – Student Guide – R3.

 Provides an essential level of knowledge in the following areas:

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Market Drivers / Issues for IT

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

IT‟s Key: Managing to Business Value

Managing Value means:

What is IT Service Management (ITSM)?

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

IT Service Management Goals

 Improve the quality of IT services – in whatever way

 Reduce the long term cost of

Reasons for Adoption in North America

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Integration of the 5 Core Books

Service Objectives from

© Crown copyright 2007

because they work.

Academic research Suppliers

Regulators Compliance difficult to adopt, replicate, or transfer even with the

customers by facilitating outcomes customers

enhance the performance of tasks

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Service Management Key Concepts (1)

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Service Management Key Concepts (2)

User A person who uses the IT service on

Provider A company or unit of a company that

Supplier A third party responsible for supplying

Generic Process Model

implemented, regularly and when process failures are

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

 Liaise with Process Owners throughout the

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

IT Service Management Reusable Concepts

The Business Case

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

business Gain Identify

The Service Lifecycle

The Service Lifecycle

© Crown copyright 2007

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

The Lifecycle Approach

Optimization Design Evaluation

Operation Develop, Procurement

© Crown copyright 2007

Service Strategy - Overview

Service Design - Overview

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Service Transition - Overview

Assist organizations seeking to plan and manage

Service Operation - Overview

processes required to deliver and manage services

ITSM Functions Processes

Primary deliverable: intended

Continual Service Improvement - Overview

changing business needs by identifying and Continual Service Improvement.

 The overall health of ITSM as a discipline

Primary deliverable: business justified improvement

Published by Dream Catchers, Inc 866-FOR-ITSM www.dream-catchers-inc.com

Foundations Course for ITSM (ITIL v3)

Goals, Purpose & Scope of Service Strategy