THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
The learning objective for this chapter is to gain sufficient knowledge to implement service operation. Upon completion of the chapter, you should understand the specific issues relevant to implementing service operation.
This chapter covers how the IT service provider manages changes within service operation. We start by considering the challenges of managing change in operations. The focus in the operational stage of the lifecycle is on protecting the live services, so changes in service operation must be absorbed without impacting stability. We will examine the many different triggers that cause changes to the live environment and consider how the changes are assessed before implementation. Finally, we will look at how changes can be measured to see if they are successful.
There are many events that can trigger a change in the service operation environment:
Service transition would be responsible for planning these changes, but service operation has to be ready to absorb them without them disrupting the services provided.
All changes have a potential impact on operations. This is not always understood by nonoperations staff, so it is essential that service operation staff have an opportunity to assess all changes. It is not sufficient to involve operations staff at the CAB stage because it may be too late; fundamental decisions regarding the design of the new or changed service will have been made far earlier. It is unrealistic to think that a redesign could happen at such a late stage. To prevent this, it is essential that operation staff are consulted and informed much earlier, during the initial design stage, and remain involved throughout.
It is good practice for the change manager to inform all affected parties of the changes being assessed so that affected areas (in this case, the service operation area) can prepare a response showing the operational impact of the change and setting out any concerns. This can be distributed prior to the CAB meeting to inform the discussion.
Service operation staff need to be involved throughout the design and implementation of a change with an operational impact. Early involvement is necessary to ensure that the design takes account of operational issues and requirements; involvement in the later stages is necessary to ensure that the change is scheduled to avoid potential disagreements or particularly sensitive periods.
The ultimate measure of a successful change made to service operation is that there are no unexpected variations or outages; the only visible effects are the benefits that result from the change, such as enhanced functionality, quality, or financial savings.
The use of project management processes to manage changes is commonplace in other lifecycle stages, but there is often a disinclination to use these processes for operational changes. Service operation is generally viewed as “business as usual” and does include a project approach. In fact, project management processes are both appropriate and helpful for major infrastructure upgrades or the deployment of new or changed procedures; these significant tasks will benefit from the improved control and management of costs and resources delivered by project management. Using project management to manage these types of activity would deliver a number of benefits:
The overriding concern of service operation is to maintain stability; any threat to that stability has to be assessed and acted upon urgently. An obvious example of a situation in which service operation needs to carry out a risk and impact assessment is the risk to stability from a potential change. Service operation staff must assess the possible impact of the change and share this assessment with the CAB.
A change might be implemented despite the existence of known errors that become apparent during testing but were not considered serious enough to delay the change. The existence of such known errors poses a risk to operational stability; until the errors are resolved, incidents resulting from them can recur. The impact of these incidents and the effectiveness of the appropriate workaround for each (including the speed at which it overcomes the fault) must be assessed. The results of this assessment will feed into the prioritization of the problem. Having a proven workaround mitigates the risk to a certain extent because, although the fault will occur when the service is operational and will therefore impact the business, a quick fix can reduce the impact of the incident.
Every incident, whether reported through the incident and problem processes, through a warning from the supplier, or by event management, will be assessed for impact and urgency to calculate its priority. This assessment is also an assessment of the risk it poses to the business. Finally, new projects that will result in delivery into the live environment are assessed because there is a risk that they may impact other services.
There are other risks to operational stability that would require a risk assessment. The first is an environmental risk. Environmental risks would include the sorts of risks that are assessed as part of IT service continuity planning, such as fire and flood. There may also be political and commercial risks and risks related to industrial relations. Examples of these are the risks faced by drug companies that carry out testing on animals and therefore may be subject to sabotage by those opposed to this practice, the risk of strikes affecting operation, or even the risk of a competitor engaging in a price war, which would drive down the income received.
Suppliers may also constitute a source of risk. Their failure to deliver could affect the delivery of the overall service. Their ability to provide a service might also be affected by their own internal risks. This is particularly a problem if they are the sole supplier for a particular element of the service. Taking on new suppliers also involves some risk; without a known track record of reliable delivery, there is a risk that their service may not be satisfactory. Another major area of risk involves security; security-related incidents or events may result in either theoretical or actual risks. Finally, every new customer or service to be supported is both an opportunity to be successful and a potential risk for failure.
All IT groups will be involved during service design and service transition to ensure that new components or services are designed, tested, and implemented to provide the correct levels of functionality, usability, availability, and capacity. Additionally, service operation staff must be involved during the early stages of service design and service transition to ensure that when new services reach the live environment, they are fit for purpose from a service operation perspective and are “supportable” in the future.
In this context, supportable means that they will not negatively impact other services, processes, schedules, or operational working practices. They must also be capable of being operated by the current staff, at an understood cost. The support structure, including both the internal support teams and the support provided by third-party suppliers, must be clear and understood. There should be no unexpected costs after the service goes live, and contractual obligations must be clear and straightforward.
Note that change is not just about technology. There is also organizational change to consider, and the possibility that staff or users may be hostile to the change. It is possible to reduce the risk of people resisting change through a program of communication and training. Further details about organizational change are included in ITIL Service Transition.
The final topic of this chapter is service management tools. A good service management tool can be very helpful for implementing processes based on the ITIL framework. Many organizations implement new tools to assist their implementation of new or improved processes. There are a number of factors that these organizations need to consider if the new tool is to be helpful and appropriate.
The first factor to be considered is the type of license. There are usually a number of options, at different costs. Where tools are licensed on a modular basis, careful planning is needed to ensure that the right access is obtained to enable people to carry out their work with no unnecessary modules being purchased. Here are some possible options:
In all cases, it is essential than sufficient investigation has been done to ensure that the costs are understood and agreed and that the organization remains legal in respect to having sufficient licenses.
Many ITSM tools, particularly discovery and event monitoring tools, will require some client/agent software deploying to all target locations before they can be used. This will need careful planning and execution and should be handled through formal release and deployment management. Some deployment considerations are listed here:
Remember, a tool is usually not enough to make things work better. However, if it supports processes and the user has been trained to use it, a good tool can help staff carry out new processes.
Here are some further aspects of the deployment that must be considered:
Complete details on the release and deployment management process can be found in Part 3 of this book, “Service Transition.”
In this chapter, we discussed managing change in service operation and, in particular, the need to assess and manage risk. We looked at the involvement of operations staff in service design and service transition and aspects to consider when planning and implementing service management technologies within a company.
Understand the need to manage change within service operation so it can be implemented with the minimum adverse impact on the service and its users. Understand the possible triggers for change and how and why changes are assessed and measured.
Explain how project management processes can help in the implementation of changes in service operation. Understand the benefits of using project management processes to implement changes in service operation and the reasons why it might be resisted.
Know the risks that change poses to operational stability. Understand how these risks might be managed.
Understand why service operation staff need to be involved in the design and transition stages. In particular, understand what the concept of a service being supportable means and what is required for this to be the case.
Understand the license options available when implementing a new service management tool. Be able to describe the different options and give examples of when each would be appropriate.
Understand the deployment options available when implementing a new service management tool. Be able to describe the different options and give examples of when each would be appropriate.
You can find the answers to the review questions in the appendix. Which of the following are valid triggers for making changes to live services? Which of these statements is/are correct about the result of successful change in service operation? True or False? Service operation personnel should be involved during service design and service transition to ensure that new components or services are correctly designed, tested, and implemented. How can a service management tool assist in service operation? Which of the following is NOT a benefit of using project management for complex operational changes? Which of these may be a trigger for changes to service operation? Which of the following best describes when service operation staff should be involved in the design and implementation stages? Which of these statements is/are correct about the management of change in service operation? Which of the following is a potential risk in service operation? Which of the following is NOT a license option for service management tools?Review Questions