Service Transition

Transition represents a crucial stage in the service lifecycle – specifically, it is responsible for the gradual, incremental implementation of changes to the existing service.

Since the termination of Transition entails a certain standardization of IT operations, this has a beneficial effect on service delivery and, consequently, the abandonment of IT. Transition aligns the understanding of the changes being made, their necessity, and their cost among all service participants, which is crucial when justifying their necessity.

Goals

The purpose of Transition is to ensure the successful transition of a Service from one stage to another. Any change or addition of a new service must go through this stage. This is an important stage not only for IT but also for business – it ensures that the business receives the service it needs and that the service receives the necessary transformations.

Tasks

Planning and managing service changes, introducing new services, and discontinuing existing services;
Managing risks associated with innovations;
Implementing planned global updates (releases);
Defining expectations for service changes;
Ensuring that changes deliver the capabilities and functionality required by the business;
Updating service information with relevant and high-quality information.

Before transforming a service, it’s advisable to have a transformation plan, which, of course, isn’t always possible due to its critical nature. However, if a planned update is required, a standard change plan can be used, which should be prepared in advance. This plan can include everything from implementation and testing rules to a plan for implementing the change into the existing service. Again, for most non-critical changes, these plans will be very similar, so it’s sufficient to develop them once and use them throughout the service lifecycle.

To assess the risks of implementing changes, it is necessary to accurately and accurately maintain measurements of various indicators that help reflect the stability of the service.

Boundaries

Since Transition concerns any change to a Service, the boundaries of this lifecycle stage include everything that relates to the change—planning, implementation, testing, evaluation, and deployment of a new service or changes to an existing one. If the changes concern services provided by External Service Providers, Transition closely interacts with the Service Providers.

It’s worth noting that this stage often interacts with projects, as the project involves developing something new that has not previously been used in the IT organization.

Transition Planning and Support

This is a key process of Service Transition, so we will begin our consideration of this stage of the life cycle with it.

Goals

The process’s responsibilities include planning the actions that must be performed when a Service transitions from one lifecycle stage to another. Because this is a fairly comprehensive operation and interacts with numerous other processes, service management requires managing this transition and planning it in advance. This is the primary objective of the process—planning the actions that must be performed to complete the service transformation.

This planning can concern both technical changes (i.e., managing how the service infrastructure will be modified) and application-related aspects (i.e., software changes). Naturally, this process is aimed at mitigating the potential impact of implementing changes. It’s important to note that the parties involved in this process can include not only IT department employees but also business stakeholders — some operations may require their direct involvement (for example, during testing).

Tasks

Planning and coordination of human and (other) resources;
Coordination of various activities involved in the Transition. These may include individual activities, as well as entire projects and services performed by External Service Providers;
Creating clear and comprehensive plans for the transformation. It is also necessary to ensure that all participants in the transformation clearly understand the sequence of activities and requirements (especially timelines);
Monitoring adherence to budget, deadlines, and required quality;
Compliance with new requirements described in the Design stage of the management system, which will become part of the modified service. Since changes may affect not only the Technical and Application components, this process should monitor the implementation of changes to service management methods and principles;
Ensuring the application of processes by all those involved in the Transition process. This is necessary to achieve coherence during the service’s Transition to the Operation stage;
Risk identification and management;
A general improvement in the approach to service transformation (not just the one currently being transformed).

Boundaries

The boundaries of this process are rather blurred, since this is a very global process that defines the approach to the Transition of a service, but some subtle aspects can be identified:

Prioritizing required resources. For example, using certain resources when installing software;
Planning requirements for future changes;
Identifying activities needed to improve the service Transition approach (improving the approach).

However, the main objective of this process is to coordinate the actions of all Stakeholders and transactions among themselves, and therefore the boundaries must be determined based on their quantity and quality.

Change Management Process, CMP

This process is very important for maintaining the Service, as it is responsible for making all kinds of changes to the Service.

Goals

The first objective can be partially deduced from the subject name: Change Management should respond to changes occurring in the business area and ensure a reduction in the number of Incidents, the frequency of service interruptions, and the amount of rework. This will increase the value of the service provided by IT to the business.

The second goal of Change Management is to ensure that all changes are captured (in documentation or a knowledge base), accounted for, and properly characterized. All changes (even those that will not be implemented) must be entered into the Configuration Management System, CMS, which links this process with the Service Asset and Configuration Management, SACM process.

