Service Transition - Processes

Service Transition - Processes

1. Transition Planning & Support (TPS)

2. Service validation & Testing (SVT)

3. Change Evaluation

4. Release & Deployment Management

5. Change Management

6. Service Asset & Configuration Management

7. Knowledge Management

1. Transition Planning & Support (TPS)

Goal:

Service Transition Planning and Support process ensures that the orderly transition of a new or modified service into production, together with the necessary adaptations to the service management processes. This must incorporate the service design and operational requirements within the transition planning.
Transition Planning and Support has two sets of objectives:

• Planning and Coordination

• Standardization and Improvement

Objectives:

Planning and coordination objectives:

• Coordinate resources and activities across projects, suppliers and service teams required to successfully introduce a new service or modify an existing service or retire a service

• Manage risks to minimize chances of failures

• Monitoring and improving service transition performance

Standardization and improvement objectives:

• Ensure adoption of standard and re-usable processes and supporting systems

• Continually improve the performance of the service transition stage

Benefits: A well managed transition planning and support process will deliver the following benefits to an IT service provider.

• Consistency in the Service Transition activities through the utilization of accepted set of policies, standards and models.

• Increased ability to manage multiple transitions at the same time.

• Management and deliberate prioritization of resources required by various projects and change activities resulting in cost efficiencies as well as continual alignment with changing business objectives.

• Future budget and resource requirements for service transition are anticipated and procured cost effectively avoiding expensive last minute decisions

2. Service validation & Testing (SVT)

Goal:

The goal of service validation & testing is to provide objective evidence to the new or changed service support, customer, business and stakeholder’s requirements.

Objectives:

To confirm that customer and stakeholder requirements are defined.

• Assures that the release will deliver service which are fit for purpose ‘performance’ and fit for use ‘specifications’

• Remedy errors early in Service Lifecycle

Scope:

• Supports Release and Deployment Process ensuring appropriate levels of testing are performed during the release, build and deployment activities

• Can be applied throughout the lifecycle to quality assure any aspect of a service.

Key Definitions:

Service Level Package (SLP) is a defined level of Utility and Warranty for a particular Service Package. Each SLP is designed to meet the needs of a particular Pattern of Business Activity (PBA). SLPs are associated with a set of service levels, pricing policies, and a core service package.

Service Level Requirement (SLR) is a Customer Requirement for an aspect of an IT Service. SLRs are based on Business Objectives and are used to negotiate Service Level Targets.

Service Design Package (SDP) is a document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement.

Service V Model:

• The Service V-Model is a unique concept that provides a path to follow with regard to defining the requirements for a service package, designing the package, building and then testing the package

• The model provides baseline points along the path that are used as checkpoints to ensure that what is being designed, built and delivered versus what was required

• Using techniques such as the Service V-Model for Service Validation and Testing provides a framework to help organize the levels of Configuration Items that are needed and the associated testing and validation activities within and across stages of the change

• The V-Model approach is traditionally associated with the waterfall lifecycle but applicable to other approaches as well

3. Change Evaluation

Change Evaluation process aims to assess major Changes, like the introduction of a new service or a substantial change to an existing service, before those Changes are allowed to proceed to the next phase in their life-cycle. Change Evaluation is called upon by the Change Management process at various points in a Change’s lifecycle to perform a Change assessment.
Example –

• Before authorizing the Change

• Before authorizing the Release Build

• During the Post Implementation Review

Focus and Output:
Focus

• Ensures that the expectations are realistic

• Independently evaluates actual performance against the expected one

• Evaluate the intended and unintended effects of service changes

• Provide effective and accurate information to change management

Output: The results of a formal Change Evaluation are documented in a Change Evaluation Report

Change Evaluation operates in the Plan-Do-Check-Act (PDCA) fashion.

4. Release and Deployment Management

Release and Deployment Management aims to build, test and deliver the capability to provide the services specified by service design and that will accomplish the stakeholder’s requirements and deliver the intended solution.

Goal:

To deploy releases into production and enable effective use of the service in order to deliver value to the customer.

Objectives:

• To ensure clear and comprehensive plans are in place

• Build, Install, Test & Deploy the release packages, on schedule

• Knowledge Transfer to Users, Operations & Support Staff

• Ensure that the utilities, warranties and service levels are delivered as agreed

Scope: The processes, systems and functions are included in the scope of Release and Deployment Management.

Approaches:

• Big Bang vs. Phased

• Push vs. Pull

• Automation vs. Manual

An organization may, decide that the release unit for business critical applications is the complete application in order to ensure that testing is comprehensive. The same organization may decide that a more appropriate release unit for a website is at the page level.

A key to Release and Deployment Management is defining the appropriate release package type for a given type of release.

Key Definitions:

Release is any CI or group of CIs, required to implement one or more approved changes to IT Services. Release Unit is a component of an IT Service that are normally released together. A Release Unit typically includes sufficient Components to perform a useful function.

• One Release Unit could be a Desktop PC, including Hardware, Software, Licenses, Documentation.

• A different Release Unit may be the complete Payroll Application, including IT Operations Procedures and User training.

ELS – Early Life Support
During early life support Service Transition and Service Operation work together. (aka hand-holding)

5. Change Management

Goals:

• Respond to the customer’s changing business requirements

• Maximize RFC value and reduce incidents, disruption and re-work

Respond to the business and IT requests for change that will align the services with the business needs

Objectives:

• To ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner

• Overall business risk is optimized

7 R’s:
7 R’s are the questions that must be answered for all changes. Without this information, the Risk & Impact assessment cannot be completed.

• 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 to build, test & implement the change?

• What is the RELATIONSHIP between this change & other changes?

Types of Changes:

• Normal Change are changes that must go through assessment, authorization and may require Change Advisory Board (CAB) agreement before implementation

