This documentation supports the 1.4 version of Remedy with Smart IT.

To view the latest version, select the version from the Product version menu.

Creating and managing problem investigations in Smart IT

BMC Remedy with Smart IT is integrated with BMC Remedy Problem Management to to provide a comprehensive framework for creating and managing problem investigations on desktop and mobile devices. With Problem Management 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 to reduce number and impact of incident requests.

Overview of the problem management process

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. A typical problem management process consists of the following steps:

  • Performing the incident request review
  • Creating the problem investigation
  • Performing a root-cause analysis
  • Identifying changes
  • Closing or reassigning problem investigations

Performing the incident request review

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 incident request information to identify problems with the services they are responsible for.

Creating the problem investigation

If the problem coordinator finds an incident request for which a problem investigation already exists, they 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. 

Performing 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 Root Cause, Workaround, and Resolution fields of the problem investigation as appropriate.

Identifying changes

If the specialist thinks that a change is required to permanently work around or remove the root cause, 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 finished. 

Closing or reassigning problem investigations

When the root cause analysis is finished, the problem coordinator reviews the analysis. If the coordinator is unsatisfied with the root cause analysis, they reassign the problem investigation for further analysis. if the problem is resolved, the problem coordinator closes the problem investigation.

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 confirms that this is the case. If a change is implemented, 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 generated during the release management process are also assigned to the problem coordinator for closure. During closure, the problem coordinator performs a final assessment of the problem investigation. If the problem coordinator is satisfied that the problem's root cause has been permanently removed, they close 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.

Creating problem investigations and known errors

Smart IT provides an easy way to initiate problem and known error tickets.The problem coordinator initiates a problem investigation by creating a problem ticket in Smart IT. Refer to Creating tickets using Smart IT and Overview of information displayed on a ticket in Smart IT for detailed information about creating and viewing tickets in Smart IT. 

You can also relate problem investigations and known errors to other tickets so they appear on the Related Items tab of the related ticket. Refer to Relating items to the current ticket for information about relating tickets to other items.

To create problem investigations and known errors 

To create a related change request from a problem investigation or known error 

To view and update problem investigations and known errors 

To relate existing tickets to problem investigations and known errors 

To create a knowledge article from a problem investigation or known error 

Example of managing a problem investigation in Smart IT

Mary Mann is a problem coordinator in the Network Infrastructure group. Mary hosts a monthly incident review in which the review team evaluates incident tickets for the month and identifies recurring incidents for underlying problems with the services they are responsible for.  When the team finds an issue with a routing table for network equipment that is causing recurring incident requests, Mary begins the problem investigation process:

  1. Mary locates an incident that was triggered by the problem, and on the Related Items tab, she selects Create > Related Problem Investigation.
  2. The new problem investigation is prepopulated with information from the incident, so for now, Mary updates the Investigation Driver field (a required field), and assigns the problem to a specialist. She sets the Investigation Driver to Re-Occurring Incidents. For the assignee, she clicks the pencil icon in the Assignment group. Here she has the option of having Smart IT automatically assign the best-fit group, from which she can select a specialist. However, she instead selects Bob Baxter from the Backoffice Support group, because he has the most experience in dealing with this type of problem.
  3. After saving the problem investigation, Mary clicks the Share  icon and emails Bob, informing him that he has been assigned the problem investigation. She also clicks the Follow  icon so she can see updates to the problem investigation as it proceeds.
  4.  Mary then relates incidents to the problem investigation. She selects the Related Items tab and clicks Relate Existing Item. She searches for routing table and selects related incidents. From the Relationship Type, list she selects Related to. Then she saves the ticket. The related items now appear on the Related Items tab.

Bob then initiates the root cause analysis. He begins by looking for a temporary workaround while he determines a permanent solution. Bob decides to review knowledge articles, where he identifies a workaround to the issue. He then updates the problem investigation ticket with the workaround:

  1. In Smart IT, Bob selects Console > Ticket Console to locate and open the problem investigation. Open tickets assigned to him are displayed by default.
  2. On the Resources tab, Bob finds a knowledge article that provides a workaround to the issue and pins it to the problem ticket.  
  3. Bob then updates the Workaround field with a summary of the procedure and instructions to refer to the knowledge article he pinned to the problem investigation. He then updates the status to Under Investigation and saves the ticket.
  4. Bob clicks the Share  icon and emails Mary to inform her that he has identified a workaround and updated the problem investigation with that information.

With the temporary workaround in place, Bob continues to investigate the root cause. He finds that the solution is to reconfigure the routing table. Before initiating the change process, Bob updates the Root Cause field:

  1. Bob opens the ticket console and selects the problem investigation from the My Tickets list.
  2. The Root Cause field is not visible because it contains no information. Bob clicks the pencil icon to edit the ticket and scrolls down to locate the Root Cause field. He sets the root cause to Infrastructure Issue. When he saves the changes, the field becomes visible on the ticket.


    Some fields, such as Root cause, are not visible on a ticket until they contain data.

  3. Bob adds an Activity Note describing the root cause. He then emails Mary to inform her that he has identified the root cause. Mary emails Bob back, letting him know that the fix requires a change request.

Now that the root cause has been identified, Mary is ready to create a related known error:

  1. Mary opens the problem investigation, and under Related Items, she clicks Create and selects Related Known Error from the list.
  2. Mary reviews the imported information in the Known Error form and makes any changes or additions that are needed. She then saves the known error, which subsequently appears on the Related Items tab of the problem investigation.

Mary notifies the incident review team that the root cause has been identified and that a change request will be needed to implement a structural solution. After the team evaluates the root cause, Mary creates the change request:

  1. Mary opens the problem investigation and selects the Related Items tab at the bottom of the form.
  2. Mary clicks the Create button and selects Related Change Request.
  3. Mary follows the procedures in Creating and managing change requests using Smart IT to complete the change request.
  4. When the change is implemented, Mary updates the problem investigation status to Completed.

After the change process is complete, Mary sets the status of the problem investigation to Closed, which completes the problem investigation.

How administrators configure problem management functionality

The administrator must ensure that users have the minimum permissions needed to access problem management functionality in Smart IT. Refer to the Problem Agent permissions in Smart IT Permissions.

If your organization requires custom fields to capture additional data in change requests, the administrator can add those fields to the change wizard. For more information, see Adding custom fields to your views using Smart IT in Related topics.

Related topics

Smart IT Permissions

Configuring risk assessment (BMC Change Management documentation)

Scenarios for creating tickets using Smart IT

Adding custom fields to your views using Smart IT

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.