ITIL V3 Core Framework

Continual Service
Improvement

Service
Operation

Service Transition

Service
Service
Design
Design

Validates the service design

against
service

Service
Service
Strategy

requirements

ITIL
SERVICE
TRANSITION

Page 1

Service Transition (ST)

ST will ensure that the design will deliver the intended strategy and that it
can be operated and maintained effectively.

ST is concerned with managing change, risk & quality assurance and has
an objective to implement service designs so that service operations can
manage the services and infrastructure in a controlled manner.

Main Target Audience:

IT Service Managers, Service Owners, operational staff.

Main Influencers:
Customers, Service owners, support staff.

Page 2

ST The Real World

The majority of IT projects do not yield desired results / outputs

Near 80% of incidents are caused by failed changes and activities within IT

Most IT organization need:

Stability
Improved Quality
Increased Efficiency & Effectiveness
Reduced IT Costs

Page 3

ST Key Terms

Change : The addition, modification or removal of anything that could have an effect on
IT Service; scope should include all IT services, Configuration Items, Processes,
documentation, etc

Configuration Item (CI) : Any component that needs to be managed in order to deliver
an IT service

Build : The activity of assembling a number of Configuration Items to create part of an

IT service. It may also refer to a Release

Configuration Management DataBase (CMDB): Configuration Management identifies

the various components of IT infrastructure as Configuration Items (CIs). All the
information regarding CIs are help within the Configuration Management Database
(CMDB)

Configuration Management System (CMS) : A set of tools and databases that are
used to manage an It Service Providers configuration data

Definitive Media Library (DML) : One or more locations in which the definite and
approved versions of all software Configuration Items are securely stored

Page 4

ST Key Terms

Release : A collection of hardware, software, documentation, process or other

components required to implement one or more approved Changes to IT
Services

Release Unit : Components of an IT service that are normally released

together.

Service Knowledge Management System (SKMS) : A set of tools and

databases that are used to manage knowledge and information which
includes the Configuration Management System.

Transition : A change in state, corresponding to a movement of an IT service

or other Configuration Item from one Lifecycle status to the next.

Validation : An activity that ensures a new or changed IT service, process,

plan or other deliverable meets the needs of the business.

Page 5

ST Purpose, Goals & Objectives

How to introduce new services ( or change the existing services) with

appropriate balance of :
Speed
Cost
Safety
Focus on customer expectations and requirements

Page 6

ST - Activities

Two specific activities that are important to Service Transition:

Organizational and stakeholder Change:
Reflecting the holistic nature of change that Service Transition must be based on,
organizations do not transform their IT service by only changing the IT services.

Communications:
Service Transition must take on communication piece to ensure that the business, the end
user community and the IT staff are all aware of the services available, why they are
important, how they interrelate with and impact other services, and how they are supported.

Page 7

ST - Processes

Transition Planning & Support

Change Management

Service Asset & Configuration Management

Release & Deployment

Service Validation & Testing

Evaluation

Knowledge Management

Page 8

Transition Planning & Support Management

Purpose :
Plans and coordinates the resources to move a new or changed service into
production within the predicted cost, quality and time estimates.

Goal :
Manage the planning & coordination of resource to meet requirements.

Objectives :
Ensure adoption of a common framework for making changes.

Page 9

KPIs - Transition Planning & Support Management

Page 10

Change Management
Goal

To ensure that standardized methods and procedures are used for efficient
and prompt handling of all Changes, in order to minimize the impact of
Change-related Incidents

Benefits

Reduction in incidents and problems caused by unplanned change

Communication with appropriate parties before change occurs

Approval received from appropriate parties before change occurs

Time spent on preparation and prevention rather than fire fighting and
downtime

Page 11

Change Management Key Concepts

Change : Addition, modification or removal of anything that could have an

effect on IT Services

Request for Change (RFC) : A formal proposal for a change to be made.

Change Window : A regular, agreed time when changes may be

implemented with minimal impact on services.

Change Advisory Board (CAB) : A group of people that advices the

Change Manager in the assessment, prioritization and scheduling of
changes.

Page 12

Type of Requests and Changes

An organization needs to ensure that appropriate procedures and forms are available
to cover the anticipated requests.

Different types of changes may require different types of change requests.

Normal Changes
Changes to :
Service Portfolios, Service definitions
Project changes, User accesses, Operational Changes
Standard Changes
Change to a service or infrastructure for which the approach is preauthorized by Change Management.
Has an accepted and established procedure.
Emergency Changes
Changes that will have a high negative impact on the business.

Page 13

Standard Change

The crucial elements of a Standard Change are that:

Pre-authorized Changes.
The tasks are well-known, documented and low-risk tasks.
Authority has been in advance.
Budgetary approval is already set or is controller by the requestor

Example
Installing workstation software from an proved list.

Page 14

Change Management - Activities

Create & Record
Assess & Evaluate
Authorize Changes
Coordinate Changes
Review & Closure

Page 15

Change Create & Record

