Join Mark Thomas for an in-depth discussion in this video Change management, part of Cert Prep: ITIL Foundations.
- Okay, so we've hit transition planning and support, we've hit service asset and configuration management as a part of service transition, let's start talking about Change Management. Probably one of the most popular out there, a lot of people talk about Change Management. And this is a process that can be done really really well, or it can be done really really bad. And you have to have this process well understood, because what happens in an organization if your change process is not functioning properly, right? We deploy improper changes into the production environment or into operation, and it causes incidents, it causes more pain for, so we start reacting, and then we add more changes on top of that, then we might introduce more errors into production because we haven't really looked at the risks, we haven't looked at the relationships between configuration items, we haven't done the diligence to ensure that that change has a positive effect on the business environment.
So, changes are standard, right? We have, change is going to take place. We have to embrace change and so therefore we have to have a process that allows us to achieve the business benefits we need by making those modifications, additions or deletions into the production environment or the operation environment. And those are, you know, proactive or reactive kinds of things, so we are making changes into the environment to seize market initiatives, right? To add new services, or we might be making changes as a reaction to something that is not working properly.
So, a lot of different pieces involved here that I think are good to know. So, change management, controlling the life cycle of all change, enabling the business benefit with minimal disruption to the business. So, what the business is expecting from us is the changes that are required, when those changes are required with minimal down times. So we want to reduce the amount of disruption that our customers are going to have because we're making these alterations into the environment. So, basically what we're doing here is we are responding to the customers' changing business requirements.
Now, I've had folks say, "Well, but a lot of our "requests for change are generated within IT." But every one of those have some business benefit, right? You can map that change all the way up to the business functions that it's going to support so that it maximizes the value of IT, maximizes the value of those configuration items that are being changed. And so, we're reducing the change related service failures, disruption and rework. Nothing is more frustrating that when my service desk is working on an incident, and the first question that comes up says, "What changed?" "Oops, there was a change made last night," that was either done improperly or was unauthorized, and it causes more disruption for us, and so more rework has to be done.
So therefore, we might have to now look at emergency changes, and possibly add more risk into the environment, and therefore to our customers' processes, okay? So, making sure that we're responding to the business and IT requests for the change that will align services with the business need. Is it the right change? Are we doing this the right way? Are we minimizing the amount of risks that we are going to introduce as a part of this change? And these are some very important things that the role called the Change Manager, and the process called Change Management, really have to make sure we understand.
So, ensuring that changes are managed in a controlled manner throughout the life cycle. There's a life cycle of these changes, from when it's requested through when it's actually deployed. And that change is now, is a live service or a change service that's being handled by the operations team. There's a full life cycle, Change Management controls that entire life cycle. Now Change Management doesn't actually do the deployment, doesn't do the Build, Test and Deployment. That's another process called Release and Deployment that does that stuff. But the change has to control that.
So some things that we have to ensure that we've got as a part of this change, is that we have to have a remediation plan. What do we do if this change is in and it's either not working, it's not working properly, it's not getting the expected benefits. Or we're into deploying that change and we find out that we either don't have enough time or we weren't prepared, and we have to back that change out. Every change request has to have some remediation plan that comes along with that. What are we going to do? How are we going to remove that change? Again, with minimal disruption on the customer side.
So, those are the things that, kind of, think about as we're looking at this. Let's move on to the next piece and talk about some key concepts of the Change Management process, okay? So, a couple of things that I want to make sure that I hit here, first of all, we've got something called a Service Change. And what is a Service Change? It's any addition, any modification, or removal of authorized, planned or supported service or service component, CI, and its associated documentation. So, Service Change. Remember, we've got services that we're providing to our customer, changes, modifications, removals of those changes, is what we might consider a Service Change.
Now, one of the challenges you run into in Change Management, is a lot of folks say, "Well, who actually does the coordination? Who "does the actual, you know, the deployment of this stuff?" Remember, we've got a couple of other processes here in service transition. Change is controlling the life cycle of that change. Transition planning and support is ensuring that the coordination is done across the transition phase itself. Release and Deployment management is actually ensuring that we're doing the Build, Test, Delivery of the deployment. Knowledge Management is capturing the pertinent information that we need to be able to store that on that newer change service for future use, okay? And so, there are different types of changes that you run into, and I always hear that the saying, and you hear this a lot of times, and you may heard this yourselves.
A CIO or a Director of IT says, "If you make an unauthorized change in the production "environment, there will be, you know, a price to pay." Well, that's a great policy, but you have to be careful because there are certain things that you can preapprove for example, okay? And so, these are what we call Standard Changes. Let's take a look at the different change types here for a minute. Let's take my service desk, for example. My service desk, they do password resets, okay? Technically speaking, a password reset is some type of change to configuration items, right? And so, does that mean every time my service desk does a password reset they have to request an RFC, has to go to the Change Advisory Board and be requested for everyone of those? No.
I may have technical resources, let's take my Sys Admin or maybe my DBA, let's take my DBA for example. Again, this is not, an absolute standard change for every organization, remember I'm just using this as an example. Let's say my DBA adds table space to tables, and let's say, it's a routine, they do it on a routine basis. And so my DBA comes and says, "Every time I add "table space, do I need to come and get "a RFC and go through the Change Board?" Well, let's put that through the Change Board and see, that might be a good candidate for a Standard Change.
So, what are the characteristics of a Standard Change? Well, it should be low risk, well understood, we should have a pre-defined set of steps. I can grant you local authorization to be able to do that, and it's a very low risk type of change that can be made. And we can approve it at the Change Board, and nominate you to be able to make those changes that you need to, okay? That's what a Standard Change is all about. So it's gives you the local authorization to make relatively low risk, well understood, has to have a trigger to kick that thing off.
But I can allow you at your level to be able to make those changes. Let's go back to password resets, okay? A password reset is a Standard Change in some cases, in many cases. So let's say I've got a password reset, I give my service desk authorization to be able to make those password resets, but I don't let my Sys Admin, don't give them the authority to be able to make those password resets, so that's why it's very important, as part of our governance, that we know who can do what on those Standard Changes. So, to be considered a Standard Change, some things I mentioned earlier, a defined trigger, to initiate the RFC, tasks are well-known, documented and proven, authority is basically given in advance and budgetary approval is done in advance as well, okay? So it's an established procedure.
Now, we always had a policy in my former data center, that if there is an approved Standard Change and that Standard Change causes an incident, or causes some disruption, we then put in on what we called, probation. It came back to Normal Change until we were again comfortable that it could be classified back as a Standard Change, okay? So, Change Management, we will continuously review those and ensure that those are accurate and that they're up to date. That's what we call a Standard Change, okay? The second type we have is what's called the Normal Change.
So, we're got the Standard Change done. On a Normal Change, essentially it follows the full model of request, it gets assessed, it gets authorized, it goes to the CAB, and it goes through its implementation. That's what we call a Normal Change. And we can categorize, and classify and prioritize these changes, and in different levels of severity or different priority kinds of things we have there. That's what we call a Normal Change. We'll talk a little more about the process in a future video, okay, so and then we have this thing called the Emergency Change.
And (laughs) Emergency Changes, can be, can be good and bad, and often times you've got to be careful that they are not abused. An Emergency Change, that process, that type of change should have its own change model. We'll talk about models soon. But that should, it's intended to react to and address a major issue or response to a, basically, a major negative impact to the business, or a very high level customer group, those types of things.
Again, a lot of these might be driven by our SLAs, our Service Level Agreements. So an Emergency Change, we have a different approval process possibly for that, we might have a CAB called an ECAB, for the emergencies. But we need to make sure that we have an authority with clearly documented and understood responsibilites on who can make certain approvals. And the thing I always like to mention here is an Emergency Change does not give you immunity from testing. But what you can do is documentation that you would normally do for changes, in many cases these Emergency Changes have to be done and have to be assessed and looked at immediately.
So therefore, you can follow up after the Emergency Change and do the documentation afterwards on those things. But, very important to have the full understanding of how that model comes into play. So, those are the three change types that we have. Of course, at your organization, right, you can modify and have different types of changes, but those are essentially the three classifications that we look at within the ITIL model. Now, every process has to have a trigger point or something that kicks the process off, in this case, we're talking about a RFC, or Request For Change.
This is the official recognition that there has been a Change Request initiated, okay? And in this, basically, RFC is a formal proposal for a change and includes details of the proposed change. Typically, we assess that by the Change Manager. Depending on the type of change, it may go to something called a CAB, or Change Advisory Board that we have here. So, that's the official request for this. Now, a Change Record, so a lot of times a RFC and a Change Record are used in the same sentence.
But a Change Record is the official docket, it's the official historical record of that change throughout the life cycle that it has. So, Change Record contains the details of the change, and for every RFC there is an associated Change Record that comes along with that, okay? It's the, it could be the historical, the rap sheet of that change I guess, if you will. Now, we've got this thing called a Change Proposal next. So, there, in many cases, you may have major changes that have significant cost, risk or organizational impact.
So, a Change Proposal is not a change to upgrade of an operating system on a server. A Change Proposal is a major service type of change that might be taking place. And so, that Change Proposal is, looks at really the impact and needs to be, we need to review that, the resources that are required for that. And in many cases, there may even be multiple RFCs that come along with that whole Change Proposal, okay? So, those are the key concepts of this, these two pieces down below, Change Model, the CAB and ECAB, those will be the subject of the next two videos.
ITIL® is a registered trade mark of AXELOS Limited. This ITIL Foundations course is offered by Interface Technical Training, ATO of EXIN.