Integrating Change and Configuration Management (CCM)

Closed loop integration is the mechanism for the accelerated execution of a change request. It also provides verification that the change was successfully performed, based on requirements specified in the change request. When you perform a change to the configuration of IT managed resources, you must maintain consistency and control through the entire process. A "closed loop" approach makes sure that the change is properly documented, assessed, tracked, implemented, and verified. A closed loop Change and Configuration Management (CCM) solution from beginning to end makes sure that the change requested was completed. All these stages are provided in the CCM suite of products. This section provides an overview of the integration points between the components in the solution.

The BMC CCM solution addresses three types of change essential to an IT organization:

• Software packaging
• Patch deployment
• Software license management

Among the numerous advantages in using the BMC CCM solution are:

• Consistent identification of Configuration Items (CI) and Storage locations throughout the change process, which improves communication between members of the support staff.
• Reduction of cost and overhead using an integrated, out-of-the-box solution that preserves flexibility.
• Automatic transfer of critical information between steps to maintain the integrity of the change.
• Closed loop verification of software-related tasks to make sure that the change was successful and to provide an audit trail.

At the heart of the CCM solution is the AR System Administrator. In the context of ITIL, the AR System Administrator supports the following primary functions:

• Accounts for all IT assets.
• Provides accurate information to support other Service Management processes.
• Provides a sound basis for Incident Management, Problem Management, BMC Helix ITSM: Change Management, BMC Helix ITSM: Asset Management, and Release Management.
• Enables the verification (and correction) of records against the infrastructure.
• Provides access to federated data stored outside the AR System Administrator, but linked to CIs, extending the AR System Administrator functionality to a vast data store of related information and detailed attributes:
  • Related information, such as detailed Incident or Discovery data, does not qualify as a CI, but its data relationships with CIs enable you to view it through the AR System Administrator.
  • Detailed attributes, such as machine details or problem records, are CI attributes you do not track at the AR System Administrator level.

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 Helix ITSM, including an IT Product/Service Catalog and fulfillment. For example, in this scenario, if users need Adobe Acrobat on their computer, it requires the IT organization to undertake a service-related change process.

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

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. The workflow then generates a change request ID.
   Business rules in 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, 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 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—The 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 Change Management transfers the policy, deployment, or verification tasks in the specified sequence. You can configure verification tasks to start manually or automatically, but after TMS initiates them, they run automatically. 

The following figure illustrates the life cycle of a configuration management task. 

1. 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 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 and then reviews job details.

   Warning

   As a task implementer, if you open a BMC Configuration Automation for Clients console window from 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.

2. 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 updates the new policy as required.
   Change Management fills out the program's online form with the AR System Administrator data the task requires, in this case, a target. The AR System Administrator contains a single source of truth about the content and configuration of computers on your network. The AR System Administrator is updated as task implementers work on the CIs that need improvement or alteration. In addition to the target information provided by the AR System 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 Change Management and BMC Configuration Automation for Clients, the task implementer can open the task from Change Management or BMC Configuration Automation for Clients without having to retype a user ID and password.
3. 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.
4. 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.
5. 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 was 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 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 life cycle is now finished. Change Management picks up the process again at the Review step.
6. Review and Close—The change request enters the Review stage. The task implementer must now verify that the task has been completed. 
   

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 that summarizes 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 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 AR System Administrator.

The service request and the RFC are Closed.