Problem investigation resolution with a change request

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/2009

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

After running the search, the problem coordinator looks for incident request records that have not yet been linked to a problem investigation. The problem coordinator, Bob Baxter, performs an incident request review on the OPS by querying the Incident Management system for incidents or recent changes related to the OPS. Bob discovers that over the past six months there were several similar incidents 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 the specialist, Ian Plyment, 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) and 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 assignment.

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 both 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.