Page tree
Skip to end of metadata
Go to start of metadata

This topic describes the Change Management policy for BMC's Helix services. For information about submitting a request for change (RFC), see Request for Change process.

RFC requirements

The following list describes the requirements for RFCs:

  • An RFC may be submitted by either the customer or BMC, depending on who is initiating the change. For example, BMC will usually be the submitter of an RFC for the application of a hotfix or patch.
  • Customers will submit an RFC via their support portal. If you are using the i.onbmc.com support portal, use the Request a Change option, otherwise submit a case through Support Central. 
  • An RFC that involves a customization must be submitted to BMC with sufficient time to allow for appropriate assessment. The amount of time required for the assessment is based on the complexity of the customization being submitted. Although not mandatory, customizations may be approved in advance by BMC's Customization Review Board. See BMC Helix ITSM Customization policy for additional information.
  • RFCs must be submitted with a minimum of 24 hours' notice. You will request a change window and BMC will respond as to whether or not that window can be accommodated. If that window is not available, BMC will suggest an alternate slot.
  • All changes must be assessed and categorized according to Priority (Impact + Urgency), Timing, and Risk. For more information, see RFC criteria and classifications.
  • All changes should be communicated to those potentially impacted by them.
  • All changes that impact infrastructure or applications must be associated with the applicable Configuration Items (CIs) in the BMC Atrium CMDB.
  • A Forward Schedule of Changes (FSC) must be maintained to provide visibility and coordination of approved changes. If you are using the i.onbmc.com support portal, your changes may be viewed by selecting the Change Calendar option.
  • Necessary documentation and training materials must be updated before implementation.
  • A separate RFC is required for the application of a change in each environment.

Reminders:

BMC SaaS Operations usually has limited involvement in change activities during the onboarding phase as changes are managed by the onboarding team.

For BMC Helix ITSM customers, see Using BMC Remedy Deployment Application for a self-service option for promoting changes. If you are using this application to promote a change from one environment to another, you do not need to submit an RFC.

Testing and review requirements

The following list describes the requirements for the test and review processes:

  • All changes must be tested successfully (where possible). Post-release (implementation) testing is required if pre-implementation testing was not possible.
  • A post-implementation review must be conducted for all changes that are classified as high-impact (significant or extensive impact), high-risk, emergency, or latent, or those that are deemed unsuccessful for any reason.

Approvals and appeals requirements

The following list describes the requirements for approvals and appeals:

  • All changes must be approved before implementation by a member of the customer's Change Approver list. If you do not have a Change Approver list filed with BMC, the change can only be approved by the submitter. Changes that are rejected can be appealed.
  • Any approved change that is modified before implementation must be reapproved.
  • Reuse of an approved change to implement additional changes is not permitted.
  • Once closed, an RFC cannot be reopened.

Related topic

Creating and deploying a package using BMC Remedy Deployment Application

3 Comments

  1.  

    1.  

  2.