You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 31 Next »
Role required: change_manager.
Assign and update change requests
To assign a change request, perform the following steps:
Navigate to Change Enablement → All Change Requests and open the change request you need to assign.
On the General tab, click the magnifier icon
next to the Assigned User or Assignment Group field.
Select the responsible person or group to assign the change request.
Click Save or Save and Exit to apply the changes.
To update a change request, complete the steps below:
Navigate to Change Enablement → All Change Requests and open the change request you need to update.
Update the necessary fields.
Click Save or Save and Exit to apply the changes.
Planning and Scheduling
Change requests must be planned and scheduled carefully. Planning and scheduling allow minimizing vital business function disruption.
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:
Navigate to Change Enablement → All Change Requests and open the change request you need.
On the Schedule tab, enter the date and time for the request to start and finish processing into the appropriate fields.
After the request was processed, enter the actual date and time.
Schedule tab fields
Field | Mandatory* | Description |
---|---|---|
Planned Start Datetime | N/Y | 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/Y | 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/Y | 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/Y | Add any notes about the planned service downtime. Fill in this field before the change request can be processed. |
Possible Conflicting Changes | N/Y | 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/Y | Pick a date and time for the actual start of the request processing. |
Actual End Datetime | N/Y | Pick a date and time for the actual finish of the request processing. |
Actual Downtime | N/Y | If the service downtime occurs, specify its duration. This field is mandatory if the Planned Downtime field is filled in, and the state of the change request is Completed. |
*Whether the field is mandatory depends on the state of the change request.
To plan a change request, complete the following steps:
Navigate to Change Enablement → All Change Requests and open the change request you need.
On the Planning tab, fill in the fields as required.
Planning tab fields
To plan a change request, fill in the following fields in the Planning tab:
Field | Mandatory* | Description |
---|---|---|
Preparation | N/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 | N/Y | Describe the process of change implementation. Fill in this field before the change request can be processed. |
Validation | N/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 | N/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. |
*Whether the field is mandatory depends on the status of the change request.
Change request authorization
Change requests of the non-standard type with Change Authority not set to Local Authorization 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:
all other approval tickets are rejected automatically.
the change request is considered to be rejected and goes back to the authorization stage.
the state of the request is changed back to Registered.
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.
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 (Change Advisory Board):
|
Very High | Complex CAB (Change Advisory Board):
|
Change Manager controls the lifecycle of all changes.
The Change Advisory Board (CAB) group advises Change Managers in prioritization, authorization, and scheduling changes.
Customize a CAB
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:
Modifying an include script containing parameters responsible for CAB gathering. These modifications will affect all change requests created later.
Adding new participants to a specified change request CAB while processing it.
Modify a CAB script
Role required: admin.
To bring in some global modifications into a default CAB, complete the steps below:
Navigate to System Definition → Script Includes.
Click the magnifier icon
at the top of the list.
Enter calculateCAB into the Name field and press Enter; the relevant script should be found.
Click the script title to open it.
All role sets for different CABs are defined in this script with a corresponding comment, as follows:
// 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.
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.
A CAB can be customized for change requests in the Registered or Authorization state.
For change requests in the Authorization state, when a necessary user is added to the CAB and the change request is saved, an approval ticket is automatically sent to that user.
The Customize CAB widget allows to add users with the itsm_agent role.
The users are added as mandatory participants of the approval process.
The Ignore Automatically Generated CAB option allows for overriding CAB participants, designated by the included script described above, with those chosen from the list. This option is only available for change requests in the Registered state.
To customize a CAB, complete the steps below:
Navigate to the change request to extend.
Make sure that State IS Registered or Authorization and Change Type IS NOT Standard.
Select the General tab.
Click the Customize CAB button and select the necessary users from the list (you can select as many users as you need).
Click Add.
Change templates
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:
from scratch
from the change request processed earlier
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:
Navigate to Change Enablement → Change Request Templates.
Click New and fill in the fields.
Click Save or Save and Exit to apply the changes.
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. Keep in mind that for correct request creation, all mandatory fields have to be specified (such as Change type, Subject, Reason, etc.). Also, do not specify read-only fields, such as Priority or Risk. Attempting to create a change request without following these recommendations will lead to validation errors. |
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. |
Change template state model
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. |
|
Create a template from a change request
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:
Navigate to Change Enablement → Closed and open the change request you need.
In the hamburger menu
, select Create Template.
Edit the change request template form.
Click Save or Save and Exit.
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.
Closure information
Based on the state model, the change request has to be closed when it has been fully processed. The Closure Information 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:
|
- No labels