When implementing a change, it’s important to assess the negative risks associated with it. However, it’s important to remember that the risks of not implementing the change must also be assessed.

Tasks

According to ITIL, this process is designed to ensure the successful implementation of service changes. A poorly designed and uncontrolled change management process can lead to rework and additional changes, which will entail even greater costs. The task of Change Management is to control changes and build a process that minimizes potential damage from both planned and unplanned changes.

Boundaries

Change can affect any service component, architecture, or infrastructure, as well as processes, documentation, and metrics. Therefore, the Change Management Process must be managed and structured, covering changes at any stage of the service lifecycle — from Strategy to Continuous Improvement. Furthermore, changes must be controlled at all organizational levels — strategic, tactical, and operational. It is essential to establish a seamless change management process — both internal and external — (this links Change Management with the Supplier Management Process).

Changes that extend beyond the scope of a service typically have greater potential impact. Such changes may target the organization’s structure, business policies, and business processes.

Since changes can “arrive” from any source and affect anything, it’s necessary to sort and filter Change Requests and categorize them by importance and scope. It’s worth noting that Change Management isn’t responsible for coordinating changes with projects — that’s the responsibility of the planning and supporting Transition processes.

Types of changes

Any change must be formally documented — this could be a Help Desk request or a generated change document. This requires a system that manages requests and tracks them. ITIL defines three change concepts, similar in name but different in purpose:

Change — is any addition, modification, or deletion of something from a Service;
Change Request — is a formal request for a change, which can be written or electronic. This entity only determines the fact that a request exists; whether it is rejected or approved is irrelevant. Furthermore, a Change Request does not track the change’s lifecycle;
Change Record — is created as a result of a Change Request (including those that are rejected). These records are stored in the Configuration Management System, CMS.

As mentioned earlier, a change may be required for any area of the Service, but they can all be broken down into several types: Standard, Emergency, and Normal.

Standard Change

These changes are known in advance, their risks are understood, and the steps required to implement them are known in advance. The following elements define a Standard Change:

The trigger (the event that serves as the basis for a Change Request) is clearly defined, such as a Help Desk ticket;
The actions are initially clear, tested, and documented;
The authority to implement the change is granted in advance;
The risks are low, or clear and known in advance.

Emergency Change

This type of change is either an urgent response to critical (business) errors or actions to prevent them. Naturally, they carry greater risks, are less well-assessed, and are poorly planned.

If necessary, Emergency Changes can be evaluated by a special group of people, the Emergency Change Advisory Board. It has the same functions as a “regular” Change Advisory Board, but deals specifically with Emergency Changes. Because Emergency Changes carry increased risks, special attention should be paid to their testing.

They are emphasized by the following elements:

Evaluation can be performed urgently by the Emergency Change Advisory Board;
Testing can be limited or, in some cases, completely absent (if all risks are understood and accepted);
Documentation can be performed retroactively (after the change has been applied).

Normal Change

The types of changes discussed above are either performed regularly and require little oversight (Standard), or they require a quick response and are subject to high risks (Emergency). The first type is implemented according to a fairly simple scheme and can be classified as Operational activity. The second, with good planning, should be used much less frequently.

There’s also a “third” type—Normal Change. Essentially, this type carries the “normal” suffix only to distinguish it from other types; (is case of ITIL exam, if this suffix is missing on the exam, it’s a Normal Change). In its classic form, it consists of the following steps:

Create a Request for Change, RFC. This request can be very basic and can be initiated by any source, but each source must be considered without exception. The level of detail may depend on the complexity of the request (for example, the source may not be familiar with the technical requirements), but the change must be described as clearly and understandably as possible. This stage should entail the creation of a Change Record, which must be assigned a unique identifier for tracking purposes;
Request for Change, RFC Review. This review should answer the following questions:

Is the Change feasible?
Is there sufficient information about the Change and does the budget allow for its implementation?
Does this Change duplicate any previously created Changes?
If it is rejected, the source must be notified of this and the reason for the rejection.

Change analysis and evaluation;
Change assignment;
Update planning;
Change management;
Request for Change, RFC Review and Closure.

Change Advisory Board

