CCM solution overview

The need for a company to have the latest version of a software program installed on their system is a perfect example of a typical Change and Configuration Management (CCM) solution. The following scenario describes a CCM solution in which users interact with the BMC Remedy ITSM suite, including an IT Product/Service Catalog and fulfillment. Imagine users who need Adobe Acrobat on their computer. This requires that the IT organization undertake a service-related Change process.

The following figure illustrates how to initiate such a change request.

Lifecycle of a change request

Click the following figure to expand it.

1. Initiate — The user submits a service request to install the latest version of Adobe Acrobat. A manager receives a notification of the service request requiring approval. The manager sees no problem with this request for change (RFC) and approves it. Workflow then generates a change request ID.
   Business rules in BMC Change Management make sure that the RFC is automatically routed to the appropriate support group or individual. The Change Manager receives notification that an RFC has been assigned to him. In this scenario, the Change Manager is also the Change Coordinator.
   Because this request is not urgent, workflow routes the RFC as a standard change. However, the Change Manager recognizes that the entire company, not only this user, should receive the latest version of Acrobat. As a result, even though the change's urgency is medium and its timing is normal, the impact of such a company-wide installation is extensive.
   If the request is urgent, for example, a mission critical server has crashed, then an entirely different business policy would be implemented.
2. Review & Authorize — 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. The time segment for the change is scheduled on the calendar. The Change Manager reviews the RFC and verifies that the correct change request template and tasks are connected to the change request generated by the service request. Here the Change Manager relates the two Policy Manager and Compliance Check tasks (already provided with BMC Change Management) to the change request, and edits the appropriate change request and task information as necessary.
   The Change Manager updates the RFC by adding the appropriate implementers or assignees for the tasks, and any Backout, Test, and Implementation plans, if needed. Finally, the Change Manager adds the appropriate date information for the tasks and updates the Status of the RFC from Planning in Progress to Scheduled.
3. Plan & Schedule — Because this is a standard change, the business rules dictate that this type of change does not require more approvals. The Change Manager approves it.
   If the change request requires additional approvals, for example, because the change's impact is widespread and potentially disruptive to users, the Change Manager initiates the approval process. In this case, each level of approvers must review the request and approve it. Within the ITIL framework, the Change Advisory Board (CAB) must approve all significant changes.
4. Implement — Workflow routes the tasks to the task implementers. BMC Configuration Automation for Clients takes over the process of task management and verification. The Task Management Subsystem (TMS) within BMC Change Management hands off policy, deployment, or verification tasks in the specified sequence. You can configure verification tasks to kick off manually or automatically, but after TMS initiates them, they run automatically. The following figure illustrates the lifecycle of a configuration management task.
   
   Lifecycle of a Configuration Management task
   

   Click the following figure to expand it.
   

   
   
5. Create Policy — The task implementer receives notification of the task to install the latest version of Adobe Acrobat throughout the company. The task implementer uses BMC Change Management to view the Install Acrobat" task.
   Unlike a change request process-where multiple users engage in the request, planning, approval, implementation, and review stages-a Configuration Management task process benefits from automation features in the update or deployment stages.
   In this scenario, the first step is saving a policy. The task implementer defines or updates a policy, then reviews job details.

   Warning

   If you open a BMC Configuration Automation for Clients console window from BMC Change Management to edit a policy or deployment job, make sure you work on only one Configuration Management task during that session. Launching new browser windows can generate session conflicts and corrupt your data.

   As the change request enters the Implementation stage, task implementers log their progress as they work to implement the change request and its related tasks. When the first task is completed, task implementers for the next stage in the sequence are notified of their task assignment. Task implementers can calculate the cost of implementing their tasks.
6. Review Details — The task implementer reviews the details and makes any necessary edits.
   The task implementer views task details from TMS, retrieving data based on the Change ID and Task ID, and defines a new policy as required.
   BMC Change Management fills out the program's online form with the Remedy Administrator data the task requires, in this case, a target. The Remedy Administrator contains a single source of truth about the content and configuration of computers on your network. The Remedy Administrator is updated as task implementers work on the CIs that need improvement or alteration. In addition to the target information provided by the Remedy Administrator, the Definitive Software Library (DSL) provides source information about Storage Locations. Storage locations represent the location of the packaged software and data available in the system.
   Because the task implementer's company has deployed the integrated CCM solution with seamless authentication, which uses web services as the communication protocol between BMC Change Management and BMC Configuration Automation for Clients, the task implementer can open the task
   from BMC Change Management or BMC Configuration Automation for Clients without having to retype a user ID and password.
7. SPM:Update — The task implementer uses Policy Manager to update policy information and store the policy in the directory service. When the policy is saved, Policy Manager sends a Success message to TMS.
8. Get Details — When tuners running on the endpoints check in, they receive their new policy and update the local system. Because packaged applications use the BMC Configuration Automation for Clients channel format, the process takes advantage of file compression, bandwidth throttling, checkpoint restart, and byte-level and file-level differencing. The location of a package application is captured in the DSL as Software Library Items are available for future service requests.
   At the scheduled time, the Policy Service running on their systems updates all company computers.
9. Query Compliance — The verification task queries the BMC Configuration Automation for Clients inventory database for information about the compliance percentage you specified as the threshold for success, and elapsed time. The goal IT configured in the compliance task was to deploy the software on 80 percent of the company's computers within seven days.
   When the task achieves the specified compliance level or the time window expires, the verification process sends a status message to TMS.
   In this scenario, the verification process notifies TMS that the task completed successfully. In this case, at least 80 percent of the systems are in compliance within seven days.
   All necessary information about the task identifier, target, and packages is automatically transferred to BMC Change Management.
   If the task is not successful, the task verification process notifies TMS of the failure. Details of the failure from BMC Configuration Automation for Clients are recorded in the Work Info tab of the change request and the task is closed with a status reason of Failed.
   The configuration management lifecycle is now finished. BMC Change Management picks up the process again at the Review step.
10. Review and Close — The change request enters the Review stage. The task implementer must now verify that the task has been completed.
    
    Review
    

During the task and verification process, BMC Configuration Automation for Clients captures audit trail data, including:

• Task ID
• Change ID
• Time stamps
• Machines

In BMC Configuration Management's Report Center, you can view predefined queries on the Machine Details page summarizing tasks performed on any computer. For more information, see the Report Center Administrator's documentation (available on the Customer Support website) or Report Center help.

When all task implementers finish their tasks and mark them as Closed in BMC Change Management, CCM automatically verifies the status of the task and the system notifies the requester that the change request has been resolved.

If the task is successful, CCM marks the task as Closed. The requester is automatically notified 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 Confirm Resolution to Closed. If the requester does not close the change request, the request closes automatically after a pre-configured time. If the change request is part of a dependent sequence, the Change Manager for the next change request in the sequence is notified.

Reviewers verify that the change request was completed successfully. For example, reviewers can analyze key performance indicators (KPIs) that apply performance analytics to the change, such as how many incidents the change eliminated. Reviewers can also analyze the accuracy of the Remedy Administrator.

The service request and the RFC are Closed.