Learning about Change Management

The change module in BMC Helix ITSM provides a planning, scheduling, implementing, and change-tracking, approval and risk evaluating interface that is simple to learn and use. The objective of the Change Management is to coordinate changes efficiently, minimizing the risk and impact of change implementation.

Related topics

Orientation

The following screenshot displays a sample change request:

Sample change request.png


The following table describes the information in a change request:

Ticket header

Title, ID number, Priority, Status, SLA progress bar

Displays the change summary, unique identification number of the change request, stage in the lifecycle of the change request, urgency and the number of people it might affect, and so on.


ID

Unique identification to reference a specific change request.


Title

Summary of the change request.


Risk

Risk level of the change request.


Priority

Priority indicates the relative order in which change requests should be addressed, and is influenced by considerations of risk and resource availability.


Status

Stage in the lifecycle of the change request.


Created

The date on which the change request was created.


Updated

The date on which the change request was last updated.

Related service request


The ticket screen displays one of the following:

  • If the ticket relates to a service request that was created in service request management, you can see the request ID, title, and the Related service request label on the ticket screen.

  • If the service request fulfillment workflow in the BMC Digital Workplace catalog creates a change request, you can see the request ID, title, and the Related DWP request label on the ticket screen.

    Important

    The Related DWP request label, request ID, and the title of the BMC Digital Workplace service request are displayed on the ticket screen only in the Progressive Web app. 

To view the service request details, you can click on the request ID.

Location details

Location company

Displays the company to which the customer belongs.


Location

Displays the region and site to which the customer belongs.


Change reason

Displays the reason why the change status is being changed.


Service

Displays the business which is affected by the change request.


Operation category

Identifies the operational category and product category that are assigned to the change request.

Important: Within the system, the Operational and Product categorization information is organized around a three tier hierarchy, with Tier 1 being the most general category and Tier 3 being the most specific category. The information that is shown in the Categorization fields represents the Tier 3 category. For example, if the product categorization is: Tier 1, Hardware; Tier 2, Laptop; Tier 3 <modelName>, the <modelName> appears in the Product Category field.


Product category

Operational and Product categorizations are not configured and shipped for work orders. You must modify the records in the Operational Catalog Setup and Product Catalog Setup forms of BMC Helix ITSM if you intend to use them with work orders.

If multiple CIs are associated with the ticket, the system displays the affected CI in the Product Category field.

Ticket details

Description

Detailed information about the change request. That indicates why is the change request created.

Assignment

Change coordinator

In the change process Change coordinator is typically the person who creates the change request. The Change coordinator identifies the support group and individual within the support group that is assigned to work on the change request.





Change manager


Change coordinator group


Change manager group


Assign to me

Assign the ticket to yourself.

Ticket details

Impacted areas

The location that is impacted by the change.

Dates

Scheduled Dates, Actual Dates, Target Dates

Enter the dates in this section. The dates are used to manage collisions.

Risk


Includes a few questions that the system uses to calculate risk.

Tasks


Allows you to create and assign tasks related to the change request, update the tasks, and track their progress. You also have the option of creating change requests by using the Progressive Web Apps screen.

For more information, see Creating-and-modifying-tasks.

Configuration Items


CIs related to change requests are listed in Configuration Items.

Related items


Lists any records that are associated with the change request, such as work orders or incidents. From this section, you can relate existing records, or create new records.

For more information about the information recorded in these sections, see Relating-items-to-the-change-request.

Documents


Select the documents you plan to add for this change request.

You can watch the following video about the overview of Change Management:


icon_play.pnghttps://youtu.be/WaYJ8-Z8zHc

Process overview

The following video explains the Change Management process flow.

Important

Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.


icon_play.png https://youtu.be/-BLQN6MaAnM

The following figure illustrates the lifecycle of a typical change request.

Stages in the lifecycle of a change request.gif

The typical lifecycle of a change request consists of the following major stages:

Initiate and record

When you initiate a change request, you must record essential information about the change, such as its class (standard, normal, no impact, emergency, expedited, latent), affected configuration items (CIs), scheduled dates, risk level, and supporting documents. If you use a template to create a change request, values in the template take precedence over system defaults.  For more information, see Creating-a-change-request-at-the-Initiate-stage.

pwa_create change request_general.jpg

