Service Transition

The Service Transition book covers the development and improvement of
capabilities for transitioning new and changed services into the live production /
operating environment.
11 Transition Planning & Support

12 Change Management

Service Asset &
13
Configuration Management (SACM)

14 Release & Deployment Management

15 Service Validation & Testing

16 Change Evaluation

17 Knowledge Management
2

Created by PelegIT, Ltd. – www.pelegit.com, - All Rights Reserved

Purpose of Service Transition

Ensure new, modified or retired services meet the
expectations of the business as documented in the
Service Strategy and Service Design stages of the
lifecycle.


• Increased success rate of changes and
releases

• More accurate estimation of service
levels and warranties

• Leas variation of costs and other
resources against those estimated in
the budgets.


• One of the more complex tasks of
knowledge management is ensuring that
more then simply capturing desecrate facts
about various elements of the organization
and IT infrastructure.


Knowledge Management
Context

Data
Understanding

Data
Data is a set of discreet facts. Most organizations
capture significant amounts of data every day.

© Crown copyright 2011. Reproduced under license from OGC. - Created by PelegIT, Ltd. – www.pelegit.com, - All Rights Reserved

Context

Information
Who, what,
when, where?

Data
Understanding

Information
Information comes from providing context to the
data. This usually requires capturing various sources of
data and applying some meaning or relevance to the
set of facts.


Context

knowledge
How?

Information
Who, what,
when, where?

Data
Understanding

Knowledge
Knowledge is composed of the experiences, ideas,
insights and judgments from individuals. This usually
requires the analysis of information, and is applied in
such a way to facilitate decision making.


Context

Wisdom
Why?

knowledge
How?

Information
Who, what,
when, where?

Data
Understanding

Wisdom
Wisdom gives the ultimate discernment of the
material and having the application and contextual
awareness to provide a strong sense of judgment. The
use of wisdom ultimately enables an organization to
direct it’s strategy and growth in competitive market
spaces.


Service Knowledge Management System

Decisions
Configuration Management System
(CMS)

Configuration
Management
Database (CMDB)

Known Error
Database (KEDB)


Service Knowledge Management
System (SKMS)
The complete set of integrated repositories that are
used to manage knowledge and information. The
SKMS stores, manages and presents all the
information that an IT service provider needs to
manage the full lifecycle of services.


(CMS)
The CMS contains configuration data; the CMS also
includes information about incidents, problems,
known errors, changes and releases.

It may also contain data about employees, suppliers,
location of business units, customers and users.


Configuration Management
Database (CMDB) & Known Error
Database (KEDB)
CMDB – stores configuration detail for IT
infrastructure.

KEDB – Created by Problem Management and is used
by Problem Management and Incident Management.


Service Asset and Configuration
Management (SACM)
Goal: support the agreed IT service provision by
managing, storing and providing information about
Configuration Items (CI’s) and Service Assets
throughout their service lifecycle.


Database (CMDB)
Captures data about CI and the relationships they
have between other CI’s.


CI


It is important to determine the
level detail which will be stored in
the CMDB for each CI.


Configuration Management Activities


Planning
• Defining the strategy, policy scope, objectives,
processes and procedures for SACM.
• Roles and responsibilities for staff and
stakeholders.
• Location of storage areas and libraries uses to hold
hardware, software and documentation
• CMDB Design
• CI Naming conventions
• Housekeeping including license management and
archiving CI


Identification
• Selection, Identification, labeling and registration
of CI’s.
• What CI’s are recorded, what are their attributes,
what relationships exist.
• Identification can take place for:
• Hardware/Software (including OS)
• Business Systems (Custom Built)
• Software Packages (off the shelf)
• Physical Databases (DB)
• Feeds between DB
• Software releases
• Documentation


Control
• When the CMDB is utilized to store or modify
configuration data.
• Only authorized and identifiable CI’s are recorded
from receipt to disposal.
• Control may be used during:
• Registration of new CI’s
• Updating of CI’s and Licenses
• Updates in relation to Request for Change (RFC)
and Change Management
• Updating after physical audits


