![]](/nav/3dbar_grey_right_1.gif)
|
 |
The ITIL Change Management process is comprehensively described within the official publications, but within this article we attempt to provide a high level overview of the stages of the Change Management process, the various roles that need to be undertaken at each stage and also details of the responsibilities.
The article does not stipulate interactions with other ITIL disciplines such as Configuration Management, nor does it go into operational details such as what may be included on a Request for Change (RFC) form.
As part of a series of articles ITILnews will expand on the process described and based on practical experience will include details around 'governance'.
We welcome any feedback and knowledge that you are prepared to share.
2012-02-15 by "femi.olawoyin"
The process highlighted here makes a lot of assumptions that are not clearly called out.
In general, change requests go through 3 main goalposts:
-Initiation
-Approval
-Implementation.
The approval process is when the Go/No Go decision is made. Post-implementation, verification is done (ideally in a controlled environment) before the change is 'released' to the production environment. This flow here either assumes that all these steps are implemented in a controlled environment (where back-out can be implemented with minimal or no impact on production) OR disregards the need for such a critical control step. It is expedient to point out that change implementation and validation should be done in a controlled environment BEFORE production access is granted (either the system should be 'locked down' during the change implementation window or access disabled while the change is being implemented AND verified).
The critical requirements for change implementation must be:
1. All changes MUST be approved BEFORE implementation (except for routine/standard changes that are already pre-approved and follow a set path)
2. Impact assessment must be done at a higher level than that of the person implementing the change
3. Changes must be verified in a controlled environment BEFORE release to production
4. Changes should never be implemented without clearly-validated rollback/back-out plans
It is expedient to build these best practices into flows in order to minimize the potential for production 'disasters' due to change.
Finally, the Change Initiator (not the Change Manager) should be the one closing out the change request. This person is the final point of verification that confirms changes have been implemented as requested OR agreed (in cases where there are modifications to the initial request).
In general, change requests go through 3 main goalposts:
-Initiation
-Approval
-Implementation.
The approval process is when the Go/No Go decision is made. Post-implementation, verification is done (ideally in a controlled environment) before the change is 'released' to the production environment. This flow here either assumes that all these steps are implemented in a controlled environment (where back-out can be implemented with minimal or no impact on production) OR disregards the need for such a critical control step. It is expedient to point out that change implementation and validation should be done in a controlled environment BEFORE production access is granted (either the system should be 'locked down' during the change implementation window or access disabled while the change is being implemented AND verified).
The critical requirements for change implementation must be:
1. All changes MUST be approved BEFORE implementation (except for routine/standard changes that are already pre-approved and follow a set path)
2. Impact assessment must be done at a higher level than that of the person implementing the change
3. Changes must be verified in a controlled environment BEFORE release to production
4. Changes should never be implemented without clearly-validated rollback/back-out plans
It is expedient to build these best practices into flows in order to minimize the potential for production 'disasters' due to change.
Finally, the Change Initiator (not the Change Manager) should be the one closing out the change request. This person is the final point of verification that confirms changes have been implemented as requested OR agreed (in cases where there are modifications to the initial request).
NB: This page is © Copyright ITILnews.com and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to www.itilnews.com.
