Вы когда-нибудь задумывались над смыслом этого слова? Что оно значит для вас? Готов поспорить, что ответ на это вопрос будет на 100% зависеть от контекста! Но этого мало. Вам надо быть уверенным, что вы со своим собеседником одинаково понимаете не только контекст, но и значение этого термина. Если вы работаете в сфере ИТ и знакомы с ITIL, это не означает, что ваши клиенты будут воспринимать инцидент так же, как и вы. Для вас это незапланированное прерывание или деградация качества услуги, а для клиента инцидент — это событие, требующее присутствия полицейских.
Интерес к этой теме привлекает как тех, кто находится на стороне поставщика услуг, так и тех, кто находится на стороне потребителя. Рано или поздно мы все сталкиваемся с ситуацией, когда что-то пошло не так и требует вмешательства специалистов, коррекции или восстановления.
Не все торопятся обращаться в службу поддержки. Это касается не только сферы ITSM, но и ярко иллюстрируется нашим отношением к своему здоровью. Медицинский контекст обычно ярче и понятнее раскрывает и объясняет те же ситуации, которые происходят в ИТ-сфере. И если управление инцидентами нацелено на скорейшее восстановление нормальной работы услуг (такая вот “скорая помощь” с лечением симптомов, зачастую без понимания первопричин), то управление проблемами – это истинное “лечение” (с постановкой диагноза и терапией), призванное избавить наши услуги от инцидентов, желательно, качественно и надолго. Ну, а координацией этой деятельности занимается команда под названием Service Desk.
Как выстроить работу команды, как стать центром коммуникаций поставщика услуг со всеми пользователями, какие инструменты для этого потребуются, как оценить качество работы – это лишь неполный список вопросов, с которыми сталкиваются те, кто связывает свою жизнь с работой в Service Desk и является “лицом” и голосом ИТ.
Каждый раз, когда мне приходилось обращаться в службы поддержки, я всегда ждал, что это будет точка контакта с профессионалами, а не камень преткновения в решении возникших у меня вопросов. Ведь согласитесь, в службу поддержки обращаются чаще, когда требуется помощь, а не когда все прекрасно и хочется поделиться своим счастьем. Итак… Звонок, отклик, музыка в трубке и периодическое напоминание о том, что мой звонок очень важен… Независимо от того насколько хороша музыка, пользователям не понравится долгое ожидание ответа первого освободившегося оператора. Чем дольше ожидание, тем быстрее приходит понимание, что мой звонок не так важен, и создается негативное впечатление не только о работе службы поддержки, но и об ИТ-команде в целом.
Вот, 5 ошибок в работе команды Service Desk, которые на мой взгляд влияют на качество работы службы поддержки:
- Неправильно рассчитанная численность персонала первой линии поддержки или недостаточная квалификация сотрудников. Это приводит к избеганию или невозможности обработки поступающих звонков, созданию очередей, что влияет на удовлетворенность клиентов и приводит к потере обращений. Такая ситуация может быть отправной точкой для совершенствования: применения виртуальных помощников, чат-ботов, порталов самообслуживания, подбора и обучения персонала.
- Агенты Service Desk работают “для” клиента, а хотелось бы чтобы “с” клиентом. Идентификация себя с клиентом помогла бы агенту службы поддержки воспринимать проблемы клиента как свои, а это позволило бы воспринимать качество услуг с позиции клиента. Важно осознавать, что для клиента масштабность возникших трудностей может казаться значительнее, чем для агента службы поддержки, и это не должно отражаться на качестве обслуживания.
- В культуре команды преобладает взаимодействие вместо сотрудничества. Совместная и командная работа – это не одно и то же. Даже при внешнем тесном взаимодействии в команде, может оказаться, что люди работают в бункерах. Это касается не только взаимоотношений внутри службы поддержки, но и совместной работы с клиентами. Сплоченность и единая цель – повышает эффективность работы команды и повышает качество обслуживания клиентов.
- Привычка решать вопросы реактивно, а не проактивно. Установка инструментов мониторинга позволит реагировать на инциденты раньше, чем о них сообщат пользователи. Использование инструментов автоматизации позволит часть рутинных задач решать быстрее. Избегайте непроверенных, временных решений, которые потом все равно придется переделывать, но уже в режиме пожарной машины. Когда вы начинаете воспринимать экстренные ситуации как рутину и норму, вы тем самым неосознанно снижаете качество своей работы.
- Неверно подобранные метрики для оценки работы персонала. Метрики должны являться инструментами для достижения цели, а не самоцелью. Правильно выбранная цель может скорректировать вектор приложения усилий. Важно работать не много, а эффективно. Мы чаще оцениваем и восхищаемся умением исправлять, чем предотвращать трудности.
Опять напрашивается аналогия с медициной. Профессионализм в экстренной помощи почему-то ценится больше, чем профилактика и поддержание здоровья людей, хотя, казалось бы, должно быть все наоборот.
А как обстоят дела в вашей организации? Вы тоже вознаграждаете больше тех, кто “лечит”, чем тех, кто предотвращает “болезни”? Если вы ответили утвердительно, то самое время пересмотреть свои взгляды.
Где подробнее узнать о практиках мониторинга и управления событиями, управления инцидентами, проблемами, запросами на обслуживания, организации службы поддержки:
- В рамках подписки MyITIL
- На курсе VAP-Support
- В наших публикациях на портале Digital Enterprise
- В наших вебинарах.
Работа поддержки всегда будет актуальна и значима как для потребителя, так и для поставщика услуг, она влияет на формирование клиентского опыта и долгосрочность сервисных отношений. Умение говорить на одном языке с клиентом, понимать его трудности, проявлять эмпатию, быстро и эффективно решать проблемы – вот в чем заключается работа службы поддержки. Вне зависимости от того, что вкладывается в понятие проблема: любая возникшая сложность, или Проблема (Problem) – причина или потенциальная причина инцидента или инцидентов (произошедших, текущих или будущих).
Илья, доброго дня.
Не вдаваясь в обсуждение деталей хотелось бы заметить что от “гуру” ожидаешь нечто большего чем обычная декларация лозунгов.
На примере любого из пунктов (взял пятый):
Описание ошибки: Неверно подобранные метрики для оценки работы персонала.
Лозунг 1. Метрики должны являться инструментами для достижения цели, а не самоцелью.
Лозунг 2. Правильно выбранная цель может скорректировать вектор приложения усилий.
Лозунг 3. Важно работать не много, а эффективно.
Наблюдение 1. Мы чаще оцениваем и восхищаемся умением исправлять, чем предотвращать трудности.
Хотелось бы видеть от Вас конкретные советы (раз мы про SD говорим) по “правильным” метрикам для тех или иных ситуаций.