Page tree

       

    To view the latest information for BMC Helix services and policies, go to BMC Helix Subscriber Information.

    Skip to end of metadata
    Go to start of metadata

    The following steps describe the standard change request process flow.

    Note

    Separate requests for change (RFCs) must be created for each customer environment, such as the development, quality assurance (QA), and production environments. You may use the 'Request Again' button from the original request to fast track submission of similar requests.

    1. Completing the RFC form

    The RFC form is available from the BMC OnDemand support portal under the Request a Change offering. It 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. 

    The change submitter ensures that the following documentation is complete:

    • 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 resources, such as engineering and design documentation, or physical diagrams

    Tips

    • The RFC form contains all the information that needs to be provided to effectively plan, manage, track, and fulfill an RFC. Submit the online RFC form from the BMC OnDemand support portal using the Request a Change offering.
    • Consider keeping the contents of the RFC simple at the beginning of the Change Management process. Doing so encourages process compliance.
    • An incomplete or ambiguous RFC may lead to rejection of the change or a delay for the change.

    2. Submitting the RFC

    While logged into the BMC OnDemand support portal, the RFC form is accessible under the Support tab, Request a Service section. Select the "Request a Change" option. After form completion, select Submit at the bottom of the page. This will create the internal CRQ# and auto-route the request to the BMC Change Advisory Board (CAB). You may track the progress of your request under the Updates tab.

    Note

    An RFC must be submitted with 24 hours lead time (if submitted before 09:00 AM UTC) and 48 hours lead time (if submitted after 09:00 AM UTC) to allow for appropriate assessment.

    3. Reviewing the RFC

    The BMC CAB reviews all submitted RFCs to ensure that:

    • All required information is provided
    • Requested changes are in-line with BMC standards
    • All prerequisites exist for executing the changes

    4. Authorizing the RFC

    For each change, formal authorization is obtained from a change authority (your designated change approver and a BMC CAB member). 

    Customer-authorized change approvers will be contacted via email by BMC SaaS Operations to request authorization.

    All changes must be approved before implementation. All RFCs are reviewed by BMC CAB technical resources. If this team has any questions then they can withhold the approvals until clarification is received. The CAB meets daily (Monday to Friday) starting at 2:00 PM UTC.

    Any approved change that is modified before implementation must be reapproved. Reuse of an approved change to implement additional changes is not permitted.

    5. Scheduling the RFC

    All authorized RFCs are scheduled by the BMC CAB using your preferred change window. In the absence of any free slot, BMC SaaS Operations will contact your emergency contact through their preferred method of contact (email or phone) to negotiate an alternate change window.

    6. Executing the RFC

    All scheduled 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.

    Note

    A production change request will lead to rejection if it is not already implemented in the QA environment and successfully validated. BMC SaaS Operations will need to execute the change in the QA environment before considering this same change for the production environment.

    7. Extending the change window

    Every now and then a BMC-instigated 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 minutes notification (prior to the end of the original 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

    BMC SaaS Operations performs technical validation of environments to ensure that their health is maintained after changes.

    Any business or functional validation is considered out of scope for BMC SaaS Operations, and such validation is completely owned and performed by the submitter of the RFC or the customer. BMC SaaS Operations will address validations with the following criteria:

    • Validations which do not require a customer’s userid and password
    • Validations which do not create, delete, or update business data in your environment
    • Validations which have multiple navigation steps

    9. Closing the RFC

    The requester is responsible for closing out a change request within seven days after implementation. Before closing, the status of the change request must be "Completed". You should also close any related incidents, problems, or known errors.

    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.