This documentation supports the 21.05 version of BMC Helix ITSM: Change Management. To view an earlier version, select the version from the product version menu.

Planning implementation of a change request


As a user, you can plan for a change request.

  1. Open the Change Calendar.
    1. Open the Change request.
    2. Select Quick Action > View Calendar.
    3. On the Change Calendar, select how many days worth of change requests and business events to show.
      For more information, see Scheduling-changes-by-using-the-Calendar.
    4. View requests as needed.
    5. Select the requests and business events for a specific day.
    6. Close the Change Calendar.
      For more information, see Scheduling-changes-by-using-the-Calendar.
  2. Register available or unavailable time segments for your business event, operational categorization, or CI.
    For more information, see:
  3. Use the Process Flow Status bar to move the request to Planning in Progress status in the Plan & Schedule stage.
  4. Click the Date/System tab.

    Recommendation

    If many tasks are required for the request you are planning, it might be best to create the tasks before you enter the dates. The Task Dates table displays the task dates and times to help you determine the start and end dates of the change request. For more information, see Task-implementation-for-Change-Management.

  5. When planning a change request, use the Date/System or the Dates tab to track the requested, scheduled, and actual start and end dates of changes.
    The Earliest Start Date is determined by the Submit Date. For example, User A works for a Support Group SG1 for which the working hours (shift) are defined as 9:00 A.M. to 6:00 P.M. PST. When user A creates a change after 6:00 P.M. PST, the Earliest Start Date for that change is calculated by considering the working hours of the Manager Group. Therefore, the Earliest Start Date shows 9:00 A.M. If the user is in a different time zone, that offset is automatically considered.

    Important

    When adding dates:

    • If the change status is not Draft, the Class on the Change form is automatically set to Expedited with a warning when the Requested Date is earlier than the Earliest Start Date.
      When the Class is changed to Expedited, you are prompted to select a Timing Reason.
    • The Actual Start Date and Actual End Date fields of the change request are populated depending on the tasks defined in the Implementation phase of the change. The Actual Start Date is populated when the first task of the phase is activated and the Actual End Date is populated when the last task of the phase is closed, completed, or cancelled.
    • When the Actual Start Date or Actual End Date is earlier than the Submit Date a warning message is displayed. The message states that the change must be a Latent change for the Actual Start Date to be earlier than the Submit Date that is displayed and the value in the Actual Start Date field is cleared. This behavior is displayed irrespective of the status of the change request.
  6. (Optional) Use the Schedule Assist utility to search for available times for the change request.
    For more information, see Managing-time-segment-availability-based-on-business-event-or-operational-category.
  7. In the Change Dates region of the form, provide dates for the Scheduled Start Date and Scheduled End Date fields.
    If the new dates fall outside the range of the task's Scheduled Dates, changes to the Scheduled Dates (both Start and End) can result in notifications being sent to task implementers.

    Important

    The Scheduled Start Date and Scheduled End Date fields are required when you are moving a change status beyond Planning in Progress. However, for no impact changes, or changes that follow a custom process flow that skips the Planning in Progress stage, you are prompted to enter the Scheduled Start Date and Scheduled End Date fields when you save the change or move the change to the next stage from the Draft stage.

  8. (Optional) Review the RFC Date information.
    This field contains the date and time information at which the change was requested.
  9. If the change request did not pass through the Review & Authorize stage, assess the risks and impact of the change request.
    You can compute the risk level of the change. For more information, see Computing-risk-levels.
  10. (Optional) Use the Process Flow Status bar to relate a CI to the change request, as shown in the following figure:

    cr-relate-ci_61784_516.gif

    When the CI Relationships Search dialog box appears, you can search for a CI and then relate it to the request. For more information, see Relating-and-managing-configuration-items-and-impacted-services-for-a-change-request.

  11. (Optional) Click the Tasks tab.
    You can plan and create the tasks that make up the change request. For more information, see Task-implementation-for-Change-Management.
  12. (Optional) Select Links > Financials to calculate the costs associated with the change request:

    For more information, see Adding-and-modifying-costs.

  13. Click Save.
  14. Click Next Stage in the Process Flow Status bar to move the change request forward.
    When the change request reaches Scheduled For Approval status, it must be approved to move forward. For more information, see Approving-release-requests.

 

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