Develop > Processes and Best Practices Guide > Problem Management Workflows > Problem Investigation and Diagnosis (process SO 4.2)

Problem Investigation and Diagnosis (process SO 4.2)

The Problem Investigation and Diagnosis process helps identify the root cause of the problem. Where appropriate, the problem management process should develop and maintain workarounds that enable the incident management process to help service restoration. Different specialists can be involved in this root cause analysis. If necessary, refer to external resources to verify whether the problem has already been identified and published by vendors. Decide the target dates for the problem investigation.

The following figure illustrates the Problem Investigation and Diagnosis workflow:

Problem Investigation and Diagnosis process

Process ID

Procedure or Decision

Description

Role
SO 4.2.1 Coordinate investigation and diagnosis

The Problem Coordinator verifies the schedules of resources, and assigns the resources to the problem resolution. The assigned resource starts their investigation. The Problem Coordinator coordinates the tasks that required to resolve the problem, and maintains communication with all stakeholders.

 Problem Coordinator
SO 4.2.2 Schedule the problem and establish milestones The Problem Coordinator estimates the cost and effort required to resolve the problem, and determines the target dates for the problem resolution milestones. Target dates are determined by the priority of the problem and by the impact of the problem on affected services. Additionally, this phase of planning considers whether an effective workaround or fix is available. Problem Coordinator
SO 4.2.3 Validate the problem

The Problem Analyst ensures that the problem record is valid. The Problem Analyst determines whether the problem record is a duplicate or new problem. Then, the Problem Analyst continues with root cause analysis. If the problem is a duplicate, it is linked to the problem that it is a duplicated of, and the workflow moves to SO 4.2.5. If the problem is not a duplicate, the workflow moves to SO 4.2.4.

 Problem Analyst
SO 4.2.4 Close duplicate problem The Problem Analyst closes the problem as a duplicate, and enters the necessary closure comments into the ticket. Problem Analyst
SO 4.2.5 Perform root cause analysis

The Problem Analyst performs root cause analysis of the problem. Root cause analysis can include the following methods:

  • Chronological Analysis
  • Pain Value Analysis
  • Kepner and Tregoe
  • Brainstorming
  • Ishikawa Diagrams
  • Pareto Analysis
Problem Analyst

SO 4.2.6

Investigate and diagnose

The Problem Analyst analyzes the known data to identify and isolate the root cause of the problem. If a potential root cause is identified, it is verified. If more resources are required to do this, they are requested through the Problem Coordinator, who requests them from the Problem Manager and Problem Coordinator.

Additionally, the Problem Analyst tries to identify a workaround. Potential workarounds are tested to verify that they work. If successful, a workarounds is documented in the problem record. The same is intimated to Service Desk and Incident Analysts

Problem Analyst
SO 4.2.7 Create and assign investigation tasks The Problem Analyst creates and assigns problem tasks to the resource who is responsible for root cause analysis. The Problem Analyst enters the due date for the assigned task. Additional resources (for example, suppliers and other specialists) can be used for this analysis. The Problem Analyst monitors the outstanding problem tasks. Problem Analyst

SO 4.2.8

Root cause identified?

If the root cause is not identified, the Problem Analyst must determine whether there is a workaround for the problem.

If a root cause is identified, the Problem Analyst updates the problem record with the details.

Problem Analyst

SO 4.2.9

Update problem record with root cause

The Problem Analyst updates the problem record to indicate that a root cause has been found. The problem record is updated with any affected CIs.

Problem Analyst

SO 4.2.10

Workaround identified?

If a workaround is identified, the workflow moves to SO 4.2.11. If no workaround is identified, the workflow moves to SO 4.2.16.

Problem Analyst

SO 4.2.11

Verify workaround

The Problem Analyst creates a problem task and assigns it to the Investigation category in order to test the suitability of the identified workaround for resolving related incidents.

Problem Analyst

SO 4.2.12

Workaround successful?

If the workaround is successful, the workflow moves to SO 4.2.13. If the workaround is not successful, the workflow moves to SO 4.2.16.

Problem Analyst

SO 4.2.13

Update problem record with workaround

Update the workaround (in the known error and the problem) and inform stakeholders.

Problem Analyst
SO 4.2.14 Root cause or workaround determined? The Problem Coordinator validates the results of the problem task. If the root cause is determined, the workflow moves to SO 4.2.15. If the root cause is not determined, the workflow moves to SO 4.2.16, and then determine whether additional resources are needed or whether escalation is required. Problem Coordinator
SO 4.2.15 Update any related open Incidents Review any related open incidents and advise the assigned Incident Analyst that a root cause and/or workaround has been identified. (An update will be made to the Activity Log in the incident record when the problem record is saved with an updated workaround). Problem Coordinator
SO 4.2.16 Caused by outstanding known error? Determine whether the root cause for this problem is related to an outstanding known error. If yes, continue with SO 4.2.xx. If no, forward the problem to the Problem Resolution phase, and then create a new known error record . Problem Coordinator
SO 4.2.17 Relate problem to outstanding known error The problem is moved to the Problem Resolution phase and linked to the existing known error record. The resolution of the problem is dependent on the resolution of this known error. Problem Coordinator
SO 4.2.18

Verify whether to continue investigation

The Problem Analyst determines whether to continue with the investigation, start problem resolution, or recommend abandonment.

Problem Analyst
SO 4.2.19 Continue, defer, or abandon investigation?

If the Problem Analyst decides to continue the investigation, the workflow moves to SO 4.2.6.

If the Problem Analyst determines they do not have the capabilities to investigate and determine the root cause of the problem (that is, they do not have the skill level or the available time), the Problem Analyst documents the reason that a root cause is not found, the Problem Coordinator is informed, and the workflow moves to SO 4.2.18.

If the problem can be abandoned, the workflow moves to SO 4.2.19.

If the problem can be deferred, the workflow moves to SO 4.2.20.

 Problem Analyst
SO 4.2.20

Re-assign resources

The Problem Coordinator needs to re-assigns the problem to other resource to continue the problem investigation. The problem is moved back to Categorization phase with the Assign status again, and the workflow moves to SO 4.1.10.

Problem Coordinator
SO 4.2.21

Abandon the problem

The Problem Analyst abandons the problem ticket.

Problem Analyst

SO 4.2.22

Defer the problem investigation

The Problem Analyst defers the problem investigation for a specific period of time. The reason for deferring the problem is detailed in the ticket. Periodically, the Problem Manager reviews the deferred problems to determine the appropriate action.

Reasons for deferring problem include the following:

  • The likelihood of recurrence is low
  • The cost of resolving the problem is very high
  • There is currently no plan to investigate the problem

Problem Analyst

 

Send Help Center feedback