Создание тикет-системы на базе OTRS

В данный момент у компании EFSOL для поддержки клиентов, а также внутренних сервисов используется платная тикет-система, которую мы получаем по модели SaaS. Со стороны функционала претензий к системе нет. Однако, мы задумались о другом решении для организации тикет-системы из-за экономических факторов:

1. Количество сотрудников нашей компании постоянно увеличивается и, соответственно, ежемесячные затраты растут.
2. У нас есть свой хостинг (облачные серверы и техническая поддержка) – нет проблем размещать сервис у себя, а не пользоваться сторонним облачным решением.

Выбор решения для тикет-системы

Поиск тикет-системы производился, используя следующие требования:

1. Продукт должен быть на базе свободного ПО
2. Установка должна выполняться на бесплатную ОС
3. Система должна соответствовать принципам ITSM
4. Система должна иметь широкие возможности по кастомизации и доработке.
5. Постановка заявок стандартными способами : Email, телефон, web-интерфейс пользователя.
6. Должна быть возможность формировать необходимые отчеты:
   • отчет по заявкам: количество, %просрочки, %инцидентов, статистика по клиентам и исполнителям)
   • отчет по оценке заявок
   • отчет по количеству возвращенных заявок

Были обозначены цели, которые планируем достичь с использованием новой тикет-системы:

• Перевести все взаимодействие внутренних служб ( план «Минимум»)
• Перевести текущих клиентов и использовать для новых (план «Максимум»).

Из всех решений, которые были рассмотрены, наиболее подходящим показался OTRS.

В таблице 1 ниже приведены наиболее распространенные термины которые используются при работе с системой.

Таблица 1 – Термины, используемые при работе с тикет-системой

Обзор OTRS

Рассмотрим функционал системы, который можно получить сразу после установки и базовой настройки:

1. Заведение клиентов, группировка их по компаниям.
2. Заведение агентов , группировка их по группам – это могут быть группы или линии поддержки.
3. Создание каталога услуг.
4. Создание очередей. К разным очередям можно предоставить разные доступы и разные оповещения.
5. Регистрация заявок доступна 3-мя способами:
   • По почте. Письмо с почты автоматически преобразуется в заявку в определенной очереди. Можно настроить прием заявок в разные очереди с разных ящиков.
     

     Рисунок 1 – Интерфейс настройки почты для приема заявок

   • Через Web-интерфейс. Клиент оставляет заявку через Web-сайт. При постановке заявки через Web-интерфейс, есть возможность выбрать услугу, а также срочность заявки.
     

     Рисунок 2 – Интерфейс пользователя OTRS

   • По телефону. Агент ставит заявку, которую он принял по телефону от клиента.
6. Обо всех движениях заявки приходят оповещения на почту клиента.
7. Создание SLA. Есть возможность настроить граничное время решения заявки в зависимости от сервиса и приоритета заявки. Стоит отметить, что делается это не очень просто. Сначала создаются SLA, в которых прописано граничное время реакции, эскалации и решения в привязке к сервису.
   

   Рисунок 3 – Настройка SLA

   Далее необходимо сопоставить приоритет заявки с ее типом и SLA. В таблице ниже настраивается матрица какой ID SLA будет выбран при определенном ID типа заявки и приоритете.

   

   Рисунок 4 – Сопоставление SLA, типа заявки и приоритета

8. Присутствуют базовые отчеты:
   • Перечень открытых заявок.
   • Перечень закрытых заявок.
   • Перечень заявок созданных за последний месяц.
   • Новые заявки.
   • Обзор изменения статусов заявок за месяц.
   • Обзор всех заявок в системе.
9. Обработка заявки происходит достаточно просто. Входящая заявка попадает в определенную очередь. Заявку видят все операторы данной очереди, если оператор принимает заявку – она им блокируется и другие операторы уже не смогут с ней работать.
   

   Рисунок 5 – Интерфейс обработки заявки оператором

   Оператор проводит классификацию заявки указывая приоритет и сервис. Далее может закрыть ее сам или же передать другому оператору или в другую очередь.

   

   Рисунок 6 – Интерфейс классификации заявки

Настройка системы OTRS

Для реализации первого этапа установили систему и начали ее настройку.

Базовая настройка

После того как система была установлена, ее нужно было настроить.

• Создан и подключен к системе почтовый ящик для приема писем с заявками.
• Создано и подключено DNS имя для использования Web-интерфейса.
• Заведены сотрудники компании «агенты» и сгруппированы по отделам. Клиентов не создавали – так как система будет пока служить для постановки заявок между сотрудниками.
• Созданы 2 очереди техподдержки: 1-я и 2-я линия поддержки.
• Созданы 2 очереди техподдержки: 1-я и 2-я линия поддержки.
• Вставили логотип и русифицировали интерфейс и уведомления.

