Change request process

The following steps describe the standard Change Request Process flow for BMC Helix customers. Keep in mind, you will need to submit a separate Request for Change (RFCs) in Support Central for each of your environments. For example, if you have a change needed in both production and non-production environments, you submit a change request for each.

RFC Process: The RFC form lists all of the information that you must provide to submit  the change request:

The dates and times displayed for selection are based on the availability of the specific environment you have provided. Please note that the availabilities may differ across the non-production and production requests for change. 

Step 1: Choose Your Change Window

Scheduled Change Slots

  1. An RFC should be submitted with a lead time of at least 3 working days before the day of change implementation. This allows for proper assessment and planning.

    i) If your change cannot wait for 3 working days, please still proceed with submitting the RFC with a time/date chosen. Then, submit an additional Support Case, with a description and/or reason for the urgency, your desired change window, and the RFC ID. A Technical Support Analyst (TSA) will be assigned to assist with updating the scheduled time of your RFC.

    ii). If you are experiencing issues, or requesting to troubleshoot a problem, please submit and follow the standard Support Case process.

  2. You will be able to view and select available change slots up to 30 days out. 

  3. Each change slot available for selection is an 8-hour window.

  4. Upon submission, the BMC SaaS Operations team will confirm the specific scheduled window reserved for your change via a Pending Change Request and send an email to your listed Change Approvers for acceptance.

Please note there are more change slots available for non-production environments on weekdays than production change slots. This is vice versa on the weekends where more change slots are available for production than non-production environments.

Step 2: Confirm the Details

The Change Submitter will need to ensure the following details are included in your change request submission and documented:

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

Best Practices:

  • Please ensure to submit the complete contents of your RFC.
  • Keep in mind, an incomplete or ambiguous RFC may lead to rejection of the change or a delay in scheduling.

Step 3: Authorization of Change

  • For each change, formal authorization needs to be granted from your listed Change Approvers.
  • Your Change Approvers will be contacted via email and the Pending Change Request can be found in Support Central > Case Management under Approve a Change.

Step 4: 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 the change execution.

A production environment change request should first be implemented in your non-production environments, tested and successfully validated, before promotion.

Step 5: Exceeding the change window  

Should the change window exceed the initial estimated time to implement, the BMC SaaS Operations Team will notify you.

Step 6: Post-implementation validation of the change

To make sure your systems are running as designed, after each change BMC recommends that your organization sets time aside for UAT and validations. Please validate your change in your lower environments first, then confirm with the BMC SaaS Operations Team when the validated changes are ready to be pushed to Production.

Closing the RFC

As soon as the change is complete, the BMC SaaS Operations Team will update the RFC to “complete” and close the change about 3 days post validation.

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.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*