Sitemap

Service Transition tests, integrates and releases the new or changed service delivered from Service Design phase. Service Transition must be satisfied that:

• the business is ready for the service
• the business can use the service
• service operations can manage the service

The objective for Service Transition are:

• to set customer expectations
• plan and manage service changes
• manage risks of service transition
• deploy service releases
• set performance expectations
• ensure expected business value
• provide information about services and service assets

Service Transition provides the quality gateways to ensure that project products are transitioned safely into the live environment and generally involves the following steps:

• Planning for Transition
• Building
• Service Testing and Pilots
• Planning for Deployment
• Deployment, Transition or Retirement
• Review and Closing of Service Transition

Implementation of Service Transition for an existing service provider will focus on improving existing processes. The introduction of Service Transition will need to be justified to the business in terms of the benefits. Newly introduced Service Transition processes should not be applied to current projects. Successful Service Transition requires:

• being able to find a balance betweeen a stable operating environment and being able to respond to a changing operating environment.
• creating a culture that is cooperative and responsive to change
• a clear definition of roles and responsibilities
• ensuring that the quality of the service corresponds to the quality of the business
• accounting for the needs of all stakeholders

Processes

Top Bottom

Transition Planning and Support

Top Bottom

Transition Planning and Support provides overall support and coordination for service transitions. Objectives for this function are:

• Plan and Coordinate resources to ensure that requirements are realised
• Coordinate activities across projects, suppliers and service teams
• Ensure new or changed services are established within predicted cost, quality and time estimates
• Ensure a common framework of processes and systems applied to improve integration
• Provide clear and comprehensive plans to align projects to service transition plans
• Identify, manage and control risk
• Monitor and improve Service Transition processes

Transition Planning and Support should provide and integrated approach to planning that improves the alignment of service transition plans to customer, supplier and business change

Change Management

Top Bottom

The Change Management process is used across the whole Service Lifecycle and most effort is spent on changes to operational services. The purpose of Change Management is to ensure that:

• standardised methods and procedures are used for efficient and prompt handling of all changes
• all changes to service assets and configuration items are recorded in the Configuration Management System
• business risk is minimised

The goals of Change Management are to respond to business and IT requests for change and to respond to customer's changing business requirements.

Change Management should enable beneficial changes to be made with minimum disruption. A change is the addition, modification or removal of anything that could have an effect on IT Services - or anything that changes information in the Configuration Management System. Change Management should ensure that all changes are:

• recorded
• managed/evaluated
• authorised
• prioritised
• planned
• tested
• implemented
• documented
• reviewed

Changes can be classified as:

Standard

Low-risk, relatively common and follows an established work instruction

Normal

A non-recurring task with no standard instructions. A basic Flow Model is used as a guide

Emergency

Immeadiate change to alleviate detrimental impact on business

A Request for Change (RFC) is a formal proposal for a change to be made. RFCs will normally be reviewed by the Change Advisory Board, where it will be assessed, reviewed and if approved added to the Change Schedule. The Change Schedule is an account of planned changes and their effect and will also account for key business activities that might impact resourcing the implementation of a planned change. The Projected Service Outtage identifies effect of planned changes on agreed service levels and downtime. Emergency CABs will be convened when the normal CAB meeting is too far away to respond to an emergency.

Change Proposals are high-level descriptions of change generated by Service Portfolio Management, Programme Management or Project Management. A Change Proposal will be reviewed by the Change Manager who will either authorise the change or document issues that need to be resolved. Authorised Change Proposals are added to the Change Schedule and are then chartered and service design can commence. The Change Proposal will detail the utility and warranty of the change, provide a full business case and include an outline schedule.

The Change Process Model or Change Model pre-defines steps and timescales for carrying out standard changes. Standard changes have the following characteristics:

• defined trigger for the RFC
• task is well-known and documented
• advanced authority declared
• budgetary approval granted in advance
• low-risk

Many standard changes will be triggered by the Request Fulfillment process and passed to the Service Desk

Emergency Changes require a different Model, but should adhere as closely as possible to the Normal Change Model. Records and logs of activities and actions will need to be completed. It is the responsibility of Change Management to ensure that this happens, even if it happens retrospectively. For Emergency Changes as much testing as possible should be carried out. Clear criteria should be established for identifying an Emergency Change. The Emergency CAB should consist of the Change Manager, affected business representatives and technical representatives.

The Normal Change process will begin with creating and recording the RFC. Then the RFC is reviewed to ensure it is complete and appropriately routed. The next step is to assess and evaluate the RFC to ensure:

