This chapter deals with understanding the key differences between change management, release management, and CMDBs.
How does change management fit into the larger picture of IT service management?
Change management doesn't end with just completing a change. Change management's ability to effectively roll out changes can greatly benefit from information collected in other ITSM processes, and vice versa. The ability to associate incidents with the changes they caused or were caused by, or update the CMDB based on IT infrastructural changes, are just the beginning of creating a wholesome ITSM practice that works together to help manage your organization better.
Here's how change management can work together with your other ITSM processes:
1. Incident management:
Tracking the incidents causing a change and the ones caused by a change gives you a better understanding of how changes affect your organization. For instance, when a router is being updated, you might get incident tickets reporting that the internet is down. Associating changes with the incidents they caused helps you quickly identify the cause of an incident and forego having to assign resources to fix that particular incident, as it will be fixed as soon as the change is completed.
2. Request fulfillment:
It's important to use changes for high-impact service requests to keep your IT infrastructure updated. Without changes, a service request for a server upgrade or a request to upgrade the Azure storage space ends with the service being delivered. But when you use a change to implement the service request, you can collect more information like the reason for the change and the implementation plan, get the necessary approvals from all stakeholders, and update the CMDB with the new information.
Note: Using a change for request fulfillment works best for high-impact service requests and any service requests that require a change to the CMDB. If it requires the CMDB to be updated, then it needs a change!
3. Problem management:
Problem management requires creating a change to fix the root cause of a problem. Being able to create an RFC right from within a problem ticket makes it easy to track associated changes and problems. It also gives the CAB a better picture of why the change is required, and denotes the severity of the problem that initiated the change.
What's the difference between an incident, a problem, and a change?
| Incident | Problem | Change | |
|---|---|---|---|
| Definition | An incident is an unplanned interruption to a service or reduction in the quality of a service. | A problem is a cause, or potential cause, of one or more incidents. | A change is the addition, modification, or removal of anything that could have a direct or indirect effect on services. |
| Scope | Restoring normal service operations as soon as possible | Identifying the root cause of disruptions to normal service operations | Implementing a change that addresses the root cause to prevent further disruptions to normal service operations |
| Nature | Reactive | Reactive and proactive | Reactive and proactive |
| Example | Users are unable to connect to the network. A workaround is issued to resolve the incident and give users access to the network. | A problem ticket is created to perform root cause analysis (RCA). A network switch is malfunctioning, leading to the incident. The switch needs to be replaced. | A change ticket is created to replace the defective switch. |
4. Release and deployment management:
Release and deploy upgrades benefit from the structured approach that the change process brings. You can easily track the implementation plans, rollout plans, and the actual implementation of releases and deployments using changes. The transparency and visibility changes offer also helps keep all stakeholders informed.
5. CMDB:
Any updates to the CMDB should always be done with a change. A change provides a lot of useful information on why, how, and when the update was done. The impact analysis performed alongside a change also ensures that any updates to the CMDB are properly analyzed and that the update does not create any disruptions to the rest of your organization. You can use change types to record CMDB updates of varying priority.
Make your ITSM wholesome
FAQs
Release management and change management are ITSM processes that work together to help manage the organization better. Release and deploy upgrades benefit from the structured approach that the change process brings. Implementation plans, rollout plans, and the actual implementation of releases and deployments can be easily tracked using changes. The transparency and visibility changes offer also helps keep all stakeholders informed.
Any updates to the CMDB should always be done with a change. A change provides a lot of useful information on why, how, and when the update was done. The impact analysis performed alongside a change also ensures that any updates to the CMDB are properly analyzed and that the update does not create any disruptions to the rest of the organization. Use change types to record CMDB updates of varying priority.
Release management is an ITSM process that goes hand in hand with other ITSM processes, especially change management. Release and deploy upgrades benefit from the structured approach that the change process brings. Implementation plans, rollout plans, and the actual implementation of releases and deployments can be easily tracked using changes. The transparency and visibility changes offer also helps keep all stakeholders informed.