The purpose of the change management process is to control the lifecycle of all changes. It enables making beneficial changes with minimal disruption to IT services.
Change types
Change Control supports three types of changes: standard, normal and emergency changes. The change type determines which state model should be used and the change process that must be followed.
Standard Change
A standard change is a pre-authorized change that is low risk, relatively common, and follows a specific procedure or work instruction.
Changes of this type are most frequently implemented, have repeatable steps, and were successfully implemented earlier. As standard changes are pre-approved, they follow the process in which authorization steps are not required.
You can create a template in the appropriate catalog based on approved standard change requests to make requesting a change more efficient. Also, this capability allows the team to control the changes that are authorized as standard.
Emergency Change
An emergency change is a change that must be implemented as soon as possible, for example, to resolve a major incident or implement a security patch.
You can use an emergency request to fix:
- a current failure situation or a situation where the impact has already been experienced.
- a fail case where the negative impact is invariable if action is not taken.
The priority of the emergency change allows it to go straight to the Authorization state for the Change Advisory Board (CAB) group approval.
Normal Change
Normal change is used to implement profitable change that is not a standard change or an emergency change.
These changes require a full range of evaluations and authorizations, such as technical approval, CAB authorization, change manager authorization, etc. Normal changes planning foresees possible disruption to service, so these changes are often scheduled outside change blackout windows or during defined maintenance windows. This type of changes is used to implement profitable change for any service that is not a standard or emergency change for any service.
Change Enablement State Models
The scheme below illustrates state models of standard, normal and emergency change request types:
States Description
In the following table, you can see state transitions for standard, normal, and emergency changes.
| Procedure | State | Description | Available Transitions |
|---|---|---|---|
| Registration | Registered | This state is for newly created change requests.
|
|
Authorization, Planning and Scheduling | Authorization | This state is mandatory for emergency and normal changes. After all authorization steps have been passed, the emergency and normal change requests transition to the Scheduled state. Normal change can also be rejected and turned to Registered. When the Change Authority field has the Local Authorization value within normal change, the Authorization stage is skipped. |
|
| Scheduling and Planning | Scheduled | In this state, the change request has the following prerequisites: So it is known in advanced when the change will be implemented. When a change request is Scheduled, fields on the record form become read-only, excluding the following:
|
|
| Scheduling, Planning and Implementation | In Progress | This state displays that the request is in the progress of implementation now. When the state of the change request changes to In Progress, the users responsible for the related change tasks receive a notification that the work on the tasks can be started. When the work is over, the state has to be changed to Completed. When a change request is In Progress, fields on the record form become read-only, excluding the following:
|
|
| Closure | Completed | After the work is over and the request transits into this state, the requester can perform tests and give feedback on the implementation results. The change request can be moved to the Completed state only when all of its related change tasks are also Completed. If the requester is satisfied with the results, you can change the state to Closed. When a change request is Completed, fields on the record form become read-only, excluding the following:
|
|
| Post Implementation Review | When the request is completed (whether successfully or not), the Change Advisory Board (CAB) has a right to perform a post-implementation review on the basis of the implementation. It is a good practice that allows gaining the "lessons learned" after the implementation, especially if there were any issues on the way. After the review, similarly to the Completed state, mark it as Closed. |
| |
| Closed | All activities on this change request are over, and the request cannot be reopened. |
* The assigned user can change the state from Registered to Completed by clicking Cancel. A user with the change_manager role change the state from Registered, Authorization and Scheduled to Completed.
In this case, the Closure Code is Canceled. All related tasks and approval tickets are also canceled.