Status Accounting
• Reporting of all current and historical data
concerned with each CI.
• Provides information on:
• Configuration Baselines
• Latest software item versions
• The person responsible for status change
• CI change, incident and problem history


Verification and Auditing
• Reviews to verify existence of CI’s
• Confirm CI’s are correctly recorded in the CMDB
• Audits should occur when:
• Before and after a major change
• Following a disaster recovery situation
• Response to unauthorized CI
• At regular intervals


Reporting
• Result of activities to CMDB
• Format will vary depending on organizational
needs.


Service Knowledge Management System Supplier & Contract
Management Information
System (SMIS)
CSI Register Configuration Management
System (CMS)
Support for
Service Portfolio decisions
Definitive Media
Library (DML)

Service Level Business Plans
Agreements (SLA)

Contracts & Operational Support for delivery
Budgets Level Agreements (OLA) of Services

Security Policy
(CMS)
Service Improvement
Plans

Configuration
Management DB Cost Models


The arrows to the right represent that fact that all
configuration items (CI) are described within the
configuration management system


Roles and Responsibilities
Service Asset Management
Management of service assets across the whole
lifecycle.
• Acquisitions to retirement
• Maintenance of asset inventory

Provide logical model of services, assets and
infrastructure by recording relationships.


Configuration Item (CI)
(ITIL Service Transition, ST)
Any component or other service asset that needs to be managed in order to deliver an IT
service. Information about each CI is recorded in a configuration record within the
Configuration Management System (CMS) and is maintained throughout it’s lifecycle
by Service Asset and Configuration Management (SACM).


Configuration Management System (CMS)
(ITIL Service Transition, ST) A

set of tools, data and information that is used to support service assets and
configuration management. The CMS is part of an overall service knowledge
management system (SKMS) and includes tools for
collecting, storing, managing, updating, analyzing and presenting data about all CI and
their relationships. The CMS may also include information about
incidents, problems, know errors, changes and releases. The CMS is maintained by
service asset and configuration management and is used by all IT service management
processes.


Service Asset and Configuration Management (SACM)

The process responsible for ensuring that the assets required to deliver services are
properly controlled, and that accurate and reliable information about those assets is
available when and where it is needed. This information includes details of how the
assets have been configured and the relationship between assets.


SKMS Some CI’s (such as
The CMS is part SLA or release
of the SKMS plans) are in the
SKMS
CMS

Configuration
records are stored
in CMDB’s in the
CMS

Other CI’s (such as
users and servers)
are outside the
SKMS


Service Knowledge Management System (SKMS)

Presentation Layer

Knowledge Possessing Layer

Information Integration Layer Schema Mapping, metadata
management, reconciliation,
extract, transform, mining
Integrated CMDB

Data Layer

Records in CMS or other External DB
Discovery, Collection, parts of SKMS
Audit
Other item sin SKMS


• The CMS holds all the information about a CI
within scope.
• Changes to every CI must be authorized by
change management and all updates must
include updates to relevant configuration
records.

• In some organizations authority to modify CI’s
within the SKMS is assigned to the
Configuration Librarian…responsible for
modifying configuration records in the CMS.


• The CMS maintains the relationship between all
service components and may also include records
for:

• Related Incidents
• Problems
• Know Errors
• Changes
• Releases


• The CMS may include data stored in several physical CMDB, which come
together at the information integration layer to form a integrated CMDB



Presentation Layer

Knowledge Possessing Layer

Data Layer


• Since the data in normally owned by other
business units, agreements will be needed by
other business units…agreements about what
data will be available and how it will be accessed
and maintained.

• This agreement will should be formally
documented in an OLA.


• Records used to support service management processes such as:

• Incident Records
• Problem Records
• Change Records
• Release Records
• Know Error Records

• Should be associated with the specific CI that they relate to.


CMS
Network
CMDB

Security
CMDB

Service Desk
Marketing
CMDB


Definitive Media Library

