Related Articles

• Problem Management - ITIL® Process
• Incident Management - ITIL® Process
• Request Relationships

Introduction

Usually, after the Incidents/SR module is operational, the following module to be implemented is Problems. This article addresses the application of the Problem Management process in Octopus. To learn more about the basic ITIL® concepts for this process, see the Problem Management - ITIL® Process article.

General concepts

There is a fundamental difference between an incident and a problem. Simply put, an incident is an unplanned situation and must be resolved as soon as possible since it directly impacts the users capacity to work. Problems, meanwhile, have a different view of an incident by understanding its root cause, which could also be the cause of other incidents. While assignees involved in Incident Management are busy resolving incidents, those involved in Problem Management primarily look for ways to prevent the occurrence of incidents or reduce their impacts so that users are not affected by interruptions. To help you put these concepts into context, we will use a scenario.

«Recently,  analysts from the Service Desk have been reporting a higher number of calls for workstations not responding (frozen). One particular user mentions that she did not have this problem in the past, but now the situation happens regularly. Service Desk analysts make the usual troublehooting for this kind of incident and until now, a reboot restores the situation. This is done for all users reporting similar symptoms. Each time, an incident is created and resolved by rebooting the computer.»

Understandably, the reduction or elimination of these repeated incidents would benefit, both the IT group and the users experiencing these interruptions.

Here are three important rules:

• A «Resolved» incident should not be kept open to be analysed later, we proceed with its resolution anyway. However, it is appropriate to create a problem request and link all related incidents to it.
• An incident is not closed, without being resolved, because a problem exists for it. The incident must still be resolved. If there is no solution available, the incident must be escalated to a specialised or higher level group, sometimes help can be sought with a supplier if the expertise is not found internally. But you need to keep looking for a solution to eliminate the incident, even if it is a temporary one. The Service Desk will keep creating and resolving incidents that arise, as long as a permanent solution is not deployed (usually with a change).
• When a change is required to resolve an incident, a problem is not necessarily created. If the incident analysis was sufficient to find the cause and the solution of the situation, a change can be applied directly. . Do not burden your service with a problem that would not have any added value. A relationship between the incident and the change will explain the situation.

While it is more common that a problem is created after the occurrence of several incidents of the same nature, ITIL® mentions that one incident is enough to justify the creation of a problem record, as long as you suspect the existence of an underlying cause. The criteria observed in potential problem identification are multiple and could be: same symptoms, recurrence at a time of the day (week, month), new incidents following a change or a deployment, etc. Here is an illustration that shows the relationship between incident, problem and change.

Problem Creation in Octopus

Create a problem manually

1. From the Problems module, click the Create a problem action 
2. Document the problem with pertinent information, identify CI(s) and add related incidents. Note that Group and Subject fields are mandatory for creation
3. Click OK to save the problem. A unique reference number is automatically allocated by the system

Description of the fields

Problem closure

When closing a problem, you can specify a closure categorization by selecting an activity type. 

From the Activities tab:

1. Click on Add
2. Select a type that corresponds to the problem closure
   • Application update
   • CI decomissioned
   • External supplier intervention
   • Hardware repair
   • Internal technical intervention
3. Document the closure activity in the Work breakdown section
4. Save with OK
5. Change the problem status to Closed

To find out how to configure the activity types, see the Activities in Octopus Wiki article.

Create a problem record from an incident

1. Open an existing incident, from which you want to create a problem
2. Click on Create a problem from this incident action - category, assignment, subject, description and CI in cause are automatically copied into the problem record
3. Fill in the problem creation form according to known information, link other incidents if applicable
4. Click OK to save the problem record
5. The incident that was the source of the problem is automatically linked to the problem with the relation Is an occurence of

Create a problem record from a problem

The action Create a problem from... in Problems Module needs a plugin: 
ESI.Octopus.PlugIns.PinkCertification that can be added to your Octopus database. To get it, you only need to make a request to the Octopus Service Desk.

By clicking this action, the system opens a problem creation form and transfers the following informations:

• Impact, urgency, priority
• Category / subcategory
• Assignment
• Subject
• Content of Description field in Documentation Tab.

