Role required: change_manager. |
To assign a change request, please perform the following steps:
To update a change request, please complete the steps below:
All activities will be shown in the Note tab of the change request.
Change request implementing must be planned and scheduled carefully. Planning and scheduling allow minimizing vital business function disruption.
When scheduling the change request implementation, remember about time overlaps; minimize the effect caused to the multiple services or CI's at implementation time.
To schedule a change request, please complete the following steps:
To plan a change request, fill in the following fields in the Planning tab:
Field | Mandatory | Description |
---|---|---|
Preparation | Y | This plan specifies the steps that need to be done and the criteria to be met before implementing the change. Fill in this field before a change request can be processed. |
Core Activities | Y | Describe here the process of change implementation. Fill in this field before a change request can be processed. |
Validation | Y | The process of how the change must be tested after implementation. Fill in this field before a change request can be processed. |
Backout | Y | The plan specifies the processes that will roll back the system, service or CI condition to its previous state in case of a failed implementation. Fill in this field before a change request can be processed. |
The change requests that are not standard type must go through authorization procedure (the standard change state changes to the Scheduled automatically, without authorization stage).
The authorization is a request approval by Change Authorities of different levels depending on the risk level and probability level. The higher the risk and probability levels, the stricter the authorization procedure.
In SimpleOne, once a change request requiring authorization is registered, it goes to the authorization stage. The state of the request changes to the Authorization. For this, approval tickets should be sent to all necessary authorities depending on the Change Authority level. In such a ticket, every recipient is proposed to approve or reject a request.
If all approval tickets have been approved, the change request is considered to be successfully approved. The state of the request changed to the Scheduled.
If there is even one approval ticket rejected, then:
For the emergency changes, due to their high importance for business services or CI's, the relationship between the Registered and Authorization states is of one-way type. It means that emergency tickets cannot be rejected. Refer to the Change Enablement State Model article to learn more.
Change Authority level
This role list is specified in the calculateCAB script include delivered with your solution. This script is intended for CAB automatic generation (except for Local Authorization) for all authorities. |
The following table shows the dependency between the change request risk level and the authority level.
Risk level | Change Authority level |
---|---|
Low | Local Authorization (authorization by the Assigned User) |
Medium | Change Manager Only:
|
High | Basic CAB:
|
Very High | Complex CAB:
|
|
A default CAB structure is described above, but you may need to modify it according to organizational structure or business needs. You can do it in several ways:
Modifying a CAB script
Role required: admin |
To bring in some global modifications into default CAB, please complete the steps below:
// Complex CAB const roles = [ 'change_manager', 'problem_manager', 'incident_manager' ]; |
Add or delete a role into an appropriate section to modify any CAB, basic or complex.
For example, you want request managers to participate in the Complex CAB, and, at the same time, you want to relieve problem managers from these duties. Then you need to delete the problem_manager role from the script and add the request_manager role.
Please consider that this approval process works when these roles are applied to employees. It is not enough to create a user record and grant it a role; a relevant employee record must also exist. |
Modifying a specified CAB
You can also modify a CAB for any specified change request with no effect to further requests. For example, you want a particular change request to be approved by some specified employees. For this, please complete the steps below:
The Ignore Automatically Generated CAB option allows overriding CAB participants designated by the included script described above with those that are chosen from the list. |
You can create a template that can be used later to create change requests with pre-defined tasks. In addition, templates make the processes easier by populating the fields automatically.
You can create a template of any complexity, pre-filling any fields, including assignments. A template can be nested, so you can include change tasks into it if necessary.
Templates can be created in two ways:
Templates can be created for Standard or Normal changes. The difference between the two options is that a standard change template is already authorized. So any standard change request created out of the change template does not go through the authorization stage. And both the normal change template and its change request will be created with the Authorization state.
To create a change template from scratch, please complete the steps below:
Change template form fields
Field | Mandatory | Description | |
---|---|---|---|
Name | Y | Specify a template name. It should be unique. | |
Table | Y | In this field, select the Change Requests table. | |
Created From Change Request | N | In this field, a change request number is specified if a template is created out of an existing request. | |
Short Description | N | Specify a short description for this template. | |
Template | N | Select fields and specify their values that will be populated in requests created on the basis of this template.
| |
State | Y | Available options:
| |
Active | N | Select this checkbox to make a template active or inactive. | |
Change Request Templates | |||
In this tab, create change task templates and relate them to this template. If a change request is created based on a template with a related task templates, it will also have subtasks. | |||
Requested Approvals | |||
In this tab, you can find template approval tickets that were sent but not processed yet. | |||
Completed Approvals | |||
In this tab, you can find already processed either declined or approved tickets. |
The following picture describes the state flow of change templates:
In the following table, you can see state descriptions and available transitions.
State | Description | Available Transition | |
---|---|---|---|
Draft | This state is for the newly created change request templates. |
| |
Authorization | Approval tickets are send to the users that are responsible for the authorization.
|
| |
In Use | Change requests can be created based on the template.
|
| |
Archived | This template is no longer needed, all activities on it are over. |
A template can be created only from a change request in the Closed state. |
To create a template out of a change request, please complete the following steps:
As a result, created template appears in the Change Request Template table and inherits all attributes from the parent record. That means, for example, if the request had some change tasks, the newly created template would have relevant related change tasks templates. The template will have a reference to the change request on the base of which it was created in the Created From Change Request field.
Based on the SimpleOne state model, the change request has to be closed, when it has been fully processed. The responsible person can provide the closure code, when closing the change request.
Closure code
This code specifies an option of the closure. SimpleOne has the following options:
Option | Description |
---|---|
Implemented | This state displays that the change request was fully implemented. |
Partially Implemented | This state displays that the change request was implemented with some exclusions that do not affect the critical functionality of the service. |
Not Implemented | This state displays that the change request was not implemented. |
Cancelled | This state displays that the change request was canceled because the caller's authorization was failed or revoked. |
Backout | This state displays that the change request implementation was unsuccessful, and the previous state of service or CI was restored. |