Change request process

The following steps describe the standard change request process flow. Separate requests for change (RFCs) must be created in Support Central for each customer environment, even if you are applying the same change to multiple environments. 

1. Submitting the RFC

The RFC form lists all of the information that the change submitter (BMC SaaS Operations, or customer or project teams, on behalf of a customer) must provide to fulfill the change request. It requires enough information in order to effectively plan, manage, track, and fulfill an RFC.

The Change Submitter ensures that the following documentation is complete:

• A detailed description of the change, including the purpose or expected outcome of the change
• Procedures needed to prepare, install, verify, and back out the change
• Impact and risk analysis of the change, including worst-case impact, analysis of a failed change, and a mandatory backout procedure
• Change prerequisites
• Required artifacts, such as design documentation, or physical diagrams that help explain the nature of the change

Consider keeping the contents of the RFC simple at the beginning of the Change Management process. Doing so encourages process compliance. Also, make sure the change form is filled out completely. An incomplete or ambiguous RFC may lead to rejection of the change or a delay in scheduling the change.

2. RFC lead time 

In order to allow enough time for proper assessment, an RFC must be submitted with a lead time of three working days for normal change requests. If you are not able to provide the required notice, your change slot may not be accommodated. See also Emergency changes. Please ensure: 

• the required information is provided
• the requested changes are in-line with BMC standards, following best practices under the BMC Helix ITSM Customization policy
• all prerequisites exist for executing the changes

3. Authorizing the RFC

For each change, formal authorization is obtained from a change authority (your designated Change Approver). 

Customer-authorized change approvers will be contacted via email by BMC SaaS Operations to request authorization and in-application on Support Central > Case Management under Approve a Change. 

4. Scheduling the RFC

All authorized RFCs are scheduled by the BMC Change Team using your preferred change window whenever possible.  If the requested change window is not available, BMC SaaS Operations will select another option and contact your Change Approvers to negotiate an alternate change window. 

5. Executing the RFC

All approved RFCs are executed according to their schedule. BMC SaaS Operations will send a timely notification (Start, End, Delayed, Extended) to keep you updated on the status of execution.

7. Extending the change window

Every now and then a BMC-initiated change will require an extension to the change window in order to complete the request. When this situation arises, BMC SaaS Operations will provide a minimum of 15-minute notification (prior to the end of the originally scheduled window) to the customer. If an extension is necessary, the change window will be extended by one hour unless the extension notification states otherwise.

8. Post-implementation validation of the change

It is the customer's responsibility to perform technical validation of BMC Helix environments and connected systems to ensure that their health is maintained after changes. Such validation is completely owned and performed by the Change Submitter. 

9. Closing the RFC

As soon as the change is complete, the change engineer will mark it as completed, and it will automatically be closed three days later.

The status code shows the final disposition of an RFC. For more information, see RFC status codes.

After it is closed, an RFC cannot be reopened. However, customers can email in case of any issues post the change or can directly submit a new case.