10 проблем на первой линии поддержки и пути их решения
Решение использовать систему Service Desk связано с довольно типичными ожиданиями от пользователей системы, специалистов, обеспечивающих техподдержку, а также владельцев бизнеса.
Давайте разбираться в этих ожиданиях и проблемах, возникающих при их пересечении. Будем рассматривать систему, где доступ от заказчика к специалистам второй линии возможен только через специалистов первой линии.
Ожидания пользователя обычно можно сформулировать следующим образом: «У меня возникла проблема, я ее озвучил кому-то или куда-то, ее решили немедленно (или время решения стремится к нулю)».
Отсюда сразу же возникает первая проблема организации поддержки:
Удобство доступа пользователя к службе поддержки
При организации удобной службы технической поддержки пользователь должен четко знать, где и в каком виде оставлять заявку. Часто пользователю проще взять телефон и позвонить тому специалисту, которого он знает или к которому обращался ранее. В таком случае может возникнуть потеря заявок или перегруженность какого-либо специалиста первой линии. Очевидным решением этой проблемы является разработка инструкции для пользователя. Инструкция должна в себя включать:
- перечень каналов связи с техподдержкой;
- описание процедуры регистрации пользователя в системе;
- способы создания заявки;
- классификация заявок по типам и важности;
- способы отслеживания статуса заявки;
- дополнительные возможности (редактирование, добавление вложений, комментариев).
Грамотная инструкция призвана упростить процесс подачи и приема заявки первой линией, но не каждый пользователь будет действовать строго по инструкции, особенно если это требует от него дополнительных усилий. Поэтому ключевым моментом во взаимодействии пользователя с оператором первой линии является удобство интерфейса.
Удобство интерфейса
Для того, чтобы не возникали проблемы типа: «пользователь не предоставил всю нужную информацию», «пользователь некорректно заполнил данные по заявке», «пользователь совсем не смог оставить заявку», интерфейс системы должен включать все необходимые специалисту поля, но при этом не запутывать заказчика. Часто серьезным барьером для использования системы является язык интерфейса. Кроме этого, необходимо продумать наличие обязательных полей, снабдить их подсказками, проверкой на корректность ввода. В некоторых системах техподдержки этот инструментарий доступен «из коробки». Нужно только потратить время на грамотное планирование интерфейса и его настройку. Хорошо, когда большинство полей при оформлении заявки пользователь может заполнить путем выбора из списка и для каждого типа заявки есть свой набор полей.
Интерфейс портала Service Desk со стороны пользователя
Поля, заполняемые пользователем при оформлении заявки в техподдержку
После того, как пользователь выполнил все, что от него требуется при оформлении заявки, он ожидает реакцию. Отсюда возникает следующая проблема.
Быстрое решение проблемы или обратная связь с пользователем
Очевидно, что основным критерием качества работы службы техподдержки является время решения задач. И здесь очень важную роль играет автоматизация обратной связи с пользователем. Ведь одно дело, когда заявка отправляется в недра какого-то «черного ящика» и пользователь вынужден находиться в томительном ожидании. И совсем другое, когда пользователь получает немедленный отклик и его ставят в известность при любых действиях по его проблеме. Однако не всегда ресурсы технических специалистов позволяют уделять внимание вежливому общению, да и просто вовремя брать заявки в работу в период большой загрузки.
Здесь на выручку приходит автоматизация. При оформлении заявки заказчик должен получать, как минимум, письмо о том, что заявка поступила в работу. А также письма при изменении статуса заявки. При желании, он может отказаться от этой рассылки, а может добавить комментарии или вложения к своей заявке. Таким образом, у пользователя не будет ощущения, что его «бросили».
Конечно же кроме писем заказчику, автоматизация должна подразумевать одновременное оповещение операторов первой линии. Задача действительно не должна «повиснуть в воздухе». Для этого в системе должны быть:
- явно указаны ответственные за прием заявок специалисты;
- прописан четкий регламент работы с новой заявкой;
- оговорено время реакции на новую заявку;
- автоматизированы оповещения ответственным лицам;
- автоматизировано назначение ответственных за заявку при переводе ее в другой статус;
- настроена аналитика с явным указанием критических по сроку выполнения заявок.
Настройка автоматических оповещений
При наличии всех этих пунктов можно избежать потери задач, а следовательно, увеличения времени их решения при передаче от специалиста первой линии к специалисту второй линии или при ожидании дополнительной информации от заказчика.
Теперь рассмотрим ожидания специалиста первой линии.
Что ожидает оператор: четкое описание проблемы; возможно, перечень действий, приводящих к проблеме; описание окружения пользователя; историю инцидентов. Это позволит ему без лишних затрат времени приступить к выполнению заявки. Разберем, какие проблемы возникают с этими ожиданиями.
Сбор информации
Оператору первой линии очень хотелось бы собрать максимум информации от пользователя, задав минимум вопросов. А также избежать ошибок в ответах пользователей на вопросы, в которых они могут быть некомпетентны.
Для решения этой задачи хорошо подходят системы мониторинга или CMDB-системы. Использование такой системы предполагает создание хранилища всей информации об ИТ-среде компании. Это хранилище должно содержать в себе информацию об:
- рабочих станциях пользователей;
- используемом ПО, версиях, лицензиях;
- периферийном оборудовании;
- серверах;
- облачных сервисах.
Интеграция CMDB-системы с системой сервис деска будет хорошим решением для повышения эффективности работы первой линии техподдержки.
Примеры CMDB-систем: Nagios, Zabbix, Zenoss, OpenNMS. Рассмотрение этих систем — тема для отдельной статьи.
Следующая проблема первой линии —отсутствие информации по подобным заявкам, что особенно проявляется при поступлении на работу нового сотрудника — оператора первой линии.
База знаний для специалистов первой линии
Правильное ведение базы знаний повышает уровень своевременного и качественного решения задач на первой линии. Помогает вводить в курс дела менее компетентных сотрудников. Кроме того, можно создавать статьи с ответами на часто возникающие вопросы пользователей.
Но, чтобы база знаний приносила пользу, при ее создании необходимо учитывать несколько основных моментов:
- Удобство пользования базой знаний: интерфейс должен быть максимально простым, а организационная структура логичной и понятной.
- Модерация статей перед публикацией: нужно избегать перегруженности базы знаний, а также не допускать появления дубликатов.
- Контроль версий: должна быть возможность редактировать статьи, вносить актуальные правки.
- Возможность подачи заявки на необходимые статьи или разделы.
Единая точка входа
Оператор первой линии часто сталкивается с тем, что заявки поступают по различным каналам и не в формализованном виде. Следствием этого могут быть потерянные, незарегистрированные заявки, неравномерная загрузка операторов.
Каналы поступления заявок
Чтобы этого избежать, нужно создавать единую точку входа. То есть все операторы принимают заявки с одного общего почтового ящика, портала или одного номера телефона. В идеале задачи с почты или портала могут даже распределяться ответственным лицам автоматически в соответствии с политикой и правилами, принятыми в компании.
Далее рассмотрим ситуацию, когда специалисты первой линии не могут справиться с заявкой и вынуждены привлекать специалистов второй линии или сотрудников других отделов и департаментов.
Эскалирование задачи
Часто возникает такая ситуация, при которой заявка, ушедшая дальше с первой линии техподдержки, просто теряется. Такое может произойти, если первая линия, передавая заявку, перестает быть ответственной за нее, а специалисты второй линии, выполнив свою часть работы, не переводят задачу обратно или эскалируют ее дальше, но без назначения другого ответственного. Таким образом, задача «гуляет» между специалистами, оператор первой линии про нее давно забыл, а заказчик никак не дождется решения вопроса.
Для того, чтобы таких ситуаций не возникало, можно предложить сценарий распределения ролей таким образом, что специалист первой линии, принявший заявку, будет ответственным за нее до ее окончательного разрешения. Кроме того, чтобы не тратить время на поиски специалистов второй линии, можно настраивать автоматическое назначение заявки человеку при переводе ее в другой статус.
Конечно, предварительно придется потратить время на продумывание workflow-задачи и настройку системы сервис деска соответствующим образом.
Пример workflow для заявки, попавшей на первую линию
SLA и просроченные задачи
В работе специалистов первой линии бывают такие моменты, когда вся нагрузка становится критической, сроки выполнения по многим заявкам поджимают в одно и то же время, ресурсов не хватает, пользователи недовольны, внимание оператора снижается, возникают ошибки.
Критические ситуации не должны падать как снег на голову. В идеале они вовсе не должны возникать, но если уж такая вероятность есть, то лучше, чтобы система предупредила заранее о приближающихся проблемах.
Для этого, как минимум, надо настроить адекватные SLA (Service Level Agreement), создать отчеты для просмотра статистики по выполнению этих SLA. Не лишним будет создание собственного отчета, показывающего, сколько существует просроченных задач и сколько их намечается в ближайшее время.
Можно настраивать предупреждающие оповещения, но только в случае, если специалисты техподдержки не перегружены оповещениями различного типа и это действительно поможет им оперативно реагировать.
Ожидания владельца бизнеса, как и руководителя ИТ-отдела, состоят в повышении эффективности работы техподдержки, снижении стоимости ИТ-инфраструктуры, а следовательно, здесь очень важными будут возможности анализа.
История инцидентов
Для специалистов первой линии очень важно не просто отрабатывать очередь заявок, а еще и классифицировать их по типам. Благодаря этому можно увидеть, какие из заявок чаще возникают. Например, если это неполадки в работе оборудования, то на основе таких данных можно принять решение о смене оборудования, предварительно проанализировав стоимость такого решения. Бывает, что некоторые типичные заявки можно исключить, приняв некоторые организационные меры на предприятии. В любом случае наличие структурированной истории инцидентов предоставляет большие возможности для анализа и поиска эффективных решений.
Однако суть проблемы в том, что кто-то должен заниматься классификацией заявок. Конечно, логичнее всего поручить эту обязанность специалистам первой линии. Чтобы не слишком усложнять процесс принятия заявки, интерфейс системы должен позволять использовать различные шаблоны или метки для разных типов задач. В таких системах обычно есть возможность настраивать различные workflow для каждого типа заявки, что еще больше упростит работу оператора.
Если же система не содержит такой функционал, для первой линии техподдержки, а возможно, и для пользователя придется прописывать инструкции, в которых будут определены присваиваемые типы заявок и правила оформления описательной части заявки.
Прочие возможности анализа
Владельцу бизнеса хочется контролировать эффективность службы поддержки, а службе поддержки хочется обосновать собственное существование и показать загрузку операторов, качество их работы.
Здесь на выручку обеим сторонам приходят самые разнообразные отчеты. Например, можно отслеживать скорость реакции, выполнение SLA, процент решения задач на первой линии, загрузку каждого из операторов, наиболее эффективного специалиста и так далее.
Настройка таких отчетов обычно тоже ложится на плечи специалистов техподдержки, но занимает, как правило, немного времени при использовании таких систем, как Jira. И дает ясную картину слабых мест и резервов эффективности.
Резюме
Подытожив все вышеизложенное, можно сказать, что основные проблемы первой линии техподдержки можно разрешить путем внедрения подходящей системы сервис деска, интеграции ее с системами мониторинга и базами знаний. Кроме того, необходимо потратить время на планирование работы, соответствующую настройку всех систем и разрешение организационных вопросов.