• Correct level of authorisation for change
• Who should be involved in CAB
• Justification for change
• Impact of change
• Costs, benefits and risks of change

Following evaluation, the CAB can make their decision which should be communicated to all interested parties, especially the change initiator. If the change is authorised, then revised CS and PSO documents are issued. The authorised change will be implemented by Release and Deployment. Change Management will oversee the implementation and review and close the change. Review and closure involves collating the change documents, baseline and evaluation reports, review all documentation regarding the change and finally closing the change record. All information should be added to the Configuration Management System

Poor Change Management processes are indicated by:

• unauthorised changes
• unplanned outtages
• low change success rate
• high number of emergency changes
• delayed project implementation

Service Asset and Configuration Management

Top Bottom

Service Asset and Configuration Management provides a logical model of the organisations infrastructure by identifying, controlling, maintaining and verifying versions of all the organisations CIs.

The objectives of SACM are to define and control the components of the services and infrastructure and maintain accurate configuration information on historical, planned and current services and infrastructure

The scope of Asset Management includes service assets across the whole service lifecycle, providing asset inventory and recording responsible parties. Configuration Management ensures that selected components are identified, baselined and maintained and that any changes and releases are controlled

SACM provides interfaces to internal and external service providers and may cover non-IT assets such as people and buildings. Configuration Items are any asset, service component or any other item under the control of Configuration Mangement.

The Configuration Model defines services, assets and infrastructure and their relationships. As such it represents a single, common representation of IT Service Management and supports the following activities:

• incident and problem management
• impact assessment for changes
• planning and design of services
• planning upgrades
• planning release and deployment
• asset utilisation optimisation

The variety of CIs in the Configuration Model can be classified into:

Service Lifecycle CIs

business cases, service management plans, service lifecycle plans, change and release plans, test plans

Service CIs

service capability assets, service resource assets, service model, service package and service acceptance criteria

Organisation CIs

business strategy and policies

Internal CIs

items delivered by individual projects such as software

External CIs

an external customers requirements and agreements

Interface CIs

required by the end-to-end service across a service providers interface

The CMS is a set of tools used to manage an IT Service providers configuration data and holds information on all CIs and their relationships, any incidents, problems, known errors, changes, releases and documentation. The CMS relies on interfaces to:

Secure Library

A collection of software, electronic and document CIs of known type and status. Access is strictly controlled. The Libraries are used for controlling and releasing components throughout the release lifecycle. The Definitive Media Library (DML) hosts authorised versions of all media CIs

Secure Store

Provides reliable access to equipment of a known quality that can be used for additional systems or incident recovery.

Configuration Baseline

Captures the structure, contents and details of a particular configuration

Snapshots

Captures the state of a CI at a given point in time, providing a fixed historical record

SACM as part of its management and planning activities will produce a Configuration Plan which will cover the following:

Scope

applicable services, infrastructure and environments, geographical locations

Requirements

Policies and Standards

Policies and Standards affecting configuration and asset management

Organisation

Roles and responsibilities

Relationship Management

Communication interface controls

Standards for Configuration Identification will:

• define the classes and types of identification
• define how CIs will be labelled
• define roles and responsibilities
• define and document criteria for selecting CIs
• assign unique IDs to CIs
• specify relevant attributes of CIs
• identify owner of CI

Typical attributes defined for a CI will include:

• unique identifier
• CI type ID
• Name
• Version Number
• Model/Type ID
• Place/Location
• Department responsible
• Supplier
• Supply Date
• Change Record ID
• Incident/Problem Record ID
• CI History
• Status

Typical relationships recorded in the CMS for Configuration Items will include parent-child, used by, connected to or installed on.

Configuration control ensures that the CMS reflects the real world and any changes must be controlled and reflected in the CMS. Configuration control prodecures should include:

• Licence Control
• Change Management
• Version Control
• Access Control
• Build Control
• Promotion/Migration
• Configuration Baselines
• Deployment Control
• Installation
• Maintaining the DML

Configuration Status Accounting and Reporting is concerned with ensuring that all configuration data and documentation is recorded as each asset progresses through its lifecycle. The Verification and Audit process ensures:

• conformity between documented baselines and actual business environment
• physical existence of CIs in organisation, DML or Spares Store
• release and configuration documentation available prior to a release

Release and Deployment Management

Top Bottom

Release and Deployment Management is used to plan, schedule and control the build, test and deployment of releases and to deliver new functionality required by the business whilst protecting the integrity of existing services.

A release is a 'collection of hardware, software, documentation, processes or other components required to implement one or more changes to IT Services'. Releases are managed, tested and deployed as a single entity, often called a Release Unit.