One or more locations in which the definitive and authorized versions of all software
configuration items are securely stored. The definitive media library may also contain
associated configuration items such as licenses and documentation. It is a single logical
storage area even if there are multiple physical storage locations. The DML is controlled
by services asset and configuration management and is recorded in the CMS.


Service Asset and Configuration Management (SACM)

The process responsible for ensuring that the assets required to deliver services are
properly controlled, and that accurate and reliable information about those assets is
available when and where it is needed. This information includes details of how the
assets have been configured and the relationship between assets.


DML CMS

CMDB

Information
about CI’s
Physical CI’s
Release Record

Electronic CI’s

Deploy new release
Test new release


The DML is the foundation for
release and deployment
management.


Options for release and deployment
Big Bang: New of changed service is deployed to ALL users in one operation.
Fast but has increased risk of negative impact for failed release.

Phased Approach: Partial deployment. Repeated to other areas as per schedule.
Can be slow and create tension between departments.

The Push Approach: Service is PUSHED to the target locations.
In terms of deployment either Big Bang or Phased use the pushed approach, since
the service may be delivered at a time not of the users choosing.

The Pull Approach: Software is made available in a secure location and users may
PULL it down into their system at a time of their choosing.

Automated: A automatic system delivers the release. This is often easily repeatable.

Manual: often error prone and very slow.


Release and Deployment Activities
Release policy & planning
Design & Develop or Order & Purchase

Build & Configure Release

Release Testing & Acceptance

Deployment Planning
Communication, Preparation & Training

Logistics, Delivery &
Installation


Release Planning
• Defining the Release controls
• Defining the Release Schedule
• Defining the resources, roles and responsibilities
required for the release


Design & Test
(Coordinates with other Service Design and Service Transition Processes)
• Produce release assembly & build instructions
• Create installation scripts
• Run test plans
• Develop back-out procedures
• Produce tested installation procedures


Rollout Planning
• Define timetable for distribution
• Identification of effects CI’s
• Defining communication plans
• Defining training plans
• Communication and trailing for:
• Users
• Support staff (including service desk)


Logistics, Distribution & Installation
1. Transfer financial assets
2. Transfer changes required for business/organization
3. Deploy processes and materials
4. Deploy Service Management Capabilities
5. Transfer Service
6. Deploy Service
7. Decommissioning and retiring of service
8. Remove redundant assets


Roles and Responsibilities
Release and Deployment Manager
• Drive effectiveness & efficiency process
• Manage release management team
• Liaise with Change & Configuration Management,
IT Platform Managers, Application developers etc.

Release and Deployment Management Team
• Manage DML
• Design, build, test and deploy releases
• Manage software management/distribution tools


Change

The addition, modification or removal of anything that could have an effect on IT
services. The scope should include changes to architectures, processes, tools, metrics
and documentation, as well as changes to IT services and other CI’s


Standard Change

A pre-authorized change that is LOW risk, relatively common and follows a procedure or
work instruction – for example a password reset or provision of standard equipment to a
new employee. Requests for Change (RFC) are not required to implement a standard
change, and are logged and tracked using a different mechanism, such as a service
request.


Normal Change

A change that is not an emergency change or standard change. Normal changes follow
defined steps of the change management process.


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.


Major Release

Normally contain large areas of new functionality some of which may eliminate temporary
fixes to problems.

A major upgrade or release usually supersedes all preceding minor upgrades, release
and emergency fixes.


Minor Release

Normally contain small enhancements and fixes, some of which may already have been
issued as emergency fixes.

A minor upgrade or release usually supersedes all preceding emergency fixes.


Emergency Release

Normally contain corrections to a small number of know errors, or sometimes an
enhancement to meet a high priority business requirement.


Known Error
(ITIL Service Operation, SO)

A problem that has a documented root cause and a workaround. Known errors are
created and managed throughout their lifecycle by problem management. Known errors
may also be identified by development and suppliers.


Change Advisory Board

A group of people that support the assessment, prioritization, authorization and
scheduling or 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.


Role
Create RFC
Change
Initiator