Accept Change
Validate Initiator
Validate Change

Record
Register Request for Change
Full History of Change

Logging
Unique Identification

Registered via CMS

Control Access
Editing
Viewing

Page 16

Change Access & Evalute

Impact
Business Operations
Infrastructure
Services

Effect on Change
If NOT implemented
IT, Business & Other Resources

Schedule
Change Schedule (CS)
Projected Service Outage (PSO)

Plans
Continuity, Capacity, Availability & Security

Page 17

Change Authorize Change

Formalized Acceptance
Accountability, Responsibility

Levels of Authorization
Considers
Type, Size & Risk

Organizational Approach
Hierarchical
Flattened

Acceptance Criteria
Anticipated Business Risk
Financial Implications
Scope of Change

Page 18

Change Management Authorizing Change

Escalations, RFCs, Issues

Decisions, Directions

Business
Executives

IT
Manageme
nt Board

Change Advisory
Board

Local Authorization

High Cost/Risk

Level 1

Impact on
Multiple service
or divisions

Level 2

Level 3

Impact only on
Local or
service group

Level 4

Standard
Changes

Page 19

Change Advisory Board (CAB)

The Change Advisory Board (CAB) delivers support to the Change Management
team by
approving requested changes and
assisting in the assessment and prioritization of changes.

Generally made up of IT and Business representatives that include

Change Manager
User managers and groups
Technical experts
Possible third parties and customers (if required)

CAB is responsible for oversight of all changes in the production environment

CAB is tasked with reviewing and prioritizing requested changes, monitoring the
change process and providing managerial feedback

Emergency Change Advisory Board (ECAB): It is a subset of the CAB that considers
a RFC tagged as an Emergency Change.

Page 20

Change Coordinate Change

Handoff to Change Builder(s)

Formal Tracking
Work Orders

Coordination Responsibility For

Scheduled Delivery of Change
Remediation Procedure development
Quality Assurance Conformance

Page 21

Change Review & Closure

Post Implementation Review

Technical
Incident
Problems
Known Errors

Business

Requirements
Desired Outcome
No Undesirable Effects
Time & Cost of Delivery

Follow Up if Required
Closure if Successful

Page 22

Change Management The 7 Rs

Who RAISED the change?

What is the REASON for the change?

What is the RETURN required from the Change?

What are the RISKS involved with the change?

What RESOURCES are required to deliver the change?

Who is RESPONSIBLE for build, test & implementations of the change?

What is the RELATIONSHIP between this change and other changes?

Page 23

Change Management Measures & Outcomes

Measures link to business goals, cost, service availability, and

reliability
Percentage reduction in unauthorized changes
Volume of change
Frequency of change
by service
By business area

Ratio of accepted to rejected change requests

Time to execute a change.

Page 24

Change Management - Challenges

Major IT Cultural Shift

Perceived as Bureaucratic
Siloed Technical Functional Areas
Organizational Behavioral Change

Establishment of the New Normal

Attempts to Bypass
Changes Only Made via Change Management

Vendor/Contractor Compliance

Page 25

Review and Close Change

Changer Review
Meets objectives
Users, Customers are happy
Side effects
Resources consumption
Time and Cost

Page 26

Service Asset & Configuration Management (SACM)

Purpose:
Establish control over the physical IT infrastructure

Goal :
Document the content and the context of the IT infrastructure

Objective :
Ensure all of the CIs are authorized and under a single processes.

Page 27

SACM Key Concepts

Asset
Any component of a business process
Process (Change Management)
Organization (Experience, Reports)
People, Infomration, Applications, Infrastructure
Financial Capital

Configuration Item
Any asset being a service component, or other item under control of
Configuration Management

Page 28

SACM Configuration Management System (CMS)

System used to manage the information under SACM

Details of all the component of IT Infrastructure
Maintain relationships
Configuration Management Database (CMDB)
Automated tools

Page 29

Configuration Management System (CMS)

The CMS is the heart of Service Asset and Configuration Management

The CMS maintains one or more CMDBs, and each CMDB stores attributes of CIs, and
relationships with other CIs.

The CMS also maintains several physical libraries, such as the Definite Media Library
(DML) for the secure storage of CIs. Although this is a physical library, the CMS
logically represent its content.

Page 30

Configuration Management DataBase (CMDB)

Details about CIs are stored in the Configuration Management DataBase

(CMDB) from which queries about the IT Infrastructure can be answered

The details of a CI that are mentioned in a CMDB include :

Unique Identifier
Attributes
Status
History
Category
Relationship

(service tag)
(supplier, price)
(ordered, testing, production, archived)
(past incidents, applied changes)
(hardware, software)
(is connected to, is a part of)

The scope of the Configuration Management database is defined by the area of

responsibility of the IT organization

The level of detail is defined by the need for information of the IT management
processes, the control of the information and the costs and benefits of a CMDB

Page 31

CMDB & CMS

CMDB is a database only, while the CMS also includes tools

CMS maintains one or more CMDBs

CMS is used by all IT Service Management processes

