Давка в очереди — как быть?

Виталий задал вопрос на нашей странице в Facebook:

Посоветуйте, пожалуйста, как поступить?

Есть несколько трудоемких заявок которые поступили практически в один момент (например, установка операционной системы или что-то похожее). У них у всех крайний срок в соответствии с SLA определен в течение 8 рабочих часов. Ситуация такова, что даже задействовав весь персонал, мы не укладываемся в крайний срок как минимум у нескольких заявок. Как должна быть организована работа в таком случае?

Товарищи-практики управления инцидентами, поделитесь опытом решения подобных коллизий?

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

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

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

  1. KGP

    Проинформируйте о вашей пиковой текущей загрузке.

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

    Уведомите о новых срока реализации с извинениями.

    Нарушение SLA запротоколируйте и добавьте в статистику, через нее может увидите, что у вас есть заранее прогнозируемые пиковые периоды и тогда пересмотрите ваш SLA на подобные периоды. А может поймете, что отвлекли ресурсы на какой-то проект не учтя повышенной нагрузки в этот период.

    1. Дмитрий Бойко

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

      — одновременно возникших n инцидентов / работ по х услугам (n может быть не равно х);

      — в течение y времени (в течение времени устранения других инцидентов (выполнения других работ), но не в течение месяца);

      — при наличии на работе не менее z специалистов,

      т.е. согласовать с бизнесом риски:

      — отпусков, больничных, коммандировок (z),

      — возникновения инцидентов (срочных работ) в момент устранения других инцидентов (выполнеиня друших срочных работ) (y),

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

      1. Денис Денисов

        Я бы не стал вносить подобные пункты в SLA. Ведь в таком случае заказчику услуга предоставляется с существенными ограничениями гарантий, на которые поставщик повлиять в приведённом в примере не может (не хочет?). Тогда о каком обеспечении уровня услуги можно вести речь, если сплошь ограничения? Кроме того, чем больше ограничений вводится со стороны поставщика, тем больше риск злоупотребления ими.

        1. Олег Скрынник

          Поддерживаю.

          Меня как клиента будет непросто убедить, что когда у поставщика много инцидентов, то я должен подождать. Ещё сложнее убедить, что время решения моих инцидентов зависит от числа вышедших на работу ИТ-специалистов. Я ведь ни другими инцидентами, ни ИТ-специалистами не управляю, а потому влиять не могу. А мне надо, чтобы всё работало.

          Второй аргумент почему я бы не стал так делать — простота. Чем проще SLA, тем он понятнее обеим сторонам, тем проще его контролировать, за него отчитываться, его изменять при необходимости. Составить отчёт о фактическом уровне услуги, если в SLA есть много слов «когда», «если», «в случае» и «за исключением» — крайне непросто.

  2. Олег Скрынник

    Так как в вопросе речь идёт не про инциденты, а про запросы на обслуживание («Есть несколько трудоемких заявок которые поступили практически в один момент, например установка операционной системы или что-то похожее.»), то можно действовать следующим образом:

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

    Тактически, если завалы стали регулярными — анализировать работы, «сваливающиеся» одновременно, оценивать трудозатраты, изменять плановый срок в SLA по согласованию с заказчиком на основе анализа и убедительных объяснений.

    1. Алексей Юсов

      Поддерживаю!

      1. При чём тут инциденты? Это сервисные запросы. Для них SLA всегда ниже, чем для инцидентов. Планируйте SLA правильно, а для этого ...

      2. Необходимы нормативы на выполнение типовых работ. На основании этих нормативов можно уже выходить на конкретные цифры.

      3. То, что Олег обозначил как «можно», на сам деле «только так и нужно».

       

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

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

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

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

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