Change Proposal Change Record RFC
(Optional) Management
Requested

Activities assigned to
Change Review RFC
the role “change Management
management” may be Ready for evaluation
carried out by a change Asses and

Update Information in CMS
practitioner, a change evaluate change
authority or the change Change
management process Management Work Instruction
owner, depending on
organizational design. Authorize change
Change build and test Ready for decision
Authority
*Activities to Authorized
plan, create and deploy Coordinate change
releases are part of build and test*
release and deployment Change
management process Management Work Instruction
Authorize change
Change deployment Created
Authority

Coordinate change Scheduled
deployment
Change Work Instruction
Management Implemented
Review and close
change record
Closed

Important steps of change:
1) The RFC is logged
2) An initial review is performed to filter RFC’s
3) The RFC’s are assessed – this may involve the CAB or ECAB
4) This is authorized by the change manager
5) Work orders are issued for the build change (Carried out by another group)
6) Change management coordinates the work performed (with multiple check points)
7) The change is reviewed
8) The Change is closed


Change Management

Auth Auth Auth AuthAuth uth
A Auth
Authorize Authorize Authorize Authorize Post
release planning build and test Check-in to DML Deployment / implementation
Transfer / retirement review

Release and
Release build Review and
Deployment Deployment
and test test
Planning

Deployment

Transfer

Retirement


Change Proposal
Major changes that involve significant cost, risk and organizational
impact will usually be initiated through Service Portfolio
management process.

Change proposals are submitted to change management

Authorizing a change does not mean authorizing implementation.
Created by Service Change Management
Portfolio Management for authorization

Change Change
Proposal Proposal


Change Proposal Includes
High level descriptions (business outcomes to be supported &
UTILITY and WARRANTY to be provided. )

Full business case including:
• Risks
• Issues
• Alternatives
• Budget Expectations
• Financial Expectations

Outline schedule for design and implementation of change.


Change Management
• Reviews the change proposal
• Evaluates current change schedule
• Identifies any potential conflicts
• Issues and responds to change proposal
• Either authorizes or documents issues that need to be addressed

After new/changed service is chartered RFC’s are used via normal change


Assessing and Evaluating Change

Impact Typical Escalation Level
Standard Excluded using a pre-defined form or template
Normal Changes
Minor Change Manager (CM) or other operational manager
Significant Change Advisory Board (CAB)
Major IT Management Board
Urgent Changes
Normal Change Management or Change Advisory Board (CAB)
Emergency Emergency Change Advisory Board (ECAB)


7 R’s of Change Management
1 • Who RISED the change?

2 • What is the REASON for the change?

3 • What is the RETURN required from the change?

4 • What are the RISKS involved in the change?

5 • What RESOURCES are required to deliver the change?

6 • Who is RESSPONSIBLE for the build, test and implementation of the change?

7 • What is the RELATIONSHIP between this change and other changes?


The 7 R’s MUST be answered for ALL CHANGES!


Change KPI

• Number of RFC’s (Accepted/Rejected)
• Number and percent of successful changes
• Emergency changes required
• Number of changes awaiting implantation
• Number of implemented changes per period
(quarter, bi-quarter, yearly)
• Change backlogs or bottle-necks
• Business impact of changes
• Frequency of changes to CI’s


Workaround

Reducing or eliminating the impact of an incident or problem for which a full resolution is
not yet available – for example by restarting a failed CI. Workarounds for problems are
documented in known error records. Workarounds for incidents that do not have
associated problem records are documented in incident records.


Error

A design flaw or malfunction that causes a failure of one or more IT services or other CI. A
mistake made by a person or a faulty process that impacts a CI is also an error.


Incident Record

A record containing the details of an incident. Each incident record documents the
lifecycle of a single incident.


Change

The addition, modification or removal of anything that could have an effect on IT
services.


Change management covers changes to all configuration
items (CI) across the whole service lifecycle.


