This documentation supports the 22.1 version of BMC Helix ITSM: Service Desk.To view an earlier version, select the version from the Product version menu.

Learning about Problem Management

The mission of the Problem Management process is to minimize the number of incidents. Problem Management can proactively prevent the occurrence of incidents, errors, and additional problems. The problem lifecycle includes request review, root cause analysis, analysis review, and closure. BMC Helix ITSM: Service Desk uses automated Problem Management processes to ensure reactive resolution of customer questions and issues, and proactive work to prevent recurring issues.

You use the following consoles to access the features in Problem Management:

The Overview Console

Using the Overview Console, specialists can view problem investigations that were assigned to them through the Problem Management application. 

Overview Console.PNG

The Problem Management Console

TheProblem Management Console provides problem coordinators and specialists with a single point from which they can create problem investigations and known errors. 

Problem Console.PNG

Process overview

The Problem Management process consists of the following stages:

Stage

Description

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

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. The following scenarios could take place:

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

Watch the following video (8:25) to learn about the basic flow of the Problem Management process.

Disclaimer

Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.


icon-play.png https://youtu.be/RvLTHtL3A4U

Testing your knowledge

Check your knowledge by answering each question.

How does the problem management process start?

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. Emergency changes as well as periodic availability management and capacity management reviews can also trigger problem investigations.

What does it mean for a problem investigation to be at an impasse?

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.

When are changes identified?

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?

For information about managing problem investigations and known errors, see Managing-problem-investigations.

For information about managing incident tickets, see Managing-incident-requests.

To learn about the roles and permissions required for Incident Management, see Problem-Management-roles and Problem-Management-permissions.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*