ITIL (Problem Management) by means of OTRS

Let me remind you that the main purpose of Incident Management is to restore the service as quickly as possible, which sometimes becomes like an attempt to extinguish a forest fire with a shovel. Since, having extinguished the fire on an individual hill, we will not eliminate the general calamity, and, having extinguished the entire area of ​​the fire, we will not resolve the issue with the appearance of a new focus next season or even the next day. It is necessary to deal with the cause of the fire, whether it is tourists and it is necessary to conduct agitation (training), or whether it is a swampy, dried up forest, and it is necessary to carry out its cleaning (modernization).

Or, for example, a case from the life: when printing on a printer with several trays, paper was jammed from one tray, as a result, within the framework of Incident Management, trays were changed, thus the issue of jamming was temporarily eliminated. And this situation was repeated for several days, causing inconvenience to users, and distracting IT specialists. In this example, Problem Manegement showed that the reason was the wear of the paper feed rollers and after replacing them the printer began to work in normal mode.

Go deeper!

A bit of theory

According to ITIL, a problem is an unknown cause of one or more incidents. Just what you need!
So, if you look at the main task of Problem Management - to prevent problems from occurring, to eliminate the occurrence of recurring incidents and to minimize the impact of incidents that cannot be warned.
')
For which it is necessary to manage problems from a business point of view, this is probably a higher availability of IT services, higher staff productivity, including IT, and cost reduction due to the absence of repeated incidents.
Here we will look at reactive problem management, that is, the response to the problem being discovered.

Let's proceed to the implementation

- What, problems?

How are we looking for problems? Here we are assisted by monitoring tools, ServiceDesk, incidents, data from suppliers or data from Proactive Problem Management

When it became clear that before us we are really registering the problem in the agent interface, for which it is necessary to do a number of manipulations in the admin part of OTRS.

To register problems, you need to activate the request type Problem.

Next, you need to hide the application types from users.
Ticket -> Frontend :: Customer :: Ticket :: ViewNew set the parameter Ticket :: Frontend :: CustomerTicketMessage ### TicketType - No
Thereby, by simplifying the task to the user, and by complicating the task ServiceDesk.

To unload the agent interface, enter the queue “Problem Queue”. Now all problems are available only to those agents who are allowed to this on a separate tab.

The application description is assigned to ServiceDesk or the Problem Manager in case of a problem description. i.e. add agent rights to the "Queue of problems"

Classification

We decided to focus on the classification of services, although it can be classified by queues. The classification should be the same as in Incident Management for more convenient presentation and further debriefing in conjunction with Incident Management.
The right window “Application information” contains information about the service, SLA, decision time for the application in accordance with the SLA.
The bottom part displays incidents that relate to this problem. The ConfigItem is also linked, that is, the printer we are working on in the context of this problem. When clicking on the link, we can view additional information on it.

Priorities

Level 5. Major problem - requiring immediate solution, as a rule - these are problems affecting top management, or affecting a large number of users.
Level 2-4. All other problems
Level 1. Affecting a small number of users.

Search for a cause

This is where the work begins. It is necessary to determine the cause of the problem.

All work performed is recorded through notes, adding to the log of the problem, which can speak about the effectiveness of IT service workers, as well as useful when similar problems appear. It also records the time spent on the work. The total time for the problem is summarized from the time for all notes.


If we are lucky and we have determined the reason go to the agent interface and describe it.
You must specify a reason code for a global analysis of the causes of all problems, if necessary, adding a description.
If we haven’t gotten to the cause of the problem yet, but have found a workaround, it is necessary to fix it in order to increase the time for resolving newly occurring incidents. For ITIL, it is recommended to create a Known Error Record. However, I use a change in the type of request from Problem to Problem.Known Error.

Again we perform some manipulations, namely, we add the necessary fields for applications and their values.
For these settings are responsible DynamicField (Dynamic fields), revised functionality, which appeared in version 3.2 OTRS


We will need the Cause (Dropdown), Cause Description (TextArea), Workaround (TextArea) fields.
The description of all fields is done in English, and the translation is done through the file ru.pm, located in the folder / opt / otrs / Kernel / Language /

For the Dropdown field, set the predefined values.

Add to the configuration Ticket -> Frontend :: Agent :: Ticket :: ViewAddtlITSMField


So it looks in the agent interface.

Decision

After the solution to the problem is found, we must formally close the problem by changing its status to “Closed successfully”.

Reporting

Management reporting

• The number of problems registered for a certain period.
• Cost of problem solving for the reporting period
• % problems with priority 5

Problem Manager reporting

• The cause of problems for a certain period, by services, by type CI.

PS In version 3.2 a new feature appeared: ProcessManagment, which allows you to manage applications using WorkFlow, so you have to go back to the Request Fulfillment process