Purpose, Objectives and Scope of Service Transition

All stakeholders need to be considered in the transition planning to ensure customers

satisfaction of the service
Provide a consistent and managed approach to reduce risks and enhance efficiency and
effectiveness of service introduction

Purpose of Service Transition

The purpose of Service Transition is to ensure that the agreed services are now delivered
from service design to service operation effectively (deployment)

Objectives of Service Transition

Plan and manage changes to services (either introducing new or retiring existing services)
and to deploy the new services successfully to support business objectives while ensuring
the integrity of all existing services
Ensure the service can be operated and supported according to the service design
Manage the risks associated
Set the expectations of the business with testing on the performance
Provide knowledge and info of the service / service assets to relevant people to ensure
smooth operation

Scope of Service Transition

Provide guidance on the development and improvement of the required capabilities
Provide guidance on service transition between internal and external service providers
including relationship between strategy, design and transition (also considers service
retirement and transfer of services between service providers)
Provide guidance on management of transition for the coordination of all activities involved
(among different projects)
Communicate with all parties concerned

Processes of Service Transition

Knowledge Management
Transition Planning and Support
Change Management
Service Asset and Configuration Management (SACM)
Release and Deployment Management
Service Validation and Testing (*not covered in ITIL v3 Foundation exam)
Evaluation (*not covered in ITIL v3 Foundation exam)

Change Management Process

[definition] A change is the addition, modification or removal of anything that could have
an effect on IT services

 Change requests are submitted as Requests for Change (RFC), the degree of formality of
the RFC depends on the extent of the change
Change Records are to be used to capture the details of the lifecycle of the changes making
references to the configuration items affected (stored in configuration management system),
one change record for each individual change
No change should be approved without a back-out or remediation plan (to restore the initial
configuration)
[definition] Remediations are actions taken to recover after a failed change or release.
Remediation may include back-out, invocation of service continuity plans, or other actions
designed to enable the business process to continue.
Purpose: to control the lifecycle of all changes, enabling beneficial changes to be made
with minimum disruption to IT services.
uncontrolled changes might cause a surge in incidents
to consider all aspects (intended and unintended) a change may bring
Objectives
to keep abreast of and support the changes in the business environment (by reducing
incidents, disruption and rework)
to ensure that changes are recorded and evaluated, and that authorized changes are
prioritized, planned, tested, implemented, documented and reviewed in a controlled
manner as recorded in the configuration management system (CMS)
to optimize risk (balance between risk of doing and risk of not doing)
to control the assets of the infrastructure
Scope
cover everything from configuration items (servers, infrastructure, documentation,
services and configuration), management systems and tools, processes, metrics,
solution and architecture from design strategy to continual service management
excluding organization and business changes, and minor operational changes
manage all changes in a controlled manner on all levels (strategic, tactical and
operational) by making reference to the service portfolio
Change management is not responsible for the coordination of processes for the
successful implementation of projects; this will be handled through the planning and
transition support process.
Output
change schedule (CS, also an input)
projected change outage (PSO)
remediation plan
ITIL recommends the use of a change model or change process model to handle changes
in a consistent manner:
Steps for handling the change
The order in which the steps should be carried out, including any dependencies
Responsibilities throughout the process

 Timescales