• Emergency Change are only for highly critical changes needed to restore failed high availability or widespread service failure, or that will prevent such a failure from imminently occurring. Emergency changes are handled through ECAB (Emergency CAB)

• Standard Change are used for pre-authorized repetitive, low-risk, well-tested changes. Often these will be used for service operational maintenance changes

Key Definitions:

• Service Change is the addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc

• Configuration Item (CI) is any component that needs to be managed in order to deliver an IT Service

• Change Advisory Board is a body that exists to support the authorization of changes and to assist Change Management in the assessment and prioritization of changes

Key Metrics and Challenges:

Key Metrics for change management are:

• Unauthorized changes

• Unplanned outages

• A low change success rate

• A high number of emergency changes

• Delayed project implementations

Key Challenges with change management are:

• Lack of ownership of the impacted systems

• Inaccurate configuration data may result in poor impact assessments

• Bypassing the agreed procedures

• Resistance against an umbrella of Change Management authority

Role: Change Manager:

The role of change manager is as follows:

• The Change Manager controls the lifecycle of all Changes. (Allocate priority, reject incomplete & impractical)

• Ensure minimum disruption to IT services due to change.

• Chair Change Advisory Board (CAB) and ECAB.

• Issue Change Schedules

• Coordinate building, testing and implementation

• Update the Change Log

• Review implemented Changes

• Review outstanding RFCs

• Publish Management Reports

6. Service Asset & Configuration Management

Goal:

The purpose of the SACM process is to ensure 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 relationships between assets.

Objectives:The objectives of SACM are to:

• Ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle

• Identify control, record, report, audit and verify services and other configuration items (CIs), including versions, baselines, constituent components, their attributes and relationships

• Account for, manage and protect the integrity of CIs through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made

• Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system (CMS)

• Maintain accurate configuration information on the historical, planned and current state of services and other CIs

Value to Business: Optimizing the performance of service assets and configurations improves the overall service performance and optimizes the costs and risks caused by poorly managed assets, e.g. service outages, fines, correct license fees and failed audits.

SACM provides visibility of accurate representations of a service, release or environment that enables:

• IT staff to understand the configuration and relationships of services and the configuration items that provide them

• Better forecasting and planning of changes

• Successful assessment, planning and delivery of changes and releases

• Resolution of incidents and problems within the service level targets

• Delivery of service levels and warranties

Basic Concepts:

Service Asset:
A service asset is any resource or capability that could contribute to the delivery of a service. Examples of service assets include a virtual server, a physical server, a software license, a piece of information stored in a service management system, or some knowledge in the head of a senior manager.

Configuration Item:
A configuration item (CI) is a service asset that needs to be managed in order to deliver an IT service. All CIs are service assets, but many service assets are not configuration items. Examples of configuration items are a server or a software license. Every CI must be under the control of change management.

Service knowledge management system (SKMS):
The service knowledge management system (SKMS) is a set of tools and databases that are used to manage knowledge, information and data. Many configuration items are available in the form of knowledge or information, and these are typically stored in the SKMS — for example, a service level agreement, a report template or a definitive media library. The SACM process is not responsible for managing the SKMS. Some items in the SKMS will be owned and managed by the SACM process, but others will be owned and managed by other processes or people.

Configuration Record:
A configuration record is set of attributes and relationships about a Cl. Configuration records are stored in a configuration management database (CMDB) and managed with a configuration management system (CMS). It is important to note that CIs are not stored in a CMDB; configuration records describe CIs that are stored in the CMDB.

Configuration Management Database (CMDB)
A database used to store configuration records throughout their lifecycle. The configuration management system maintains one or more configuration management databases, and each database stores attributes of configuration items, and relationships with other configuration items.

Configuration Management System (CMS): A set of tools and databases that are used to manage an IT Service Provider's Configuration data.

• The CMS includes information about Known Errors, Changes and Releases and may contain data about employees, Suppliers, locations, Business Units, Customers and Users

• The CMS is part of a larger Service Knowledge Management System (SKMS) that drives the effectiveness and value of service knowledge

• CMS is maintained by Configuration Management and is used by all IT Service Management Processes

• The CMS maintains the relationships between all service components and may also include records for related incidents, problems, known errors, changes and releases. The CMS may also link to corporate data about employees, suppliers, locations and business units, customers and users

Definitive Media Library (DML):

The definitive media library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected.

• It stores master copies of versions that have passed quality assurance checks. This library may in reality consist of one or more software libraries or file-storage areas, separate from development, test or live file store areas. It contains the master copies of all controlled software in an organization

• The DML should include definitive copies of purchased software (along with license documents or information), as well as software developed on site. Master copies of controlled documentation for a system are also stored in the DML in electronic form

• The DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by SACM

• The DML is a foundation for release and deployment management

Relationship between CMDB, CMS and SKMS:

The relationship of the three levels, with configuration data being recorded within the CMDB, and feeding through the CMS into the SKMS. The SKMS supports delivery of the services and informed decision-making.

7. Knowledge Management

Goal:

• Knowledge Management aims to gather, analyze, store and share knowledge and information within an organization

• The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge

• It is a central process responsible for providing knowledge to all other IT Service Management processes

DIKW:

• Data is a set of discrete facts about events

• Information comes from providing context to data or by asking questions on the data

• Knowledge is composed of the concepts, experiences, ideas, insights values and judgments of individuals

• Wisdom gives the application of knowledge to provide a strong common sense judgment

Service knowledge management system (SKMS):

• It is the central repository of the data, information and knowledge that the IT organization needs to manage the lifecycle of its services

• Its purpose is to store, analyze and present the service provider's data, information and knowledge

• The SKMS is not necessarily a single system – in most cases it will be a federated system based on a variety of data sources