ITIL - Service Transition Processes Video Tutorial
1 Service Transition Processes
This lesson will help you to understand the constituent processes of service transition.
After completing this lesson, you will be able to: • Describe the purpose, objective and scope of transition, planning and support • Explain the purpose, objective and scope of change management • Describe the concept of Service Asset and Configuration Management or SACM • Identify the purpose, objective and scope of Release and Deployment Management or RDM • Explain the purpose, objective and scope of knowledge management
3 Introduction to Service Transition Processes
The processes in service transition phase are critical as they influence and support all stages of the service lifecycle. Following are the processes in service transition phase: 1. Transition, planning and support provides the planning and support for new or modified services and ensures orderly transition of services. 2. Change management controls the lifecycle of all changes and ensures balance between flexibility and stability. 3. Service Asset and Configuration Management provides the information required to manage CIs and assets across the service lifecycle. 4. Release and Deployment Management plans, builds, tests the releases and deploys the services into the customer’s environment. 5. Knowledge management gathers, analyses and shares information with the organisation to increase efficiency for the future.
4 Transition, Planning and Support
Transition, planning and support is a process that includes planning and coordination for the activities involved in service transition. Let us focus on the purpose, objective and scope of transition, planning and support. Purpose: The purpose of the transition, planning and support process is to provide overall planning for service transition. In addition, it helps to coordinate the resources required to deliver the service. Objective: Following are the objectives of the transition, planning and support process: • Plan and coordinate the resources to ensure that the requirements defined in service strategy phase are implemented in service design phase; in addition, ensure that the requirements are successfully released in service operation phase • Coordinate activities across projects, suppliers and service teams where required • Provide clear plans that help the customer and the business change projects to align their activities with the service transition plans • Establish new or modified information systems and tools, technology and management architectures and service management processes; in addition, establish new or modified measurement methods and metrics to meet the requirements defined during service design phase • Monitor and improve the performance of the service transition phase Scope: The scope of the transition, planning and support process is to: • maintain policies, models and standards for the activities and processes in service transition. • coordinate the efforts needed to manage several transitions at the same time. • prioritise conflicting requirements for service transition resources. • review and improve the performance of activities related to transition, planning and support.
5 Introduction to Change Management
We will now discuss change management. A change is a modification, addition or removal of anything that could impact IT services. The impact may be altering the process or adding a CI. This includes the addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. For example, if a server, with its defined configuration is a CI for the customer, any addition of memory to that server constitutes a change. Changes can be made for proactive or reactive reasons. Examples of proactive reasons include cost reduction and service improvement. Examples of reactive reasons include solving service disruptions and adapting the service to a changing environment. The change management process is responsible for controlling the lifecycle of all changes, from the inception to the closure of the change. It is important to manage the change because it helps to optimise the risk to business services and minimise the severity of any impact and disruption. The process also enables changes to be successful at the first attempt.
6 Change Management-Overview
Change management includes changes to baselined service assets and configuration items across the entire service lifecycle. Let us understand the purpose, objective and scope of change management. Purpose: The purpose of the change management process is to control the lifecycle of all changes. The process also helps in making beneficial changes with minimum disruption to IT services. Objective: Following are the objectives of the change management process: • Respond to business and IT requests to ensure alignment of services with business needs • Ensure that changes are introduced in a controlled manner, thus optimising business risk • Implement changes timely and successfully to meet business needs • Use the standard processes and record every change Scope: Changes may occur in service strategy or service design phase, for example, there may be a change in the service portfolio. Changes may also occur at a tactical level in service operations phase, for example, there may be an addition of two new servers. The scope of change management includes: • any change to all architecture, tools, metrics, processes and documentation. • addition, removal or modification of a service, Configuration Item or an associated documentation. • changes to any of the five aspects of service design.
7 Change Model
A change model refers to a predefined set of steps, policies and procedures for assessing, authorising and executing a specific type of change. Change models help to save costs, minimise risk and improve the consistency of execution around changes. A change model includes the following components: • Steps to handle changes, including unexpected events and issues • The chronological order in which these steps should be taken, with any dependency or co-processing defined • Responsibilities as in who should do what, including identification of change authorities who will authorise the change and decide whether formal change evaluation is needed • Thresholds and timescales for completion of the actions • Escalation procedures including who should be contacted and when
8 Types of Change
Following are the three types or models of change: • Normal change • Standard change • Emergency change Normal change is a change that follows all steps of the change process. It is assessed by the Change Manager and approved by Change Advisory Board or CAB. Standard change is a pre-approved change that has low risk. It is relatively common and follows a defined procedure or work instruction. Password reset or provision of standard equipment to a new employee is considered as a standard change. Emergency changes are defined as changes that must be addressed quickly, for example, to resolve a major incident or implement a security patch. The organisation uses an advanced process for handling emergency changes. These changes should be kept to a minimum as the impact and chances of failure are more for an emergency change.
9 Key Terminologies
Some of the key terms related to service transition are remediation planning, service change, Request for Change or RFC and change proposal. Remediation planning refers to a recovery plan to a known state after a failed change or release. Before instigating the change, it is important to know if various remediation options are available. Once it is established that the remediation is viable, the risk of the proposed change is determined and appropriate decisions are taken. Service change refers to the addition, modification or removal of an authorised, planned or supported service component and its associated documentation. Request for Change is a formal request for a service change. It can be raised or issued by anyone involved in the service. An RFC is standard form to capture and process all changes to any Configuration Item. A change proposal is raised for major changes with significant organisational or financial effects.
10 Change Proposal
A change proposal is utilised to communicate a high-level description of any change that has occurred. It may include multiple changes. The change proposal is created in the Service Portfolio Management process. It is then passed to the change management team for authorisation. In some organisations, change proposals may be created by the Programme Management Office. A change proposal includes a high-level description of the new, changed or retired service. It also comprises a business case including risks, issues and alternatives. In addition, a change proposal includes financial requirements and an outline schedule for design and implementation of the change.
11 Change Management Process-Change Flow
The image illustrates different activities in the change management process. Following are the activities: 1. The change management process starts with a Request for Change or RFC. 2. The RFC is logged in the change management system. The information is captured and tracked through to completion. 3. An initial review is performed to filter RFCs that are incomplete or incorrectly routed. 4. The RFCs are assessed. This is when the Change Advisory Board or the Emergency Change Advisory Board may be involved for business justification, impact, cost, benefit and risk of the changes. 5. The RFCs are authorised by the Change Manager. The change requester in turn ensures that they have the approval in three main areas. Following are the areas: • Financial approval: What is it going to cost and what is the cost of not doing it? • Business approval: What are the consequences to the business if the changes are not implemented? • Technology approval: What are the consequences to the infrastructure if the changes are not implemented? 6. Change management coordinates the work performed at multiple checkpoints. The change management team forwards approved changes to the relevant product experts. The experts build and test the changes as well as create and deploy releases. 7. The changes implemented are reviewed. This is called Post-Implementation Review or PIR. If the change is successful, it can be closed. A key activity of change management is assessment of the change request by the Change Manager or Change Advisory Board.
12 Change Advisory Board
Let us now focus on the Change Advisory Board. The Change Advisory Board is a consultative body that meets regularly to help the Change Manager assess, prioritise and schedule changes. The Change Advisory Board is a group of experts with a clear understanding of stakeholder needs. The Change Manager chairs the board. The board may include representatives from all areas of the IT service provider. These areas are technical support, operations, development, service management, customers, other stakeholders and third parties such as suppliers. People, who are directly or indirectly affected by the changes, are a part of the Change Advisory Board. The Emergency Change Advisory Board is a subset of the CAB organised by the Change Manager. It offers advice on emergency changes.
13 Change Manager-Responsibilities
Following are the key responsibilities of the Change Manager: • Ensuring that the process is followed, and authorising minor changes • Identifying key stakeholder for the changes, coordinating with them and conducting the Change Advisory Board meetings • Producing the change schedule, and ensuring that all changes are scheduled without conflict and without causing a bottleneck to business requirements • Coordinating the change, built, test and implementation • Reviewing or closing changes by collating all documentation related to the changes • Initiating post-implementation review meetings with the CAB
14 7 R’s of Change Management
Now let us understand the 7R’s of change management. There are seven questions that should be asked for proper impact assessment and understanding of the risk to benefit ratio. These questions must be asked for all changes. The change assessment cannot be completed without getting the answers to these questions. The risk to benefit ratio cannot be understood as well. Following are the questions asked by the Change Manager or the CAB: • 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 for the build, test and implementation of the change? • What is the relationship between this change and others?
15 Change Metrics
We will now focus on how the change management process is measured through metrics. A metric is defined as something that is measured and reported to help manage a process, IT service or activity. Key Performance Indicator or KPI is another term used in measuring performance. It is an important metric for that process, IT service or activity. KPIs are selected to ensure that efficiency, effectiveness and cost-effectiveness are managed. Some of the metrics used in change management process are as follows: For compliance, the metrics are: • decrease in the number of unauthorised changes; • decrease in the number of emergency changes; and • maintaining the integrity of the CI’s and change. For effectiveness, that is, for ensuring that the process delivers value effectively, the metrics used are: • an increased percentage of changes implemented to meet customers’ requirements; • a reduction in disruption, defect and re-work; • a reduction in changes that have failed or have been withdrawn; and • a decrease in the quantity of incidents attributable to any change. For efficiency, the metrics are: • the benefits gained, that is, the value of change compared to the cost incurred to make the change; • the average time taken to implement change by urgency, priority or type; and • the increased percentage of accuracy in change estimates.
16 Key Challenges in Change Management
Following are the key challenges faced by change management: • Business pressure: Organisations come up with new initiatives for their business process and may pressurise for immediate execution of these ideas. • Incomplete and inaccurate Configuration Management System or CMS: This leads to incomplete and inaccurate assessment of changes. • Soiled technical function areas: Lack of communication channels to the technical teams make it difficult to execute a change. • Misunderstanding of emergency changes: Sometimes the technical team may misunderstand urgency and emergency changes. • Scalability across large organisations: Scalability is a big challenge because some of the CIs may not be deployable in the existing infrastructure. The change management team may find it difficult to solve this issue. • Vendor or contract compliance: Vendors may own the change management system or resist from following the change management process in an organisation.
17 Service Asset and Configuration Management-Overview
Now let us discuss the Service Asset and Configuration Management process. This process manages the service assets to support other service management processes. An organisation cannot function efficiently or effectively unless they manage their assets well. These assets are vital for the functioning of the customer’s or organisation’s business. Let us understand the purpose, objective and scope of SACM. Purpose: The purpose of SACM is to ensure that the assets required to deliver services are properly controlled. In addition, it is important to store accurate and reliable information on these assets. It is also necessary to ensure that the information is available anytime. Objective: Following are the objectives of the SACM process: • Define and control the components of infrastructure and services • Maintain exact configuration records; this helps an organisation to comply with corporate governance requirements, control their asset base and optimise their costs; it also helps to manage change and release effectively, and resolve incidents or problems faster Scope: The scope of SACM is to make sure that all assets used during the service lifecycle are within the scope of asset management. SACM helps in managing the complete lifecycle of each Configuration Item. The process offers a complete overview of all assets, and shows who is responsible for the control and maintenance of these assets.
18 Knowledge Check
Let us do a quick recall of the concept of SACM covered in this lesson.
19 Configuration Baseline and Database
Now let us define two key terminologies. A configuration baseline is the configuration of a service, product or infrastructure that is formally reviewed and agreed upon. It serves as the basis of further activities. The configuration baseline can be changed only through formal change procedures. It captures the structure, contents and details of a configuration. It represents a set of Configuration Items that are related to each other. A configuration baseline is the snapshot of the configuration of a CI on a particular time interval. This can be used for comparison in the future. A Configuration Management Database or CMDB is a database to store records of Configuration Items. One or more CMDBs can be part of a Configuration Management System. The CMDB provides a logical model of the IT infrastructure as it captures CIs and the relationships between them. Similar to the CMDB, there are two libraries defined as part of the Configuration Management System. These libraries are used for controlling and releasing components throughout the service lifecycle, for example, in design, building, testing, deployment and operations. Take a look at the example of configuration management.
20 Definitive Media Library
Now we will discuss the Definitive Media Library. The Definitive Media Library or DML is a secure store where the definitive, authorised and approved versions of all media CIs are stored and monitored. The DML is the only source for build and distribution. The master copies of items stored in the DML pass quality assurance checks. The DML includes master copies of all software assets such as: • scripts and codes; • in-house and external software houses; • management tools and applications; and • licences.
21 CMDB and DML
The image illustrates the relationship between CIs, CMDB and Definitive Media Library. It also explains how they are used to roll out new releases and deployments to the live environment. The big rectangle box in the image represents the CMS. The DML and the CMDB are a part of the CMS. During a new release, authorised CIs are taken or checked out of the DML. They are then used in the development environment to create a new release. The new release is tested in the test environment before it is rolled out for deployment in the production environment. All documentation on this release is included in the release record. The documentation is related to associated CIs in the CMDB.
22 Secure Library and Secure Stores
Let us now discuss secure library and secure stores. Secure library is a collection of software, electronic or document CIs of known type and status. Access to items in a secure library is restricted. A secure store is a secure location where IT assets such as PCs, server and other hardware are stored. Definitive spares are kept in the secure store. Definitive spares are spare components and assemblies maintained at the same level as the comparative systems within the live environment.
23 SACM-Logical Model
We will now focus on the logical model of SACM. The configuration management’s logical model of the services and infrastructure is THE model. It is called so because it is a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier and customers. The image depicts the breakdown of two business services, e-banking and e-sales, into constituent IT services and components or CIs. The services provide a user experience that depends on the availability and Service Level Agreement or SLA. These services depend on IT applications, which are governed by business rules and underlying infrastructure such as data services or web services. The infrastructure is housed in a datacentre, and connected by a network. This might not be the actual architecture of the services, but logically such a model lets the customers and service providers give an overview of end-to-end services. This is enabled by the Configuration Management System.
24 Relationship between CMDB, CMS and SKMS
The image represents the relationship between CMDB, CMS and Service Knowledge Management System or SKMS. Service Knowledge Management System: Service Knowledge Management System is the complete set of integrated repositories or databases used to manage knowledge and information. The SKMS includes CMS, tools and databases. The SKMS stores, manages, updates and presents all information that an IT service provider needs. The information helps the IT service provider to manage the full lifecycle of services. The purpose of the SKMS is to provide quality information so that informed decisions can be made by the IT service provider. The SKMS consists of the following information: • The experience of the staff • Records of peripheral matters, for example, the user numbers and behaviour, and the organisation’s performance figures • Suppliers’ and partners’ requirements, abilities and expectations • Typical and anticipated skill levels of the user CMS: The CMS is maintained by Service Asset and Configuration Management and is used by all IT Service Management processes. Following are two major components of the CMS: • CMDB: It stores configuration details of the IT infrastructure. • Known Error Database or KEDB: It is the database created by problem management. The database is used by incident and problem management.
25 Introduction to Release and Deployment Management
Release and Deployment Management or RDM is one of the phases of service transition. This process aims at building, testing and delivering the capability to provide the services specified by service design. In the context of ITIL®, a release is a set of new or changed Configuration Items that are tested and implemented into production. Release management is responsible for planning, scheduling and controlling the movement of new or changed services, in the form of a release package. This applies to both the testing and live production environments. Deployment management is responsible for the movement of new or changed hardware, software, documentation or other Configuration Items into the live production environment. Release management is responsible for planning and scheduling the release. Deployment management is the team that implements the changes. Let us discuss some facts related to release units and release packages. A release unit is a part of the service or infrastructure included in the release, in accordance with the organisation’s release guidelines. For example, an organisation may decide that the release unit for business critical applications is the complete application. It ensures that the testing is comprehensive. A release package is a single release unit or a structured collection of release units. It includes all elements of a service. These elements are infrastructure, hardware, software, applications, documentation, knowledge and so on. A release package comprises the release unit of a business critical application, documentation, operations and end-user training.
26 Release and Deployment Management-Overview
An effective RDM enables the service provider to add value to the business by delivering changes faster. It also helps the service provider to deliver changes at optimal cost and minimised risk. Let us focus on the purpose, objective and scope of Release and Deployment Management. Purpose: The purpose of the Release and Deployment Management process is to plan, schedule and control the build, test and deployment of releases. The purpose is also to deliver new functionalities needed by the business while ensuring that the integrity of existing services is protected. Objective: The objective of the Release and Deployment Management process is to: • define Release and Deployment Management plans and get the customers’ and stakeholders’ consent on those plans. • create and test release packages comprising related Configuration Items that are compatible with each other. • make sure that all release packages can be tracked, installed, tested, verified, uninstalled or withdrawn. • record as well as manage risks, deviations and issues related to a new or changed service so that necessary corrective actions can be taken. • ensure that there is knowledge transfer. This enables the customers and users to optimise the service and support their business activities. Scope: The scope of Release and Deployment Management is to: • define processes, systems and functions to package, build, test and deploy a release into production. • establish the service specified in the Service Design Package or SDP before handing it over to service operations. • include all Configuration Items required to implement a release.
27 Release Policy
Let us now discuss the release policy. The release policy is the primary strategy for releases and is derived from the service design phase of the service lifecycle. The policy includes the following components: • Description of the release with its unique identification, numbering and naming conventions; it indicates the types of releases and how they are identified and tracked • The roles and responsibilities related to each stage of the process; it helps to identify the activities and the persons accountable and responsible for such activities in the release and deployment process • The expected frequency related to each type of release • The approach in which changes should be accepted and grouped into a release • The mechanism followed to automate the build, install and release distribution processes for improvement, repeatability, reuse and efficiency; the policy statement typically identifies the use of automation in release and deployment • How the configuration baseline for the release is captured and verified against the contents of the actual release, for example, hardware, software, documentation and knowledge; this refers to how the release and deployment process manages the integrity of the CI change and CMDB. • Entry and exit criteria, and authority for accepting the release at each stage of service transition and into the controlled training, test, production and disaster recovery environments • Criteria and authorisation to exit early life support and handover to service operations
28 Types of Releases
The three types of releases are major, minor and emergency releases. A major release contains large proportions of new functionalities. It is also known as a major upgrade that supersedes any preceding minor upgrade. A typical example of major release is windows service packs. A minor release contains small enhancements and fixes. A minor release or upgrade supersedes previous emergency fixes. A typical example of minor release is upgrading the routers to the latest version. An emergency release is linked to an emergency change. A typical example of emergency release is Microsoft releasing an emergency patch to protect Windows from malicious attacks. A key concept in Release and Deployment Management is the approach taken to deploy the releases. We will focus on such approaches in this lesson.
29 Release and Deployment Approaches
In the release design, different considerations apply with respect to the way in which the release is deployed. The most frequently occurring options for the rollout of releases are big bang versus phased, push versus pull and automated versus manual approaches. The big bang approach refers to the new or changed service being deployed to all user areas in one operation. It is often used when introducing an application change and consistency of service across the organisation, which is considered as important. The negative aspect of the big bang approach is that it increases the risk and impact of a failed release. Example: Installing the office software for 500 users at one stretch The phased approach means that the service is deployed to a part of the user base initially. Then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan. This approach applies to many scenarios such as in retail organisations. In such organisations, services are introduced into the stores’ environment in manageable phases. The push approach is used where the service component is deployed from the centre and pushed to the target locations. Example: Pushing the Antivirus software upgrades to the connected PCs from the server The pull approach is used for software releases. The software is made available in a central location, and users are free to bring the software to their own location as and when required. Example: Informing the employees to pull the software from the server when required The automated approach refers to automating releases using technology, which ensures consistency. The time required to provide a well-designed and efficient automated mechanism may not always be available or viable. Example: The common live updates from the vendors for their laptops or desktops The manual approach refers to distributing a release manually. It monitors and measures the impact of many repeated manual activities as they are likely to be inefficient and error-prone. Example: Installing the required Microsoft Office upgrades when required
30 RDM Phases
Let us now focus on the four phases of Release and Deployment Management. The four phases in RDM are ‘release and deployment planning’, ‘release, build and test’, ‘deployment’ and ‘review and close’. In the first phase, which is ‘release and deployment planning’, plans are created for developing and deploying a release. This phase starts with change management authorisation to plan a release. It ends with change management authorisation to create the release. In the second phase, which is ‘release, build and test’, the release package is built, tested and checked into the DML. This phase starts with change management authorisation to build the release. It ends with change management authorisation for the baseline release package to be checked into the DML. This is done by Service Asset and Configuration Management. This phase occurs once for each release. In the third phase, which is ‘deployment’, the release package in the DML is deployed to the live environment. This phase starts with change management authorisation to deploy the release package to one or more target environments. The phase ends with handing over the release package to service operation functions and early life support. There may be many separate deployment phases for each release, depending on the planned deployment options. In the last phase, that is ‘review and close’, experience and feedback are captured. In addition, performance targets and achievements are reviewed, and lessons are learnt. This marks the end of the Release and Deployment Management process. Take a look at the example of release management.
31 Introduction to Knowledge Management
We will now discuss the next process in service transition phase, which is knowledge management. The ability to deliver a quality service or complete a process depends on the ability of those who are involved in it. The ability depends on their understanding of the situation, consequences and benefits, which are collectively called the knowledge of that particular situation. Following are the facts related to knowledge management: • Knowledge management provides support for the capture and effective publishing of knowledge that surfaces during service transition and other phases. • The quality and relevance of the knowledge rests on the accessibility, quality and continued relevance of the underpinning data and information available to the service staff.
32 Knowledge Management-Overview
Knowledge management is significant within the service transition phase. This is so because testing and validation data is gathered in this phase prior to release into the live environment. Let us now understand the purpose, objective and scope of knowledge management. Purpose: The purpose of the knowledge management process is to: • share perspectives, ideas, experience and information. • make sure that the information is available at the right time and in the right place. This helps to make informed decisions, and improve the efficiency by minimising the need to rediscover knowledge. Objective: The objective of knowledge management is to: • improve the quality of management decision-making by ensuring that secure and reliable information is available for the service lifecycle. • ensure that the right information is delivered to the appropriate place or person at the right time to enable informed decisions. • maintain a SKMS that offers controlled access to information, knowledge and data that are appropriate for each audience. Scope: The scope of knowledge management is to: • provide knowledge throughout the service lifecycle. • manage knowledge, information and data on the identity of stakeholders, available timescales or resources and acceptable levels of risk and performance expectations. Knowledge management is visualised using the Data-Information-Knowledge-Wisdom structure.
Data-Information-Knowledge-Wisdom or DIKW is the heart of the knowledge management. Effective sharing of knowledge requires the development and maintenance of SKMS. This system should be available to all information stakeholders and suit all information requirements. Data is a set of discrete facts. Most organisations capture significant amounts of data every day in the form of metrics. Information comes from providing context to data. This requires capturing various sources of data and applying meaning or relevance to the set of facts, for example, reports on metrics. Knowledge comprises the experiences, ideas, insights and judgements from individuals. This requires the analysis of information, and is applied to facilitate decision-making. The use of wisdom enables an organisation to direct their strategy and growth in competitive market spaces. Wisdom provides the ultimate understanding of the material. Developing an awareness of the application and context enables a strong common sense judgement. Quantitative data from metrics are transformed into qualitative information. Knowledge is obtained by combining information with experience, context, interpretation and reflection. It can be used to make the right decisions, which leads to wisdom. Tools and databases can be used to capture data, information and knowledge, but wisdom cannot be captured in this way. Wisdom is a concept relating to the abilities to use knowledge for making correct judgements and decisions.
Let us summarise what we have learnt in this lesson: • The purpose of the transition, planning and support process is to provide overall planning for service transitions. • Change management includes changes to baselined service assets and Configuration Items across the service lifecycle. • Service Asset and Configuration Management provides the information required to manage CIs and assets across the service lifecycle. • The purpose of RDM is to plan, schedule and control the build, test and deployment of releases. • Knowledge management ensures that the information is available in the right place and at the right time. Next, we will look at a few questions based on this unit.
About the On-Demand Webinar
About the Webinar