Page History

Assigning and Updating Change Requests

To assign a change request

, perform the following steps:

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

To update a change request

, complete the steps below:

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

Create Change Tasks

If solving of change request requires the participation of different departments, then you can create a Change Task for each of them. They will be related to the parent change request, but not like in the "master-slave" model. The better example is the "parent-child" model. 

To create a change task, please complete the following steps:

1. Open the change request you want to work on;
2. Scroll down the page, then open the Change Task tab;
3. Fill in the form:
   1. Number - filled automatically;
   2. Change - the change request that is the parent for this task;
   3. Assignment group - choose a responsible group to assign a task;
   4. Assignment user -  choose a responsible person to assign a task;

   5. Subject - describe the task here in a brief manner;

   6. Description - put there the detailed task description;
   7. Type - the type of change task. It can be customized based on the business needs, (for example, Deployment Task, Code Review Task, Documentation Task).
   8. State - task state. Available choice options:
      1. Waiting for Change Authorization - this is the initial state for the change task that has been created under the Normal or Emergency Change. After the parent change request is authorized, its change tasks all transit to the Pending state.
      2. Pending - the task has been scheduled and is waiting for the implementing;
      3. In Progress - the assignee started working on the task;
      4. Completed - the task has been completed successfully.
      5. Cancelled - the task was cancelled due to any reasons (parent change request was not authorized; change task was not described correctly; any other reasons).
4. After you have entered task details, specify start and end dates for task implementing.
   1. Actual Start Date - the date and time when the assigned person started working on this task. The assignee must fill this field;
   2. Actual End Date - the date and time when the assigned person finished working on this task. The assignee must fill this field;
   3. Planned Start Date - the date and time when you need the assigned person to start working on this task;
   4. Planned End Date - the date and time you need this task to be finished (completed and closed).
5. Click Save.

Change Task State Model

Image Removed

Create a Change Request Announcement

Create an announcement informing related to the Change Request processed.

To create a Change Request announcement, please click the Create Announcement button in the Change Request form.

In there, two types of announcements are available:

• Maintenance - this type of announcement informs that some service or CI recovery activities are going to be under maintenance in the specified period;
• Urgent Maintenance - this type of announcement informs that some service or CI recovery activities are going to be under maintenance in the nearest time due to high urgency. 

Create Relationships

You can create relationships between changes and other types of tasks. For this, please complete the following steps:

1. Open the change request you want to work on;
2. Scroll down the page, then open the Related Records tab;
3. You can create these types of relationships:
   1. Resolved Incidents;
   2. Caused Incidents;
   3. Resolved Problems;
   4. Caused Problems;
   5. Related Articles;
   6. Related Inquiry.
4. To create these relationships, please complete the steps below:
   1. Click a magnifier icon next to the appropriate field;
   2. In the window appeared choose a necessary option and click Save.

Relationship Types

Creating Changes out of Problems

When you have investigated a Problem and by result of this you have found a need in a Change, you can create a Change request straight out of the Problem. To do this, please complete the following steps:

1. Navigate to Problem Management → All;
2. Open the problem you need to work on;
3. Enter the hamburger menu on the left side at the top of the page and choose Create Change item;
4. Choose the type of the change you need to create (standard, normal or emergency);
5. Fill in the fields of the change request, and then click Save.

Creating Changes out of Incidents

When you have fixed an incident and by result of this you have found a need in a Change, you can create a Change request straight out of the Incident. To do this, please complete the following steps:

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

Planning and Scheduling

Implementation of change request 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, complete the following steps:

1. Navigate to Change Enablement → All Change Requests and open the change request you need.
2. Open the Schedule tab, and enter the date and time for the request to start and finish processing into the appropriate fields.
3. After the request was processed, enter the actual date and time.

To plan a change request, fill in the following fields in the Planning tab:

Change Request Authorization

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 raisedregistered, 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 the Change Authority level (see the table below for more information). In such a ticket, every recipient is proposed to approve or reject a request.

