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
Three types of changes are supported: standard, normal, and emergency changes. The change type determines which state model should be used and what 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 have successfully been implemented earlier. As standard changes are pre-approved, they follow the process in which authorization steps are not required.
To make requesting a change more efficient, you can create a template in the respective catalog based on the approved standard change requests. 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
A normal change is used to implement a 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, and so on. Normal changes planning foresees possible disruption to service, so these changes are often scheduled outside of change blackout windows or during defined maintenance windows. This type of changes is used to implement a profitable change for any service that is not a standard or emergency change for any service.
Change enablement state models
The scheme below illustrates the state models of standard, normal, and emergency change request types.
States description
The following table lists and describes 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. A normal change can also be rejected and turned to Registered. When the Change Authority field has the Local Authorization value within a normal change, the Authorization stage is skipped. |
|
| Scheduling and Planning | Scheduled | In this state, the change request has the following prerequisites: Therefor, it is known in advanced when the change will be implemented. When a change request is Scheduled, the fields on the record form become read-only, excluding the following:
|
|
| Scheduling, Planning and Implementation | In Progress | This state displays that the request is currently in the progress of implementation. When the work is over, the state has to be changed to Completed. When a change request is In Progress, the fields on the record form become read-only, excluding the following:
|
|
| Closure | Completed | After the work is over and the request moves to this state, the requester can perform tests and give feedback on the implementation results. 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 (successfully or not), the Change Advisory Board (CAB) has a right to perform a post-implementation review on the basis of the implementation. This 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. |