You can create a new problem from an existing problem, but you could also create problem templates by writing Model in the subject. By excluding those models from your current problems lists, you could create a new list that only contains problem models. Those could represent, for example:

• Major Problem - high priority, assignment to the System Administrator group, with a procedure indicated in description
• Network Problem - assignment to the Network Administrator group, with a procedure indicated in description
• Other

Create a change record from a problem

The action Create a change from this problem in the Problems Module needs a plugin that can be added to your Octopus Database. To get it, you only need to make a request to the Octopus Service Desk.

By clicking this action, the system opens a change creation form and once the change is recorded, the problem request is automatically linked to the change record in Requests Tab.

Create a Known Error

In Octopus, there is a built in list that displays the Known Errors. This list is based on specific criteria.

Here are the steps to create a known error:

• The status of the problem is not Closed
• The root cause has been identified
• A workaround has been identified

Once these criteria are met, the problem will appear in the Known Error list and the Octopus users will apply the workaround when appropriate.

Resolve the linked occurrences

The Resolve the linked occurrences action resolves or closes any incidents related to a problem that use the link Has for occurrence. 

When the action is selected, a window appears on the screen to write the resolve/close activity. 

The resolve/close activity will be added to each of the linked requests.

If a workaround is documented in the problem, the This occurrence has been resolved with problem #xxx's workaround solution message is displayed in the resolve/closure activity. 

What you need to know:

A message will appear when it is not possible to Resolved/Closed a link Incident.

Contribution to Incident Management

Octopus users involved in Incident management can contribute in many ways to Problem Management. The first and most important contribution is undoubtedly the rigorous processing of each incident. This includes:

• Proper documentation, of the subject, description, troubleshooting steps, actions taken and resolution applied, for each incident
• The confirmation of the categorization and the CI in cause when resolving the incident
• The use, when appropriate, of the Potential Problem checkbox for an incident that could be a potential problem

Incident marked as Potential Problem

Any Octopus user can report an incident as a potential problem by selecting the Potential Problem checkbox and justifying the reason for this action. There is no Octopus permission for this, we recommand to establish an internal procedure to ensure the effectiveness of incident analysis. It is of course necessary to document property in the activies, the symptoms, troubleshooting steps and functional escalations to other support levels. If a workaround temporarily removes the symptoms, it should be mentioned in the incident resolution activity. Link other incidents of similar nateure, as they can be linked to the problem. All these actions and documentation provide elements for analysis and important clues to identify the root cause and possibly a solution to the problem.

To report a potential problem from an incident:

1. Check the the Potential Problem checkbox, located below the Activity Log
2. Add a note to justify the reason
3. Link any other incidents of the same nature, if applicable

Note that this action does not create a problem request, it merely identifies incident(s) that could be potentially be a problem.

Problem Management Contribution

Documentation of the problem Workaround field provides Incident Management with a list of temporary solutions to resolve incidents. From the Incidents/SR module, the Find a solution action displays a list of problems for which a workaround is documented. By clicking this action, the system searches for a correspondance with the CI, and/or the manufacturer, the model, the categorization and displays a list of potential workarounds.

As we mentioned above, you must decide which problem is worth pursuing until a permanent solution. If you have to modify a CI to resolve a problem, the best practice is to go through a change. Therefore, a problem well documented wtih the impact, urgency, related incidents or events, related CI, efforts and costs will contribute to the evaluation and implementation of the change.

Data Analysis

Various analysis techniques are available to help teams identify the root cause of an incident and assess the options in the approach to be taken to reduce the impact or resolve. We invite you to consult the Investigation & Diagnosis activity described in the Problem Management - ITIL® Process, article, you will find a short description of these techniques.

Using Octopus, employees working in Problem Management will be able to gather data from Octopus to observe what happened in the production environment, identify trends and create appropriate problems. There are several possible sources of data in Octopus, including:

• Incidents marked Potential Problem
• Statisticmodule:
  • Problem > Most problematic CI
  • Problem > Most problematic CI models
  • Problem > Most problematic CI types
