Processing Change Requests

Assigning and Updating Change Requests

How to assign a change request

1. Open a change request you need to assign;
2. Click a magnifier icon in the Assigned User or the Assigned Group field;
3. Select the responsible person or group to assign the change request;
4. Click Save or Save and Exit to apply changes.

How to update a change request

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

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:

1. Navigate to Incident Management → All;
2. Open the incident 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.

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 raised, 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 Authority level (see the table below for more information).

In such 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 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 is of one-way type. It means that emergency tickets cannot be rejected.

Change Authority level

Customizing a CAB

A default CAB structure is described above; but one may need to modify it according either to organization structure or to business needs. You can do it in several ways:

1. Modifying an include script containing parameters responsible for CAB gathering (these modifications will affect all change requests created later).
2. 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, please complete the steps below (you need to have admin privileges for this):

1. Navigate to System Definition → Script Includes.
2. Click on the magnifier icon on 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'
    ];

To modify any CAB, basic or complex, just add or delete a role into an appropriate section.

For example: you want the Request Managers to participate in the Complex CAB and, from the other side, you want to relieve Problem Managers from this duties. Then you need to delete the 'problem_manager' role from here and add the 'request_manager' role.

Modifying a specified CAB

You can also modify a CAB for any specified change request with no affect to further request. For example, you want this particular change request to be approved by some specified employees. For this, please complete the steps below:

1. Navigate to a change request you need to be extended.
2. Make sure that State IS Registered and Change Type IS NOT Standard.
3. Navigate to the Schedule tab of the Related lists area.
4. Click the Customize CAB button and select required persons 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 tasks. Templates make the processes easier by populating the fields automatically.

You can create a template of any complexity, pre-filling any fields, including assigns. Template can be nested, so you can include change tasks into it if necessary.

Templates can be created in two ways:

1. From scratch.
2. From the change request processed earlier.

Templates can be created for Standard or Normal changes. The difference between these two options that template for Standard change is already authorized, and the change request based on it does not go through the authorization stage. And the template for the Normal change will be created with the Authorization state; so the change request based on it.

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

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

Change template form fields

Change template authorization

If you are creating a template to create change requests, you need it to be authorized first. For this, please complete the steps below:

1. Create a template as described above, fill it with fields and values, save the record. Note that the record is in the Draft state.
2. Change the template state to Authorization.
3. Navigate to Requested Approvals tab of the Related Lists area and click either on the approver name (approval form is opened in a new window) or on a state title in the state column (and inline-edit it).
4. If anyone rejects, then the template returns to Draft state. Fix it and move it to Authorization again until it is authorized by all approvers.
5. When all approved, the template state is changed to In Use, and after that, change requests can be created basing on it. To create a CR basing on this template, pick a Create Change Request item from a hamburger menu.
6. If this template is no longer needed, then you can archive it by changing the state to Archived.

Creating a template out of a change request

A template can be created only from a closed CR. To create a template, open such a request and pick a Create Template item from a hamburger menu. A creating template will inherit all attributes from the parent tasks, what means, for example, that if the request had some change tasks, so the newly created template will have relevant related change tasks templates.

Closure Information

Basing 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

Change request implementing must be planned and scheduled carefully. It is very significant for the successful request implementing. Also, planning and scheduling allows to minimize vital business functions disruption.

When scheduling the change request implementing, it is recommended in the case of time overlaps, to minimize the effect caused to the multiple services or CI's at a time when implementing.

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. Preparation - describe the process of pre-implementing testing;
2. Core Activities - describe the process of the change request implementing;
3. Validation - describe the process of post-implementing testing;
4. Backout - 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.

The risk of the Change Request can be figured out based on the following metrics:

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