Learning about Problem Management
Remedy with Smart IT provides a comprehensive framework for creating and managing problem investigations on desktop and mobile devices. You can initiate new problem investigations, perform root cause analysis, define known errors, relate problem investigations to other ticket types, and create knowledge articles. The goal of Problem Management is to reduce number and impact of incident requests.
The following video (03:34) provides an overview of problem management.
Problem investigations follow a well-defined process. This process is initiated and managed by the problem coordinator, and relies on the participation of a team of assignees and specialists. The following diagram provides an overview of the problem management process:
A typical problem management process consists of the following stages:
Review incident requests
The Problem Management process usually begins with an incident request review, which the problem coordinator performs at regularly scheduled intervals. During the review, the problem coordinator analyzes the incident request information to identify the problems with the services they are responsible for.
Create the problem investigation
If a problem investigation already exists for an incident request, the problem coordinator relate that incident request to the existing problem investigation. When a new problem is identified, the problem coordinator creates a problem investigation and relates it to the corresponding incident requests. The problem coordinator then assigns the problem investigation to a specialist who has the appropriate combination of skills, availability, and access rights to perform a root cause analysis.
Problem investigations can also be triggered by other processes. For example, a service desk specialist can create a problem investigation if they think that an incident request was caused by an underlying problem. Emergency changes as well as periodic availability management and capacity management reviews can also trigger problem investigations.
Perform a root-cause analysis
When a problem investigation is assigned to a specialist for root cause analysis, the specialist looks for a temporary workaround to restore the affected service. If the specialist implements a workaround, they add information about it to the problem investigation record. This helps other specialists resolve future incidents caused by the problem until a permanent or structural solution is implemented. Next, the specialist looks for the root cause of the problem. The specialist can also create a known error related to the problem investigation. If the specialist finds a root cause, they update the problem investigation with information about the root cause, workaround, and resolution.
If the specialist thinks that a change is required to remove the root cause or to enable a workaround, they inform the problem coordinator that the change coordinator must be included in the analysis. Otherwise, the specialist implements the preferred structural solution. If the specialist cannot find the root cause or cannot propose a structural solution, the specialist adds the reason to the problem investigation record. Regardless of whether a structural solution is proposed or implemented, the specialist informs the problem coordinator when the root cause analysis is completed.
Close or reassign problem investigations
After the root cause analysis is completed, the problem coordinator reviews the analysis. If the coordinator is unsatisfied with the root cause analysis, the coordinator reassigns the problem investigation for further analysis. If the problem is resolved, the problem coordinator closes the problem investigation. During closure, the problem coordinator performs a final assessment of the problem investigation. If the problem coordinator is satisfied that the root cause of the problem has been permanently removed, the coordinator closes the problem investigation. If the root cause analysis concluded that no permanent workaround or solution to the root cause exists, and the problem coordinator agrees, the problem coordinator indicates that the problem investigation is at an impasse. This indication leaves the investigation open for periodic review in the event that an appropriate solution becomes available in the future. If, however, the resolution did not remove the root cause, or if the problem coordinator thinks that an appropriate solution is available, the problem coordinator reassigns the problem investigation for further analysis.
The problem investigator also closes the investigation if the specialist performed a sound analysis but could not propose a structural solution. If the specialist did propose a structural solution but did not implement it because the specialist believes that a change is required, the problem coordinator must confirm that the change is required. If a change is required, the problem coordinator generates a known error and passes it to the change coordinator of the affected service. This action starts the Change Management process. Later, after the change is implemented, the change coordinator reassigns the known error to the problem coordinator for closure.
Known errors can also be generated during the release management process. Known errors are also assigned to the problem coordinator for closure.
Testing your knowledge
Check your knowledge. See if you can answer each question. Click the questions to view the answer.
Do you want to learn more?
Learn what information you can record for problem investigations and known errors in Overview of information displayed on a ticket in Smart IT.
When you're ready to get started, see Investigating and tracking problems.