Configuration Item (CI)
Any component or other service asset that needs to be managed in order to deliver an IT
service. Information about each CI is recorded in a configuration record within the
Configuration Management System (CMS) and is maintained throughout it’s lifecycle by
Service Asset and Configuration Management (SACM).



A set of tools, data and information that is used to support service assets and
configuration management. The CMS is part of an overall service knowledge
management system (SKMS) and includes tools for
collecting, storing, managing, updating, analyzing and presenting data about all CI and
their relationships. The CMS may also include information about
incidents, problems, know errors, changes and releases. The CMS is maintained by
service asset and configuration management and is used by all IT service management
processes.



A set of tools and databases that is used to manage knowledge, information and data.
The SKMS includes the CMS as well as other DB and information systems. The SKMS
includes tools for collecting, storing, managing, updating, analyzing and presenting all
the knowledge, information and data that a service provider will need to manage the
full lifecycle of IT services.


Incident

An unplanned interruption to an IT service or reduction in quality of an IT service.
Failure of a CI that has NOT yet effected service is also an incident – for example
failure of a disk to mirror.


Problem

A cause of one or more incidents. The cause is not usually known at the time the
problem record is created, and the problem management process is responsible for
further investigation.


Known Error

A problem that has a documented root cause and a workaround. Known errors are
created and managed throughout their lifecycle by problem management. Known
errors may also be identified by development and suppliers.


Workaround

Reducing or eliminating the impact of an incident or problem for which a full
resolution is not yet available – for example by restarting a failed CI. Workarounds for
problems are documented in known error records. Workarounds for incidents that
do not have associated problem records are documented in incident records.


Change Management

The process for controlling the lifecycle of all changes, enabling beneficial changes
to be made with minimum disruption to IT services.


Change management must work with transition planning
and support to ensure that there is a coordinated overall
approach to managing service transition.


Change Model
Steps that should be taken to handle the change including…issues
and unexpected events

Chronological steps…dependencies

Responsibilities – who should do what, who will authorize the
change, who will decide whether formal change evaluation is
required.

Timelines and thresholds

Escalation procedures – who should be contacted and when.


Remediation:
Actions taken to recover after a failed change or release. Remediation may include
back-out, invocation or service continuity plans, or other actions designed to enable
the business process to continue.


Release and Deployment
Plan, schedule and control the build, test and deployment of
releases…

Deploy releases from DML…


Definitive Media Library

One or more locations in which the definitive and authorized versions of all
software configuration items are securely stored. The definitive media library may
also contain associated configuration items such as licenses and documentation. It
is a single logical storage area even if there are multiple physical storage locations.
The DML is controlled by services asset and configuration management and is
recorded in the CMS.


4 Phases of Release and Deployment

Release and deployment planning
1 Plans for creating and deploying the release are created. This phase starts
with change management authorization to plan a release and ends with
change management authorization to create the release.

Release build and test
2 The release package is built, tested and checked into the DML. This phase
starts with change management to build the release and ends with change
management authorization for the baselined release package to be checked
into the DML by service asset and configuration management. This phase only
happens once for each release.


Deployment
3 The release package in the DML is deployed to the live environment. This
phase starts with change management authorization to deploy the release
package to one or more target environments and ends with handover to the
service operations functions and early life support. There may be many
separate deployment phases for each release, depending on planned
deployment options.

Review and close
4 Experience and feedback are captured, performance targets and
achievements are reviewed and lessons and learned.


Data:
A set of discrete facts.
• Capture accurate data
• Analyze, synthesize and then transform the data into information
• Identify relevant data and concentrate resources on its capture
• Maintain integrity of the data
• Archive and purge data to ensure optimal balance between
availability of data and use of resources


Information:
Comes from providing context of data. Information is typically
stored in semi-structured content such as documents, e-mail and
multimedia.


Knowledge:
Is composed of tacit experiences, ideas, insights, values and
judgments of individuals. People gain knowledge both from their
own and from peers’ experience, as well as from analysis of
information (data).


Service Transition

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Service Transition

Similaire à Service Transition (20)

Plus de Peleg

Plus de Peleg (8)

Service Transition