New change requests can be created in other ways. Examples include:


    • Problem coordinators can create a change request from a Known Error.
    • Using the Requester Console, a user can request a service that generates a change request.
    • A technician who made changes to a database server during non-work hours can create an after the fact latent change request from the Overview Console.
    • The Action Request System workflow in the BMC Service Request Management application can automatically generate change requests (for example, a service request to replace a mission-critical server).
    • The discovery process can automatically generate a change request if it detects that a server does not have the latest patches loaded.
    • BMC Helix ITSM: Asset Management can automatically generate a change request from a purchase requisition (for example, purchasing a laptop for a new employee).
    • BMC Performance Manager can automatically generate a change request if it detects that a mirrored web server has failed and needs to be replaced. 

The following activities in Change Management are designed to support this stage of the process:

Review and Authorize

If no approvers are mapped to this stage, change requests bypass the Review & Authorize stage entirely. But if the application administrator configured approvers, each level of approvers must review the request and approve or reject it.

approve.png

After the request is approved, the Change Coordinator can move the change request to the Plan & Schedule stage. After the change planning is completed, the change is sent to the Change Manager who reviews the change to ensure the information is complete and accurate, before submitting it for approval. Tasks are automatically assigned to the appropriate task implementers.

The following activities in Change Management are designed to support this stage of the process:

Plan and Schedule

BMC Helix ITSMhelps you plan when to make the change. The dates you choose must avoid conflicts with other change requests that are related to the same CIs and scheduled during the same time frame. You can run impact analysis and collision detection for a change request. These functions help you identify all impacted CIs, and then  manage any conflicts with other change requests and outages that affect the same CIs. The calendar shows collisions in a graphical format.
Calendar.png

The following activities in Change Management are designed to support this stage of the process:

Implement

The process to implement a change involves a set of tasks. A task represents a specific set of steps and is assigned to a task implementer. The task implementer can locate the assigned tasks in Ticket Console. If you use a change template to create a change request, the tasks that are needed to complete the change are automatically included. After the change is initiated, you can also add and assign tasks by using task and task group templates, or by adding ad hoc tasks. When all tasks are closed, the change moves to Completed status and the Actual End date is automatically populated. 
NestedTask_PWA.jpg

The following activities in Change Management are designed to support this stage of the process:

Closed

The change request lifecycle is managed through status transitions. When all of the tasks are completed, the change request status changes to Completed. After recording the actual dates for the change and entering any final notes, you can set the status to Closed.

The following activities in Change Management are designed to support this stage of the process:

Approvals in Change Management

The change manager or change coordinator controls the overall progression of a change request, and can perform approvals at several points in the change lifecycle.

For change requests that have a status of Request for Change with no approvers, the change manager or the change coordinator can move the change forward to Planning In Progress, cancel it, or send it back to the requester by assigning it a status of Draft.

After a change is planned and a change request is built, the change request is set to a status of Scheduled for Review. The change manager or change coordinator can again review change plans and schedules, before moving the change to the Implementation Approval phase.

The following screenshot displays the approval form used for approving or rejecting change requests:

approvals.png

Testing your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

What type of approvals can you have for a change request?

Change requests can require any combination of the following approvals:

  • Review approval, after the change request is initiated
  • Business approval, before planning and scheduling begin
  • Implementation approval, before task implementers start to implement the change
  • Close down approval, after the task implementers complete their work
What are the stages in a change life cycle?
  • Initiate and record
  • Review and authorize
  • Plan and schedule
  • Implement
  • Closed
In which stage, you need to check collision detection?

Plan and schedule

Do you want to learn more?

For more information about creating change requests, see Creating-change-requests-in-the-Initiation-and-Recording-stage.

For more information about approving change requests, see Approving-change-requests-in-the-Approval-stage.

Instructions for classic interfaces

View instructions for Mid Tier

The Change form is used to request a change and track the progress from the Initiate stage to the Closed stage. This form also shows the impact that the change has on the organization. The Change form is used to relate tasks to different support groups. You can relate the change to configuration items that are being modified.

best-practice-view_61946_516.gif

Before you begin creating or modifying information in the Change form, you should understand the information relationships in the different areas of this form. The Change form provides an example of the level of integration that can occur between the various modules in BMC Helix ITSM, such as a change request that occurs due to an incident, a change to a configuration item, or a known error correction as a result of problem investigation.

Tip

As you work with the forms and dialog boxes, you might see a plus sign (+) included in a field label. You can type part of the information in these fields and press Enter. If an exact match is found, the field is automatically completed. If a selection list appears, double-click the item to put it in the field. Using auto-fill fields and lists is faster, more consistent, and more accurate than typing the information.

If other applications are installed, you might see additional links in the navigation pane for applications that are installed in addition to Change Management.

