THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
The learning objective for this chapter is to gain sufficient knowledge of service transition principles, techniques, and relationships to be able to understand how these are applied to ensure new, modified, or retired services meet the expectations of the business.
Unless setting up an entirely new service provider organization (in what is known as a greenfield situation), we are seldom in the position of implementing service transition processes from scratch; even badly run organizations will have some process for introducing new services, however inadequate. In the vast majority of cases, we shall be attempting to improve current processes. The ITIL Continual Service Improvement publication provides guidance on assessing the current approach to service transition processes and establishing the most effective and efficient improvements to make, prioritized according to the business benefit. The syllabus for the ITIL CSI Intermediate exam, which covers this guidance, is covered in Part 5 of this book, in Chapters 43–50. The CSI approach to implementing improvements, as shown in Figure 30.1, should be used. We have seen this diagram before; the CSI approach applies to all stages of the service lifecycle.
Introducing new or improved service transition processes will mean a significant organizational change. It should also improve the services delivered by the service provider. Logically, the guidance on delivering new or changed services contained in the ITIL Intermediate Service Transition course (which is covered in this section of the book) applies to introducing service transition itself. Although, as we have said, this is seldom carried out from scratch, implementing improvements to service transition is itself a service transition exercise. It will result in a change to how services are delivered by the service provider, and as with any transition, this carries a risk of disruption unless done carefully.
The key activities in the introduction of service transition are as follows:
We are going to look at each of these in turn, but first you should note that the preceding list conforms to the usual service lifecycle; the justification stage is strategy, the design stage is design, introduction of components is transition, and business as usual is operation. Once implemented, the process will be subject to continual service improvement.
Effective service transition is essential if the service provider is to deliver quality services to the business. Transition delivers the design into day-to-day operations. If service transitions are executed successfully, the processes behind that delivery are invisible to customers; this means that they do not understand the importance of ensuring that these processes are properly resourced. A failed service transition will highlight a lack of or inadequate processes, but the challenge is to show the business how important they are, without having to “prove” it through a failed transition. To win the support of stakeholders for the implementation or improvement of service transition, the service provider must show them the benefits of such an initiative. The benefits should be quantified as far as possible, showing the balance between the impact to the business (negative and positive) and the cost. The negative impact of delayed implementation should be emphasized.
To justify improvement, the service provider may need to provide evidence of the costs that have resulted from previous failed changes, such as budget overruns and the number and impact of errors found in live running that could have been detected during test transition.
The design of service transition should ensure that all the required legislative standards and policies are incorporated. Examples of such requirements include Sarbanes-Oxley regulations and/or the rules governing organizations responsible for the management of credit card payments.
The new or changed IT service will often be there to support new business practices. In many situations, service transition must work together with parts of the organization that are transitioning other elements of a business change, such as HR, facilities management, education, and training. The processes should facilitate these relationships. The implementation of the business change can involve many parties, so it is essential that ownership of each component of the overall service is clear.
In addition to these other internal support services, service transition includes working with other stakeholders:
Although service transition provides an overall net benefit to the organization in that it saves the disruption and expense of failed changes, it has to be funded itself. The service transition strategy needs to address who provides the funding and the level of funding that is required. For example, service transition requires an infrastructure including testing environments, a CMS, and an SKMS.
The costing of transition objectives must be an integral part of design, whatever the funding mechanism may be, and will involve service transition and customers working with design.
The responsibility for the provision of the resources required by service transition must also be decided. These resources will include staff, test data, and network resources. The maintenance of the test environment is a significant cost item, but failure to fund this adequately or to provide the staff resources required will lead to inadequate testing, with the consequential risk of failed changes.
Careful consideration should be given to the introduction of service transition to existing projects. It will be practical to introduce these processes only when the project is at the transition stage, rather than attempting to “retrofit” the desired practices at an earlier stage. When bringing existing projects into the new process, the conversion from old to new process should be considered. This transition from one process to another needs to take place without risking the successful transition of the project. The conversion from old to new should be designed (and tested where possible) as part of the design responsibility.
Even if procedures already exist, formalizing them may meet with resistance and will involve a degree of cultural change.
The support of service transition staff and those supporting and being supported by service transition need to understand why the changes to procedures are being made, the benefits to themselves and to the organization, and how their roles will change. A cultural change program is required that addresses all stakeholders. This should continue throughout and after transition to ensure that the changed attitudes are firmly embedded.
As with all transitions, decisions around transitioning should be made only with a full understanding of the expected risks and benefits. Alienation of support staff, excessive costs to the business, and unacceptable delays to business benefits are all examples of possible risks. Measures of the benefits resulting from service transition might include customer and user satisfaction, reduced incident and failure rates for transitioned services, and reduced cost of transitioning.
The risks and beneficial values require a baseline of the current situation if the changes are to be measurable.
During the initial period immediately after the new processes are introduced, there should be extra support provided to ensure that staff have the guidance they need until the processes are fully understood and embedded. This early life support is a feature of all types of service transition. Following the successful introduction of service transition processes, the processes should be used for all transitions. Reporting the benefits of each transition should help to win over those who were previously unconvinced because in operation these benefits can be proved. There will be a need to adjust the processes over time to better fit the requirements, and this should be done in conjunction with continual service improvement.
The processes involved in the service transition stage of the service lifecycle are inter-independent. The relationships between them are complex, and it is not possible to design and implement them separately. The diagram in Figure 30.2 is a simplified example of the steps that might be required for a single service transition.
An integrated plan for introduction or improvement of service transition processes must consider how the processes fit together and the roles and responsibilities of all those involved. It must match the inputs, outputs, and triggers of each process step with the corresponding steps in other processes. Such a plan would include the following items:
Implementing virtualization or cloud architectures will have an impact on how an organization manages the design, implementation, and operation of service transition. These technologies pose particular challenges due to the dynamic nature of the environments involved. They often require rapid provisioning of new virtual servers or migration of virtual servers between hosts to support changing workloads. Many activities such as the following examples will be automated:
The automation required in virtual and cloud environments can be an opportunity but may also cause difficulties when implementing service transition processes. The challenges will need to be understood, and the processes need to be designed to work under such circumstances. This may necessitate more sophisticated tools, which will then need to integrate with the existing tools.
Configuration information is particularly challenging in this environment because configurations are so dynamic. The service provider might choose to document all allowed configurations and identify preferred configurations for use by the incident, problem, and change management processes as well as others. Alternatively, it may be sufficient to document the high-level configuration and use discovery tools to identify the current state when needed. Factors, such as the agreed warranty for the service and the specific service levels, will need to be considered when deciding which of these approaches is appropriate. The virtual or cloud architecture may also require the creation of new configuration item (CI) types, release models, change models, and standard changes. In addition, managing this technology will require different tools, activities, authorities, roles, and responsibilities. Adopting cloud or virtual architecture will therefore require new operational level agreements and underpinning contracts. There may be changes required to change, release, and deployment processes to ensure that they work in both physical and virtual environments. Where external services are used, the supplier management process becomes even more important because the services using the cloud architecture are likely to be business critical.
The service asset and configuration process may actually become easier if an organization uses a public cloud because most of the underlying complexity will be managed by the external service provider. The organization still needs to carry out service asset and configuration management, but the CIs are likely to be at a much higher level.
This chapter covered the implementation and improvement of service transition in an organization.
We explored the following topics:
Be able to list the other stakeholders involved in service transition. Successful transition requires understanding who is affected and building the required relationships with affected groups, whether these are in the business, external to the organization, or other service provider teams.
Be able to explain and describe the four key activities in the introduction of service transition. It is important to understand that the organization needs to know why service transition is necessary and the benefits it will bring. Also, the introduction of the process is like any other transition; it must be designed, and the introduction must be planned so that it goes smoothly. Finally, it needs to be embedded.
Understand the interrelationships and dependencies between the different service transition processes. Know why the processes need to be introduced together and the importance of an integrated approach, such that the outputs of one process provide the required inputs for the next.
Be able to describe the particular challenges of implementing service transition in a cloud or virtual environment. Understand how some aspects may be easier, due to automation or the level of management provided by the external supplier, and some may be more challenging, due to the dynamic nature of such environments.
You can find the answers to the review questions in the appendix. Which of these statements is/are correct? Which of these are valid activities for service transition involvement? Justification for service transition may require evidence of poor transition. Which of these are examples of evidence of poor transition? Which of these is a key consideration for justifying service transition? True or False: An integrated plan for introduction or improvement of service transition processes should be based on an understanding of how the processes fit together. Which of the following shows the correct order of the steps in the CSI approach, together with the correct matching inputs? Which of the following are possible challenges when seeking support and funding to introduce or improve service transition? Service transition may require liaison with other stakeholders. Which of the following are among possible stakeholders listed within the ITIL Service Transition publication? Which of the following statements about the introduction of service transition processes is/are TRUE? Which of the following statements about implementing service transition in a virtual or cloud environment is/are TRUE?Review Questions