Сервис Деск на вырост

Мы продолжаем рассказывать о простых решениях, которые упрощают жизнь ИТ компаний. Как известно, договоренности на словах часто приводят к различиям между ожидаемым и получаемым.  После очередного подобного случая заказчик изъявил желание самостоятельно размещать задачи и отслеживать их выполнение.

В компании в это время уже использовался продукт Atlassian Jira, поэтому было принято решение расширить его функционал и создать Сервис деск на базе Jira.

Решение получилось простым, но вполне функциональным. Ниже мы подробнее расскажем о нем.

Вид со стороны заказчика

Каналы доступа:

Клиент может создавать задачи путем отправки письма на электронную почту или через веб-портал самообслуживания.

Мера участия:

Используя веб-портал, в зависимости от настроек системы, заказчик может не только получать уведомления на почту, но и отслеживать статус заявки, просматривать и редактировать задачи. Кроме того управлять собственными комментариями и вложениями. Возможности заказчика определяются в настройках схемы разрешений (Permission Scheme).

Вид со стороны исполнителя

Роли проекта

В проекте настроено 2 роли:

• ADMINISTRATORS – имеют максимальные полномочия. Могут менять настройки проекта и управлять схемами прав, безопасности, ролями и т.д.
• SERVICE DESK TEAM — служба технической поддержки. Их задача работать с заявками.

Схема работы службы

Команда службы поддержки разделяется на 2 группы, обеспечивая 2х уровневую модель обслуживания. Первый уровень непосредственно общается с клиентом и разрешает большинство типичных и не требующих высокой квалификации задач. Второй уровень получает задачи не от клиента, а от первого уровня и дальше работает над задачей совместно с заказчиком или со специалистом первого уровня.

Типы заявок

В данном проекте заведено несколько типов заявок:

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

Рабочий процесс

Несколько слов о категориях статусов. В данном примере используется 3 категории:

1. Работа над задачей не началась (Синяя)
2. Задача в работе (Желтая)
3. Работа над задачей завершена (Зеленая)

В нашем случае после создания заявки она появляется в очереди «Неназначенных задач». Именно эта очередь используется для отслеживания поступивших обращений. Для того чтобы взять задачу в работу переводим ее в статус Work in progress с помощью кнопок с названиями  в соответствии с Workflow для данного типа задач.

После этого статус задачи поменяется.  Это будет отображено в очереди задач.

Статус Work in progress говорит о том, что задача находится на первой линии технической поддержки. Из этого состояния можно перевести ее в ожидание (статус Pending), например, если нужен ответ от заказчика или для решения этой задачи необходимо чтобы  другая задача была решена. При нехватке времени или знаний задача может быть передана на вторую линию технической поддержки. Для этого нужно изменить статус на Escalated.

На любом уровне задача может быть решена (статус Completed) или отменена (статус Canceled). Такая задача требует контроля выполнения. В нашем случае эту роль выполняет Заказчик. Он переводит задачи в статус Closed,  фиксируя тем самым факт завершения работы над задачей.

В нашем случае все действия с задачей генерируют оповещения (e-mail) для автора задачи (то есть заказчика), а также для назначенного на задачу специалиста техподдержки и администратора проекта.

Service Level Agreement

Используется два контрольных диапазона времени: Время реакции и время решения задачи. Временем реакции считается время от момента создания заявки до момента перевода задачи в любой другой статус. В нашем случае этот параметр установлен в значение 1 час при обращении в рабочее время (5 дней в неделю, 9 часов в сутки).

Временем решения задачи считается время от момента создания заявки до перевода ее в статус Completed или Closed или Canceled. Установлено 4 часа на решение в рабочее время.

Если задача находится в статусе Pending, время не считается.

Вид со стороны администратора

Отчетность.

Мы начнем с нее, потому что в нашем случае руководство интересуют цифры, а не способы их получения,  вследствие чего формированием отчетов для руководителя занимается администратор системы сервис деск.

Итак, преднастроенных отчетов мало, поэтому по необходимости формируем требуемые графики.

Каждый график  показывает количество задач отфильтрованных требуемым вам JQL фильтром.

Наборы задач для фильтрования могут представлять собой  все Созданные задачи, все  Решенные задачи или Множества задач, определенные временными SLA:

• Время реакции – соблюдено
• Время реакции – просрочено
• Время решения задачи – соблюдено
• Время решения задачи – просрочено

Настройки очередей

Текущую информацию о количестве задач проще смотреть по состоянию очередей.

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

Управление Клиентами

В нашем случае настроено следующее поведение системы. Когда не зарегистрированный Заказчик оставляет заявку через E-MAIL, Jira автоматически создает пользователя, после чего он появится в списке Customers, но не будет иметь доступа к порталу, пока администратор не предоставит ему соответствующие права.

Настройки проекта

Настройки проекта аналогичны настройкам проектов Jira других типов. Мы надеемся на то, что Вы постоянный читатель наших статей, поэтому не будем останавливаться на конфигурировании проекта в этой публикации.

Автоматизации

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

К сожалению Jira не умеет запускать что-либо по расписанию. Автоматизация запускается только  по указанному триггеру, срабатывает для задач, отвечающих описанному условию, и выполняет указанные действия. В нашем случае, автоматизация оповещает по электронной почте ответственных сотрудников о том, что появилась не назначенная задача. «Осуществить некоторые потребности автоматизации можно также с помощью пост-функций» – скажете Вы. Однако, инструмент автоматизации более простой и наглядный. По мнению автора, ему не хватает функционала (хотелось бы более широкий выбор триггеров, условий и действий), но эта проблема может быть решена путем установки дополнительных плагинов. В общем, здесь выбор за Вами.

Вот собственно и все, что используется для успешного взаимодействия с клиентом. Это пример простой конфигурации службы сервис деск на базе ПО Atlassian Jira. Большое количество настроек осталось стандартными, то есть не изменялось после инсталляции. Однако за 3 месяца работы можно сказать, что настройки по умолчанию вполне пригодны начала для работы в реальных условиях. Таким образом, непростое ПО используется для простой задачи. Зачем? Бизнес растет, как в объемах,  так и в потребностях. Требование к гибкости повышает сложность системы. Используя Atlassian Jira Service Desk, Вы получаете рабочий инструмент при изменениях процессов в Вашей компании.

О более сложном решении читайте в следующей статье.

А если Вам нужна консультация по организации работы службы сервис деск в Вашей компании – наши специалисты с удовольствием помогут Вам, [email protected]