Перенесли Service desk из Jira на российское ПО Kaiten, чтобы продолжить работать с госсектором

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

Меня зовут Григорий Меньших, я отвечаю за партнерскую сеть в компании Hopper IT. В декабре мы окончательно перенесли процессы нашей службы поддержки из Jira в российский аналог — Kaiten.

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

В главных ролях:

• Григорий — отвечаю за партнерскую сеть.
• Михаил — руководитель системы внедрения Service desk.
  
• Дмитрий — выступал в качестве аналитика и настраивал всю систему.
  

Hopper IT помогает бизнесу и госсектору внедрять корпоративные порталы, автоматизировать HR- и бизнес-процессы, оцифровывать знания, поддерживать стабильность работы IT-систем.

В компании сейчас 3 основных направления:

• внедрение Битрикс с уклоном на HR-функции;
• информационно-техническая поддержка пользователей заказчика;
• новое большое направление — импортозамещение и внедрение российских продуктов.

Среди наших клиентов: Департамент информационных технологий Москвы, МФЦ города Москвы, Россети, Объединённая авиастроительная корпорация, МТС и другие компании.

В штате более 200 человек. Есть коммерческий блок, отдел внедрения, разработка и большое подразделение службы технической поддержки, которое занимается мониторингом систем заказчиков.

Все сотрудники компании используют наши же ресурсы для получения внутренней поддержки пользователей. Такие запросы можно базово разделить на 3 категории:

• техническая поддержка,
• предложения по развитию внутренних сервисов компании,
• заявки в тендерный отдел.

Мы получали и обрабатывали все заявки с помощью Jira, где для каждой категории был настроен свой воркфлоу, по которому работали отдельные команды.

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

В зависимости от категории обращения на заявку автоматически назначался нужный сотрудник и вел ее по воркфлоу внутри проекта. А после выполнения заявки заказчик мог заполнить форму обратной связи и оценить работу специалиста.

Мы потратили немало времени, чтобы настроить эту систему. В итоге она всех устраивала и работала как часы.

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

Основными критериями для нас были:

• наличие Service desk системы для работы с заявками;
• легкий и быстрый перенос данных из Jira;
• понятный интерфейс, позволяющий быстро адаптироваться в продукте;
• приемлемая цена.

Kaiten проходил по всем этим пунктам. К тому же это довольно универсальная система, в которой, помимо таск-трекера, есть встроенный Service desk и инструменты для создания базы знаний.

Конечно, по функциональности он попроще Jira, но зато более понятный. Не нужно быть экспертом, чтобы разобраться и настроить процессы, как тебе нужно.

Приятный бонус, что к Kaiten можно прикрутить Telegram-бота и подавать через него заявки в службу поддержки.

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

Мы начали переезд с того, что задокументировали всё, что у нас было, и попробовали реализовать это Kaiten.

Шаг 1. Создали 3 пространства под разные категории обращений: Запросы в техподдержку, Развитие, Тендерный отдел. На каждом пространстве построен свой воркфлоу:

Шаг 2. Создали типы карточек по аналогии с типами обращений, которые у нас были ранее в Service desk. В зависимости от типа задачи можно создавать шаблон карточки, а также настраивать автоматизации. Об этом расскажу далее.

Шаг 3. В самом Service desk настроили сервисы для приема обращений в поддержку. Пользователь выбирает категорию вопроса и отправляет заявку. Заявка автоматически отправляется в виде карточки на нужное пространство, где с ней работает команда поддержки.Здесь отмечу, что некоторые сервисы не видны всем пользователям. Например, заявки на развитие портала могут направлять только руководители подразделений.

Шаг 4. Внутри каждого сервиса настроили автосообщения, которые отправляются заказчикам при обращении. А также указали, в каких случаях заказчику уходят другие нотификации. Например, когда карточка взята в работу или переведена в статус «Готово».

Шаг 5. Для каждой категории обращений настроили динамические поля. Форма заявки автоматически трансформируется, когда имеющиеся в ней поля заполнены определенным образом.

