Change management provides for us the stability in the environment especially when we are working in mixed environments like many of us do. It would be so very easy to manage a network if every single system were identical in their devices, drivers, operating systems and applications, with the same level of skill sets on the users and so on. But, most of us don’t really work in that sort of ideal type of environment. Instead, we have so many mixed like Windows, Novell, Linux, Apple, and so on. On the network, it may in fact be that we’re dealing with some thousand different vendors, it can be very difficult with change management to make any changes.
Which is not a bad thing really, as the process is in place for the purpose of creating stability. This means that if you go through proper channels, can get the changes made. However, when someone randomly find this newest, latest and greatest security patch and try to push it to the 200 computers in production on their own, with no proper protocol, then that could cause problems because no one else is on board with the changes as there’s been no communication about it, and not gone through the proper channels.Someone else may have already planned on a proprietary patch rather than one from a vendor and then the two programs run incompatible with each other, negating each out of the picture.
Patch management relates to change management. It is when change has been developed and is a better way to implement. However, regardless of how much more useful it can be, if not gone through proper channels and been through the change management process, then it could also lead to problems. It’s possible to have users restricted to where they are not able to make those kinds of changes. In other words, not allow the user to install applications, which is a way to lock down the users tightly. There’s ways to not allow the users access to applications in terms of downloading and installing. Often, the programs are not business appropriate, or are just not clean or even not virus-free. Not all applications in the world of the internet and network, are particularly suited for the environment. So, best bet is to limit the user’s ability to install random applications.
Different organizations have different methodologies for their changes and handling change management. Depending on the organization, there may be different approaches and what different standards that is expected. There’s so many problems that come out of the network like people installing applications from home or have a certain level or degree of control and make changes to even their baseline configuration. To keep stability and maintain some control, every change should be controlled for and documented. There should be approval and testing prior to any changes and prior to the product rolling out on the production line. Even though there are differences in approaches, changes should still be structured and scheduled as well as documented. Part of this is also making sure to train people on using those changes we’ve put into place.
Change management is the process for at least marking and understanding the scheduled, structured changes in our software and keeping the documentation up to date. So often, disaster can be averted if we keep track of the various changes. We may end up changing one aspect and lose completely on a functionality. We’d need to be able to look at the documentation and refer back to restore the system or application to its previous state. If we’re not keeping track or receiving the approvals, it may be a change that no one else is even knowledgeable about and the one dude who made the change is out sick today or doesn’t even work at the organization anymore. So, all of this is related to change management.
Other important elements of change management reflect over the vendors and what information gets transferred between the organization and the vendors. For example, we need to document contact information, and other support information so that we can contact the vendor especially if there is a service level agreement (SLA). Overall, change management requires control and documentation of any changes to our baseline of the configuration. This includes patches, vendors and other changes that might be taking place.
Patch management is just a part of the overall change management. Since it is also a part of this, then there needs to be policies and procedures in place. There’s even a varying level of critical importance associated with patches and they may change in a moment’s notice. Therefore, it is easily as important to manage patches in some sort of way as to getting approval, getting documentation, and so on before pushing out the patch for the original software. Either way to look at it, there is a process and have to follow this process to keep a little control and stability over the overall. This process is change management.