3.3/5 - (3 голоса)

В предыдущей статье мы рассказывали о том, как настроить Сервис Деск систему на базе Jira сделав минимум изменений в конфигурации из коробки. В этой публикации речь будет идти о разработке, заточенной под рабочие процессы компании.

Итак, принцип работы: Первая линия принимает обращения пользователей по нескольким каналам связи: почта, мессенджеры (Skype, Telegram, пр.), звонки, сообщения системы мониторинга и других систем. Проблемы, для которых решение известно, и его возможно выполнить за 30 минут, закрываются непосредственно специалистами первой линии. Остальные – передаются далее по цепочке более компетентным или свободным администраторам. Ключевые моменты, на которые было обращено при разработке решения:

  • Задача не должна потеряться
  • Задача должна быть обработана в сроки, оговоренные в SLA
  • Задача не должна быть отставлена без внимания в процессе решения.

Для того чтобы задача не была потеряна кроме ручного создания задачи администратором технической поддержки настроен прием задач по электронной почте. Это позволяет принимать заявки как от адекватных пользователей, которые в состоянии описать проблему, так и от автоматических  систем: например,  мониторинга или системы учета заявок одного их клиентов.

Таким образом, в нашем решении появилось 2 типа задач: принятые вручную и принятые автоматически. Бизнес процессы для них практически одинаковые. Поэтому логику работы мы будем рассматривать на Workflow для автоматически принятых заявок.   Выглядит он следующим образом:

первая линия service desk jira

Созданная задача имеет статус Waiting for support, и может находиться в таком состоянии до 5ти минут. За это время задачу должен назначить на себя кто-то  из специалистов Сервис Деск. В противном случае задача подсвечивается красным, а система начинает оповещать о том, что есть необработанные задачи.

Назначенная задача переходит в статус Open. С этого статуса также начинается обработка задачи созданной в ручном режиме. У обоих бизнес процессов есть два статуса приостановки работы: по причине ожидания пользователя и по иным причинам, связанным с внутренними вопросами команды Service Desk. Также есть четыре статуса, при которых работа над задачей завершена:

  • Done – заявка выполнена.
  • Closed – заявка закрыта без выполнения.
  • Escalated и Autoescalated – заявка передана на выполнение за пределы команды Сервис Деск.

На выполнение задачи у специалиста технической поддержки есть 30 минут, без учета времени в статусах ожидания. Если за это время задача не решена, она автоматически переходит в статус Autoescalated.

Для того чтобы задачи автоматически эскалировались на нужных людей, в системе предусмотрено отдельное поле, в котором указывается проект в котором создастся эскалированная задача. Такая задача при создании назначается на лидера проекта. Поле, в котором указывается проект, может заполняться вручную при создании или редактировании задачи или автоматически в зависимости от автора задачи.

Собственно — все. Все автоматические действие выполняются при изменении статуса задачи с помощью post-функций. Для создания новых задач используется Run CLI Actions in JIRA add-on, для изменения значений полей используется JIRA Misc Workflow Extensions add-on (ссылка на статью), для формирования специфических проверок Adaptavist ScriptRunner for JIRA add-on. О некоторых из них мы писали ранее, некоторые стоят того, чтобы посвятить им отдельную статью.

«Зачем же использовать Jira Service Desk, если все делается с  помощью post-функций?» — резонно спросите Вы. Сервис Деск используется для:

  • организации автоматизированной проверки SLA;
  • организации реакции на превышение этих значений;
  • организации очередей и отчетности;
  • группировки наборов пользовательских (клиентских) записей в Организации.
  • В будущем планируется использование портала для создания автоматически решаемых задач.

За время эксплуатации системы был выявлен ряд неудобств. Например:

  • Для того чтобы избежать возможного превышения SLA, сотрудники решают задачи, а потом создают их в Jira.
  • Задача, которая ушла на вторую линию технической поддержки, не имеет с первой линией обратной связи, кроме ссылки, соответственно при анализе закрытых задач первой линии невозможно понять, решена ли проблема.
  • Виден ряд задач, которые могли бы быть решены в автоматическом режиме, при наличии необходимой информации в нужных полях задачи.

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

Если у Вас есть вопросы по организации систем Сервис Деск на базе продуктов Attlassian – обращайтесь. Наш опыт может помочь Вам, [email protected]

Privacy Preference Center