Practice ITIL with OTRS

In articles I will try to reveal the features of the implementation of ITIL practices, including using OTRS.

What does the user want from the IT department in the first place?


I’ll try to answer, with an eye on ITIL, the user's words (it must be a very good user), as follows: The user wants IT services to be provided in accordance with the expectations agreed with the IT department or external organization providing the services. If there are failures in the provision of services, he should know where to turn and the service should be restored as quickly as possible. In addition, the user wants to receive certain IT services, such as software installation, so the basic processes that can be implemented immediately are:
')
Incident management
Request Fulfillment (Service Request Management)

Examples of incidents: does not turn on the PC, an error when starting the application, etc.
Examples of requests for services: software installation, granting rights to corporate resources, etc.

To prevent holivar in comments: software installation can be both a change and a service request, and the granting of rights can be regulated by Access Management. It all depends on the tasks facing the IT department and the description of the Services that the department provides.

Some ITIL terminology

An incident is an unplanned interruption of an IT service or a reduction in the quality of an IT service.
The goal of the Incident Management process is to restore IT services to users as soon as possible.

A bit about OTRS

On Habr there were mentions of this system, nevertheless I will remind about it a little:
As the Wiki says, this is an open application processing system, although its functionality goes far beyond just processing applications.
You can download the system on the official website www.otrs.com. There you can also find installation and configuration manuals.

OTRS setup

We define the types of tickets. More precisely, we leave the ones that we need to implement the above processes, since the system already has a predefined set of settings.



If you wish, you can define queues, such as Hardware, Print, Software. Each queue has the ability to configure agent access. Agents are employees who perform work to resolve incidents, as a rule, employees of ServiceDesk.
For queues, calendars must be defined, i.e. availability of agents responsible for a specific queue, in accordance with their work schedule.

Calendar settings are made in the module:

Core :: Time :: Calendar1

Such calendars can be assigned up to 10 pieces and for each you can specify the working hours of agents for each day of the week, annual and one-time holidays and weekends. Time according to the SLA will take into account the availability of agents.

We define the Services (ie the Service Catalog) and the SLA service level agreement.


The minimum is one SLA, which will determine the time of the first reaction and the time of the decision.

Applications are received through the WEB-Interface, by telephone, through the interface of the IT department agents.
Despite the fact that OTRS has a user interface for working with queries, we implemented interaction through an internal site that runs on joomla, which has the OTRS Gateway plugin (in the house that Jack built). The plugin allows you to create applications, and view your own previously created requests.

OTRS Gateway

An incoming request receives a new state. In the agent interface, the time is available to the first reaction and to the decision.


The fact of starting work with the application is fixed by the answer created on the basis of the template.
After that, the application is blocked and it receives the open state. At the same time, a message is sent to the user that the application has been submitted for consideration. The time counter to the first reaction is reset.
The request should be described, if necessary, incorrectly entered user data.
After the decision, we transfer the application to the pending auto close + state.
The wait time is set by the parameter:

$ Self -> {'Ticket :: Frontend :: PendingDiffTime'} = '14400'

If the user does not receive any additions to the request, it will be switched to the closed successfull state. Yes, it may not be entirely honest, but on the other hand you will not ask the user to additionally enter the WEB-Interface and write comments to the completed request.

$ Self -> {Ticket :: StateAfterPending} = {
'pending auto close +' => 'closed successful',
'pending auto close-' => 'closed unsuccessful'

For the transfer of states, the Unix cron scheduler is responsible, in which it is necessary to set the status update rate to be less than the default of 2 hours:

check every 120 min the pending jobs
45 * / 2 * * * $ HOME / bin / PendingJobs.pl >> / dev / null

We change the parameter, in our case by setting the time equal to 5 minutes. At the same time remember the performance of the system.

check every 5 min the pending jobs
* / 5 * * * * $ HOME / bin / PendingJobs.pl >> / dev / null

For convenient display of requests in the agent interface, set the parameter:
Core :: Ticket :: ViewableStateType,
leaving only the new and open states, thereby hiding the wait states in the agent interface.

Challenges

The description of the request is partially shifted onto the shoulders of the user, without inflating the description dialog, so as not to tire the user. The required fields are Service and Type. Incorrectly described requests are fixed by ServiceDesk.
It is necessary to record all the appeals of users, we solve this problem through the motivation of Service Desk employees.

Reporting

Reporting is formed using standard functionality using a report wizard, for example:
Average response time by performers
Average Service Reaction Time
Average decision time for performers
Average solution time for services
Number of requests for the reporting period (month) by performers
Number of requests for the reporting period (month) for services
The percentage of requests made in accordance with SLA to the total number of requests.

Reporting by executors is necessary for evaluating (motivating) the specialists involved in the Operation of the Services.
Reporting on the Services is provided to interested parties.

In addition, the reports obtained by SQL queries to the database are used and they are the main indicator of the IT service work:
The percentage of requests made in accordance with the SLA. (in our case it is 80%, we strive for 90%)

What's next

Next, we consider the Problem Management, Service Catalog Management, Change Management, Configuration Management, etc.
It is possible to shift both towards ITIL in general, and towards OTRS in particular.