First, it’s important to define what a Change Advisory Board is. It’s a group of people who meet to evaluate proposed changes before they are accepted for planning and implementation (authorized). The composition can change constantly depending on the Change Request and the IT and business areas it affects. The Board often includes representatives from the business (Customer) and technical specialists, as well as representatives from Service Providers if the changes affect External Services.

To successfully conduct a change meeting, all participants must be aware of the upcoming topic of discussion and have access to all necessary information. Typically, the following questions are raised at the meeting:

Change proposal;
Change Requests, CR that need to be reviewed and evaluated;
Change Requests, CR that have already been evaluated;
Overview of other changes;
Current changes and their status;
Schedule changes, as well as identified causes of delays;
Unauthorized changes;
Poorly implemented changes;
Suggestions for new changes for the future.

Change Management Process and other processes

Before considering this issue, it is worth recalling the key property of this process: it can impact any area of Service provision at any stage of their life cycle.

Change Management Process interacts with:

Process	How it interacts
Transition Planning and Support	Change coordination
Release and Deployment	Along with the process under consideration, this is closely linked to project management and business process change management. This relationship ensures the smooth and seamless implementation of changes to service delivery. However, these relationships are bidirectional – they may require changes to each other.
Supplier Management	Involved when using External Services
Formal procedure for assessing changes to business processes	In the case of complex changes, this process may require the initiation of a formal change assessment procedure. Such processes may exist within the organization, but are typically only required for critical changes that impact Vital Business Functions
Service Asset and Configuration Management	Handles data necessary for change assessment
Problem Management	Is one of the primary sources of change
Information Security and IT Service Continuity Management, ITSCM	Participates in the assessment of changes to ensure security and planned service continuity
Capacity Management and Demand Management	May forward to additional changes
Service Portfolio Management	In addition to providing information to the Change Management Process, it may lead to global changes for the business
Service Level Management	A change must be assessed for its impact on service levels
Availability Management	Most changes impact this process

Service Asset and Configuration Management

An IT department is more than just software, network protocols, and the people who make it all work—an IT department (like any other) has its own assets, for which it is responsible and which it manages. This process is aimed at achieving maximum benefit from the assets available to the IT department.

Goals

The primary objective is to ensure the IT department has control over the assets it owns. This requires an understanding of what they are, what functions they perform, and how they interact with each other. This can only be achieved by maintaining a comprehensive inventory of them, detailing both their characteristics and configurations, as well as the other assets with which they interact. This may seem somewhat bureaucratic, but proper documentation enables the effective management of IT department assets. Particular attention should be paid to documenting asset configurations and their relationships — this will allow for faster and easier recovery of the system (or individual elements) in the event of a failure.

Tasks

Ensuring that assets under the control of the IT department are accounted for and controlled. This may include the asset’s software version, its components, key characteristics, and any other useful information;
Documenting information about the services provided and the assets used for them. It is especially important to describe the function the asset performs;
Configuration Item Management. A Configuration Item can be anything that enables the provision of a service. This process closely integrates with Change Management to ensure the list of used Configuration Items is up-to-date and for filtering them;
Ensuring infrastructure planning, logging, and accounting;
All of the above points enable more informed decisions regarding not only assets but also the overall service delivery.

Boundaries

First and foremost, this is asset identification. All assets that are involved in providing a service and are controlled throughout their lifecycle are called Configuration Items. For example, a router would be a Configuration Item (it is directly involved in transmitting data over the network), but the system administrator’s knowledge of it would not be (it is not directly used to provide the service, only indirectly to configure the router, a Configuration Item). Likewise, the data transmitted via the router would not be a Configuration Item. At the same time, both the data and the system administrator’s knowledge would be Assets. It can be concluded that a Configuration Item is, in most cases, a physical unit. But this is not always the case – for example, the Role and Responsibility Matrix, RACI Model can be accounted for as a Configuration Item.

Typically, a Configuration Management System, CMS is used to track all IT assets. Everything related to IT should be stored within it, based on the principle: the more information, the better. The system itself can be divided into smaller sections called Configuration Management Database, CMDB, which typically serve to expedite the search for specific assets.

When an enterprise has a business process for managing its assets, the Service Asset and Configuration Management process should be aligned with this business process. A Configuration Management System, CMS often serves as a valuable aid in this regard.