Например, самый частый запрос — это предоставление доступа к какому-либо сервису. Пользователь может выбрать, к какой системе ему нужен доступ. И, в зависимости от его выбора, Kaiten предложит заполнить поля, необходимые именно для этой системы. Это помогает нам быстрее понять, что нужно человеку и не задавать лишних вопросов.

Перед переходом на Kaiten мы провели рефакторинг и выяснили, что мы можем оптимизировать 15% из общего количества внутренних процессов, добавив более глубокую категоризацию запросов. Для каждого обращения создали 3-4 уровня уточнений, в чем конкретно проблема.

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

В зависимости от категории запроса карточке присваивается тип, автоматически назначается ответственный сотрудник и добавляется определенный SLA и приоритет.

• Например, «Запросы на доступ» имеют высокий приоритет и SLA — 40 минут. Так как такие вопросы могут тормозить работу коллег и должны обрабатываться как можно быстрее.
• В категории «Вопрос / Консультация» приоритет средний, порядка 8 часов. Чтобы ответственный сотрудник мог спокойно на него ответить в течение рабочего дня.
• Запросы на улучшение имеют более долгий SLA, так как требуют большей детализации и проработки.

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

По ходу работы над заявкой карточка перемещается по колонкам Канбан-доски и меняет свой статус: Создано, В работе, Требует уточнения, Пауза и Готово.

• В колонке «Требует уточнения» мы можем узнать у инициатора заявки дополнительную информацию.
• Колонка «Пауза» предназначена для заявок, которые требуют привлечения дополнительных команд.

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

Сотрудники службы поддержки работают только со своими заявками и следят за ними в разделе «Личное». Это позволяет им не отвлекаться на информационный шум.

Внутри карточек специалисты могут отставлять комментарии для пользователей:

• отправить заготовленный шаблонный ответ,
• запросить уточнения,
• отправить ответ на заявку.

Таким образом, сотрудник работает только внутри карточки, а пользователь получает ответы на почту или может посмотреть историю сообщений на портале.

Сами пространства со всеми заявками позволяют руководителю поддержки видеть общую картину. Например, если он видит, что карточка с высоким SLA находится в работе больше 2-х часов, значит, есть какая-то проблема и нужно подключиться.

Мы перешли на Kaiten с 1 декабря. И уже за первый месяц работы получили только положительные оценки работы сервисов.

На самом деле для заказчиков мало что изменилось:

• вид портала, на котором они оставляют заявки и могут мониторить их статус. В Kaiten сразу видно все категории заявок, а внизу можно посмотреть свой список текущих и прошлых обращений. В Jira приходилось проваливаться в меню и искать это дольше;
• появилась возможность подать более подробную заявку. Настраиваемые поля позволяют сразу уточнить необходимые детали и избежать недопонимания и лишних коммуникаций.

В остальном всё так же, как раньше. Мы старались сделать всё по аналогии с предыдущим сервисом, добавив лишь улучшения в категории заявок. Это сделало получение услуг легче.

Дальше в планах:

• добавить виджет с заявками пользователя на наш корпоративный портал;

• создать единую базу знаний для проектного офиса. То есть сделать единую точку входа для всех статей, которые сейчас разбросаны в нашем Confluence, Confluence заказчика и других источниках. В Kaiten для этого есть возможность создавать и импортировать документы, а также публиковать базу знаний по ссылке для внешних пользователей;
• интегрировать наш текущий Telegram-бот с Kaiten. У нас уже был разработан несложный бот для отправления заявок в Service desk, а у Kaiten это встроенная функция с возможностью посмотреть статус заявки, оставить комментарии и поставить оценку прямо в боте. Мы просто берем готовые функции и внедряем его к себе.
  

Интересно узнать, как работает служба поддержки в других компаниях. Поделитесь своим опытом в комментариях – какие сервисы используете, как приоритизируете заявки, как оцениваете работу специалистов?