CMS Components

Secure Libraries and Secure Stores

Definitive Media Library (DML)
Configuration baseline
Snapshot

Page 32

Release & Deployment Management

Purpose :
Ensure the structured release and deployment of IT Services

Goal :
Deploy release into production & establish the effective use of the service.

Objective :
Project the line environment through the use of formal procedures.

Page 33

Release & Deployment Management

Release & Deployment Management ensures well-planned, cost-effective and

properly implemented IT Service. It helps balance the customers demand for
change and IT stability.

Release and Deployment Management, deploys change into the live

environment, along with responsibility for quality control during development
and implementation.

It provides a clear plan that guides release activities with minimal unpredicted
impact to live services.

Page 34

Release and Deployment - Concepts

Release
A collection of hardware, software, documentation, processes or other components
required to implement one or more approved changes to IT services.

Release Unit
Components of an IT Service that are normally released together

Release Package / release Design

One or more release units to upgrade from as-is situation to to-be situation

Page 35

Release and Deployment Releases Approaches

Big Bang versus Phased approach

Big Bang: The new or changed service is deployed to all user areas in one
operation. This will often be used when introducing an Application change and
consistency of service across the organization is considered important.
Phased : The service is deployed to a part of the user base initially, and then this
operation is repeated for subsequent parts of the user base via scheduled rollout
plan.

Push versus Pull deployment

A push approach is used where the service component is deployed from the centre
and pushed out to the target locations.
A pull approach is used for software releases where the software is made available
in a central location but users are free to pull the software down to their own
locations at a time of their choosing or when user workstation restarts.

Automation versus Manual deployments

Automation will help to ensure repeatability and consistency

Page 36

Release And Deployment Management - Roles

Release and Deployment Manager

Responsible for planning, design, build, configuration and testing of all software and
hardware to create the release package for the designated service

Other roles
Release Packaging and Build Manager
Deployment Staff
Early Life Support Staff

Page 37

Definite Media Library

The Definite Media Library (DML), maintained by Configuration Management,

provides a secure repository for the definitive versions of the software the
Release & Deployment Activities will use to complete its activities.

It stores master copies of versions that have passed quality assurance

checks.

Only authorized media should be accepted into DML, strictly controlled by

SACM.

Page 38

Release & Deployment Measures & Outcomes

Maintain integrity of release package through transition activities and

ensure recording in CMS

Comprehensive and clear release deployment plans with minimal

unpredicted impact.

Reduction in number of discrepancies

Reduced resources and cost

Reduced incidents against the service.

Page 39

Definite Media Library

Page 40

Service Validation Management

Purpose:
Provide for the Structured validation & testing of IT Service

Goal :
Assure IT Service value is achieved for the benefit of the customer.

Objectives
Ensure the IT Service delivers the expected outcomes & value.

Page 41

Service Validation Management

Service Testing and Validation establishes confidence that a new or changes

service will deliver the value and outcomes expected.

Service Testing and Validation provides a structured validation and testing

process that delivers quality assurance that the Service Design and release is
fit for purpose and fit for use.

Page 42

The Service V Model

The Service V model represent the different configuration levels to be built

and tested to deliver a service capability.

The left-hand side represents the specification of the service requirements

down to the detailed service design.

The right-hand side focuses on the validation activities that are performed
against the specifications designed on the left-hand side.

The V model approach is traditionally associated with the waterfall lifecycle,

just as applicable to other lifecycle including iterative lifecycle, such as
prototyping, RAD approaches.

Page 43

The Service V Model

Represents the different configuration levels to be built and tested to
deliver a service capability

Page 44

The Service V Model

Page 45

Evaluation

Purpose:
Provide consistent means of determining the performance of a service

Goal :
Set stakeholder & provide accurate information

Objectives :
Evaluate the indented effects of a service change.

Page 46

Evaluation Model

Evaluation provides an overarching view of Service Transition.

Some common evaluations are:

Service Design:
Release and deployment
Acceptance

Page 47

Knowledge Management

Purpose:
Ensure the right knowledge at the right time place.

Goal :
Improve quality of management decisions.

Objective :
Ensure a clear and common understanding value of IT Services.

Page 48

Knowledge Management

Knowledge Management ensures that availability and quality of

knowledge assists in the direct support of IT Services across the
entire lifecycle.

Page 49

DIKW Model

Page 50

Service Knowledge Management System (SKMS)

SKMS is a broader concept that covers a much wider base of

knowledge, for example :
The experience of staff
Records of peripheral matters ( e.g., weather, user numbers and behavior,
organizations performance figures)
Supplier and partner requirements, abilities and expectations
Typical and anticipated users skill levels.

Page 51

Service Knowledge Management System (SKMS)

Information, in the form of

knowledge, to base decisions
on.
Consists of:
Staff experiences
Peripheral records
Supplier / Partner information
Requirements
Abilities
Expectations
User skill levels

Page 52

Service Knowledge Management System (SKMS)

Page 53

Questions

Questions

Page 54