This documentation applies to the 8.1 version of Change Management, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Creating a change request at the initiate stage - Best Practice view

The section describes how to create a change request at the Initiate stage when using the Best Practice view of BMC Change Management.

To create a change request

  1. On the Change Management console, click Create or Create for Company (in a Hub and Spoke environment).
    If you are working in a Hub and Spoke environment, you are asked to identify the company you are creating the record for. Select the company from the drop down list, then click Create. The Change form opens on the spoke server of the company you chose. Continue with the rest of this procedure.

    Note

    The record that you create for the selected company is created and submitted on the spoke server where the company is defined.


    In the Initiate stage, the change request initially appears in Draft status. The change request has not yet been submitted to the Change Management process.

  2. Use the following fields to specify the change coordinator:
    • Coordinator Group — Specify the group of people with the Infrastructure Change Coordinator functional role. This list is populated with groups that have at least one user with a Infrastructure Change Coordinator functional role.
    • Change Coordinator — Specify the user responsible for the change. The list is populated with users who have the Change Coordinator or Change Manager functional role and are included in the Coordinator Group selected.

      When in the Search mode, the Change Coordinator field is populated with all users of the Coordinator Group selected, irrespective of their functional role.

  3. From the Service field, select the business service configuration item (CI) that relates to the change request that you are creating.
    The Service field relates business service configuration items (CIs) to the change request at the time it is created. Business service CIs are related either to the customer directly or to the customer's company, organization, or department.

    Note

    The business service CI is not a physical CI (such as a printer or a router); it is a logical CI. In this context, a logical CI is a business service that can be provided from one business, or organization within a business, to another. Service CIs can include customer support, employee provisioning, web farms, storage, and so on. When business service CIs are created and made available on the Service field menu, they are related either to a customer directly or to the customer's company, organization, or department. If you need to have a new business service CI added to the Service field menu, you must notify a system administrator with Asset Administrator privileges.

  4. (Optional) Select a template to complete part of the change request.
    Change templates are especially useful in any change request that follows well-defined methods for specific and repeated requirements.
    The template is attached to the change request. The custom process flow associated with the change template applies to the change request. A new Work Info record is created that includes a textual representation of the change process flow. In the process flow bar, the options for next and back are changed to reflect the process flow.

    Note

    If you start to enter fields in the change request and then select a change template, the change template overwrites any field values that are already present in the change request, including any relationships or tasks included with the change request.

  5. (Optional) Enter a date in the Target Date field.
    The target date is the date by when the change must be completed, according to the applicable service level target. Alternatively, the target date can be a date that is agreed to on an ad hoc basis, per change. The target date cannot be set to a date earlier than the current date, except for Latent changes.

    For detailed information about the dates related to a change request, see The Dates tab.

  6. Complete the following fields:

    Field name

    Description

    Summary

    Provide a brief description of the change.

    Class

    Specify the relative urgency of the change, so that the approvers can assess its magnitude.

    Note: The Class field can be used to categorize a change based the approval process. Each Class can be mapped to a different approval process, which will drive the status transitions that can be defined as per the organization's requirement.

    You have the following options:

    • Standard indicates a change (for example, a computer upgrade) that is typically preapproved and requires only approval by the change manager. Standard changes follow the out-of-box change process defined as per ITIL specifications. This configuration is not provided out of box.
    • Emergency indicates a change that resolves an incident or problem deemed critical to business continuity and for which a workaround is not sufficient.
      You must configure the Approval Process to follow for Emergency changes.
    • Expedited indicates that a change has an enterprise-wide impact with an associated risk. If you select Expedited, you must also select the Timing Reason (for example, Known error correction).
      You must configure the Approval Process to follow for Expedited changes.
    • Latent indicates a change that has already been performed (for example, if a task implementer is assigned to replace the hard drive on a computer and then decides to upgrade the memory while the computer is open). Latent timing automatically sets the request status to Completed after you save the change request. The Target Date for a latent change can be earlier than the current date.
      This out of box configuration of latent changes cannot be changed.
    • Normal indicates a change that must follow the complete change management process. Normal changes are often categorized according to risk and impact to the organization (for example, minor change – low risk and impact, significant change – medium risk and impact, and major change – high risk and impact). By definition a normal change will proceed through all steps of the change management process and those that are categorized as medium or high risk will be reviewed by the Change Advisory Board (CAB).
      The default value is Normal. Out of box a change follows this process.
    • No Impact indicates a change that has no impact on the infrastructure and requires no approval.
      By default, No Impact changes follow the Business Approval - No Impact phase and move to the Scheduled status. Use this process for preapproved no impact changes where the change is automatically scheduled after the approval phase is complete.
      For more information on approval processes provided out of the box, see Approval processes provided out-of-the-box for Change Management .

    Impact

    Specify the extent to which the change affects the business. The default value is 4-Minor/Localized. Impact is often directly related to the extent to which the service has degraded from agreed service levels. Impact can be measured by the number of people affected, the criticality of the system affected, and the loss of revenue as a result of the service degradation or disruption.

    For detailed information about Impact, see Impact, urgency, and priority criteria.

    Urgency

    Specify a value that indicates the importance of the change request, and reflects how quickly a change must be implemented, or the time available to reduce the impact of the change on the business. The default value of the Urgency field is Low.

    Use the following factors to determine Impact and Urgency:

    • Number of customers affected by associated Incidents
    • Duration and scope of the service disruption
    • Availability of a solution or workaround
    • The type of service being disrupted, usually based on the CI involved
    • Awareness of the future impact on the business

    For detailed information about Urgency, see Impact, urgency, and priority criteria.

    Priority

    Specify the importance that you (as support staff) assign to the change request.

    Priority indicates the relative order in which to address the changes. It is influenced by considerations of risk and resource availability, but is primarily driven by the combination of Urgency and Impact. The default value of the Priority field is Low.

    For detailed information about Priority, see Impact, urgency, and priority criteria.

    Risk Level

    The system automatically performs the risk assessment for the change request in the Risk Level field. The risk level is used as a criterion to determine required approvals. The default risk level is Level 1, which is the lowest level. The highest risk level is Level 5.

    Risk assessment involves computing the total risk based on risk related questions and the derived risk factors. For more information, see Computing risk levels.

  7. In the Initiate stage of the Process Flow Status bar, click the arrow and choose Next Stage.
  8. Review the information in the Change Initiation dialog box, and then click Save.
  9. By default, a new Work Info record is created that includes a textual representation of the default change process flow.

The newly created change is assigned to the appropriate group based on the predefined assignment routing. If there is no appropriate assignment routing, you are prompted to assign the change request manually.

Was this page helpful? Yes No Submitting... Thank you

Comments

  1. Chris Williams

    Hi Team,

        The link to "Approval processes provided out-of-the-box for Change Management" is pointing to the Release Management approval process and not the Change Management ones which are found here: https://docs.bmc.com/docs/display/public/change81/Approval+processes+provided+out-of-the-box+for+BMC+Change+Management

    Please could you correct this.

    Cheers

    Chris

    Aug 04, 2014 08:46
  2. Scott Skeate

    Still not corrected in the main document.

    Dec 19, 2017 07:01