Change request lifecycle

This topic uses the following business scenario to explain BMC Change Management features and processes:

Calbro Services has discovered that a mission-critical server is almost reaching capacity. It must replace the current server with a model that has more capacity. The Change Manager initiates a change request to replace the server. The following figure illustrates the lifecycle of a typical change request.

Stages in the lifecycle of a change request

The typical lifecycle of a change request consists of the following major stages and approvals.

1. Initiate — In the upgrade server hardware scenario, the Change Coordinator, Allen Allbrook, creates the change request from the Change Management console to replace the mission-critical server. He must properly classify its Class (for example, Normal), add relevant information (Target Date, Service, configuration items, and so on), and assign a Coordinator Group, Manager Group or Change Manager. When change requests are assigned to them, support staff members are notified. When the request moves into a new status, for example, Request For Authorization, the application generates notifications to the Change Manager and Change Coordinator Support Group. In this case, Allen Allbrook is the Change Requester as well as the Change Coordinator.
   
   New change requests can be created in other ways. Examples include:
   • Problem coordinators can create a change request from a Known Error.
   • Using the Requester Console, a user can request a service that generates a change request.
   • A technician who made changes to a database server during non-work hours can create an after the fact latent change request from the Overview Console.
   • BMC Remedy AR System workflow in the BMC Service Request Management application can automatically generate change requests (for example, a service request to replace a mission-critical server).
   • The discovery process can automatically generate a change request if it detects that a server does not have the latest patches loaded.
   • BMC Remedy Asset Management can automatically generate a change request from a purchase requisition (for example, purchasing a laptop for a new employee).

   • BMC Performance Manager can automatically generate a change request if it detects that a mirrored web server has failed and needs to be replaced.
     
     Mary Mann, the Change Manager, receives a notification that a change request has been assigned to her. She opens the Change Management Console and reviews the change request assigned to her.
     
     At the Initiate stage, she estimates the risk impact and costs associated with the change request. She chooses to compute the risk level of the request. If the change request requires tasks, she can create and schedule these tasks.

     Note

     If an approver is mapped to the approval phase, the change approver must approve the change request before it can move to the Review & Authorize stage. For more information, see Working with BMC Change Management as an approver.

2. Review & Authorize — If no approvers are mapped to this stage, change requests bypass the Review & Authorize stage entirely. But if the application administrator configured approvers, each level of approvers must review the request and approve it before it can move forward.
   
   After the request is approved, the Change Coordinator can move the change request to the Plan & Schedule stage. After the change planning is completed, the change is sent to the Change Manager who reviews the change to ensure the information is complete and accurate, before submitting it for approval. Tasks are automatically assigned to the appropriate task implementers. Mary continues to fill in additional details about the change request (for example, she revises the start and end dates).
3. Plan & Schedule — Allen, the Change Coordinator relates the server CI to the change request. He uses the Collision Detection tool to detect if there are other change requests scheduled to work on the same CI during the same time. After he resolves any conflicts, he plans a forward schedule of changes (FSC). He opens the Change Calendar and views the current schedule of change activities and business events. He then blocks out a time segment to work on the change request by targeting the scheduled start and end dates. Larger projects can include planning all the changes approved for implementation. If the change request needs additional tasks, the Change Coordinator can create and schedule these tasks.
   
   In this scenario, Allen then assigns the change request to the Change Manager, Mary Mann.
   Mary, the Change Manager reviews the Change Request. Mary reviews the risk & impact analysis to ensure that appropriate actions have been planned to minimize both the risk of failure and the impact on users during change implementations and that the timing of planned implementations does not conflict with other planned changes or events.
   
   If Approvals are required, the change request is routed to the configured approvers which could included the CAB to take the appropriate actions.
4. Implement — Ian Plyment, the task implementer, receives notification that a task is assigned to him, to replace the server. He opens the request in the Change Management Console, and then the task assigned to him. He updates the task status as his work progresses. This modifies the Change Status to Implementation In Progress and the Actual Start Date is automatically populated.
   
   As the change request enters the Implement stage, the BMC Atrium CMDB is modified by Configuration Discovery, BMC Service Impact Manager (SIM), or other types of discovery tools as the task assignee works on the CI that needs extra memory. Ian logs his progress as he works on the tasks that need to be completed in order to get the change implemented (for example, uninstall the old server, install the new server, and so on). When a task is completed, the implementer of the next task in the sequence is notified of the task assignment. Task implementers can calculate the cost of implementing their tasks.
   
   When all tasks are closed, the change moves to Completed status and the Actual End date is automatically populated.
   
   When Allen Allbrook, the change requester, has verified that the change request was resolved satisfactorily, he can set the change request to Closed. If the requester does not close the change request, the request closes automatically after a preconfigured time. If the change request is part of a dependent sequence, the Change Manager for the next change request in the sequence is notified.
   
   Before the change request can move out of the Implement stage, the Change Coordinator must enter its actual start and end dates, and then assign a performance rating to the work performed on the change.
5. Closed — The change request enters the Closed stage. The Change Manager Mary must verify that the change request was completed. She also might analyze key performance indicators (KPIs) - for example, whether the change successful, or how many incidents were resolved by the installation of the new server. Reviewers also must analyze the accuracy of the BMC Atrium CMDB.