Versions Compared

Old Version 37

changes.mady.by.user Dina Baksheeva

Saved on

compared with

New Version Current

changes.mady.by.user Dina Baksheeva

Saved on

Key

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


Tip

Role required: change_manager.

Creating

Create a change request

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

  1. Navigate to Change Enablement → New.
  2. Fill in the form.
  3. Click Save or Save and Exit to apply the changes.


Tip

You can copy the record number, title and link via the hamburger menu. To do so, click Generate link.

New Change Request form fields
General tab

FieldMandatoryDescription
NumberYThis field is populated automatically and contains a change request number in CHGXXXXXXX format.
CallerYThe request originator.
CompanyNA company to which the request is related.
Change TypeY

Specify the change type. Available choice options:

  • Standard
  • Normal
  • Emergency
.

Based on the selected option

picked up there

, the request should be authorized differently.

Please refer

Refer to the Change Request Authorization article to learn more

about this

.

ServiceYThe service affected by this change request.
Related CIsNService-related CI that will be affected by this change request.
Copy CIs to OriginatorsNSelect this checkbox to automatically relate configuration items from the problem to problem originator entities.
Assignment GroupY

Specify a responsible group to work on the request.

Note

When a change request is assigned to a responsible group, the Assigned User field becomes non-mandatory. The same goes for other task objects, like incidents or service requests.

There is a

dependence

dependency between the Assigned User and Assignment Group fields. Refer to the Task Auto Assignment article to learn more.

Assigned UserY

Specify a responsible person to work on the request.

Note

When a change request is assigned to a responsible user, the Assignment Group field becomes non-mandatory. The same goes for other task objects, like incidents or service requests.

There is a

dependence

dependency between the Assigned User and Assignment Group fields. Refer to the Task Auto Assignment article to learn more.

SubjectNDescribe the request briefly. After saving, the field is hidden on the form.
ReasonYJustify the request.
Followers ListN
Users

The list

who 

of users who follow

 the

the request for tracking the updates

is displayed

.  

Info

The field appears if at least one user followed the problem. It is read-only.


StateN

Specify the work state and progress. This field is populated automatically with the Registered state. Other states you can

see

find in State Models. 

ImpactY

Measure the effect that a change request may cause on the business processes and select one of the available choice options:

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

Identify how soon a change request will have an impact on the business and select one of the available choice options:

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

The level of possibility of disruptive or harmful event occurrence. Possible choice options:

  1. High
  2. Low
.
PriorityY

Priority is a function of impact and urgency. It identifies the importance of a request. Available choice options:

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

Risk is a function of impact and probability. It

's

is a possible event that could cause loss or harm. Available choice options:

  1. Low
  2. Medium
  3. High
  4. Very High
.
Change AuthorityYThe person or group responsible for authorizing the request. This field is populated automatically based on the value in the Change type field.
Customize CAB
See Processing Change Requests.

Schedule tab

FieldMandatoryDescription
Planned Start DatetimeNPick a date and time to start the request processing. Fill in this field before a change request can be processed.
Planned End DatetimeN

Pick a date and time to finish the request processing. Fill in this field before a change request can be processed.


Note

If a request is not processed during the planned period, it is canceled.


Planned DowntimeNIf a service downtime is expected,
then put down
specify its duration here. The responsible person must fill in this field before a change request can be processed.
Downtime NotesN
Put
Add any notes about the planned service downtime here. Fill in this field before a change request can be processed.
Possible Conflicting ChangesNChange requests that have a time overlap with this request. It possibly can impact request implementation. This field is populated automatically.
Actual Start DatetimeNPick a date and time for the actual start of the request processing. 
Actual End DatetimeNPick a date and time for the actual finish of the request processing. 
Actual DowntimeN

If the service downtime occurs,

put down

specify its duration here

.

.

Info

The field is mandatory if the Planned Downtime field was filled in, and the state of the change request is Completed.


Planning tabPlanning 

FieldMandatoryDescription
PreparationYThis plan specifies the steps that need to be done and the criteria to be met before implementing the change. Fill in this field before a change request can be processed.
Core ActivitiesYDescribe
here
the process of change implementation. Fill in this field before a change request can be processed.
ValidationYThe process of how the change must be tested after the implementation. Fill in this field before a change request can be processed.
BackoutYThe plan specifies the processes that will roll back the system, service, or CI condition to its previous state in case of a failed implementation. Fill in this field before a change request can be processed.

Closure Information tab appears when the change request state is Completed.

FieldMandatoryDescription
Complete originatorsNSelect this checkbox to make the originators related to this request be completed along with it.
Closure NotesYSpecify some notes summarizing the implementation process.
Closure CodeYSpecify a closure code. For more information,
please
refer to the Closure Code article.


Note

When a change request is Scheduled, In Progress, or Completed, fields on the record form become read-only, excluding the following:

  • Assignment Group
  • Assigned User
  • State
  • Followers List
  • Additional Comments on the Notes tab
  • Actual Downtime on the Schedule tab
  • All fields on the Related Records tab

Change Request Prioritization 
Anchor
priority
priority

The priority of the Change Request change request can be figured out based on its impact and urgency using 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. The damage will be done to the business user, 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 impacts the business – in case of emergency changes.
  • Until lack of change implementation 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, the changes can be categorized as:

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

Excerpt Include
Priority Management
Priority Management


Risk Management
Anchor
risk
risk

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

  • Impact
  • Probability
  • IT Service Business Criticality.

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

Risk metrics for IT Service Business Criticality = Low

Probability / ImpactLowMediumHighVery High
LowLowLowMediumHigh
HighMediumMediumHighHigh

 
Risk metrics for IT Service Business Criticality = High

Probability / ImpactLowMediumHighVery High
LowLowMediumHighHigh
HighHighHighHighVery High
Change

Create a change request

creation

You can create change requests based on two specific issue types:

  • Problem
  • Incident.

When you have fixed an incident or a problem, and, as a result, you have found a need in a change, you can create change requests straight out of incidents or problems. 

Info

You can create a change request out of problems and incidents in any State.

out of

Problem

problem

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

  1. Navigate to Problem Management → All Problems and open the problem you need to work on.
  2. In the hamburger menu , select Create Change.
  3. Choose the type of change you need to create:
    • Standard Change
    • Normal Change
    • Emergency Change.
  4. Fill in the fields of the change request.
  5. Click Save or Save and Exit.

As a result, a new change request is created in the Registered state. There is a reference to the problem in the Caused by Problems field of the Related Records tab.

out of

Incident

incident

To create a change out of an incident, please complete the following steps:

  1. Navigate to Incident Management → All Incidents and open the incident you need to work on.
  2. In the hamburger menu , select Create Change.
  3. Choose the type of change you need to create:
    • Standard Change
    • Normal Change
    • Emergency Change.
  4. Fill in the fields of the change request.
  5. Click Save or Save and Exit.

As a result, a new change request is created in the Registered state. There is a reference to the problem in the Caused by Incidents field of the Related Records tab.

Table of Contents
absoluteUrltrue
printablefalse