Definition of Change Timing / Class selection available on change request form

Version 2
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    Remedy Change Management Application


    BMC Remedy Change Management Application



       What is the definition of each change timing/Class selection available on change request form 
       Change Management 7.0.x, 7.5.x,7.6.x 




    Legacy ID:KA304227


    Change Timing specifies the relative urgency of the change, so that the approvers can assess its magnitude. Possible values are Emergency, Expedited, Latent, Normal, Non-Impact. The Change Type, Timing, Impact and Urgency are required before a change can be submitted. Selection of these values automatically determines the Risk Level and Lead Time for the change. While people can configure these values to use as they wish, the intention by BMC, to keep in line with ITIL. 

      1) No Impact:
      Change has no impact on the infrastructure and requires no approval. 
      By default, No Impact changes follow the Business Approval - No Impact phase and move forward to the Scheduled status. Change Ad Hoc approval process is used in the No Impact Business Approval phase with the Change Manager login as the first approver. By default, this Ad Hoc approval process applies only to changes with a Timing setting of No Impact. When the change moves through the process flow and Change Manager approves the change in the Business Approval – No Impact phase, it then moves to the Scheduled status. You use this process for pre-approved No Impact changes where the change is automatically scheduled after the approval phase is satisfied. 
      If the change is approved, it moves to the Scheduled status. If the request is cancelled, it moves to the Cancelled status. If the request is rejected, its status changes to Rejected. 
      2) Expedited:
      Enterprise-wide impact with an associated risk. If you select Expedited, you must also select the Timing Reason. Timing Reason defines reason for creating a change request with a Timing of Expedited (for example, insufficient lead-time). 
      The Earliest Start Date is determined by the Lead Time for the Change. The Requested Start Date is automatically set to the Earliest Start Date if it is not already specified. If the Requested Start Date is earlier than the Earliest Start Date and the change status is not Draft, the Change Timing is automatically set to Expedited, and you will be prompted to select a Timing Reason. The Scheduled Start Date and Scheduled End Date fields are required when moving a Change status beyond Planning in Progress. 
      3) Emergency:
      Resolves an incident or problem deemed critical to business continuity and for which a work-around is not sufficient OR Emergency is where the actual work on the Change has not begun, yet, but the ticket needs to be advanced, quickly, through the phases. Depending on how your application administrator has configured the BMC Remedy Change Management application, emergency change requests bypass the normal approval process. When you create a change, and select Emergency from the Timing field, the new approval process phase will be used, bypassing the normal change states. For example, if emergency requests are configured to bypass the Review approval stage, the change is not held up waiting for approvals, but is automatically approved. The request skips to the next stage in its lifecycle. 
      4) Latent:
      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. 
      When Change request going through Review Approval in the Review & Authorize Stage. 
      If the Timing of the change is Latent, it moves to the Completed status. The Timing and Timing Reason fields are locked by workflow. You cannot make modifications to the values set in these fields until the change request is approved and it moves to the next status in its lifecycle. 
      5) Normal:
      A standard change (for example, a computer upgrade) that is typically pre-approved and requires only approval by the change manager. The default value is Normal. 
      6) Standard:
      A type of change that must be coordinated by a change coordinator and for which a change template exists that has been approved by the service owner. Standard changes considered changes to the infrastructure that follow an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements. 
      There is no WORKFLOW difference between Standard or Normal. This Class field was applied in Change Management 7.6. The usage of the Class Standard is a Best Practice designation not driven by workflow and this is by design. The information is based on the SMPM and ITIL Best Practice descriptions. If you look at SMPM then you will see much of this information. This is in affect the Use Case to use. 
    Related Products:  
    1. BMC Remedy Change Management Application


    Article Number:


    Article Type:

    Solutions to a Product Problem

      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles