Space banner

 

This documentation supports the 19.08 version of Change Management.

To view an earlier version, select the version from the Product version menu.

Creating a change request at the initiate stage

As a user, you can create a change request at the Initiate stage by using the Change Management console.

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, to identify the company for which you are creating the record, select the required value from the drop-down list, and then click Create. The Change form opens on the spoke server of the company that you chose. Continue with the rest of this procedure. The record that you create for the selected company is submitted on the spoke server where the company is defined.

    Important

    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 the groups that have at least one user with an Infrastructure Change Coordinator functional role.
    • Change Coordinator—Specify the user responsible for the change. The list is populated with users that have the Change Coordinator or Change Manager functional role and who are included in the selected Coordinator Group.

      Important

      When in the Search mode, the Change Coordinator field is populated with all users of the selected Coordinator Group, 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 either related to the customer directly, or to the customer's company, organization, or department. When you select the Service CI, the Product Categorization values for the change request are populated with the matching Business Service CIs product categories.
    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 Admin privileges.

  4. (Optional) Select a change template to complete part of the change request. 

  5. Change templates are especially useful when you are creating 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. For more information, see Selecting change templates.

    Important

    If you select the change template after you start to enter the fields in the change request, 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.

  6. (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.

  7. Complete the following fields:

    Field nameDescription
    SummaryProvide a brief description of the change.
    Class

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

    You can use the Class field to categorize a change based the approval process. You can map each class to a different approval process, which drive the status transitions that can be defined as per the organization's requirement.

    You have the following options:

    • Standard—Indicates a change that is typically pre-approved (for example, a computer upgrade) and only requires an approval by the change manager. The Standard changes follow the out-of-the-box change process defined as per ITIL specifications and a defined procedure with a well understood risk assessment.
    • Normal—Indicates a change that must follow the complete change management process where risk assessment is typically based on many factors. Normal changes are often categorized according to the risk and impact to the organization. For example, minor change is low risk and impact, significant change is medium risk and impact, and major change is high risk and impact. Normal changes require some level of approvals to be carried out through the lifecycle of the change request. By definition, a normal change proceeds through all steps of the change management process, and those that are categorized as medium or high risk are reviewed by the Change Advisory Board (CAB). The default value is Normal. The out-of-the-box change follows this process.
    • Emergency—Indicates a change that resolves an incident or problem deemed critical to business continuity and for which a workaround is not sufficient. These changes typically bypass the Normal change approval process and may have a process of their own. You must configure the approval process to follow Emergency changes.
    • Expedited—Indicates a change that needs to be fast tracked, as there is some enterprise-wide impact and an associated risk. If you select this option, you must also select the Timing Reason (for example, Known error correction). You must configure the approval process for expedited changes. Just like normal changes, these changes also require some level of approvals to be carried out through the lifecycle of the change request.
    • Latent—Indicates a change that has already been performed, but a request was not originally raised. For example, 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-the-box configuration of latent changes cannot be changed. Also, the Latent change requests are not displayed in the change calendar as the calendar does not display closed change requests. We recommend not to use Latent changes, but given the complexities and requirements of the business, sometimes, these types of changes are made. It is important to track these changes to determine a process around them to avoid the same change occurring in the future.
    • 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 pre-approved no impact changes where the change is automatically scheduled after the approval phase is complete.

    For more information about the approval processes provided out-of-the-box, see Approval processes provided out-of-the-box for Change Management.

    Best Practice

    Although the change class is a required attribute, the Change Management application does not enforce the use of all these change classes. However, the Standard, Normal, and Emergency change classes are considered best practices and must be included in your implementation.

    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 the Impact and the 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

    The importance that you (as support staff) assign to the change request. This is set by the combination of the values that you have selected in the Impact and Urgency fields.

    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 sets the risk assessment to Risk Level 1 (lowest level). However, we recommend that you answer all the risk related questions to allow the system to automatically set the risk assessment based on the answers provided.

    Important: The highest risk level is Level 5. If the Risk level is set to 2 in the change request form, the value is stored as 1 in the system.

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

  8. In the Initiate stage of the Process Flow Status bar, click the arrow and select Next Stage.
  9. Review the information in the Change Initiation dialog box, and then click Save.

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