The objectives of Release and Deployment Management are:

• Define and agree RADM plans
• Create and test release packages
• Ensure the integrity of release packages and that they are stored in the DML and recorded in the CMS
• Deployment of packages from the DML to the live environment following agreed plan and schedule
• Ensure packages can be tracked, installed, tested, verified and uninstalled
• Ensure organisation change is managed during release and deployment
• Ensure new or changed service can deliver utility and warranty
• Record and manage deviations, risks and issues
• Ensure there is knowledge and skills transfer to users and service functions

A Release Policy, created in Service Strategy, is used to provide effective management and control of all releases. Release Policies will apply to one or more services and should include:

• Unique ID, numbering and naming conventions for different types of releases and descriptions
• Roles and responsibilities for each stage of the RADM process
• Requirement to only use software assets from the DML
• Expected frequency of each type of release
• The approach for accepting and grouping changes into a release
• Mechanisms to automate build, installation and distribution
• How configuration baseline is captured and verified against actual release contents
• Exit and entry criteria and authority for acceptance of the release into each Service Transition stage
• Criteria and authorisation to ELS into Service Operations

Release and Deployment Models are used to describe how the Release Policy will be followed.

RADM begins with Release and Deployment Planning, following Change Management approval to plan the release. Once the Release Plan is built, Change Management authorisation is required to create the release. When the release has been built, Change Management authorisation is required for the baseline release package to be checked in to the DML by Service Asset and Configuration Management. Deployment begins following Change Management authorisation to deploy the release package to one or more environments and ends with handover to Service Operations and ELS. The RADM process ends with the Review and Close process that will focus on 'lessons learnt'.

Service Validation and Testing

Top Bottom

Service Validation and Testing ensures that services are fit for purpose and fit for use

Evaluation

Top Bottom

Determines whether the service performance is acceptable

Knowledge Management

Top Bottom

Knowledge Management is a Lifecycle-wide process responsible for the oversight and managment of knowledge and the information from which that knowledge derives. The purpose of Knowledge Management is to share perspectives, ideas, experience and information to enable informed decisions. The Service Knowledge Management System provides controlled access to knowledge, information and data appropriate for each audience.

The DIKW (Data - Information - Knowledge - Wisdom) structure describes the transition from data to wisdom:

Data

discrete facts about events. Data captured needs to be correct and relevant

Information

Data in context becomes information

Knowledge

Puts data and information into a format that can aid decision-making

Wisdom

Combining knowledge with common-sense

Data is gathered in Configuration Management Databases. These databases in turn will be contained by the Configuration Management System which provides the information layer. As such the CMS will additionally contain information about incidents, problems, known errors, changes, releases, employees, suppliers, locations, business units and customers and users. The Service Knowledge Management System provides the knowledge layer and thus contains the CMS and also records the experience of staff, peripheral matters that impact business activities, supplier and partner requirements, abilities and expectations and information on typical and anticipated user skill levels.

Roles

Top Bottom

Service Transition Manager

Top Bottom

The Service Transition Manager is responsible for the daily management and control of the Service Transition teams and their activities

Change Manager

Top Bottom

The Change Manager is responsible for developing and maintaining the Change Management process and managing RFCs from receipt to closure. The CM will chair and convene both CAB and ECAB, ensure the CS is distributed, normally via the Service Desk, and ensure that change logs are maintained. They will ensure that all changes have a remediation or backout plan and in the event of major failures will invoke the ITSCM plan. The Change Manager will also produce management information on all matters referencing change.

Configuration Manager

Top Bottom

The Configuration Manager is responsible for the Configurationn Management process. Responsibilities are:

• ensuring the efficient and effective running of the Configuration Management process
• Monitoring and auditing the process
• Identifying weaknesses
• Implementing improvements
• Maintaining the CMS and CMDBs
• Maintaining appropriate standards
• Maintaining awareness of the process
• Managing the configuration librarians and administrators

Release Packaging and Build Manager

Top Bottom

The Release Packaging and Build Manager role belongs to the Release and Deployment Management process and is responsible for establishing the final release configuration, including documentation of Known Errors and Workarounds. Responsibilities will also include building the final release, testing the build prior to releasing it to external testing and attendance at the final implementation sign-off.

Release and Deployment Manager

Top Bottom

The Release and Deployment Manager is responsible for all aspects of the end-to-end release process. As such, they will coordinate the build, test and release teams, ensuring that policies and procedures are adhered to and will report on release progress to other Service Management functions.