Configuration item management can be complicated by an inappropriate level of detail. For example, if the detail is too detailed, it will be difficult to find the necessary information, while if it is too brief, the necessary data may simply be missing. For example, should each component of a personal computer be considered a separate configuration item or should they be treated as a single unit? ITIL also recommends classifying configuration items and assigning them to different configuration management databases (CMDBs) by dividing them into the following categories:

Service Lifecycle Configuration Items. Documents describing plans and requirements for a service (e.g., service business case, design documents, service management plans, etc.);
Service Configuration Items. Documents including service enablers (e.g., processes, management practices, staff skills, etc.), resources (e.g., finances, infrastructure, staff, etc.), and service acceptance criteria;
Organization Configuration Items. Standards and policies applicable to the service;
Internal Configuration Items. Assets obtained during service delivery (e.g., the deliverables of a project or other service);
External Configuration Items. Assets required for interaction with external parties (e.g., contracts, agreements, and requirements);
Interface Configuration Items. Assets that describe the interaction between different Service Providers, as well as their interaction with the customer.

A Configuration Record is another term you need to know. It’s a set of attributes and relationships between Configuration Items stored in the Configuration Management Database. It’s important to note that the Configuration Item itself isn’t stored in the previously noticed database; rather, records about it are.

Configuration Model description

This model is intended to represent all Configuration Items and the relationships between them as a single entity that enables service delivery — in other words, it is a graphical repository of all Configuration Items, taking into account their relationships. The phrase “single entity” does not necessarily imply that all its elements are represented at once. There are no clear rules for representing a Configuration Model, so everything depends on corporate guidelines. Below are two Configuration Models, one of which is freeform, the other is implemented according to the UML standard:

Configuration model

Most of the services provided consist of a large number of Configuration Items, which makes them difficult to understand - then the Configuration Model is broken down into several parts and combined into smaller ones - the Matryoshka effect is applied.

Configuration Management System, CMS

This system is necessary for managing system configurations and therefore includes both the Configuration Model (as a means of conveniently representing the configuration) and additional information describing Configuration Items. Working with the system is part of the Service Asset and Configuration Management process, and the data it contains must be linked to the Service Knowledge Management System, both of which are components of the global Configuration Management System, CMS. An important aspect is that the system must meet the requirements for information sufficiency and availability—that is, it must ensure the appropriate level of detail for Configuration Items, as well as the appropriate level of accessibility and ease of retrieval of the necessary information.

Naturally, like any other system, this one must be updated as changes occur in Configuration Items and the relationships between them.

Definitive Media Library

This library is particularly important within the Configuration Management System, CMS because it is crucial for service management. It includes both the software and its documentation, as well as any license agreements. It’s important to note that while multiple libraries may be physically distributed across different locations, they should logically form a unified whole — without duplication or inaccuracies. Each piece of software used should not undergo Release and Deployment Management and be released into Operation without being included in the Definitive Media Library. Furthermore, each version of modified software should be recorded in the Definitive Media Library — this will allow for the complete restoration of any required version’s configuration, as well as the tracing of the service’s history and its use as a learning experience for future service delivery.

When managing this library, it is of course necessary to maintain the accepted security level (it may be more harsh than the corporate one).

Knowledge Management

De facto, this process covers all life cycles of a service, but is classified under Transition, since it is where knowledge is most often handled.

Goals

The main task is to organize the provision and operation of knowledge in such a way that maximum efficiency can be achieved, mainly by using previously accumulated knowledge, rather than collecting it again.

Efficient knowledge delivery is also achieved by reducing delivery time and ensuring the required information is comprehensive. The first is fairly straightforward: the faster information is searched and delivered, the better. As for information comprehensiveness, the user should receive precisely the information that will be useful to them, no more and no less. For example, a system administrator experiencing problems with a router is unlikely to be interested in information about the organization of a business process, but rather its technical specifications and a network map.

High efficiency in providing information is needed not only for “patching holes”, but also for making decisions regarding both changes and new services that are only just being designed.

Tasks

Improving the quality of information provided for strategic decision-making. As noted above, data must be of the required completeness. The concept of “quality” in this case includes data completeness, reliability, accuracy, and security;
Ensuring that the source of incoming information meets quality requirements. Sources can include software, personnel, external systems, etc.;
Supporting the Service Knowledge Management System. The mechanism that processes and provides data is also important;
Organizing data collection, storage, analysis, and provision as an iterative process. Establishing all these procedures using a new methodology each time will be extremely time-consuming, and their accuracy will be highly questionable (due to errors that arise during the process).

