Эстафета в управлении инцидентами

Про футбол я уже как-то писал, на этот раз тема тоже спортивная, но про эстафету. 

На днях были со Степаном Хрулевым у заказчика и нам рассказали грустную историю из всеми любимого процесса управления инцидентами. Процесс построен силами специалистов заказчика. Все как обычно: есть первая и вторая линия, есть нормативы на сроки обработки обращений. И как обычно случаются ситуации, когда одна группа затянула диагностику, посмотрела в последний момент и поняв, что это не ее, передала дальше. Вторая группа, получив обращение в последний момент, не успела выполнить вовремя, получила ярлык «просрочено» в обращении и грустит на тему «где в этом мире справедливость?».

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

  1. Если есть нормативы на сроки, то надо задуматься и о контроле времени, из которого складывается время решения обращения.
  2. Если описанная ситуация — частое явление, то можно ввести органичения или эскалации при переназначении в последний момент (например, за час до окончания срока).
  3. По обращению должны быть видны все участники и время, которое они потратили на работу ним.
  4. При построении отчетов, если с обращением работало несколько групп, нельзя сваливать «просрочку» всегда только на последнюю.
  5. Для сокращения ошибочных назначений из-за недостаточной диагностики, необходимо сделать доступными средства диагностики на первой линии (в виде опросников, диагностических утилит и т.д.). Кроме того, должно проводиться обучение специалистов первой линии методам диагностики и классификации обращений. С учетом того, что в этом заинтересованы специалисты второй линии, можно смело их привлекать.
  6. Если идет речь о работах, в которых по определению должны участвовать специалисты нескольких групп, желательно иметь нормативы для каждой из частей работ. 

Пожалуйста поучаствуйте в пополнении списка, если у вас есть свои способы борьбы с подобной эстафетой.

est

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    По моему опыту следует разделить показатели соблюдения сроков восстановления услуг (общий для всей поддержки) и индивидуальные показатели длительности обработки инцидентов групп и/или специалистов. К сожалению, просто нарезка длительности обработки на одинаковые для групп интервалы не всегда объективна. В идеале должны вестись модели обработки инцидентов с нормативной длительностью обработки для каждой группы. Такое решение позволит учесть технологическую составляющую в обработке инцидентов и даст большую точность оценки нормативных сроков, но и большие издержки на управление. Имхо 😉

    0
    0
  2. Антон

    Добрый день.

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

    0
    0
    1. Роман Журавлёв

      Антон, с OLA может получиться не проще, а сложнее. То есть ответственность будет определена однозначно, но влияние на «скорейшее восстановление нормальной работы услуги» у такой практики может быть негативным. Ведь ни менеджер процесса управления инцидентами, ни менеджер сломавшейся услуги могут не иметь в этом случает рычагов влияния на группу, действующую в рамках OLA. Подробнее об этом можно посмотреть в вебинаре Дмитрия, примерно с 44 минуты. 

      0
      0
  3. Альберт

    Все конечно зависит от масштабов и исходных условий. Скорее всего на 100% проблему решить не удастся, но перечисленные выше меры помогут снизить вероятность выхода за рамки OLA/SLA.

    Часто получается такая ситуация, первая линия работает 24×7, вторая линия и сами пользователи 8×5, иногда на это накладывается разница часовых поясов и праздничные дни.

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

     

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

    0
    0
  4. Елизавета

    Как и у многих, у нас сейчас разбор заявок происходит по мере их поступления. При этом во внимание не принимается, что, допустим, пользователь, который инициировал заявку, к моменту, когда до него дойдет очередь, может удалиться на совещание или еще похлеще — айти в отпуск (бывает и такое )))

    Поэтому сейчас, как вариант, думаем о согласовании времени исполнения некоторых типов заявок с пользователем. Т.е. нужно, например, установить и настроить некое ПО. Пользователь указывает, что будет ожидать подключения к своей машине с 15 до 16 часов. И пользователь к месту весь день не привязан в ожидании исполнения его заявки, и у службы поддержки появляется некое подобие оперативного планирования. + снижается риск просрочки исполнения заявки.

    Если же для исполнения требуется участие нескольких групп, то соответственно производится общее согласование времени исполнения. Как-то так...

    Возможно, уже кто-то практиковал такой подход? Если да, прокомментируйте, пожалуйста.

     

    0
    0
  5. Вадим Бекетов

    Обычно в модели инцидента мы настраиваем контроль пороговых значений на каждом этапе, в % от времени по SLA и настройку реакции  (уведомление руководителю,эскалация) в случае превышения. (Профессиональная версия 1С:ITIL, в версии СТАНДАРТ сталкивался с аналогичными проблемами довольно часто, но так и не нашел решения). 

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)