This documentation supports the 22.1 version of BMC Helix ITSM Insights.

To view an earlier version, select the version from the Product version menu.

Learning about proactive problem management

A problem is an underlying cause of one or more incidents. The problem management process aims at minimizing the number of incidents, and thus, reducing the effort required by Service Desk to mitigate the impact of incidents. The Problem Management module in BMC Helix ITSM supports this goal by managing problem investigations and known errors. 

A problem investigation helps an IT organization get to the root cause of incidents. It initiates actions that help to improve or correct the situation, preventing the incident from recurring. For example, if servers are running low on disk space, ideally the problem can be resolved before it becomes an incident.

The problem lifecycle includes request review, root cause analysis, analysis review, and closure.

Problem management can proactively prevent the occurrence of incidents, errors, and additional problems. An organization can use the reactive or proactive approach to problem management.

Reactive and proactive problem management

Reactive problem management is triggered directly after an incident that is deemed worthy for a root cause investigation, such as one major incident or a series of incidents which are significant in totality. It complements incident management by focusing on the underlying cause of an incident to prevent its recurrence and identifying workarounds when necessary. Reactive problem management considers all contributory causes, including causes that contributed to the duration and impact of incidents, as well as those that led to the incidents happening.

Proactive problem management seeks out issues, faults, and known errors in IT systems by going through past incidents, networking monitor data logs, and other sources of information, then proceeds to solve them permanently before they arise as incidents. This process is a part of continuous service improvement. Proactive problem management is driven from a continual improvement perspective. The trigger is not the result of an active incident, but rather the result of identified risks to service. These risks may include warnings, errors, or potential breaches to thresholds that indicate potential problem areas. As such, proactive problem management activities take place as ongoing activities targeted to improve the overall availability and end user satisfaction with IT services. 

Both types of problem management follow the same phases of problem-solving. The only difference is the approach towards identifying the problem. 

Proactive problem management process

The goal of the proactive problem management process is to identify frequently recurring incidents and improve Service Desk efficiency by preventing these incidents from reoccurring in the future.

The proactive problem management process consists of the following stages:

Review incidents

The process usually begins with review of incident data. A problem coordinator can use either automated rules or perform manual reviews to check for closed and resolved incidents. During the review, the problem coordinator analyzes the incident data to identify those incidents that are recurring and generate most work for the Service Desk. 
Automated rules enable you to create problem investigations when certain conditions are fulfilled. For example, you can have automated rules to create a problem investigation every time a major incident is created.
To know more about incident rules, see Configuring incident rules Open link .
To know how to create problem based on certain incident events, see Creating a problem investigation Open link .

Create the problem investigation

When a problem area is identified, the problem coordinator creates a problem investigation and relates it to the corresponding incidents. 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.

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, the specialist adds information about it to the problem investigation record. This helps other specialists resolve future incidents caused by the problem until a permanent solution is implemented. Next, the specialist looks for the root cause of the problem. 

Identify changes

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.

Testing your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

The problem coordinator typically starts the process with an incident request review. 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.
If root cause analysis concludes that no permanent workaround or solution to the root cause exists, the problem investigation is at an impasse. Problem investigations at an impasse are open for periodic review in the event that an appropriate solution becomes available in the future.
Changes are identified by specialists during root cause analysis. Changes might be required to permanently work around or remove the root cause.

Do you want to learn more?

Determining areas for problem investigation

Was this page helpful? Yes No Submitting... Thank you