Versions Compared

Key

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

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 Caused by this Change;
    4. Related Changes;
    5. Related Request.
  4. To create relationships for the Incidents Resolved by this Change, Incidents Caused 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

TypeDescription
Incidents Resolved by this ChangeThe incidents specified will be resolved after resolving this change request.
Incidents Caused by this ChangeThis change request is the cause of the incidents specified.
The problems specified will be resolved after resolving this change request.
Problems Caused by this ChangeThis change request is the cause of the problems specified.
Related ChangesThis change request has related change requests.
Related RequestThis change request has related service requests.


Info

The relationship types Incidents Resolved by this Change and 

To use this feature, please complete the following steps (for the Incidents Resolved):

  1. Open the change request you want to work on;
  2. Scroll down the page, then open the Related Records tab;
  3. Click the lock icon near Incidents Resolved by this Change;
  4. In the window appeared, choose incidents that will be resolved by this change request. You can select over one incident;
  5. When you've finished, click the lock icon again;
  6. Then open the Closure Notes tab;
  7. Turn the Complete Originators checkbox on;
  8. After you mark the change request as Completed, all related incidents will be marked Completed as well.


ченджи моэно создавать из проблемов - не похоже, возможно, в 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

Risk levelChange Authority level
LowLocal Authorization (authorization by the assigned user)
MediumChange Manager Only
High

Basic CAB:

  • Change Manager;
  • Service Owner(s);
Very High

Complex CAB:

  • Change Manager;
  • Service Owner(s);
  • Related CI Owner(s);
  • Head of Assigned User;
  • Head of Service Owner(s);
  • Head of Related CI Owner(s);
  • Process Manager.

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

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:

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 cancelled because of authorization failed or revoked by the caller.
BackoutThis state displays that the change request implementation was not successful, and the previous state of service (or CI) was restored.

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

Impact / Urgency

Very High

High

Medium

Low

High

Critical

Critical

High

Moderate

Medium

Critical

High

Moderate

Low

Low

Critical

Moderate

Low

Low

Change Template

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

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

Table of Contents
absoluteUrltrue
classfixedPosition