The Change form has the following functional areas:

Form area

Function

Change form header

Breadcrumb bar

A navigation aid that contains links to related records that you opened from the current release record.

Breadcrumb navigation controls

  • Back button—Takes you back one link in the breadcrumb trail.

  • Forward button—Takes you forward one link in the breadcrumb trail. The Forward button is only visible if you have returned to a record on the breadcrumb trail that you previously viewed.

  • Menu—Contains links to all the records that you viewed from the current release record, including records that are not currently visible in breadcrumb trail.

  • Home icon—Takes you to the IT Home page.

Process Flow Status bar

The change stages in the Process Flow Status bar move through the change request lifecycle from the Initiate stage to the Closed stage.

View Broadcasts

Opens the View Broadcasts dialog box. For information, see Broadcasting messages.

Navigation pane

Functions

Allows you to perform the following actions:

More

Allows you to perform the following actions:

Process flow and the stages of a change request

The user interface in BMC Helix ITSM: Change Management enables managers, administrators, users, and approvers to perform regular tasks simply and efficiently. The Process Flow Status bar on the Change form takes you through the change process from the Initiate stage to the Closed stage. It provides a visual mechanism to track the stages of a change request, as indicated by best practices that are rooted in ITIL processes. For more information, see Change-Management-roles.

You can use the Process Flow Status bar to control the progression of the request through the different stages in the lifecycle. It functions similar to a wizard, guiding you through the stages of the change lifecycle from stage to stage. As the change advances through the stages, the current stage of the change is highlighted on the Process Flow Status bar of the Change form by color and text.

The Status field on the Change form is also updated. The Status and Status Reason field selections are limited to valid status values for the transition.

Best practice
Do not manually set the Status and Status Reason fields in the Change Request form. When you select an action from the Process Flow Status bar menu, the value in the Status field is automatically updated based on the action that you have selected.

process-viz_61934_516.gif

Important

The Process Flow Status bar and the status of a change request might not be in sync if, in a single session, the same user updates the status of the change. To synchronize the status bar and the status of the change request, close the change request and reopen it.

If a custom process flow is associated with a change template, when you select the change template, the stages indicated in the Process Flow Status bar change to reflect the process for the type of change. For example, the process for provisioning a new virtual machine might skip the Plan & Schedule stage. If you do not select a change template, or if the change template is not associated with a custom process flow, the standard change process is followed.

When approval is required within any of the stages, the word Approval is displayed on the Process Flow Status bar. The request will not move to the next stage until all required approvals for that stage have been granted. For example, if an approval is required in the Initiate stage, the required users are prompted to approve, cancel, or reject the change request before the change request can move to the Review & Authorize stage. You can approve changes from the Approval table on the change form or Approval Central, if you are a valid approver for the change.

You can perform other functions using the Process Flow Status bar. For more information, see Performing additional functions from the Process Flow Status bar.

When you select an accelerator, you might be prompted to enter the data required to complete the stage. For example, when you are in the Plan & Schedule stage you are prompted to enter the required start and end date of the change request and its tasks.

accelerator_61936_516.gif

The following figure is an example of a process flow dialog box:
implement example.png

The current and overall approval status of the change is highlighted by the following colors:

  • Yellow—Pending
  • Green—Approved
  • Red—Rejected
  • Gray—Transitional (does not require an approval)

You can perform the following functions from the Process Flow Status bar:

Function

Action

Move the Change or Release to next status or milestone

In the Process Flow Status bar, click the arrow on the green status and select Next Stage.

The Change or Release moves to the next status or milestone.

Move the Change or Release to Pending status

  1. In the Process Flow Status bar, click the arrow on the green status and select Enter Pending.
  2. Select appropriate status reason (for example, Manager Intervention).
  3. Select Resume from the Process Flow Status bar when you are ready to continue work on the request.

Return the Change or Release to earlier status or milestone

  1. In the Process Flow Status bar, click the arrow on the green status and select Back.
  2. Select the milestone you want to return to, for example, Initiate.

Important: If you use the Back option to move the request to a previous stage or milestone, all required approvals defined for any stage that is repeated must be performed again.

Cancel a change or release request

  1. In the Process Flow Status bar, click the arrow on the green status and select Cancel.
  2. Select appropriate status reason, for example, Resources Not Available. The Change or Release moves to the Completed or Close Down milestone.

View process flow help

In the Process Flow Status bar, click the arrow on the green status and select Help.

The process flow help is displayed (if it is installed).

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*