Role required: change_manager. |
To assign a change request, perform the following steps:
To update a change request, complete the steps below:
Change requests must be planned and scheduled carefully. Planning and scheduling change requests allow for minimizing disruption to vital business functions.
When scheduling a 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, complete the following steps:
Schedule tab fields
Field | Mandatory | Description | |
---|---|---|---|
Planned Start Datetime | N | Pick a date and time to start the request processing. Fill in this field before the change request can be processed. | |
Planned End Datetime | N | Pick a date and time to finish the request processing. Fill in this field before the change request can be processed. | |
Change Schedule | See the Change Schedule article. | ||
Planned Downtime | N | If a service downtime is expected, specify its duration. The responsible person must fill in this field before the change request can be processed. | |
Downtime Notes | N | Add any notes about the planned service downtime. Fill in this field before the change request can be processed. | |
Possible Conflicting Changes | N | Contains change requests that have a time overlap with this request. It possibly can impact request implementation. This field is populated automatically. | |
Actual Start Datetime | N | Pick a date and time for the actual start of the request processing. | |
Actual End Datetime | N | Pick a date and time for the actual finish of the request processing. | |
Actual Downtime | N | If the service downtime occurs, specify its duration.
|
To plan a change request, complete the following steps:
Planning tab fields
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 the change request can be processed. |
Core Activities | Y | Describe the process of change implementation. Fill in this field before the change request can be processed. |
Validation | Y | The process of how the change must be tested after the implementation. Fill in this field before the 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 the change request can be processed. |
Change requests of non-standard type must go through authorization procedure. For standard change request, the state changes to Scheduled automatically, without authorization.
The authorization is a request approval by change authorities of different levels, depending on the risk and probability levels. The higher the risk and probability levels are, the stricter the authorization procedure is.
In SimpleOne, once a change request requiring authorization is registered, it goes to the authorization stage. The state of the request changes to 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 prompted 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 changes to Scheduled.
If there is even a single approval ticket rejected, then:
For 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 Types and State Models article to learn more.
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 (Change Advisory Board):
|
Very High | Complex CAB (Change Advisory Board):
|
|
A default CAB structure is described above, but you may need to modify it according to the organizational structure or business needs. You can do it in several ways:
Modify a CAB script
Role required: admin. |
To bring in some global modifications into a default CAB, 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 a 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. |
Modify 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, complete the steps below:
The Ignore Automatically Generated CAB option allows for overriding CAB participants, designated by the included script described above, with those chosen from the list. |
You can create a template that can be used later to create change requests with predefined tasks. In addition, templates make the processes easier by populating the fields automatically.
You can create a template of any complexity and prefill 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, complete the steps below:
Change template form fields
Field | Mandatory | Description | |
---|---|---|---|
Name | Y | Specify a template name. It should be unique. | |
Table | Y | 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 | Add a short description for this template. | |
Template | N | Select fields and specify their values that will be populated to 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 | |||
This tab appears after the template is saved. On 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 template, it will also have subtasks. | |||
Requested Approvals | |||
This tab appears after the template is saved. On this tab, you can find template approval tickets that were sent but not processed yet. | |||
Completed Approvals | |||
This tab appears after the template is saved. On this tab, you can find already processed either declined or approved tickets. |
The following table lists and describes the available states and their transitions.
State | Description | Available Transition |
---|---|---|
Draft | This state is for newly created change request templates. |
|
Authorization | Approval tickets are sent to the users responsible for the authorization. If anyone rejects, the template returns to the Draft state. |
|
A template can be created only from a change request in the Closed state. |
To create a template from a change request, complete the following steps:
As a result, the 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 based on which it was created in the Created From Change Request field.
Based on the state model, the change request has to be closed when it has been fully processed. This tab appears when the change request state is Completed.
Field | Mandatory | Description |
Complete originators | N | Select this checkbox to make the originators related to this request be completed along with it. |
Closure Notes | Y | Specify some notes summarizing the implementation process. |
Closure Code | Y | Specify a closure code:
|