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 is owned by the customer. BMC will act as facilitator to implement/move the changes as per the customer request.

• RFCs must be submitted with a minimum of 3 days of notice. Please request a change slot and BMC will respond as to whether or not that window can be accommodated. If that window is not available, BMC will suggest alternative slots.

  Please note that a database refresh will require a minimum of 5 days of notice, so take this into account for your project timelines. 

  Emergency changes can be submitted for emergency situations. Please contact your Customer Success Specialist to help expedite the request with the Change Team. 

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