Привет, Хабр! В блоге ЛАНИТ хочу поделиться историей внедрения Service Desk, которая продолжается до сих пор, точно, как в анекдоте, что ремонт нельзя закончить, его можно только прекратить. Я не буду подробно описывать все этапы внедрения. Расскажу только, с какими проблемами мы сталкивались на этом пути и как мы их решали. Возможно, наш практический опыт внедрения окажется для вас полезным.
Почему мы решили внедрить Service Desk? Все очень просто: у нас работает свыше пятисот сотрудников, при этом в отделе поддержки всего семь системных администраторов, которые поддерживают центральный офис, три региональных офиса и складской комплекс. Наверное, как и многие другие, мы сталкивались с тем, что не понимали, как управлять обращениями пользователей и не знали наверняка, какое оборудование установлено у пользователей, какие лицензии ПО они используют и как часто сбоит или выходит из строя то или иное оборудование. В общем, тушили пожары по мере их возникновения. Единственный выход из этой ситуации видели в том, чтобы все взять под свой контроль.
Проблема №1. Выстроить процессы лучше до выбора системы
Мы думали, что достаточно выбрать соответствующий продукт, как все наладится, совершенно забыв про такую банальную вещь, как построение оптимальных процессов. Правда, здесь нужен разумный компромисс. С одной стороны, автоматизировать хаос невозможно, с другой, – не нужно вылизывать все процессы до идеального состояния, поскольку в жизни все часто меняется и любой продукт все равно предложит свою схему функционирования, которую можно принять за основу. Поэтому мы сделали следующее.
1. Выделили почтовый адрес и номер телефона для приема обращений пользователей.
2. Разработали структуру таблицы для внесения всех обращений в файл Excel.
3. Определили пару простых справочников: виды обращений (ошибка/задача) и виды проблем (с рабочими местами, информационными системами, почтой и интернетом).
После этого оповестили всех пользователей о проведенных изменениях. Пользователи стали писать на выделенный адрес. Мы анализировали их письма, суть обращения вносили в файл Excel, указывали статус «В работе». После выполнения заявки суть решения также вносили в файл Excel и меняли статус на «Выполнено». Увидели, что стало намного лучше. Только после этого начали выбор продукта. Не буду про это долго рассказывать, так как выбирали на основе заданных критериев из продуктов, имеющихся на рынке в тот момент. Стоимость лицензий и необходимых доработок также была существенным фактором. В итоге выбрали российский продукт и начали его внедрение.
Совет: не пренебрегайте подготовительным периодом. Лучше минимально привести в порядок текущие процессы и построить хотя бы минимальный учет обращений в Excel, чтобы было от чего отталкиваться.
Проблема №2. Когда хочешь все и сразу, это не всегда получается
Мы решили сразу настроить продукт до идеального состояния. Поскольку мы с ним раньше не работали, процесс изучения и настройки занял слишком много времени. Пользователи даже перестали спрашивать, когда будут изменения, а мы начали потихоньку выгорать. Лучше было настроить все процессы по умолчанию и быстро запустить, чтобы пользователи привыкли и начали им активно пользоваться.
Совет: не старайтесь сделать все сразу на 5. Правило быстрых побед никто не отменял.
Проблема №3. Лучше сразу информировать пользователей о всех изменениях
Продукт допускал создание обращений либо в web-интерфейсе, либо по почте, что для пользователей было гораздо привычнее. Мы оставили прежний почтовый адрес для приема обращений, но теперь входящие письма обрабатывал «робот». Он был настроен следующим образом: каждое письмо с темой, в которой отсутствовал номер заявки, он считал новым обращением. Если же в теме письма был номер заявки, «робот» прикреплял текст письма к заявке с этим номером в виде комментария. Пользователи же думали, что общаются с живым человеком и вступали с ним в многочисленные переписки, часто не отвечая на предыдущее письмо, а посылая новые с новой темой. Естественно, что «робот» воспринимал эти письма как новые обращения. Нас завалил шквал ложных заявок, и мы поняли, что лучше было сделать новый почтовый адрес и оповестить (и не один раз!) пользователей о правилах подачи обращений по почте.
Совет: всегда рассчитывайте на худшее. Если что-то может пойти не так, обязательно пойдет. И не забывайте о постоянном информировании пользователей обо всех изменениях.
Проблема №4. Дайте возможность сотрудникам проявлять инициативу
Мы думали, что лучше всего назначать исполнителей по заявкам, обращая внимание на квалификацию и загруженность. Выделили диспетчера, который обрабатывал входящие заявки и назначал исполнителей. В итоге оказалось, что одни были недогружены, а другие – перегружены. К тому же это не стимулировало сотрудников развиваться, поскольку им всегда назначались схожие по теме и сложности заявки. Решили перейти на другую схему, когда заявки попадали в очередь в группе исполнителей, а там системные администраторы сами разбирали заявки «по вкусу» или по договоренности друг с другом. Системные администраторы начали понимать, какой квалификации им не хватает, стали учиться, к тому же загрузка исполнителей в итоге выровнялась. В общем, ставка на доверие к людям оправдала себя.
Совет: подходите критически к схемам «по умолчанию» или «лучшей практике», которая рекламируется в специализированных изданиях. Выбирайте тот вариант работы, который будет лучшим именно для вас и ваших условий. И не забывайте, что среди системных администраторов тоже нужно проводить разъяснительную работу.
Проблема №5. Не забывайте о коммуникациях с пользователями
Как организовать информирование пользователей о ходе решения заявки? С помощью уведомлений. В системе было предусмотрено восемнадцать (!) уведомлений.
1. Регистрация новой заявки в Service Desk
2. Истечение 90% от срока рассмотрения заявки
3. Истек срок рассмотрения заявки
4. Заявка взята на рассмотрение
5. Отмена заявки
6. Поступление заявки в группу исполнителей
7. Назначение исполнителя заявки
8. Перевод заявки исполнителем из статуса «В работе» в статус «Отложено»
9. Возврат заявки исполнителем из статуса «Отложено» в статус «В работе»
10. Перевод заявки в статус «Вопрос пользователю»
11. Новое сообщение по заявке
12. Возврат в работу после ответа пользователя
13. Перевод заявки на третью линию
14. Возврат заявки из третьей линии
15. Истечение 90% от срока выполнения заявки
16. Истек срок выполнения заявки
17. Выполнение заявки исполнителем
18. Восстановление заявки пользователем
Естественно, мы решили использовать их все. Заполнили красивые шаблоны уведомлений в корпоративном стиле и активировали их для всех пользователей. Пару месяцев было тихо, но потом пользователи просто завалили нас просьбами присылать только самые важные уведомления и упростить их тексты, оставив только значимую для них информацию. Хотя мы в душе и сопротивлялись этому, но были вынуждены согласиться. В итоге оставили только четыре самых важных для пользователей уведомления.
1. Поступление новой заявки в Service Desk
2. Отмена заявки
3. Новое сообщение по заявке
4. Выполнение заявки исполнителем
Тексты уведомлений были предельно упрощены, в том числе размер и цвет шрифта. Пользователи были удовлетворены.
Совет: не думайте, что пользователям интересны все стадии обработки заявок. Какими бы вы продвинутыми ни были, лучше заранее узнайте у пользователей, что важно именно для них и сделайте это. Вы получите понимание и поддержку с их стороны.
Проблема №6. Лучше использовать простую и понятную пользователям терминологию
Мы решили заполнить портфель сервисов по максимуму и с точки зрения ИТ-специалистов. Например, мы назвали один из сервисов так: «Системы коммуникации между сотрудниками». Пользователи не понимали, что это такое, поэтому мы решили назвать все сервисы попроще, так, чтобы было понятно пользователям: «Почта», «Телефония», «Интернет» и т.д. Единственный момент, на который я бы хотел обратить внимание. Например, сначала мы назвали один из сервисов, который наиболее часто используется пользователями, «Рабочие места» и элемент сервиса – «Рабочее место». Но столкнулись с тем, что исправление проблем, связанных с ПК, мониторами, клавиатурами и мышками, входящими в рабочее место, занимает совершенно разное время. Поэтому пришлось назвать элементы сервиса по видам оборудования: «ПК», «Монитор» и т.д. Обращайте на это внимание, потому что к сервисам и его элементам будут потом привязаны параметры SLA.
Совет: называйте сервисы и его элементы как можно проще и понятнее, но не в ущерб здравому смыслу, иначе потом возможно недопонимание с пользователями с точки зрения временных параметров решения проблем.
Проблема №7. Попробуйте взглянуть на ваши процессы с точки зрения пользователя
Мы перешли к определению параметров SLA. Мы установили временные параметры восстановления работы оборудования с помощью экспертных оценок времени, которое требуется опытному системному администратору на решение проблемы. После этого столкнулись с тем, что время, которое требуется специалисту для ремонта, совершенно не устраивает пользователей, поскольку они не могут ждать. Поэтому все, что можно заменить, мы стали менять, а ремонт проводить позже в спокойном режиме. Так что параметры SLA все-таки нужно устанавливать с учетом ожиданий пользователей, но без фанатизма.
Совет: всегда учитывайте мнение пользователей, пытайтесь встать на их место и корректируйте свои параметры с учетом этого фактора. Да, возможно, вам придется что-то дополнительно предпринять. Например, мы были вынуждены составить список часто заменяемого оборудования, которое должно постоянно находиться на нашем офисном складе в определенном количестве.
Проблема №8. Следите за выполнением договоренностей с пользователями
Параметры SLA мы настроили. И с чем столкнулись? Исполнителям стали поступать срочные заявки, которые приходилось брать в работу, откладывая текущие. Был, конечно, настроен режим «Отложить заявку», но таймер оставался включенным, соответственно, возникали нарушения SLA. Тогда мы решили внести изменения в схему рабочего процесса выполнения заявок и при выборе режима «Отложить заявку» стали останавливать таймер, а при выходе из него – включать. Нарушения SLA исчезли, пользователи стали понимать, что их заявка отложена по какой-либо причине и на это время таймер выключен.
Совет: тщательно продумывайте, в каких статусах заявок таймер включается, в каких – останавливается. Таким образом, вы избежите нарушений SLA и потенциально конфликтных ситуаций.
Проблема №9. Не забывайте о подтверждении выполнения заявки
Когда исполнитель выполнял заявку, он ее сразу закрывал. Пользователь узнавал об этом, когда ему по почте приходило уведомление о закрытии заявки. Некоторые пользователи не обращали на это внимание, но большинство бросалось проверять. Как правило, все было выполнено так, как надо, но в некоторых случаях пользователь понимал, что его проблема не решена. Приходилось писать об этом в поддержку и диспетчер восстанавливал заявку. На это уходило время, поэтому мы решили, что исполнитель всегда при выполнении заявки не закрывает ее, а пишет пользователю сообщение с просьбой проверить заявку и только после подтверждения закрывает ее.
Совет: всегда просите пользователей проверить выполнение заявки. Иначе нерешенная проблема «всплывет» в самый неподходящий момент и вам придется срочно ее решать, при этом мнение пользователей о работе поддержки будет ухудшаться. Этого нужно избегать.
Проблема №10. Дайте возможность пользователю оценить вашу работу
Сначала мы оценивали работу исполнителей по двоичной системе – решил/не решил. С одной стороны, вроде бы этого достаточно. Но как оценить, как исполнитель решал ее, как общался с пользователем во время решения? Это же тоже важно. Мы пришли к тому, что после выполнения заявки будем высылать пользователю предложение оценить работу исполнителя. Да, большинство это письмо игнорировало, но некоторые отвечали и выставляли оценки по пятибалльной шкале. Таким образом, мы узнали, кто лучше работает, кому пользователи с удовольствием выставляли максимальные оценки. Правда, здесь надо иметь в виду, что минимальные оценки могли выставить за совершенно посторонние вещи, например, как исполнитель выглядит (да, бывает и такое!). Поэтому все минимальные оценки обязательно проговаривались с пользователем, и в зависимости от результата разговора принимались (или не принимались) соответствующие меры.
Совет: предлагайте пользователю оценивать работу исполнителей. Вы получите значимую статистику результатов работы сотрудников отдела поддержки. Но помните, что минимальные оценки не всегда свидетельствуют о каких-то проблемах иногда они говорят о совершенно посторонних вещах, о которых, тем не менее, желательно узнавать и правильно реагировать. Мнение пользователей – это важная составляющая в работе отдела поддержки.
Проблема №11. Отчеты – незаменимые помощники в управлении сотрудниками
Невозможно понять, что происходит в системе, если нет отчетов. Конечно, в выбранном продукте они имелись и, наверное, даже неплохие. Особенно нас впечатлили дашборды, для своего времени они производили впечатление – вся нужная информация на одном экране, постоянно обновляется, да еще красочно представлена! Но нам это показалось неудобным, да и скорость формирования отчетов могла бы быть лучше. Поскольку у нас имелся опыт работы с MS SQL Server, мы решили изучить структуру БД и написать свои запросы, которые легли в основу отчетов. После этого мы создали файлы Excel, информация в которых обновлялась в соответствии с данными в запросах. Во-первых, мы таким образом получили стандартное и гибкое средство представления информации с возможностью формирования любых аналитических срезов, во-вторых скорость формирования отчетов существенно возросла, потому что наши запросы были серьезно оптимизированы.
Совет: не бойтесь критически подойти к отчетам, предоставляемым в продукте. Как правило, они рассчитаны на нетребовательных пользователей, которым нужно быстро просмотреть имеющийся отчет. Если вам нужно больше, создавайте отчеты сами.
Проблема №12. Старайтесь объективно оценивать своих сотрудников
Мы подошли к KPI исполнителей. Как оценивать их работу? Признаюсь, сначала мы хотели использовать максимальное количество различных KPI. Кратко их перечислю.
1. Среднее время первого ответа
2. Среднее время ответа
3. Среднее время обработки заявки
4. Общее количество заявок
5. Количество просроченных заявок
6. Доля нарушения времени реакции на обращение
7. Доля нарушения времени выполнения заявок
8. Доля решенных заявок
9. Доля заявок, которые были закрыты в ходе первого обращения
10. Уровень удовлетворенности клиентов
Скажу честно, мы были удивлены таким количеством KPI, предлагаемых в специализированных изданиях. Неужели они все необходимы? Мы стали их исследовать путем накопления статистики и анализа результатов. Кстати, хочу высказать свое личное мнение. Лучше те метрики, которые не только объективны, но и понятны исполнителям и мотивируют их улучшать свою работу. Поэтому не нужно гнаться за большим количеством метрик, вы их все равно будете использовать только для себя. Мы остановились на следующих метриках:
-
доля нарушения времени выполнения заявок;
-
уровень удовлетворенности клиентов.
Первая метрика однозначно характеризуют степень выполнения SLA. Как вы помните, мы утвердили параметры SLA с помощью экспертных оценок и с учетом потребностей пользователей. Поэтому их нарушение – объективный повод для разбирательств. При этом надо понимать, что высокая доля нарушения времени выполнения заявок вовсе не характеризует загрузку исполнителя, потому что он берет из очереди те заявки, с которыми будет работать в данный момент, при этом он всегда может заявку отложить. Время нахождения заявок в очереди и в статусе «Отложено» для этой метрики не учитывается. Вторая метрика выясняется с помощью опросов пользователей по факту выполнения заявки. Все эти метрики конкретны и подкреплены фактами, с которыми можно разбираться. Я вовсе не хочу сказать, что остальные метрики не нужны. Просто для нас они оказались либо малозначимы, либо причины, приведшие к их нарушению, очень часто имели субъективный характер.
Совет: метрики обязательно нужны, но их выбор зависит целиком от вас и ваших принципов работы, а также от взаимопонимания с пользователями. С метриками точно как в известной фразе: «Лучше меньше, да лучше!».
Важное дополнение про объективную оценку работы сотрудников
Здесь мне хотелось бы подробнее рассказать про те показатели работы сотрудников, которые мы посчитали целесообразным использовать для их оценки. И это не только про KPI исполнителей как таковых, но и в целом про сотрудников отдела поддержки. Хочу заметить, что я достаточно прохладно отношусь к попыткам математически оценивать работу сотрудников. Да, пара-тройка метрик, рассчитываемых на основе данных из системы, имеют право на жизнь. Но гораздо интереснее те показатели, которые объективно влияют на квалификацию сотрудников, их отношение к работе, на создание атмосферы взаимовыручки и, в конце концов, на настроение сотрудников в отделе.
Мы используем следующие показатели.
-
Достижение целей.
-
Выполнение непрофильных функций.
-
Личные достижения:
а) работа в сложных условиях;
б) обретение новых навыков;
с) наставничество.
Остановлюсь на них подробнее.
Достижение целей – здесь мы каждый квартал определяем цели, которые сотрудник хочет (и может) достичь. Например, цель – количество просроченных заявок не должно превышать 3%. Есть ежедневный отчет, который позволяет сотруднику следить за достижением этого показателя.
Выполнение непрофильных функций – здесь сотрудник может взять на себя то, что не входит в его прямые обязанности, но необходимо для работы всего отдела. Например, курирование ИТ-склада в офисе, контроль за остатками оборудования, маркировка оборудования, установленного у пользователей, проведение инвентаризаций.
Работа в сложных условиях – здесь мы учитываем авралы или срочные задания, которые сотрудник берет на себя или участвует в решении. Отслеживается результат работы сотрудников в стрессовой ситуации, инициатива и взаимовыручка. Например, недавно наша бухгалтерия переезжала в новые помещения в очень сжатые сроки. Все сотрудники помогали, чем могли, даже в нерабочее время, потому что это нужно было сделать быстро и без ущерба для текущей работы.
Обретение новых навыков – здесь все сотрудники каждый квартал составляют список тем, которые они хотят освоить и в которых заинтересован отдел в целом. Например, редактирование почтовых рассылок, блокировка учетных записей, настройка переговорных комнат. Ну и более сложные темы: администрирование серверов на базе Linux, администрирование почтового сервера, освоение PowerShell, настройка видеонаблюдения и СКУД и т.п.
Наставничество – по понятным причинам, это не так часто требуется, текучка в отделе в последние годы практически отсутствует. Но когда приходили новые сотрудники, опытные товарищи с удовольствием брались за их обучение и следили за ними не только в течение испытательного срока, но и позже, как правило, до одного года. После этого сотрудник мог считаться полностью подготовленным к самостоятельному выполнению заявок.
Резюме
После внедрения ситуация с заявками в нашей компании ожидаемо изменилась в лучшую сторону.
Во-первых, мы взяли ситуацию под свой контроль, стали понимать, сколько заявок в работе, какие ошибки и проблемы происходят, причины их появления стало возможным анализировать, что привело к предупреждению наиболее часто возникающих ошибок.
Во-вторых, заявки стали выполняться быстрее, доля просроченных заявок уменьшилась с 25-30% до 5%.
В-третьих, наши отношения с пользователями улучшились, ситуация с заявками стала прозрачной, пользователи стали больше нам доверять, что и показали результаты последнего опроса – уровень удовлетворенности клиентов достиг 97%. В общем, можно признать, что мы добились своих целей. Но здесь нужно не забывать, что процесс внесения улучшений в работу не должен останавливаться.
Надеюсь, моя статья была вам полезной. Хочу пожелать всем тем, кто собирается внедрять Service Desk, не только знать теорию, следовать ей, но и анализировать практические результаты, не бояться что-то делать по-своему. Ведь результат внедрения – удовлетворение от своей работы и положительные оценки пользователей, ради которых это все и делается. Всем спасибо, кто прочитал, и жду ваших комментариев!
Статья написана в рамках Хабрачелленджа 2.0, который прошел весной 2024 года.
ссылка на оригинал статьи https://habr.com/ru/articles/819637/
Добавить комментарий