Рисунок 7 – Страница входа в OTRS

В результате получился инструмент, позволяющий использовать такой функционал:

• Отправить заявку письмом или же через web-интерфейс.
• Заявка регистрируется, ей присваивается номер, передается между исполнителями, закрывается.
• Автору заявки приходят уведомления о состоянии заявки, также автор может прикрепить свой комментарий через личный кабинет или ответив на письмо.

Базовая кастомизация

Для соответствия системы потребностям компании выполнили небольшую кастомизацию:

Настроен SLA. Регламентное время решения заявки вычисляется в зависимости от типа заявки (запрос на обслуживание или инцидент), приоритета и сервиса. Настроено рабочее время. Также выполнен расчет приоритета в зависимости от срочности и критичности заявки. Изначально в заявках есть только параметр приоритета.

Настроено ограничение на прием заявок. Настроили прием заявок только с почты клиентов или агентов. С адресов, не зарегистрированных в системе, заявки не принимаются, в ответ отправляется уведомление о незарегистрированном адресе.

Реализован механизм оценки заявок. При закрытии заявки исполнителем, автор получает уведомление с просьбой принять выполнение заявки и поставить оценку. Если у автора есть замечания, он отвечает на данное письмо и заявка возобновляется в работу, а его ответ крепиться комментарием к заявке.

Рисунок 8 – Уведомление на почту о закрытой заявке

Рисунок 9 – Результат оценки заявки

Реализован механизм подсчета возвращенных заявок. Количество возвращенных заявок и количество раз, которое они были возвращены является очень важным показателем качества работы ИТ-службы, поэтому в форму заявки был добавлен счетчик возобновления заявок.

Отчеты

Для оценки качества работы ИТ-подразделения пока решили использовать 3 отчета:

Отчет по заявкам. Показывает количество заявок за определенный период, в том числе количество и процент просроченных заявок – наиболее важный параметр. Также предоставляется информация по количеству и процентному соотношению типов заявок и состояний.

Рисунок 10 – Пример Отчета по заявкам

Отчет по оценке заявок. Показывает среднюю оценку по всем заявкам за выбранный период и по каждому типу в отдельности.

Рисунок 11 – Пример Отчета по оценке заявок

Отчет «Возвращенные заявки». Показывает количество возвращенных заявок в абсолютном и процентном соотношении и показывает сколько раз была возвращена конкретно каждая заявка.

Рисунок 12 – Пример Отчета «Возвращенные заявки»

Во всех отчетах настроен интервал диапазона дат – текущее число. Отчеты можно формировать по отдельному клиенту, исполнителю или очереди.

Рисунок 13 – Интерфейс для формирования отчетов на примере Отчета по заявкам

Планы по дальнейшему развитию

В данный момент система успешно запущена для работы внутренней службы. В планах поработать несколько недель и составить список новых пожеланий к системе, которые всплывут во время боевой эксплуатации системы. Далее будем решать, какие из них действительно нужны и будем их реализовывать.

В будущем планируется реализовать следующий функционал:

1. Создать веб-форму для отчетов. В данный момент отчеты выгружаются сразу в файл. Было бы удобнее чтобы формировалась форма в браузере, а уже потом, если необходима выгрузка, выгружать ее в необходимый формат.
2. Сделать более презентабельную форму формирования отчетов.
3. Реализовать механизм «Замораживания заявок». Сделать возможность, когда исполнитель смог бы приостановить выполнение заявки, указав причину. При этом SLA замораживается. Актуально для заявок, к решению которых невозможно приступить в ближайшее время, например, автор заявки просит подключить ему компьютер, который будет куплен только через 3 дня.
4. Создание красивого клиентского интерфейса.
5. Механизм согласования заявок. Необходимо создать механизм, когда определенный тип заявок не может быть выполнен исполнителем без согласования ответственного сотрудника. Очень актуально для заявок связанных с безопасностью и предоставлению доступа к данным. Такие заявки ставят сотрудники клиента, но согласовывает их выполнение служба безопасности клиента или руководитель.

Вывод

OTRS – это очень перспективная система. Основным ее преимуществом, кроме того, что она бесплатная, является большая степень гибкости. Отсюда появляется и самый большой недостаток системы – ее нужно полностью настраивать и кастомизировать под свои задачи. Без этого удастся получить только базовый функционал. Очень мало компаний используют OTRS в базовом варианте, а некоторые создают собственные платные продукты на базе OTRS или же делают платные модули, отчеты и прочее.

Мы запустили готовую тикет-систему в облаке и предлагаем её в аренду.