This documentation supports the 25.1 version of BMC Helix ITSM: Service Desk.To view an earlier version, select the version from the Product version menu.

Resolving a problem with a change request



This user scenario describes how to resolve a problem investigation with a change request. Incident Management, Problem Management, and BMC Helix ITSM: Change Management must be installed to follow this user scenario.

Scenario

Bob Baxter, the Calbro problem coordinator, conducts an incident request review on the Calbro Order Processing System (OPS). In the course of the review, Bob discovers that several similar incidents related to the OPS occurred over the past six months. The resulting problem investigation determines that a change to the IT infrastructure is required. 

A known error is created, initiating a request for change (RFC), which is assigned to Mary Mann, the change coordinator. Mary approves the change, and Ian Plyment, the specialist, executes and verifies the change. The status of the known error is automatically marked as Corrected.

Bob is notified that the change request has been completed. He notes the permanent corrective action in the problem investigation and changes its status to Closed.

Workflow

The following table describes the typical steps involved in this user scenario:

Role

Actions

Explanation

Problem coordinator

The problem coordinator performs an incident request review:

From the Incident console, the problem coordinator creates a custom search that has the following characteristics:

  • Service = OPS
  • Impact => 2-Significant/Large OR 1-Extensive/Widespread
  • Last Resolved Date >= 07/19/2019

For the purpose of this example, assume today's date is 01/19/2020. Therefore, the Last Resolved Date used is six months ago.

After running the search, Bob Baxter, the problem coordinator, looks for incident request records that have not yet been linked to a problem investigation. Bob performs an incident request review on the OPS by querying Incident Management for incidents or recent changes related to the OPS. Bob discovers that over the past six months, several similar incidents were related to the OPS.

Problem coordinator

  1. From one of the incident request records that is related to the OPS server issue, the problem coordinator creates a problem investigation.
  2. The incident record's details are copied from the incident request record to the Problem form, and a relationship is created between the problem investigation record and the incident request records.
  3. The problem coordinator completes the Problem form.

Bob wants to determine the root cause of these incidents, so he creates a problem investigation from one of the incident request records. Creating the problem investigation from an incident request record ensures that all of the relevant details are copied over from the incident request to the problem investigation.

Problem coordinator

  1. From the Problem form, the problem coordinator creates relationships between the problem investigation and all related incident requests.
  2. The problem coordinator creates a relationship between the problem investigation and the OPS server.

Bob then relates the remaining OPS incidents and the OPS CI to the problem investigation.

Problem coordinator

The problem coordinator assigns the problem investigation to the specialist.

Bob assigns the problem investigation to Ian Plyment, the specialist, to conduct a root cause analysis.

Specialist

The specialist accepts the assignment and performs the root cause analysis.

Ian accepts the problem investigation assignment and begins a root cause analysis. During the root cause analysis, he determines the physical server on which the OPS runs needs a memory upgrade and sends his root cause analysis to Bob.

Problem coordinator

The problem coordinator performs the analysis review by opening the problem investigation and independently verifying that the specialist's assessment of the root cause is correct.

Bob reviews and verifies Ian's analysis. Bob then creates a known error, which serves two purposes:

  • To identify the best workaround (temporarily routing the users to a redundant server)
  • To request a change for the memory upgrade on the primary OPS server

Problem coordinator

The problem coordinator creates a known error:

  1. On the problem investigation form, the problem coordinator sets the Status field to Completed and the Status Reason field to Known Error.
  2. This opens the Known Error form and creates a relationship between the known error and the problem investigation.
  3. The problem coordinator completes the form. The problem coordinator assigns himself as the problem coordinator. The problem coordinator assigns the change coordinator for the known error.

Bob creates the known error directly from the problem investigation, which transfers all pertinent information to the known error. Bob assigns the known error to Mary Mann, the change coordinator.

Change coordinator

  1. From the Known Error form, the change coordinator creates a change request.
    This opens the Change Request form and creates a relationship between the known error and the change request. It also copies information from the known error record to the change request record.
  2. The change coordinator saves the change request and moves the request through the change request lifecycle until the change request is approved and has a date.

Mary receives the known error and reviews it. She agrees that the change is required and creates a change request from the known error.

Mary moves the record through the change request lifecycle.

Change coordinator

  1. The change coordinator assigns the change request to a specialist.
  2. The change coordinator adds a task to the change request and relates the CIs to the change request.
  3. The change coordinator moves the change request to the Implement stage.

On the change request record, Mary creates a task to implement the change, and assigns the change request to Ian Plyment, the specialist who will perform the work. The coordinator also relates the CI to the change request.

Specialist

The specialist performs the tasks and closes them:

  1. On the Change Management Support console, the specialist searches for assigned tasks.
  2. The specialist opens the task record and performs the task. Then the specialist records information about performing the task and changes the status of the task to Closed.

Ian implements the change. When he finishes the last task, the system notifies Mary that the tasks are closed.

Change coordinator

The change coordinator completes the change request:

  1. From the Change form, the change coordinator moves the change request to the Close stage.
  2. The change coordinator enters the performance rating and the actual start and end dates.

After Mary coordinates the change implementation, she reassigns the known error to Bob for verification.

Problem coordinator

The problem coordinator confirms that the change has solved the problem. Then, the problem coordinator sets the status of the problem investigation and the known error to Closed.

Bob is notified that the change was completed and verifies that it fixed the problem. He then changes the status of the problem investigation and known error to Closed.

Result

As a result of the incident review and root cause analysis, the server on which the Calbro OPS runs receives a memory upgrade. The infrastructure at Calbro is better equipped to meet the business requirements.

Benefit

By performing a memory upgrade, Bob has taken proactive steps to prevent similar incidents from occurring.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*