The purpose of the Change Control practice is to maximize the number of successful IT changes by ensuring that the risks have been properly assessed, authorizing changes to proceed, and managing the change schedule. It used to be called Change Management and it's all about making sure that before you make a change, you have understood the risk, know who approved it, and manage it on the schedule. You want to balance the beneficial effect of changes against protecting yourself from adverse effects of changes because every time you change something, you're introducing a risk of failure, so the change has to be worthwhile.
You would like things to be stable and working properly, but it would not hurt to add new features and value. A lot of times you have to make changes, but that's going to affect the stability of the system and you want to be able to manage that risk using risk management, as well as this Change Control. The scope of Change Control is defined by each organization. This is something that is going to be decided by your governance, policies, and procedures within your particular company. It's going to include all of the IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service that you're going to change.
At this point Dion Training recommends that you comb thru out previous articles as one of them mentioned there are seven terms that you have to learn definitions of during the study of ITIL 4 practices. The first one is called a change. A change is the addition, modification, or removal of anything that could have a direct or indirect effect on IT services.
Aside from the definition of a change, there are three different types of changes. There are standard, normal, and emergency changes. A standard change is something that is pre-authorized. It's something that you can implement without additional authorization. You do not need authorization for it because it's something you do all of the time, the risks are well understood, and therefore it's going to be low risk. A good example of this would be if somebody calls up and asks to reset their password. That is something that a service desk analyst can do on their own, they don't need any kind of approval, because it's already been pre-authorized. This is a simple, well understood change, but it is still a change to the system. The second type of change is a normal change. These are changes where authorization is needed, but that level of authorization is going to be based on the different types of change and how risky that change is. If it were a low or a medium risk, but you don't consider it a standard change, it's going to go through the normal process, and the person who approves it is called a Change Authority. That Change Authority might be your supervisor or your supervisor's boss. A major change might be something that is really complex, need a higher level of approval, and it might go all the way up until you get a very senior Change Authority. The type of change is going to depend on how your organization does it, how much tolerance they have to risk, and how they want to set it up. However; there are times that you are in a rush, and this is when things come up like an emergency. And That is the third type of change - emergency changes. These are going to be expedited, and they are going to have an expedited assessment and authority process. It may be that there's a separate change authority for something that is an emergency. An emergency is when you're really trying to get something back up quickly and it needs to be gotten up right now.
A lot of organizations will use their emergency as something as a normal way of business, but you don't want to do this. Just because somebody wants the change done today, doesn't mean that it's necessarily an emergency. It maybe they just forgot to plan. This means that you have to think about what really an emergency is versus what is normal and should go through the normal process. If something is broken and is vital to your business operations such as a broken conveyor belt in the production line, that's usually going to be an emergency.
As mentioned above, the person or group who authorizes the change is called a Change Authority. In very fast-moving organizations, it's common to have this decentralized, and you might have many different Change Authorities depending on what's going on. In fact, if you're doing software development, your Change Authority might be the person sitting next to you. It might be that you review their code and they are just close by so they can approve your code. But in big organizations, a lot of times you want to do things much more formally, and you'll go through this normal change process, and have a formalized Change Authority.
Once something has been approved from the Change Authority, it goes on to the Change Schedule. The Change Schedule is used to help you plan those changes, assist in communicating that, and help to avoid conflicts and assign proper resources to it. The idea of having a Change Schedule in place is for you to know what's going to happen, you can tell those who are working with you about it in advance, and that way everybody knows. It's well coordinated, well planned, and well communicated. By doing that, you can make sure you have your top-level guys sitting there, ready to go when you make this change. And if anything goes wrong, you have the A list people there who can fix it and make it right.
When looking at all of this change stuff, it does affect different parts of your Value Change activities. For example, you have a part in Plan. Changes for your products and service portfolio, policies, and practices all require some amount of control and planning. Plan is going to help you with that. You also have a lot of improvement initiatives and those are going to be where changes are made. For example, if you want to move from an old server to a new server, that's a change. You're going to use the Change Control as part of the Improve activity. When you look at Engage, your customers and users need to know what kind of changes are coming, when downtimes are, and they should be able to expect the nature of that change. By communicating this, you're engaging with your customers, so you're going to use that Engage activity.
Then, if you look in Design and Transition, these changes are all designed and initiated somewhere. Usually in Design, and then Transition. Once a change is approved it goes into transition to be made into a reality and put into your real network. This is where the Change Control activity is a major contributor into the transition phase. Then you're going to obtain and build things. Anytime your organization wants to change something, it means you're probably buying something new, whether it's software or hardware, or you may be building some kind of custom software in-house, all of that goes on in the Obtain/Build activity.
Once it's ready, it's going to be an input into this Change Control practice, so that you can get it approved and transitioned onto the real servers. And finally, Deliver and Support activity. Changes can have an impact on Deliver and Support. They can have a huge impact there, because if you put a new server that changes the way they have to do their processes, that changes the way they do their procedures.
All that stuff is going to be changed. You'll also want to make sure you are communicating the changes both to your users and to the personnel who have to support those users. If you don't tell the Service Agents that you've gone from server 2012 to server 2019, and they now have to support 2019 without any training, that's not going to end well. Change is going to make sure that you're thinking about those types of things as well. Make sure everybody knows what change is coming and communicate that well, so everyone is ready.