• Number of events (alerts) that generated incidents
• Activity types, configurated to identify the cause of an incident at resolution
• Existing problems with their related incidents
• Etc.

According to observations and findings, the Octopus user will decide whether to create a problem. But Octopus data will not be the only source in the decision to create a problem. A known unstable CI, a critical CI with no redundancy, or CIs related in «Information» or «Warning» events, a trend that could be corrected would be a reason to create a problem proactively in order to track CIs that may generate incidents in short, medium or long term. Other examples could apply. See the Event Management - Octopus Module or Event Management - ITIL® Process articles to learn more about events.

Incidents marked as not significant for problem management

During the analysis phase, the Octopus user working in Problem Management identifies incidents that are not significant to problem management in order to remove then from future searchs.

1. Select one or more existing incidents
2. Click the Mark as not significant for problem management action 
3. A message informs you that selected incident(s) will be marked as not significant for problem management - this operation is irreversible
4. The potential problem checkbox is replaced by a note indicating that the incident was marked as non significant for problem management

Advanced Search

From the advanced search of the Incidents/SR Module you can access the Problem tab. From there, you can filter incidents with the following options:

• Incidents not associated to a problem
• Exclude incidents not significant for problem management
• Incidents marked as potential problems

Therefore, the Octopus user can do the incident search according to his needs. The search results will include all incidents, from the «new» to the «closed» status.

The advanced search allows to retrieve incidents related to problems and vice-versa. Here are the steps to use:

1. Open advanced search
2. Select Request relationship from the list of result types
3. Enter Type (Request 1) field equal Incident
4. Enter Type (Request 2) field equal Problem

You will get a list of incidents related to a problem, which you can save for future reference..

Permissions

• Access the problem management module
• Create a problem
• Manage the relationship between incidents and problems
• Modify a problem's status
• Modify a problem
• Delete a problem task

To see the list of permissions and a brief description, you can download the following document: Octopus Permission Reference.

Reports and Lists

In the Statistics Module, several reports related to Problem Management are available. Some are management reports, others are used to identify CIs, CI models or CI types that were implicated in incidents or problems, which are useful for Problem Management.

Lists also allow extraction of useful information for Problem Management, for example:

• Known Errors: display problems with documented Root cause and Workaround. They help Incident Management resolve incidents faster by making solutions available .
• CI associated to problems: list of CIs related to problems
• Open: list of active problems; by displaying priority and number of incidents columns, this list provide information about a potential priority change (an increase in related incidents could justify it)
• Closed: list of resolved problems
• Root Cause To Be Identified : problems open for more than one month for which a root cause is not documented; this list is useful to track problems that have not been worked on for some time and is based on exceeding a threshold

• Closed Incident Categories : this list serves Incident Management and Problem Management in the analysis of the categorization selected in incidents and problems, in order to adjust (by modifying or adding categories) the categorization structure. This list can be exported in Excel, like all lists created in Octopus.

Other Applications

Knowledge

To support the teams participating in Problem Management, knowledge should be documented to help with the proper operation of the process, including:

• investigations, diagnoses, root cause analysis techniques
• creating / updating workarounds, temporary fixes and resolution

This knowledge can be documented in Configurations module in a document type CI. Thus, teams can refer to and even use analysis documents in a problem. See How to Manage Procedures in Octopus that will guide you in the establishing formalized knowledge for Problem Management.

Application Development

An organization who has in-house application development, could want to record known errors during the development phase (problem with a root cause identified and a documented workaround). If the known error is resolved before the application go-live, the record can be resolved. Otherwise, we could transfer the known error into production, as it could be used for incident resolutions, by selecting a problem lifecycle status. To distinguish the known errors in development from the known errors in production, separate lists can be created for consultation.

If you want to apply this concept to your development department, you must make a request to Octopus Service Desk who will add the In Development status to the Problems Module of your database.

Major Problem

In the Octopus context, the major problem review can be assured by a standard task added to the problem workflow. It should include the following elements:

• what was done right
• what was done wrong
• what could be done better next time
• how to prevent the problem from happening again
• identification of lessons learned

Do not hesitate to consult the Task Management article to get more details on task configuration in Octopus.