Boundaries

It has been mentioned previously that the process is only formally related to Transition; in reality, it extends its effect to all stages of the service lifecycle. For example, at the Strategy stage, information is necessary for managing all provided services, as well as for making strategic business decisions (e.g., adding a new service to the Service Portfolio); at the Design stage, information will be useful for designing changes, as well as new services; at the Transition stage, it is necessary for evaluating changes; at the Operation stage, data will be compiled and populated by knowledge bases; Continuous Service Improvement is characterized by frequent references to existing knowledge to propose service improvements.

Data-to-Information-to-Knowledge-to-Wisdom

This model is familiar to almost everyone and is very easy to understand. Its structure is presented below:

Data-Information-Knowledge-Wisdom

Typically, this model is used to identify the root cause of a problem. It consists of several steps that help achieve this:

Data. The input is always data. Data can be fragmented and unstructured, offering little value;
Information. Typically, this is a list of facts obtained through superficial processing of Data. This may include the data source, time and place of creation, a superficial description, or some collected metrics.
Knowledge. This is the understanding of the underlying problem.
Wisdom. This is the final step, identifying the root cause of the problem. After this step, ITIL plans to begin assessing the need to address the source of the problem.

Release and Deploy Management

For software changes to take effect, they must first be assessed, designed, modified, and tested. Even then, they’re of little use — the new release must be deployed and successfully integrated into the existing system. This is what Release and Deployment Management does.

Tasks

The primary task of this process is to ensure that the change being deployed will occur without causing significant disruption to the existing system. In most cases, this process will be planned in advance, but regardless, the deployment must be carefully planned in advance. A secondary objective is to ensure that the deployed change complies with all requirements of the existing system (but this is more the responsibility of the Change Management process);
Release and Deployment Management Objectives;
Define the deployment plan and coordinate it with other Stakeholders. This is important not only for the users who use the system, but also for the Service Providers;
Create and debug the update package. It is important to monitor the compatibility of the changes with the existing system;
Ensure the correctness of the update package throughout the deployment lifecycle. It is especially important to record the relevant records in the Definitive Media Library. Each release is a separate Configuration Item, and as noted earlier (see the Service Asset and Configuration Management process), all of them must be noted in the knowledge base;
Follow the deployment plan (see p. 1);
Manage the update package. This includes creating it in accordance with requirements, testing for compatibility and debugging, installing, and verifying it;
Ensure that the update package meets the Warranty and Utility requirements;
Manage and record all emerging risks and deployment outcomes. Since this information can help with future deployments (not only for this specific service, but also for similar ones), it is advisable to accumulate this knowledge;
Ensure that both technical staff and users are properly trained. This goal goes beyond successfully deploying, but is equally important.

Boundaries

As noted above, not all changes must undergo the Release and Deployment Management process. To determine when a change requires this process, specific rules must be defined. These rules should be described in the Release Policy. In addition to the rules for determining whether a change must undergo the Release and Deployment Management process, this document may include the following elements:

Release designation rules;
Release deployment process (usually implemented in the form of Phases);
Release deployment roles and responsibilities;
Definitive Media Library, DML operating rules;
Release definition rules as a group of changes, as well as rules for including changes in these groups;
Entry and exit criteria for each Phase of deployment. This also includes a description of the requirements for the final Phase.

Phases

Planning. Begins with the confirmation of the Change Request and ends with the change being transferred to the Build and Test phase.
Build and Test. During this phase, the release is created, tested, and information about it is entered into the Definitive Media Library. This phase should only be entered once. This phase ends when Deployment begins.
Deployment. The deployment is carried out according to the plan established in the first phase. This phase is entered after Build and Test, and exited upon completion of the planned deployment or if deployment is not possible.
Review and Close. The final phase, during which the success of the deployment is assessed, and all errors and shortcomings are recorded. Any suggestions for improving the deployment process should also be noted.

Service Validation and Testing

Its purpose is to ensure that the service being created/modified meets the requirements defined in the Strategy and Design.

Evaluation

This process is responsible for comparing the created/modified service’s compliance with the criteria and requirements defined in the initial stages.