Escalation procedures
Types of Changes
Standard Change a change to a service or other configuration item, which has a
preauthorized approach to its execution, well understood for risks, follow a
standard procedure with a predefined trigger
e.g. installation of a new computer
RFC not required, logged as service requests
enhance the effectiveness of change management
records need to be reviewed regularly
Emergency Change a change in response to or in order to prevent a businesscritical error
need to have a clear definition of the authority levels associated with
emergency changes (e.g. emergency change advisory board (ECAB)
may not have enough time for extensive testing
documentation may need to be updated afterwards
risk of failure is high
Normal Change
Typical flow (all information stored in SKMS):
Create the request for change (RFC) -> trigger the creation of the
change record
Review the RFC sufficient information, appropriate budget, is it
practical by the change manager
Assess and evaluate the change (after approval of RFC) need
Change Proposal?
Who raised the change?
What is the reason for the change?
What is the return required from the change?
What are the risks involved in the change?
What resources are required to deliver the change?
Who is responsible for the build, test, and implementation of
the change?
What is the relationship between this change and other
changes?
Authorize the change by a change authority usually CAB, update the
change schedule and projected service outage (PSO) with a
remediation plan
Plan updates build and test
Coordinate change implementation to ensure changes are deployed
as scheduled

 Review and close the change pass the acceptance criteria: success ->
close the change record; failure -> remediation plan or workaround
Change Proposal: submitted for major change that involves significant cost,
risk or organizational impact, before the new/change service is chartered,
normally created by Service Portfolio management. Change proposals include
a high-level description of the change, a detailed business case (including risk
assessment) and schedule for design and implementation. When authorized,
the service is chartered.
RFC should specify the details of the change, including the risks, benefits,
costs, and proposed schedule for implementation, depending on guidelines.
Change Advisory Board (CAB)
determine whether normal changes should be authorized
include people from business and technical sides, stakeholders to reflect a balanced
view
Change management process is an trigger for change evaluation process
Change management involve the assessment of a large number of other processes (e.g.
capacity, IT service continuity, security, etc.)

/////////

Transition Planning and Support Process

a key process for Service Transition
covers the interface between service transition, project management and business
engagement
needs to work with
Technical Management Function: provides resources for managing the
infrastructure
Application Management Function: provides resources for managing applications
Purpose: to plan and coordinate the transition activities across different processes at a
high level with coordination of resources and capabilities (availability and schedule)
Objectives
plan, coordinate and monitor resources and various parties for the transition and
associated activities within the budget and timeframe
establish new requirements for management information systems and tools and other
management systems
ensure repeatable processes (a framework) are adopted during transition of different
services
identify and manage risks according to organization risk management framework

 Scope
plan future transition needs
maintenance of policies and standards
provide transition guidance and plan for achieving business goals
coordinate and prioritize resources for multiple transition needs
review and improvement current process and plan for future transition needs
Not including the detailed plans for building, testing and deployment

Service Asset and Configuration Management Process

control over the assets under IT management in an efficient and effective manner
Purpose of SACM: to ensure the control of IT assets for services by having an accurate
record of the assets and their relationships and configuration
Objectives
ensure proper management of IT assets through identification, recording (with
historic data) and control (verification)
manage the integrity of configuration items (CIs) which are controlled by change
management
an item of infrastructure that is managed to deliver a service
all configuration items are service assets, but not vice versa (e.g. knowledge
of technician is asset but not configuration item)
create a configuration management system
holds all information about CIs and their relationship
may make use of automatic tools to capture the data
four layers: Presentation, knowledge processing, information integration, data
Scope
all configuration items (CIs)
identify and apply control to elements of the infrastructure that are to be
managed as service assets
baseline, maintain and control through change management all CIs with a
configuration management system (CMS) in configuration management
databases (CMDBs)
any interfaces with internal and external configuration items (e.g. shared assets), e.g.
license management
Activities
Management and planning
There is no standard template for determining the optimum approach for SACM. The
management team and Configuration Management should decide what level of
Configuration Management is required for the selected service or project that is
delivering changes and how this level will be achieved. This is documented in a
Configuration Management Plan. Often there will be a Configuration Management

Plan for a project, service or groups of services, e.g. network services. These plans
define the specific Configuration Management activities within the context of the
overarching Service Asset and Configuration Management strategy.
Configuration identification
Define and document criteria for selecting configuration items and the
components that compose them
Select the configuration items and the components that compose them based
on documented criteria
Assign unique identifiers to configuration items
Specify the relevant attributes of each configuration item
Specify when each configuration item is placed under Configuration
Management
Identify the owner responsible for each configuration item.
Configuration control
Configuration control ensures that there are adequate control mechanisms over CIs
while maintaining a record of changes to CIs, versions, location and
custodianship/ownership. Without control of the physical or electronic assets and
components, the configuration data and information there will be a mismatch with
the physical world. No CI should be added, modified, replaced or removed without
an appropriate controlling documentation or procedure being followed.
Status accounting and reporting
Each asset or CI will have one or more discrete states through which it can progress.
The significance of each state should be defined in terms of what use can be made of
the asset or CI in that state. There will typically be a range of states relevant to the
individual asset or CIs. A simple example of a lifecycle is: development or
draft approved withdrawn. The way CIs move from one state to another should
be defined, for example, an application release may be registered, accepted, installed
or withdrawn.
Verification and audit
The activities include a series of reviews or audits to:
Ensure there is conformity between the documented baselines (for example,
agreements, interface control documents) and the actual business environment
to which they refer
Verify the physical existence of CIs in the organization or in the DML and
spares stores, the functional and operational characteristics of CIs and to
check that the records in the CMS match the physical infrastructure
Check that release and configuration documentation is present before making
a release
Definition of Terms
Service Asset any resource or capability that could contribute to the delivery of a
service

 Configuration Item a service asset that needs to be managed in order to deliver an

IT service
Configuration Record a set of attributes and relationships about a CI
in configuration management databases (CMDBs)
Configuration Model a model of the services, assets, and infrastructure of each
configuration item and their relationships to each other for planning and decision use
One of the most crucial factors is to define the level of detail required to manage
configuration items successfully
Categories of CI suggested by ITIL include:
Service Lifecycle CIs documents that provide information on the plans and
requirements for the services, including costs and benefits
Service CIs service capability and service resource assets; service model, package,
etc.
Organization CIs documentation relating to organizational policies or standards
Internal CIs internal assets such as software or hardware
External CIs external customer requirements and agreements
Interface CIs documentation relating to end-to-end service provision across
multiple service providers
Definitive Media Library (DML)
consists of a number of software libraries or file storage areas (physical or
electronic), which are managed and kept separate from the live, test, or development
storage areas
stores master copies of versions that have passed quality assurance checks
requires policies for retention, security, backup, archive, etc.
Definitive Spares
spare components and assemblies that are maintained at the same level as the
comparative systems within the controlled test or live environment
Configuration Baseline
the configuration of a service, product or infrastructure that has been formally
reviewed and agreed on
Snapshot
the current state of a configuration item or an environment
snapshots are recorded in the CMS and remain as fixed historical records

Knowledge Management Process

control over the assets IT manages in an efficient and effective manner
Purpose: to ensure timely retrieval of relevant ideas, perspectives, experience, and
information to the correct audience for informed decision making (facilitate reuse of
knowledge)
Objectives

 improve decision making by providing correct and timely information

reuse of knowledge for efficiency and effectiveness
maintain a service knowledge management system (SMKS)
[definition] SKMS is a set of tools and databases that is used to manage
knowledge, information and data. The SKMS includes the configuration
management system, as well as other databases and information systems. The
SKMS includes tools for collecting, storing, managing, updating, analyzing
and presenting all the knowledge, information and data that an IT service
provider will need to manage the full lifecycle of IT services.
manage the data and information
includes sources such as the service portfolio, definitive media library,
information in SLAs, OLAs and contracts, budgets, cost models, and service
improvement plans, error information, etc.
gather, store, analyze and share knowledge
Scope
the management of data and information across the service management processes
share of information with customers and users
NOT including the detailed collection and maintenance (in Service Asset and
Configuration Management)
Data-Information-Knowledge-Wisdom Structure (DIKW)
data raw facts, e.g. date and time of incidents
information data in context, e.g. average time between incidents
knowledge apply experience (the tacit experiences, ideas, insights, values and
judgements of individuals), context, and understanding to the information analysis,
e.g. average time between incidents increased by 10% when a new service is
introduced
wisdom apply the knowledge with common-sense judgement / contextual
awareness for improvement or better results, e.g. the increase in average time
between incidents is due to poor documentation

Release and Deployment Management Process

Purpose: the build, test, and deployment of the release is successfully delivered with
minimal adverse impact to business and other services
to ensure the process is planned, scheduled and controlled
Objectives
to define and agree on deployment plan with stakeholders
create and test release packages
maintain the integrity of the release packages (store in definitive media library)
ensure the new / changed services meets utility and warranty needs
capture lessons learned

 ensure knowledge transfer to users and IT staff (support and operation)

Scope
the processes, systems, and functions required to deliver a release into production
build, ensure testing and deploy the release to the utility and warranty requirements
handover of service to operation teams
manage all CIs and things related to the release
Release Policy
should be defined for the release of each service / group of service
specify the types of releases that need to be controlled e.g. major release, minor
release, emergency release
outlines the roles and responsibilities, use of definitive media library, customer
expectation, acceptance criteria, authorization requirements, criteria for handover,
etc.
Four Phases of Release and Deployment
Release and Deployment Planning begins with planning a release and ends with
change authorization to create the release
Release Build and Test the release package is built, tested, and checked into the
DML, end with authorization to include the package in DML
Deployment deploy the package from DML and handover of service to operation,
early life support might be needed for faster response and knowledge transfer
Review and Close capture lessons learned and address issues
Big bang versus Phased
Big-bang option 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 approach 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 a scheduled
roll out plan. This will be the case in many scenarios such as in Retail Organizations
for new services being introduced into the stores environment in manageable phases.
Push and Pull
A push approach is used where the service component is deployed from the centre
and pushed out to the target locations. In terms of service deployment, delivering
updated service components to all users either in big-bang or phased form
constitutes push, since the new or changed service is delivered into the users
environment at a time not of their choosing.
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 location at
a time of their choosing or when a user workstation restarts. The use of pull
updating a release over the internet has made this concept significantly more
pervasive. A good example is virus signature updates, which are typically pulled

down to update PCs and Servers when it best suits the customer, however at times of
extreme virus risk this may be.
Automation versus Manual
Whether by automation or other means, the mechanisms to release and deploy the
service components should be established in the release design phase and tested in
the build and test stages of the new or changed service. Automation will help to
ensure repeatability and consistency. The time required to provide a well designed
and efficient automated mechanism may not always be available or viable. If a
manual mechanism is used it is important to monitor and measure the impact of
many repeated manual activities as they are likely to be inefficient and error prone.
Too many manual activities will slow down the release team and create
resource/capacity issues that affect the service levels.

Other Processes of the Service Transition

Service Validation and Testing Process: to ensure the service will perform as specified and
be designed through service strategy and service design through testing and validation with
customers
Change Evaluation Process: to check the predicted performance against the actual
performance achieved by the new or changed service