Roles and responsibilities in the ITSM change management process, goals, the 7 Rs, and differences between ITIL v3 and v4 – to keep you on top of things in ITSM.
Contents:
Changes in IT can quickly lead to problems: Be it the simple replacement of a workstation computer, the introduction of new software, a switch to the cloud or increased security requirements. In order to optimally implement such innovations in the company, firmly defined processes help. With change management, the entire process can be better planned. This minimizes risks and avoids interruptions. The goal is to always further develop the existing IT strategy.
The 7 Rs of IT change management are a checklist of relevant aspects that should be considered when creating and processing a change request. The seven simple questions help to launch changes in a structured way, which would otherwise be rejected because of too many ambiguities.
In the abundance of departments, contact persons and co-decision makers, change requests on demand are a guarantee for chaos. First, we need to clarify where the request comes from. For whom are we doing this? Where do I get answers to queries? Systematically documenting this is the first step for structured IT change management.
Why are we doing this? For what reason is the change needed? A good solution is worth nothing if it solves the wrong problem. On the other hand, a change often sketches out solutions that block the view of a better idea. If we gain clarity about the reasons for the change, risks and opportunities can be better assessed. For important issues, we then look for the solution that best fits the context, while avoiding high-risk changes with minimal business benefit.
The portfolio analysis along the four-field matrix helps with the classification, whereby the changes can be sorted along the two axes (1) impact (e.g., number of users and devices) and (2) urgency, similar to incident management.
Nobody knows the future and yet it is important to play out different scenarios. What should the change result in, so that we can say afterwards: it was worth it. Not every change translates directly into customer benefits that justify a surcharge for the software, for example in the form of a software feature. The automation of time-consuming manual tasks, on the other hand, can free up capacities in development for innovations. Automated regression and load tests relieve technical support. The reduction of technical debt keeps the development environment future-proof so that it can react quickly to innovations on the market. These soft factors need to be translated, as well as possible, into hard metrics with an eye to costs and benefits that can be used to prioritize.
While we focus on the optimistic side of returns with a best-case scenario at the end of the scale, we take a pessimistic view of risks with a worst-case scenario. Every change involves risks. Some can be avoided, others may have to be accepted if the opportunities on the one hand or the disadvantages of not implementing the change on the other hand outweigh the risks. But it is to be expected that changes in one part of the system will have an impact on other areas. The consequences should therefore be worked through in advance.
At the macro level, this is always about time and money. At the micro level of IT change management, it is about people (skills) and machines (capabilities). These do not exist – or are missing – in a vacuum. If the forces are tied up in one project, they are missing in another. Do we tackle both anyway? At the same time? What delays occur elsewhere when we implement a change? The question does not stop with the internal IT organization, but encompasses the entire customer value chain all the way to the customer. Answers to these questions must also be incorporated into the prioritization of IT projects.
Who is going to do it? Who builds, tests and implements the change? In most cases, there are different people in the team or even different departments for the individual sub-steps. Therefore, it is all the more important to make responsibilities transparent and comprehensible on the one hand, and thus implementable and enforceable on the other. It is then unmistakably clear who must take action for which task and, in the event of failure, unproductive recriminations can be avoided. Throughout change and release management, responsibility must be clearly distributed and transparent to all.
IT environments are complex and have many dependencies across other areas and functions in the system. Sometimes it is enough to point out effects in other areas, in other cases you have to rely on their preliminary work. An integrated configuration management database (CMDB) makes mutual dependencies transparent and enables joint time and sequence planning for implementing changes with the least possible downtime and time delays.
In order to optimally implement IT change management in the company, changes must always be made according to defined points. First, the current state must be analyzed and the target state defined. Then a schedule is drawn up for the change. A test model helps to prevent problems - for example with service quality. If the test model runs, the change is implemented as planned. This works more easily if the ITSM processes are supported and standardized with service management software. This should meet the following requirements:
ITSM software is a powerful tool that can greatly enhance change management processes. However, it's important to remember that success is not solely dependent on the tools and policies in place. Ultimately, it is the people within the company who drive its success. After all, it is the dedication and hard work of employees that create value for customers. Their expertise and commitment are essential in ensuring a smooth and efficient change management process.
After successful implementation, the entire process is evaluated. What should be optimized next time? Were all set goals achieved? Was the schedule adhered to? It is best to use a dedicated change manager for this review, who monitors and constantly optimizes the entire IT service management project.
Despite all the technical support, the people behind it must not be forgotten. Tried and tested, sometimes beloved processes and routines have been established for years. Changes can therefore quickly lead to discontent, demotivation and political intervention at management level.
ITIL 4, which is based on the principle of "simple and practicable", provides a remedy. While the 26 life cycle processes from ITIL 3 formulate relatively rigid, rule-based procedures, the 34 management practices from ITIL 4 grant freedom for defining customized processes.
ITIL v3 |
ITIL v4 |
| Describes change management as a process in service transition. | Describes change management as a service management practice and calls it change enablement. ITIL v4 lists the basic activities in change enablement as well as the key inputs, outputs and roles. (IT) organizations can use these guidelines to design a customized process for managing changes that reflect their individual requirements. |
Process steps:
|
Change enablement practice: The change management process according to ITIL v3 does not become obsolete and can be used as a template for individual adaptation in the IT organization.
|
| Focus on service transition and deployment |
Focus on the service value chain including the design and development phase Change enablement should be designed to keep the end-to-end service management value chain in mind. An iterative approach is designed to balance rapid implementation of an RfC on the one hand with managing the associated risks to existing services on the other. |
Let's take a deep dive into the process by illustrating it with a real-life example.
Christian Klaus has a problem. After a serious failure in his company's IT system, he is called upon to revise the change management process. He clearly focuses on risk management, one of the seven requirements in ITIL Change Management.
The trigger for Christian's headache was a small change to the hardware in a regional branch. The glitch had spread area-wide and ended up severely impacting the entire organization's communications and video systems. Employees in the home office were cut off. Meetings between management and customers as well as suppliers could not take place. IT worked for three hours until essential business processes were up and running again.
As an ITIL expert and process owner for IT change management, Christian was now aware of all the factors that had led to the outage.
The root cause analysis had been performed, but there was no post implementation review. The change in the field office had not been approved by the change process, nor had it been made by a qualified and authorized person.
The change management process provided concrete steps for risk management to prevent precisely such failures. In addition, two years ago Christian and the IT change manager had already drafted a policy that defined the best practices of change management according to ITIL and mapped them for the company's own IT organization. Regular training sessions were held for the teams, in which the content was repeated and discussed. All of the specifications from the risk management section of the change management policy had simply been ignored - they had simply not been taken into account.
Change can only succeed if it is clear what you are doing it for and everyone involved has confidence that the effort can succeed. Creating this transparency and confidence was Christian's biggest challenge.
Christian did not have to do much convincing to prevent future failures like the recent one in the communications systems. No one wants errors and inconsistencies in the process workflow, disrupted processes, failures and escalations. Everyone who wanted a cleanly functioning, high-performance IT infrastructure could agree on simply regulated, comprehensible and well-documented processes with clear responsibilities and controlled risk management.
Christian summarizes his plan:
He would make a strong case for his list of requirements for the future ITSM tool in the purchasing process. In doing so, he would once again emphasize the importance of an integrated Asset & Configuration Management Database and underline the connections with the recent incident.
At the same time, he would push to add to the Request for Information (RfI) those aspects that did not solely serve process-related, system-related functionalities. Tool functions that enable transparency and automation and thus make routine work superfluous should be given more weight. More attention should also be paid to ease of use across different devices and channels.
Only then, he was sure, would colleagues quickly embrace the changes. Only then could the changes be quickly activated in the IT change management process. And only under this condition can systems be optimized, processes improved and major failures reliably prevented in the future. Business goals are thus better achieved and digitalization in the company is driven forward.