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

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

Опубликовано 6 августа 2014
Рубрики: Вопрос из зала, Практика и опыт, Управление инцидентами
Комментарии

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

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

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

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

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • KGP

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

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

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

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

    • Дмитрий Бойко

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

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

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

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

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

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

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

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

      • Денис Денисов

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

        • Олег Скрынник

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

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

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

  • Олег Скрынник

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

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

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

    • Алексей Юсов

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

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

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

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

       

  • Альберт

    Согласен с KGP. Проинформировать пользователя когда будет выполнен его запрос и поставить на паузу.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.