Develop > Processes and Best Practices Guide > Change Management Details > Change Management form details

Change Management form details

The following table identifies and describes some of the features on the Change Management forms.

Change Management field descriptions

Label

Description

Change ID

This is a system-generated field assigned when the change is opened.
Change Model A change model is a record that is used to predefine the contents of a specific type of Request for Change (RFC), including the information used to populate the RFC and the tasks that are needed to complete the change. When you open a change request using a change model, most of the necessary information is added to the change automatically.

Phase

This is a system-generated field that specifies the name of the current phase of the change.

Approval Status

This is a system-generated field that defines the global approval status for the change, not for a single approval. The system sets this field depending on current approvals and the approval type defined for the module.

These approval statuses are available out-of-box:

  • Pending
  • Approved
  • Denied

Change Requester

The name of the user requesting the change.

This is a required field. This field includes a hover-over form that displays full name, telephone, and email address if available for the user requesting the change.

Assignment Group

The group assigned to work on the change. For a description of this field see the Assignment Group field description in the Incident Management form details section in the Service Manager Processes and Best Practices Guide as this field functions similarly. The out-of-box data consists of default assignment groups for use as examples of types of assignment groups.

You may want to change the sample assignment groups to meet your own needs.

These assignment groups are available out-of-box:

  • Application
  • Email / Webmail
  • Field Support
  • Hardware
  • Intranet / Internet Support
  • Network
  • Office Supplies
  • Office Support
  • Operating System Support
  • SAP Support
  • Service Desk
  • Service Manager

Change Coordinator

The person responsible for coordinating the change implementation. Each Change Coordinator may belong to several assignment groups. Each group must have only one Change Coordinator.

Service

Specifies the service affected by the change. This is a system-generated field and is prepopulated when a change request is created from an interaction.

This is a required field.

Affected CI

The list of Configuration Items (CIs) affected by the change. The system prepopulates this field when a change request is created from an incident or problem. Users can add additional CIs. This field includes a hover-over form that displays check boxes for Critical CI and Pending Change.

Location

Specifies the location for the change. The system prepopulates this field when the change is created by escalating an interaction.

Title

Provides a short description or a gist of the change. This is a required field.

Description

Provides a detailed description of the change. This is a required field.
Scope Provides a detailed description of the change scope.

Category

This is a system-generated field that classifies the type of change.

Impact

This field is prepopulated with data from an incident when a change is created from an incident. It specifies the impact the problem has on the business. The impact and the urgency are used to calculate the priority.

These impacts are available out-of-box:

  • 1 - Enterprise
  • 2 - Site/Dept
  • 3 - Multiple Users
  • 4 - User

The out-of-box data is the same as Interaction Management, Problem Management, and Incident Management.

This is a required field.

Urgency

The urgency indicates how pressing the change is for the organization. The urgency and the impact are used to calculate the priority. This field functions similarly to the same field for interaction, incident, and problem tickets. For more information, see User Interaction Management form details in the Service Manager Processes and Best Practices Guide.

This is a required field.

Priority

This is a system-generated field using the urgency and impact of the change. This field functions similarly to the same field for interaction, incident, and problem tickets. For additional information, see User Interaction Management form details in the Service Manager Processes Processes and Best Practices Guide.

Risk Assessment

Specifies a code that indicates the risk incurred with the implementation of the change. This field becomes required in the Change Plan and Schedule phase.

These risk assessments are available out-of-box:

  • 0 - No Risk
  • 1 - Low Risk
  • 2 - Some Risk
  • 3 - Moderate Risk
  • 4 - High Risk
  • 5 - Very High Risk

After a user selects this field, the change may require additional approvals based on the risk. The approval is based on the risk number in the assessment approval record. This is a required field.
Financial Impact

Specifies a code that indicates the financial impact of the change. These financial impact codes are available out-of-box:

  • 1 - High
  • 2 - Medium
  • 3 - Low
Review Required

This option specifies whether post-implementation review is required or not. By default, it is set to true for Emergency and Normal changes in the Risk and Impact Analysis phase, while false for Standard changes in the Plan and Schedule phase. This field cannot be changed in subsequent phases.

Requested End Date

The system prepopulates this field if the change request is triggered from an interaction. This is the date the change initiator requests the change implementation. This is a required field if not prepopulated.

Alert Stage

