Портал №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.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.
;