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 that was appeared, 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 notably to avoid time overlaps, to not affect multiple services or CI's at a time. It is a good 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

CABs will be also mentioned here as well

автоматически переходит в шедулед

осветить механизм

апрувал тикеты

по разному формируются CABы в зависимости от риска и его вероятности (probability).

обязательно осветить

есть в документации на Яндекс.Диске

если все auth ticekts заапрувлены  - все в scheduled, если зареджектили один - canceled все, если change из aurh в reg, то все тикеты падают в cancelled

Create Change Tasks

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 level of damage that will be caused to the business user. 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 until a change has an impact on the business. 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

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

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