Change Types and State Models
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 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-authorized, 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.
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, Change Advisory Board (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.
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) authorization.
Change enablement state models
The diagrams below illustrate the state models of standard, normal, and emergency change request types.
- Standard Change
- Normal Change
- Normal Change (Change authority != Local authorization)
- Emergency Change
States description
The following table lists and describes state transitions for standard, normal, and emergency changes.
- Registration
- Authorization, Planning and Scheduling
- Scheduling and Planning
- Scheduling, Planning and Implementation
- Closure
| State | Description | Available transitions |
|---|---|---|
| Registered | This state is for newly created change requests.
|
|
| State | Description | Available transitions |
|---|---|---|
| Authorization | This state is mandatory for emergency changes with Change authority not set to Local authorization and for 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 or emergency change, the Authorization stage is skipped. |
|
| State | Description | Available transitions |
|---|---|---|
| Scheduled | In this state, the change request has the following prerequisites:
Therefore, it is known in advance when the change will be implemented. When a change request is Scheduled, the fields on the record form become read-only, excluding the following:
Automatic state transition Scheduled → Completed: When the Planned end date is overdue, the system automatically changes the state of a standard change to Completed. However, there are no automatic state transitions for normal and emergency changes. Only agents can change their state from Scheduled to any other available one. |
|
| State | Description | Available transitions |
|---|---|---|
| In progress | This state displays that the request is currently in the process of implementation. 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, the fields on the record form become read-only, excluding the following:
|
|
| State | Description | Available transitions |
|---|---|---|
| Completed | After the work is done and the request moves to 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, the state can be changed to Closed. When a change request is In progress, the fields on the record form become read-only, excluding the following:
|
|
| Post implementation review | When the request is completed (successfully or not), the user with the change_manager role has a right to perform a post implementation review on the basis of the implementation. This is a good practice that allows you to gain the "lessons learned" after the implementation, especially if there were any issues along the way. After the review, similarly to the Completed state, mark it as Closed. | 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 can change the state from Registered, Authorization, or Scheduled to Completed.
In this case, the Closure code is Not implemented (Canceled). All related tasks and approval tickets are also canceled.