Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


T
Tip

Role required: change_manager.

Assign and update change requests


To assign a change request, please perform the following steps:

  1. Navigate to Change Enablement → All Change Requests and open a the change request you need want to assign.
  2. Click a On the Notes tab, click the magnifier icon in next to the Assigned User or the Assignment Group field.
  3. Select the responsible a person or a group to assign the change request to.
  4. Click Save or Save and Exit to apply the changes.

To update a change request, please complete the steps below:

  1. Navigate to Change Enablement → All Change Requests and open a the change request you need want to update.
  2. Update the necessary fields.
  3. Click Save or Save and Exit to apply the changes.

All activities will be shown in the Note tab of the change request. 

Plan and schedule

Schedule and plan change requests


Change request implementing requests must be planned and scheduled carefully. Planning and scheduling change requests allow for minimizing disruption to vital business function disruptionfunctions.

When scheduling the 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, please complete the following steps:

  1. Navigate to Change Enablement → All Change Requests and open the change request you need.
  2. Open On the Schedule tab, and enter the date and time when the request has to be started and finished processing into the appropriate fields.
  3. After the request was processed, enter the actual date and time.

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

N/A

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.

Info

This field is mandatory if the Planned Downtime field is filled in, and the state of the change request is Completed.



To plan a change request, complete the following steps:

  1. Navigate to Change Enablement → All Change Requests and open the change request you need.
  2. On the Planning tab, fill in the fields as required.

following fields in the 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

a

the change request can be processed.

Core Activities

Y

Describe

here

the process of change implementation. Fill in this field before

a

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

a

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

a

the change request can be processed.


Change request authorization


The change requests that are not Change requests of non-standard type must go through authorization procedure (the . For standard change request, the state changes to the Scheduled automatically automatically, without authorization stage).

The authorization is a request approval by Change Authorities change authorities of different levels, depending on the risk level and probability levellevels. 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 the Authorization. For this, approval tickets should be sent to all necessary authorities, depending on the Change Authority the change authority level. In such a ticket, every recipient is proposed 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 changed changes to the Scheduled.

If there is even one a single approval ticket rejected, then:

  • all other approval tickets must have been are rejected automatically too.
  • 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 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 Modelenablement state models article to learn more.

Change Authority level

Note

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

Anchor
change authority level
change authority level

LowLocal Authorization (authorization by the Assigned User)
Medium

Change Manager Only:

  • All Change Managers
High

Basic CAB (Change Advisory Board):

  • All Change Managers
  • Service Owner
Very High

Complex CAB (Change Advisory Board):

  • All Change Managers
  • All Problem Managers
  • All Incident Managers 
  • All Related CI Owners

  • Service Owner.


Tip
  • Change Manager controls the life-cycle lifecycle of all changes.
  • CABThe Change Advisory Board . This group of people (CAB) group advises Change Manager Managers in prioritization, authorization, and scheduling changes.
Customizing

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.

Modifying Modify a CAB script


Tip

Role required: admin.

To bring in some global modifications into a default CAB, please complete the steps below:

  1. Navigate to System Definition → Script Includes.
  2. Click the magnifier icon at the top of the list; the search string appears.
  3. Enter calculateCAB to into the Name field and press Enter; the relevant script should be found.
  4. Click on the script title to open it.
  5. All role sets for different CABs are defined in this script with a corresponding comment, like thisas follows:


Code Block
languagejs
themeEclipse
titleComplex CAB
  // 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 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.

Tip

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 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, please complete the steps below:

  1. Navigate to a the change request you need to be extendedextend.
  2. Make sure that State IS Registered and Change Type IS NOT Standard.
  3. Navigate Select to the Schedule tab of the Related lists area.
  4. Click the Customize CAB button and select the necessary persons users from the list (you can select as many users as you need).
  5. Click Add.
Info

The Ignore Automatically Generated CAB option allows for overriding CAB participants, designated by the included script described above, with those that are chosen from the list.

Change templates


You can create a template that can be used later to create change requests with pre-defined predefined tasks. In addition, templates make the processes easier by populating the fields automatically.

You can create a template of any complexity , pre-filling 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 standard or Normalnormal 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:

  1. Navigate to Change Enablement → Change Request Templates.
  2. Click New and fill in the fields.
  3. Click Save or Save and Exit to apply the changes.

Change template form fields

FieldMandatoryDescription
NameYSpecify a template name. It should be unique.
TableYIn this field, select Select the Change Requests table.
Created From Change RequestN

In this field, a change request number is specified if a template is created out of an existing request.

Short DescriptionNSpecify Add a short description for this template.
TemplateN

Select fields and specify their values that will be populated in to requests created on the basis of this template.

Note

Please keep in mind that for correct request creation, all mandatory fields have to be specified (such as Change type, Subject, Reason, etc.). Also, 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.


StateY

Available options:

  • Draft
  • Authorization
  • In Use
  • Archived.
ActiveNSelect this checkbox to make a template active or inactive.
Change Request Templates

In 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 templatestemplate, it will also have subtasks.

Requested Approvals
In On this tab, you can find template approval tickets that were sent but not processed yet.
Completed Approvals
In On this tab, you can find already processed either declined or approved tickets.

Change template state model


The following picture describes the state flow of change templates:

In the The following table , you can see state descriptions lists and describes states and available transitions.

StateDescriptionAvailable Transition
DraftThis state is for the newly created change request templates. 
  • Authorization
Authorization

Approval tickets are send to the users that are responsible for the authorization.

  • If anyone rejects, then the template returns to the Draft state.
  • If all responsible users approve, the template state is changed to In Use.
  • Draft
  • In Use
In Use

Change requests can be created based on the template. 

Info

To create a change request based on the template, pick a Create Change item in the hamburger menu


  • Archived
ArchivedThis template is no longer needed, all activities on it are over.

Creating a template out of a change request


Info

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:

  1. Navigate to Change Enablement → All Change Requests and open the change request you need.
  2. In the hamburger menu , select the Create Template item.
  3. Edit the change request template form. 
  4. Click Save or Save and Exit.

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.

Closure information


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:

OptionDescription
Implemented

This state displays that the change request was fully implemented.

Partially ImplementedThis state displays that the change request was implemented with some exclusions that do not affect the critical functionality of the service.
Not ImplementedThis state displays that the change request was not implemented.
CancelledThis state displays that the change request was canceled because the caller's authorization was failed or revoked.
BackoutThis state displays that the change request implementation was unsuccessful, and the previous state of service or CI was restored.


Table of Contents
absoluteUrltrue
printablefalse