If all approval tickets have been approved, then the change request is considered to be successfully approved as well too. The state of state of the request changed to the Scheduled.

If there is even one approval ticket was rejected, then:

• all other approval tickets must have been 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 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

The following table shows the dependency between the change request risk level and the authority level.

Customizing a 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 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 a CAB script

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

1. Navigate to System Definition → Script Includes.
2. Click the magnifier icon Image Addedat the top of the list; the search string appears.
3. Enter calculateCAB to 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 this:

 // 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.

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.

• 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:

1. Navigate to the change request to extend.
2. Make sure that State IS Registered or Authorization and Change Type IS NOT Standard.
3. Select the General tab.
4. Click the Customize CAB button and select the necessary users from the list (you can select as many users as you need).
5. Click Add.

Change Templates

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

You can create a template of any complexity, pre-filling prefilling any fields, including assignsassignments. Template 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 these the two options is that a standard change template for Standard change is already authorized, and the change request based on it . So any standard change request created out of the change template does not go through the authorization stage. And both the template for the Normal change normal change template and its change request will be created with the Authorization state; so the change request based on it.

To create a change template from scratch, please complete  complete the steps below:

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

Change template form fields

Closure Information

Change template state model

The following picture describes the state flow of change templates:

Image Added

In the following table, you can see state descriptions and available transitions.

Creating a template out of a change request

To create a template out of a change request, complete the following steps:

1. Navigate to Change Enablement → Closed and open the change request you need.
2. In the hamburger menu Image Added, 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.

Template Approval Procedure

By default, template approval procedure is disabled. To enable it, activate the rule of approval for the table Change Request Template. 

Assignment of the responsible users for the template approval happens automatically when setting a rule of approval.

If a Change Template is created from a change, the CAB participants take part in the approval process. The templates created “from scratch” should be approved by all the users with the change_manager role.

See Approval Management for more information.

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 requestBasing on the SimpleOne state model, when the change request has been fully processed (scheduled, implemented, and reviewed), it has to be closed. When closing the change request, the responsible person can provide the closure code.

Closure code

This code specifies an option of the closure. SimpleOne has the following options:

Planning and Scheduling

When scheduling the change request implementing, it is recommended to avoid time overlaps, to not affect multiple services or CI's at a time. It is an excellent practice to follow the rule: "One timeframe - one change request."

To schedule a change request, please complete the following steps:

1. In the Planned tab, enter a date and time when the request has to be started and finished processing into the appropriate fields (Planned Start Date and Planned End Date).
2. After the request was processed, enter the actual date and time into the appropriate fields (Actual Start and Actual End).

To plan a change request, fill in the following fields in the Planning tab:

1. Pre-test Plan - describe the process of pre-implementing testing;
2. Change Plan - describe the process of the change request implementing;
3. Test Plan - describe the process of post-implementing testing;
4. Backout Plan - the plan of activities to rollback the system or service or CI condition to its previous state, in case of failed implementation

All these fields are mandatory.

Change Requests Prioritization

The priority of the Change Request can be figured out based on its impact and urgency using a priority matrix.

The impact of a change indicates the potential damage (in case of emergency changes) or effect (in case of standard or normal changes) that will be caused to the business user or service or CI.

In SimpleOne, the impact can be categorized as:

1. Low;
2. Medium;
3. High;
4. Very High.

The urgency of a change indicates the measure of time in the following cases:

• Until a change has an impact on the business - in case of emergency changes;
• Until change lack of implementing will impact the business services or CI- in case of standard or normal changes.

In SimpleOne, the urgency can be categorized as:

1. Low;
2. Medium;
3. High;
4. Very High.

Based on the priority, changes can be categorized as:

1. Low;
2. Moderate;
3. High;
4. Critical.

1. Impact;
2. Probability;
3. IT Service Business Criticality.

The IT Service Business Criticality metric specifies how crucial can be disruption of this service for the business. The options are High or Low.

Risk metrics for IT Service Business Criticality = Low

 
Risk metrics for IT Service Business Criticality = High