The next figure illustrates the life cycle of a typical change request. There can be some variation depending on how your organization configures and implements changes. For example, the model shows the use of tasks, but you might choose to only use change requests.
Figure 1-6: Life cycle of a change request
Cost assessment is not shown as part of the life cycle, but this is something you might choose to do in your business process. A change request can also use multilevel approvals and dependencies, where you could choose to use a single approver or bypass the approval process altogether. Lastly, it shows assignments given to multiple change implementers, but in a smaller company, the same person could function as change manager, approver, and task implementer. www www C.A.B. CAB analyzes change Approved Tasks assigned and worked Request completed and verified IT & BU review Task Implementers CMDB updated Accepted and prioritized by SLA Tasks scheduled Risks and impact analysis Check CMDB Change
Manager AssigneeChange RFC initiated and routed to IT Approval Planning Request Review Implementation
Steps in the life cycle of a change request 45
The normal life cycle of a change request consists of five major steps:
Step 1 Request—The need for a new change request can arise in several ways.
Examples include:
Using the Requester Console, the requester can enter the change request directly, and ask that an application be loaded on their system.
The discovery process detects that a system does not have the latest patches loaded.
BMC Remedy Asset Management determines that the company has exceeded the maximum number of installed applications under an existing software license contract.
A technician needs to make changes to a database server during non-work hours.
BMC Patrol detects that a mirrored web server has failed and needs to be replaced.
When created, the change request is automatically routed to the appropriate support group or individual. When change requests are assigned to them, support staff members are notified by email, pager, or through BMC Remedy Alert.
Step 2 Planning—The change manager plans a forward schedule of changes (FSC).
The change request includes planning all the changes approved for implementation, targeting dates, and estimating the risks and costs. If the change request must be divided into several tasks, the change manager can create and schedule these tasks. When changing any CI, planning also involves checking the BMC Atrium CMDB to account for all IT assets under the control of Configuration Management.
Step 3 Approval—If the change request requires approval, the change manager
initiates the approval process. Each level of approvers must review the request and approve it. For example, the Change Advisory Board (CAB) must approve all significant changes but the change manager can approve a standard change.
When all have granted approval, the change manager can set the change request’s Status to Scheduled. Any tasks are assigned automatically to the appropriate task implementers.
Step 4 Implementation—As the change request enters the Implementation stage,
the BMC Atrium CMDB is modified by Configuration Discovery, Service Impact Manager (SIM), or other types of discovery tools as task
implementers work on the CIs that need improving or altering. They log their progress as they work to implement the change request and the tasks that comprise it. When a task is completed, the implementer for the task with the next number in the sequence is notified of their task assignment. Task implementers can calculate the cost of implementing their tasks.
If a Change and Configuration Management (CCM) solution is in place, task implementers can review the task, initiate a launch into the BMC
Configuration Management application suite, make any necessary edits to the deployment or policy, execute the task, and then verify that the task has been completed. All necessary information regarding the task identifier, target, and packages is automatically transferred to Configuration Management.
When all the task implementers have finished their tasks, CCM automatically verifies the status of the task. If the task is successful, CCM marks the task as Closed. The system notifies the requester that the change request has been resolved.
When the requester is notified of the status change, the requester can close the change request by setting the Confirm Resolution 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.
Step 5 Review—The change request enters the Review stage. Reviewers verify that
the change request was indeed completed. They also might analyze key performance indicators (KPIs), for example, whether the change successful, or how many incidents were eliminated by the change request. Reviewers should also analyze the accuracy of the BMC Atrium CMDB.
Working with the Requester Console 47
2
Working with the Requester
Console
The Requester Console serves as the front end for the BMC Remedy Change Management and BMC Remedy Incident Management applications. It provides an easy, user-friendly interface that allows users to quickly submit requests for change or incidents to IT through the two back-end applications. The following topics are discussed:
Requester role (page 48)
Service Request Management users (page 48)
Understanding the Requester Console (page 50)
Working with service requests (page 54)
Working with service requests as the Request Master (page 65)
Service Request form (page 72)
Working with the Solutions database (page 75)