Practice ITIL with OTRS

In the 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 will try to answer, with an eye on ITIL, by the user's words (this must be a very good user), as follows: The user wants IT services to be provided in accordance with expectations agreed with the IT department or the external organization that provides the services. If there are failures in the provision of services, then he must 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, therefore, as the basic processes that can be implemented immediately, these are:

Incident management (Incident management)
Request Fulfillment

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

To prevent holivar in the comments: installing software can be like a change, or a request for service, and the grant of rights may 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.

A bit of ITIL terminology An

incident is an unplanned interruption of an IT service or a decrease in the quality of an IT service.
The goal of the Incident Management process: speedy recovery of IT services for users.

A bit about OTRS

At Habr there were references to this system, nevertheless, I will remind you a little about it:
According to Wiki, it is an open application processing system, although its functionality goes far beyond only application processing.
You can download the system on the official website www.otrs.com. There you can also find installation and configuration manuals.

Configuring OTRS

Define ticket types. More precisely, we leave those that we need to implement the above processes, since the system already has a predefined set of settings.



If desired, you can define queues, for example, Hardware, Printing, Software. Each queue has the ability to configure agent access. Agents are employees who work to resolve incidents, typically ServiceDesk employees.
For queues, calendars must be defined, i.e. the availability time of agents responsible for a particular queue in accordance with their work schedule.

Calendar settings are made in the module:

Core :: Time :: Calendar1

Up to 10 such calendars can be assigned and for each you can specify the agent’s hours of operation for each day of the week, annual and one-time holidays and weekends. Time in accordance with the SLA will take into account the availability of agents.

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


At least one SLA is sufficient, in which the time of the first reaction and the time of solution will be determined.

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

OTRS Gateway An

incoming application receives a new state. In the agent interface, time is available until the first reaction and before the solution.


The fact of starting work with the application is fixed by the response 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 before the first reaction is reset.
The request should be described, if necessary, the data entered by the user incorrectly corrected.
After the decision, we transfer the application to the pending auto close + state.
The timeout is set by the parameter:

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

If the user does not receive any additions to the request, it will be transferred to the closed successfull state. Yes, it may not be completely honest, but on the other hand you won’t ask the user to force them to additionally go into the WEB-Interface and write comments on the completed request.

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

The Unix cron scheduler is responsible for the state transition, in which you need to set the frequency status updates less than the default 2 hours:

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

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

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

To conveniently display requests in the agent interface, set the parameter:
Core :: Ticket :: ViewableStateType,
leaving only the new state and open, thereby hiding the wait state in the agent interface.

Challenges We

partially shift the description of the request onto the shoulders of the user, without inflating the description dialog so as not to tire the user. Indicate the required fields Service and Type. Incorrectly described requests are corrected by ServiceDesk.
It is imperative to record all user requests; we solve this problem through the motivation of Service Desk employees.

Reporting

Reporting is generated using standard functionality using the report creation wizard, for example, the following:
Average response time for performers
Average response time for services
Average decision time for performers
Average time for solution for services
Number of requests for a reporting period (month) per executors
Number of requests for a reporting period (month) for services
Percentage of requests made in accordance with SLA to the total number of requests.

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

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

What’s Next

Next, we consider Problem Management, Service Catalog Management, Change Management, Configuration Management, etc. ...
You can shift towards ITIL in general and OTRS in particular.