Page tree


    To view the latest information for BMC Helix services and policies, go to BMC Helix Subscriber Information.

    Skip to end of metadata
    Go to start of metadata

    The BMC Remedy OnDemand service is controlled using a defined Change Management process.

    Scope includes

    The scope of BMC Remedy OnDemand Operation Change Management is as follows: 

    • Hardware Changes – Adding, moving, or removing server and network devices to or from a customer environment 
    • Operating System and Network Software Changes:
      • Installing, patching, or upgrading OS products (including operating systems, access methods, support packages, internally developed packages, and utilities)
      • Making policy or parameter changes
      • Making iOS changes that provide connectivity between nodes or within network hardware
    • Configuration Changes – Configuration-level changes to hardware, software, networks, and applications
    • Database Changes:
      • Backing up, restoring, or refreshing databases
      • Executing SQL (as part of customer-provided scripts)
      • Modifying stored procedures
    • Application Changes:
      • Promoting application changes to environments
      • Implementing standard integrations (such as non-customized LDAP integrations)
      • Removing obsolete elements
      • Migrating changes from one environment to other environment
      • Making system configuration changes
    • Moves, Additions, Changes, and Deletions – Changes to system configurations
    • Job Schedule Changes – Requests for creating, deleting, or revising job schedules or backup schedules, or other regularly scheduled jobs
    Scope excludes
    • Any environment requested to be deemed exempt from the process
    • Customer-managed systems outside of BMC Remedy OnDemand environments
    • Functional and data changes that customers can perform with their access:
      • Foundation data loads for version 8.x releases:
        • Creating, loading, or scheduling jobs
        • Adding people to a support group or modifying people profile permissions
      • Service Level Management:
        • Editing an existing service target
        • Rebuilding service targets
        • Manually editing a business entity for an existing service target
      • Release Management:
        • Configuration approval mapping and approval changes
    • Changes made within the daily administrative process. Changes to the processes themselves, however, are subject to this change process. Examples of daily administration tasks are as follows:
      • Password resets
      • Addition and deletion of users
      • User modifications
    Change types
    • Standard Change: A preauthorized change that is considered low risk and relatively common, and does not require a Request For Change (RFC). A standard change is recurrent, is well known, and can be executed in predefined and relatively risk-free path. It is preapproved by the Change Advisory Board (CAB).
    • Normal Change: A change that is more complicated than a standard change and requires an RFC.
    • Emergency Change: A response to a critical outage situation for a customer environment. An emergency change does not follow any change management approval process, but it is recorded once the outage situation is resolved. Generally, the introduction of new change is discouraged during an outage situation.

    Standard change examples

    The current list of standard changes includes the following changes:

    • Application of hotfixes
    • Database refreshes

    Normal change examples

    Normal changes must follow the complete Change Management process. By definition, a normal change proceeds through all steps of the Change Management process and is eventually reviewed by the CAB.

    • Migration of a Service Request Definition (SRD)
    • Promotion of an .arx file from one environment to another environment
    • Any configuration changes to an environment

    When a change requires an RFC, a defined process is followed:

    • A customer approved (approved by a customer-authorized Change Approver) change is reviewed (including impact and urgency) and is approved by the CAB
    • Changes approved by the CAB are then scheduled for implementation
    • Changes requiring customization (such as new integrations or changes to workflow) require approval from the Customization Review Board prior to submission to the CAB