Processing Change Requests

Assigning and Updating Change Requests

How to assign a change request

1. Open a change request you want 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.

How to update a change request

1. Open a change request you want to update;
2. Update the fields that you want to make changes to;
3. Click Save.

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. Incidents Resolved by this Change;
   2. Incidents Caused by this Change;
   3. Problems Resolved by this Change;
   4. Problems Caused by this Change;
   5. Related Changes;
   6. Related Request.
4. To create relationships for the Incidents Resolved by this Change, Incidents Caused by this Change, Problems Resolved by this Change, Problems Caused by this Change, Related Changes, please complete the following steps:
   1. Click a lock icon, then click a magnifier icon;
   2. In the new window appeared, choose a necessary option;
   3. Click the lock icon again and then click Save.
5. To create relationships for the Related Request, please complete the following steps:
   1. Click a magnifier icon;
   2. In the new window a, choose a necessary option;
   3. Click Save.

Relationship Types

ченджи моэно создавать из проблемов - не похоже, возможно, в ITIL/SN и можно, но не у нас. Узнать у Игоря, как

ченджи из инцидентов? - не похоже, возможно, в ITIL/SN и можно, но не у нас. Узнать у Игоря, как

емердженси из сендж контролов

множественная горизонтальная связь без иерархии

Planning and Scheduling

Change request implementing must be planned and scheduled carefully. It's 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 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 Request Authorization

The change requests that are not standard type must pass authorization procedure (the standard change moves to the Scheduled state 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 level, the stricter the authorization procedure.

In SimpleOne, once a change request requiring authorization is raised, it goes to the authorization stage. The status of the request changes to the Authorization. For this, special authorization tickets are sent to all necessary authorities depending on the 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 authorization tickets have been approved, then the change request is considered to be successfully approved. The status of the request changed to the Scheduled.

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

• all other authorization tickets must have been rejected automatically too;
• the change request is considered to be rejected and goes back to the authorization stage;
• the status of the request is changed back to Registered.

For the emergency changes, due to their high importance for business services or CI, the relationship between the Registered and Authorization states is one way. It means that emergency tickets cannot be rejected.

Change Authority level

Notes:

• The Change Manager controls the lifecycle of all changes.
• CAB - Change Advisory Board. This group of people advises Change Manager in prioritization, authorization, and scheduling of 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 department you want to assign a task to;
   4. Assignment user -  choose a responsible person you wish to assign a task to;

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

   6. Description - put there the detailed task.
   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 status 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 status.
      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 when the assigned person started to work on this task. The assignee must fill this field;
   2. Actual End Date - the date when the assigned person finished the work on this task. The assignee must fill this field;
   3. Planned Start Date - the date when you want the assigned person to start working on this task;
   4. Planned End Date - the date you want this task to be finished (completed and closed).
5. Click Save.

Closure Information

Basing on the SimpleOne state model, when the change request has been fully processed (scheduled, implemented, and reviewed, it must be closed. When closing the incident, the agent must provide the closure code.

Closure code

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

Priority Management

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.

Based on the priority, changes can be categorized as:

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

The priority matrix

Change Template

и как его создать

   создаются из ченджей либо с нуля как темплейт, отдельный механизм авторизации, снять с Андрея. из темп только станд ченджи.