Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Все говорят: «Поток!». А ты построй поток
      «А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Мотивация разработчика В2В продукта
      Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT