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

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

Опубликовано 13 апреля 2014
Рубрики: ITIL, Управление инцидентами
Комментарии

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

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

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

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

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

est

 

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

  • Андрей

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

  • Антон

    Добрый день.

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

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

  • Альберт

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

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

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

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

  • Елизавета

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

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

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

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

     

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM