BMC Helix Change Management policy

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 be the submitter of an RFC for the application of a hotfix or patch.
• Customers can submit an RFC via BMC Support Central portal, under Case Management. 
• An RFC that involves 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 the risk level. 
• 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. Your changes may be viewed by selecting the Change Calendar option in  BMC Support Central , under Case Management.
• Necessary documentation and training materials must be updated before implementation.
• A separate RFC is required for the application of a change in each environment.

Test 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.