o Without the intent to restore to its original state – that is, not a test, not an incident recovery
This definition is provided as a guide for you. Use it if you feel it is helpful.
Having a consistent definition of a change, to compare suggested changes against, I have found to be a BIG WIN. Filtering out non-changes (those that do not meet the definition) can reduce the time spent by 60-70%. Removing non-change records (identifying more effective and efficient ways in which they should be handled), will save a large amount of resource wastage.
By applying my Change Definition, you can readily find many examples that people try to manage through the Change Management process, that are NOT changes. Some common examples:
1. Restoring a service back to the way it was after an Incident has occurred - Restoring to its previous state
2. Service Requests selected by a customer, from the Service Request Catalogue – Part of the service and not modifying the way the service is being delivered
3. Scheduled housekeeping or batch processing work to maintain a service – These are part of delivering the service; do not make the mistake that these alter the service just because the service may need to be taken off line. Such activities must be documented in the Service Operations Manual, including when they occur and what notification / approval is required in advance
4. Scheduled service performance testing, such as Disaster Recovery, Capacity or Security testing – Again, part of the delivery of the service. They seek to test
the quality of the service. You can never know the resilience of the service unless you test it
I have seen all of these examples considered as changes at some time, and in some organisations. Let’s look at them further.
1. Only when restoring the service requires it to be moved to a different state, will this become a change. And that is perfectly fine. However, rebooting a server (for example), to restore the service back to its exact original state, does not require the CMDB to be updated, and hence, is NOT a change.
2. Where Service Requests generate change records, in order to be processed, then you have the wrong definition of a Service Request. If the request cannot be performed without altering the way the service is run, then it is not a service request. Think to design your service requests so there is no need to have human intervention, or special planning. Automate them.
3.. I had an operations team submit 12 changes so as to cover the next year’s monthly batch runs. I asked what they would do if I rejected one of these changes? The reply was, “If you do that, the service will fail.” Clearly, this activity is a must do as part of delivering the service – NO CHANGE!
4. And the most contentious of the examples. I still do not understand why people persist with processing such activities through Change Management. I suspect that it is easier to piggy-back approvals in the Change Management process. This means that people are taking the lazy way out. This would be fine if it was agreed by all parties AND it did not