Service Transition establishes the services as specified
in the Service Design phase, based on the customer and
stakeholder requirements. A Service Transition is effective
and efficient if the transition delivers what the business
requested within the limitations in terms of money and
other necessary resources.
5.1 Purpose of Service
Transition
The Purpose of Service Transition is to ensure that
new, modified or retired services meet the expectations
of the business as documented in the service strategy
and service design stages of the lifecycle
5.2 Objectives of
Service Transition
1) 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
2) Ensure the service can be operated and supported
according to the service design
3) Manage the risks associated
4) Set the expectations of the business with testing
on the performance
5) Provide knowledge and info of the service / service
assets to relevant people to ensure smooth operation
5.3 Scope of Service
Transition
1) Provides guidance for the development and improvement
of capabilities for transitioning new and changed services
into supported environments, including release planning,
building, testing, evaluation and deployment.
2) Considers service retirement, transfer of services
between service providers
3) Focuses on how to ensure that the requirements
from service strategy, developed in service design,
are effectively realized in service operation while
controlling the risks of failure and subsequent disruption.
4) Includes the transition of changes in the service
provider's service management capabilities that will
impact on the ways of working, the organization, people,
projects and third parties involved in service management.
5.4 Value to Business
Service Transitions creates value for the business
by improving:
1) The ability to adapt quickly to new requirements.
2) The success rate of changes and releases for an
organization.
3) The predictions of service levels and warranties
for new and changed services.
4) Confidence in the degree of compliance with the
organization requirements during change.
5) Clarity of plans so the business can link their
organization change plans to transition plans.
5.5 Basic Concepts
in Service Transition Processes
1) Service knowledge management system (SKMS): It
is a set of tools and databases that is used to manage
knowledge, information and data. The SKMS includes the
Configuration Management System (CMS), 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.
2) Configuration item (CI): A Configuration Item
(CI) is an asset, service component or other item which
is, or will be, under the control of Configuration Management.
CIs may vary widely in complexity, size and type, ranging
from an entire service or system including all hardware,
software, documentation and support staff to a single
software module or a minor hardware component.
3) Configuration management system: A set of tools,
data and information that is used to support service
asset and configuration management.
4) Definitive media library (DML): Is defined as
one or more locations that securely store the definitive
and approved versions of all software CIs.
5) Change: The addition, modification or removal
of anything that could have an effect on IT services.
The scope should include changes to all architectures,
processes, tools, metrics and documentation, as well
as changes to IT services and other configuration items.
6) Change types
- Standard Change: A pre-approved Change that
is low Risk, relatively common and follows a Procedure
or Work Instruction. For example password reset
or provision of standard equipment to a new employee.
RFCs are not required to implement a Standard Change,
and they are logged and tracked using a different
mechanism, such as a Service Request.
- Emergency Change: A Change that must be introduced
as soon as possible. For example to resolve a Major
Incident or implement a Security patch.
- The Change Management Process will normally
have a specific Procedure for handling Emergency
Changes.
- Normal Change: Any service change that is not
a standard change or an emergency change. There
are three types of normal changes:
- Minor change - authorized by change management
staff directly.
- Significant change- requires advice from
change advisory board (CAB)
- Major change -requires change proposal,
business management approval
5. Service Transition
5.6.1 Change Management
Process
Change Management Process is responsible for controlling
the lifecycle of all changes, enabling beneficial changes
to be made with minimum disruption to IT services.
A) Purpose of Change Management Process
Purpose of change management process is to control
the lifecycle of all changes, enabling beneficial changes
to be made with minimum disruption to IT services.
B) Objectives of Change Management Process
- Ensure that standardized methods and procedures
are used for efficient and prompt handling of all
changes, in order to minimize the impact of change
related Incidents upon service quality, and consequently
to improve the day to day operations of the organization.
- Respond to changing business requirements.
- Minimize impact/risk of implementing changes.
- Ensure all changes are approved at the appropriate
level with the business and IT.
- Implement changes successfully.
- Implement changes in times that meet business
needs.
- Use standard processes to record all changes.
C) Scope of Change Management Process
- 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.
D) Types of change request
There are three service change types they are: Standard,
Emergency and Normal.
1) Standard Change: A pre-authorized change that
is low risk, relatively common and follows a procedure
or work instruction.
2) Emergency Change: A change that must be implemented
as soon as possible, for example to resolve a major
incident or implement a security patch.
3) Normal Change: Any service change that is not
a standard change or an emergency change. Normal changes
are often categorized into three types:
- Minor change - authorized by change management
staff directly.
- Significant change- requires advice from change
advisory board (CAB)
- Major change-requires change proposal, business
management approval
E) Change models
Change model is a repeatable way of dealing with
a particular category of change. Change Models defines
specific agreed steps that will be followed for a change
of this category. Change models may be very complex
with many steps that require authorization (e.g. major
software release) or may be very simple with no requirement
for authorization (e.g. password reset).
Change models include:
- Steps to handle the change, including issues
and unexpected events.
- Order steps should be taken, with dependences
or co-processing defined
- Responsibilities - who should do what?
- Timescales and thresholds for completion of
the actions.
- Escalation procedures - who should be contacted
and when
F) Remediation Planning
Remediation is an action 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.
G) Change Advisory Board and Emergency Change Advisory
Board
Change Advisory Board:
- A group of people that supports the assessment,
prioritization, authorization and scheduling of
changes.
- A change advisory board is usually made up of
representatives from: all areas within the IT service
provider; the business; and third parties such as
suppliers.
Emergency Change Advisory Board
- A subgroup of the change advisory board that
makes decisions about emergency changes.
- Membership may be decided at the time a meeting
is called, and depends on the nature of the emergency
change.
H) Lifecycle of a Normal change
The Change Management Process consists of seven high-level
activities specifically developed to manage the life
cycle of change requests. Typical activities in managing
individual changes are:
1) Create and record the Request for Change (RFC).
2) Review the RFC
- Filter changes (e.g. incomplete or wrongly routed
changes)
3) Assess and evaluate the change
- Establish the appropriate level of change authority
- Establish relevant areas of interest (i.e. who
should be involved in the CAB)
- Evaluate justification, impact, cost, benefits,
risks, and predicted performance
- Submit a request for evaluation to initiate
activity from the change evaluation
4) Authorize the change
- Obtain authorization/rejection
- Communicate the decision with all stakeholders,
in particular the RFC initiator
5) Plan updates
6) Coordinate change implementation
7) Review and close change
- Collate the change documentation, e.g. baselines
and evaluation reports
- Review the change(s) and change documentation
- Ensure lessons learned details are recorded
in the SKMS
- Close the change document when all actions are
completed
5.6.2 Release and
Deployment Management Process
Release and Deployment management is a process responsible
for planning, scheduling and controlling the build,
test and deployment of releases, and for delivering
new functionality required by the business while protecting
the integrity of existing services.
In the Release and Deployment management process
different considerations apply in respect of the way
in which the release is deployed. The most frequently
occurring options for the rollout of releases are: "big
bang" versus phased, "push and pull", automated or manual.
A) Purpose of Release and Deployment Management Process
- The purpose is to ensure that consistent and
integral release packages are deployed in line with
agreed policy and with plans agreed with the customers
and stakeholders, and that this takes place under
full and effective control.
- Any associated business and business process
changes, including training and skills transfer,
must be managed to take place in a timescale that
is aligned with the release timetable.
B) Objectives of Release and Deployment Management
Process
- The objective of release and deployment management
is to build, test and deliver the capability to
provide the services specified by service design.
- to define and agree on deployment plan with
stakeholders
- Create and test release packages
- Maintain the integrity of the release packages
and ensure that they are secured in DML.
- Ensure the new / changed services meets utility
and warranty needs
- Capture lessons learned
- Ensure that skills and knowledge are transferred
to operations and support staff
C) Scope of Release and Deployment Management Process
- 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
- 4) Manage all CIs and things related to the
release.
D) Four phases of Release and Deployment Management
Process
The process activities of release and deployment
management are:
- 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 - experience and feedback are
captured, performance targets, achievements are
reviewed and lessons are learned
5.6.3 Knowledge Management
Process
Knowledge Management is a process responsible for
sharing perspectives, ideas, experience and information,
and for ensuring that these are available in the right
place and at the right time. The knowledge management
process enables informed decisions, and improves efficiency
by reducing the need to rediscover knowledge.
A) Purpose of Knowledge Management Process
The purpose of Knowledge Management is to ensure
that the right person has the right knowledge at the
right time to enable them to make sensible decisions
about courses of action.
B) Objectives of Knowledge Management Process
- Improve the quality of management decision-making
by ensuring that reliable and secure knowledge,
information and data is available throughout the
service lifecycle
- Enable the service provider to be more efficient
and improve quality of service, increase satisfaction
and reduce the cost of service by reducing the need
to rediscover knowledge
- Ensure staff have a clear and common understanding
of the value their services provide to customers
and ways in which benefits are realized from use
of services
- Maintain a service knowledge management system
(SKMS) that provides controlled access to knowledge,
information and data that is appropriate for each
audience
- Gather, analyze, store, share, use and maintain
knowledge, information and data throughout the service
provider organization
C) Scope of Knowledge Management Process
- 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)
D) Data-to-Information-to-Knowledge-to-Wisdom (DIKW)
structure
- Data -- discrete facts about Events. Most organizations
capture significant amounts of data in highly structured
databases such as service management and service
asset and configuration management tools/systems
and databases
- Information - comes from providing context to
data. Information is typically stored in semi-structured
content such as documents, email and multimedia.
The key knowledge management activity around information
is managing the content in a way that makes it easy
to capture, query, find, re-use and learn from experiences
so that mistakes are not repeated and work is not
duplicated.
- Knowledge - includes tacit experiences, ideas,
insights, values, and judgments of individuals.
People gain knowledge both from their own and from
their peers expertise, as well as from the analysis
of information
- Wisdom - makes use of knowledge to create value
through correct and well-informed decisions. Wisdom
involves having the application and contextual awareness
to provide strong common-sense judgment.
Knowledge Management is typically displayed within
the Data-to-Information-to-Knowledge-to Wisdom (DIKW)
structure.
E) Service knowledge Management System (SKMS)
SKMS is a set of tools and databases that are used
to manage knowledge and information. The SMKS includes
the Configuration Management System, as well as other
tools and databases. The SKMS stores, manages, updates
and presents all information that an IT Service Provider
needs to manage the full Lifecycle of IT Services.
One very important part of the SKMS is the configuration
management system (CMS). The CMS describes the attributes
and relationships of configuration items, many of which
are themselves knowledge, information or data assets
stored in the SKMS.