Problem investigation resolution with a change request
A known error is created making a request for change (RFC), which is assigned to Mary Mann, the change coordinator. The change is approved by Mary, executed and verified by Ian Plyment, the specialist. 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.
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:
| 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. |
Problem coordinator |
| 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 |
| 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:
| 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 |
| Mary receives the known error and reviews it. She agrees that the change is required and creates a change request from the known error. |
Change coordinator |
| 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:
| 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:
| 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. |