This is a system-generated field that lists the current Alert Stage of this request. Change Management updates this field automatically when processing alerts against this change. Do not update it manually. The alerts are processed against a change by using the phase definition. This field is not active in an out-of-box system and must be manually enabled.

Scheduled Implementation Start

This field specifies the date and time that the work to implement the change should start. This field becomes required in the Plan and Schedule phase.

Scheduled Implementation End

This field specifies the date and time that the work to implement the change should end. This field becomes required in the Plan and Schedule phase.

Scheduled Downtime Start

The date and time when the change is scheduled to begin. Scheduled downtime only needs to be filled when the service is down, while implementing the change.

Scheduled Downtime End

The date and time when the change is scheduled to end. Scheduled downtime only needs to be filled when the service is down, while implementing the change.

Configuration Item(s) Down

If selected (set to true), indicates that the Configuration Items (CIs) are currently not operational and the downtime is scheduled. The fields Scheduled Downtime Start and Scheduled Downtime End are used along with the field Configuration Item(s) Down to indicate the scheduled time to bring the CI down. These fields are never required and should only be populated if you plan to bring down the CIs as part of the change. The interval selected applies to all the CIs of the change and cannot be specified by individual CI. When the change is closed, you may get the form confirming the outage times, and when you close the change, the CIs will be set as Up in Configuration Management.

Ex. Project Ref.

This field references an external project number.

Implementation Plan

An assessment of the change, often generated by the Change Implementer, that the Change Coordinator uses to assess the impact of the change to services.

Effect of not Implementing

The impact if not implementing the change. This is a required field.

Change Owner

The name of the user owning the change. This is a required field.

Subcategory

The subcategory is a breakdown of the category and describes the type of change in more detail.

Actual Implementation Start

The time when the implementation actually began.

Actual Implementation End

The time when the implementation actually ended.

Review Results

Results of the review after Post Implementation Review, this is a required field.

Closure Code

The completion code indicates the way a change is closed.

VALID VALUES

  • 1 - Successful
  • 2 - Successful (with problems)
  • 3 - Failed
  • 4 - Rejected
  • 5 - Withdrawn
  • 6 - Cancelled

Associated CIs section >

CMDB attributes need to be changed for CIs in the list

Completed/Cancelled CMDB attributes modifications

CMDB relationships need to be changed for CIs in the list

Completed/Cancelled CMDB relationships modifications

The data in this section is used by the UCMDB integration whenever there are past changes to the values registered for the CI.

Affected Services section >

Affected Services

This provides a list of affected services. When a configuration item for an incident is added or updated, a schedule record is created that runs a routine to update the list of affected services.

Approvals section> Current Approvals

This section provides an overview of the current approvals related to any changes for the CI, and important information such as approval status, and approvers as well. This includes a list of groups or operators who must acknowledge or accept the risk, cost, and so on associated with the implementation of a Change request or task. Approvals give controlling authorities the ability to stop work and to control when certain work activities can proceed.

The data displayed includes the following information:

  • Approval Type
  • Approval Status
  • # Approved
  • # Denied
  • # Pending

Approvals section> Approval Log

This subsection provides an overview of past approvals related to the changes for the CI, as well as important information such as approval status and approvers.

The data displayed includes the following information:

  • Action
  • Approver/Operator
  • By
  • Date/Time
  • Phase

Reason for Change

A code that indicates the primary reason for implementing the request.

Examples of reason codes are Incident/Problem Resolution and Business Requirement.

Approval section > Pending Reviews

The name(s) of the groups or operator IDs that should review the change for the CI after it has been approved.
Cost section > Total Cost This field indicates the system-calculated total cost of the Change, which is accumulated by the parts and labor cost of the Change itself and its related Change tasks.
Cost section > Currency Specifies a currency code used by the system to calculate the total cost.
Cost section > Parts table Specifies the parts used by the Change with their part numbers from the product catalog and the quantity used.
Cost section > Labor table Specifies the technician who worked on the Change and the actual working hours.

Tasks

Whenever a change is in a phase where the user can generate tasks, Service Manager allows user a quick view of some of the most important fields in the task in the Tasks section.

The data displayed includes the following information:

  • Task No
  • Phase
  • Status
  • Description
  • Category
Remediation Method Indicates the remediation method: Full, or Partial.

Remediation Comments

Provides a detailed method for backing out the change if there is a problem implementing the change. This is a required entry for all changes while backing out a change. It is also required in the "Release back out" phase and for the Release Management category in order to close the "Release plan and design" phase.

Send Help Center feedback