Портал №1 по управлению цифровыми
и информационными технологиями

Инцидент – как много в этом слове…

Вы когда-нибудь задумывались над смыслом этого слова? Что оно значит для вас? Готов поспорить, что ответ на это вопрос будет на 100% зависеть от контекста! Но этого мало. Вам надо быть уверенным, что вы со своим собеседником одинаково понимаете не только контекст, но и значение этого термина. Если вы работаете в сфере ИТ и знакомы с ITIL, это не означает, что ваши клиенты будут воспринимать инцидент так же, как и вы. Для вас это незапланированное прерывание или деградация качества услуги, а для клиента инцидент — это событие, требующее присутствия полицейских.

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

Не все торопятся обращаться в службу поддержки. Это касается не только сферы ITSM, но и ярко иллюстрируется нашим отношением к своему здоровью. Медицинский контекст обычно ярче и понятнее раскрывает и объясняет те же ситуации, которые происходят в ИТ-сфере. И если управление инцидентами нацелено на скорейшее восстановление нормальной работы услуг (такая вот “скорая помощь” с лечением симптомов, зачастую без понимания первопричин), то управление проблемами – это истинное “лечение” (с постановкой диагноза и терапией), призванное избавить наши услуги от инцидентов, желательно, качественно и надолго. Ну, а координацией этой деятельности занимается команда под названием Service Desk.

Как выстроить работу команды, как стать центром коммуникаций поставщика услуг со всеми пользователями, какие инструменты для этого потребуются, как оценить качество работы – это лишь неполный список вопросов, с которыми сталкиваются те, кто связывает свою жизнь с работой в Service Desk и является “лицом” и голосом ИТ.

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

Вот, 5 ошибок в работе команды Service Desk, которые на мой взгляд влияют на качество работы службы поддержки:

  1. Неправильно рассчитанная численность персонала первой линии поддержки или недостаточная квалификация сотрудников. Это приводит к избеганию или невозможности обработки поступающих звонков, созданию очередей, что влияет на удовлетворенность клиентов и приводит к потере обращений. Такая ситуация может быть отправной точкой для совершенствования: применения виртуальных помощников, чат-ботов, порталов самообслуживания, подбора и обучения персонала.
  2. Агенты Service Desk работают “для” клиента, а хотелось бы чтобы “с” клиентом. Идентификация себя с клиентом помогла бы агенту службы поддержки воспринимать проблемы клиента как свои, а это позволило бы воспринимать качество услуг с позиции клиента. Важно осознавать, что для клиента масштабность возникших трудностей может казаться значительнее, чем для агента службы поддержки, и это не должно отражаться на качестве обслуживания.
  3. В культуре команды преобладает взаимодействие вместо сотрудничества. Совместная и командная работа – это не одно и то же. Даже при внешнем тесном взаимодействии в команде, может оказаться, что люди работают в бункерах. Это касается не только взаимоотношений внутри службы поддержки, но и совместной работы с клиентами. Сплоченность и единая цель – повышает эффективность работы команды и повышает качество обслуживания клиентов.
  4. Привычка решать вопросы реактивно, а не проактивно. Установка инструментов мониторинга позволит реагировать на инциденты раньше, чем о них сообщат пользователи. Использование инструментов автоматизации позволит часть рутинных задач решать быстрее. Избегайте непроверенных, временных решений, которые потом все равно придется переделывать, но уже в режиме пожарной машины. Когда вы начинаете воспринимать экстренные ситуации как рутину и норму, вы тем самым неосознанно снижаете качество своей работы.
  5. Неверно подобранные метрики для оценки работы персонала. Метрики должны являться инструментами для достижения цели, а не самоцелью. Правильно выбранная цель может скорректировать вектор приложения усилий. Важно работать не много, а эффективно. Мы чаще оцениваем и восхищаемся умением исправлять, чем предотвращать трудности.

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

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

Где подробнее узнать о практиках мониторинга и управления событиями, управления инцидентами, проблемами, запросами на обслуживания, организации службы поддержки:

Работа поддержки всегда будет актуальна и значима как для потребителя, так и для поставщика услуг, она влияет на формирование клиентского опыта и долгосрочность сервисных отношений. Умение говорить на одном языке с клиентом, понимать его трудности, проявлять эмпатию, быстро и эффективно решать проблемы – вот в чем заключается работа службы поддержки. Вне зависимости от того, что вкладывается в понятие проблема: любая возникшая сложность, или Проблема (Problem) — причина или потенциальная причина инцидента или инцидентов (произошедших, текущих или будущих).

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 3

  • Сергей

    Илья, доброго дня.

    Не вдаваясь в обсуждение деталей хотелось бы заметить что от «гуру» ожидаешь нечто большего чем обычная декларация лозунгов.

    На примере любого из пунктов (взял пятый):

    Описание ошибки: Неверно подобранные метрики для оценки работы персонала.

    Лозунг 1. Метрики должны являться инструментами для достижения цели, а не самоцелью.

    Лозунг 2. Правильно выбранная цель может скорректировать вектор приложения усилий.

    Лозунг 3. Важно работать не много, а эффективно.

    Наблюдение 1. Мы чаще оцениваем и восхищаемся умением исправлять, чем предотвращать трудности.

    Хотелось бы видеть от Вас конкретные советы (раз мы про SD говорим) по «правильным» метрикам для тех или иных ситуаций.

    • Сергей, спасибо за отклик! Вижу, что метрики Service Desk – для Вас актуальная тема. Прекрасно! В статье приведен список, где можно узнать подробнее о практиках, в том числе и практике Service Desk. Измерения – это один из рассматриваемых вопросов в описании практик. Приходите! Расскажем, обсудим, научим не только метрикам. Нам есть чем поделиться с учетом решаемых Вами задач и профессиональных интересов.

      P.S. Небольшое уточнение: меня зовут Игорь, а не Илья 🙂

      • Сергей

        Игорь, извиняюсь. Спасибо, приду.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT