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

Приоритеты проблем, один из вариантов

Не секрет, что диагностика и поиск решения проблем весьма ресурсоемкая задача и если проблемы выявляются и поступают на обработку, то рано или поздно возникнет задача расстановки приоритетов. 

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

Таким образом, проблема, вызвавшая пару инцидентов с уровнем влияния "Критичный", будет иметь больший приоритет, чем проблема, к которой привязано несколько инцидентов с уровнем влияния "Низкий". При этом, могут быть ситуации, когда количество инцидентов с уровнем влияния "Низкий" станет настолько большим, что суммарный вес этих инцидентов станет больше, чем вес пары инцидентов с уровнем влияния "Критичный". Такая ситуация укладывается в нашу обычную логику.

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

Есть конечно у этой схемы один существенный недостаток – она зависит от предположения, что "связь между процессом управления инцидентами и проблемами работает и к проблемам привязываются инциденты". На этапе создания проблемы привязка обычно делается для подтверждения необходимости регистрации проблемы, но этого мало. В идеале инциденты должны привязываться до тех пор пока проблема не закрыта и факт привязки новых инцидентов может поднять приоритет проблемы.

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

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

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

  • Возможно, я не до конца понял идею, но пока мне кажется так:
    Цель определения приоритета проблем в описанной ситуации – решение о порядке выделения ресурсов на диагностику, выявление ошибок и поиск решений. Следствием такого решения будет выделение (или не-) определенного времени определенных специалистов на проведение диагностики и, возможно, формирование очереди проблем, подлежащих обработке. Маловероятно, что эта очередь будет состоять из десятков проблем, скорее из единиц.
    Если так, то актуализация данных о влиянии в реальном времени (привязка новых инцидентов к старым проблемам) не очень нужна, а если и нужна, то может проводиться не онлайн, а, скажем, раз в несколько дней – при перестройке очереди.

    • Рома, мне не очевидно, что привязка раз в неделю проще, чем привязка в “реальном времени”. Если решающим проблемы не до отслеживания потока инцидентов, то будет ли им до отслеживания раз в неделю, за которую их (инцидентов) накопится не один десяток (иногда и не одна сотня).
      Поэтому, даже если расстановка приоритетов, она же “перестройка очереди”, осуществляется раз в неделю, может оказаться, что поддерживать связи проще в реальном времени. Осталось только придумать зачем это занятие людям из управления инцидентами 🙂
      Могу предположить, что менеджер процесса управления инцидентами может быть заинтересован в сокращении числа инцидентов, которые “кушают его ресурсы2, поэтому на этапе закрытия может осуществлять привязку инцидентов к одной из открытых проблем, коих в идеале должно быть не так много.

  • Михаил

    Роман,
    “Маловероятно, что эта очередь будет состоять из десятков проблем, скорее из единиц.”
    Возьмите гетерогенную среду и хотя бы десяток мощных приложений, работающих на фронт/бэк-офисы. Будет намного больше.

    Женя,
    “Могу предположить, что менеджер процесса управления инцидентами может быть заинтересован в сокращении числа инцидентов, которые “кушают его ресурсы2, поэтому на этапе закрытия может осуществлять привязку инцидентов к одной из открытых проблем, коих в идеале должно быть не так много.”

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

    Если прикинуть на высоком уровне, я бы на месте менеджера инцидентов послал всех нафиг 🙂

    • “я бы на месте менеджера инцидентов послал всех нафиг”

      Я бы тоже (разумеется, если речь идёт о привязке инцидентов к проблемам, а не в целом) 🙂
      Думаю, привязку надо организовывать со стороны управления проблемами (при регистрации, в ходе контроля известных ошибок, перед закрытием) и стимулировать её через оценку решённых проблем с учётом их pain factor’а, который рассчитывается по связям. Правда при этом придётся исключать из такой логики оценки проблемы, зарегистрированные проактивно. Но такую реализацию, я, по крайней мере, могу себе представить.
      С другой стороны, стоит ли всё это городить только ради определения приоритетов проблем…

      • Михаил

        Согласен, проактивный поток наглухо потерян.

        Как делали мы у себя в операционке в свое время:
        1. У меня был менеджер инцидентов, у него в подчинении 1.5 аналитика
        Аналитики смотрели на тренды по инцидентам в разрезе всего чего можно и делали выводы о возможных проблемах. Добавляем в котел.
        2. Проактивная ветка – кто во что горазд. Точка входа для сбора проблем, выявленных в рамках проактивной ветки, была. Добавляем в котел.
        3. Раз в неделю собирается “комитет по проблемам”, который утверждает, приоритезирует, выделяет ресурсы и т.д. В комитете – статусные парни, включая ИТ-директора. Время – 1 час.
        Естественно, что протоколы и контроль.

        4. Если вдруг групповое сознание понимает, что до следующей встречи не дотерпеть, то комитет собирается внепланово в полном или усеченном составе (проецируем emergency cab из изменений).

        Далеко не идеальная схема, но позволяет держаться на плаву, проверено 🙂

        • Dimitriy

          Доброго времени суток.

          Михаил,
          А не проще выделять из "пула ресурсов" время на проблемы в соответствии с их приоритетами?

          All,
          Кто какие практики использует на практике?


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM