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

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

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

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

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

Мы с коллегами пришли к выводу, что делать два регламента управления инцидентами попросту глупо. Ведь обслуживанием-то будут заниматься одни и те же люди. Что же, они положат перед собой два документа и будут попеременно смотреть то в один, то в другой? Скрещивать два окна ведения инцидентов и гадать, какой устранять в первую очередь? Веселая картина, не правда ли?

Куда смотрит современный человек, если ему надо сделать что-то, чего он раньше не делал? Правильно, в Интернет. Но что-либо путное по указанной теме там обнаружить не удалось. Нельзя сказать, что для меня это стало большой неожиданностью. По мере развития Интернета он всё больше напоминает огромный шкаф, забитый хламом, в котором найти нужную вещь практически невозможно.

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

Каналы поступления заявок на устранение инцидентов

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

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

Классификация пользователей и приоритизация инцидентов

Некоторые сложности может вызвать и общая (сквозная) классификация пользователей. С одной стороны, «клент всегда прав», поэтому запросы внешних пользователей на устранение инцидентов надо обрабатывать в первую очередь и, следовательно, внешние пользователи имеют более высокий приоритет. С другой — если собственный сотрудник занят устранением инцидента и не может продолжить эти работы, его запрос должен иметь более высокий приоритет, чем тот, которым он занимается. Получается, что принцип приоритизации запросов на устранение инцидентов должен не только учитывать тип пользователя, срочность и важность, но и проверять такие зависимости. То есть если необходимо устранить инцидент, возникший у специалиста, занятого устранением инцидента внешнего пользователя, то первый инцидент должен иметь более высокий приоритет, чем второй.

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

  1. Существенно выросло количество запросов на устранение инцидентов, с одной стороны, из-за увеличения количества пользователей, а с другой — в связи с ростом требовательности пользователей к качеству ИТ-сервисов.

  2. Поддержка сервисов становится все более сложной и индивидуализированной из-за усложнения как общей архитектуры предприятия, так и его ИТ-архитектуры.

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

Вторичные преимущества

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

Психологически работа по обслуживанию пользователей непроста. Сотрудники всех линий поддержки, и прежде всего сервис-деска, имеют дело с недовольными, раздраженными пользователями. Вполне естественно в ответ у них возникает озлобленность против «этих бестолковых пользователей, которые всё сами ломают и даже не могут объяснить, что сломали». Для того чтобы устранить подобные конфликты придумано множество психологических упражнений, таких как расстановки, социодрама, и т. д. Цель этих упражнений состоит в том, чтобы поменять участников конфликта ролями, заставить их встать на место «противника». И успех таких упражнений несомненен. В ситуации, когда специалисты службы поддержки одновременно становятся ее пользователями, позволяет им без дополнительных ухищрений встать по другую сторону «баррикад». То есть их анализ и предложения по улучшению организации обслуживания пользователей, если, конечно, их учитывать, анализировать и внедрять, будут просто бесценны.

Заключение

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

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

  • повысить производительность работы сотрудников за счет оперативной обработки их запросов;

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

И тогда, наконец, поговорку «сапожник без сапог» нельзя будет применить к ИТ-службе.

Опубликовано 27.06.2022

Похожие статьи