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

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

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

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

  • Возможно, я не до конца понял идею, но пока мне кажется так:

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

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

    • Рома, мне не очевидно, что привязка раз в неделю проще, чем привязка в «реальном времени». Если решающим проблемы не до отслеживания потока инцидентов, то будет ли им до отслеживания раз в неделю, за которую их (инцидентов) накопится не один десяток (иногда и не одна сотня).

      Поэтому, даже если расстановка приоритетов, она же «перестройка очереди», осуществляется раз в неделю, может оказаться, что поддерживать связи проще в реальном времени. Осталось только придумать зачем это занятие людям из управления инцидентами 🙂

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

  • Михаил

    Роман,

    «Маловероятно, что эта очередь будет состоять из десятков проблем, скорее из единиц.»

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

    Женя,

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

    Менеджер оценит 2 величины — выгоду от этой привязки и трудозатраты на эту привязку.

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

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

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

      Я бы тоже (разумеется, если речь идёт о привязке инцидентов к проблемам, а не в целом) 🙂

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

      С другой стороны, стоит ли всё это городить только ради определения приоритетов проблем...

      • Михаил

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

        Как делали мы у себя в операционке в свое время:

        1. У меня был менеджер инцидентов, у него в подчинении 1.5 аналитика

        Аналитики смотрели на тренды по инцидентам в разрезе всего чего можно и делали выводы о возможных проблемах. Добавляем в котел.

        2. Проактивная ветка — кто во что горазд. Точка входа для сбора проблем, выявленных в рамках проактивной ветки, была. Добавляем в котел.

        3. Раз в неделю собирается «комитет по проблемам», который утверждает, приоритезирует, выделяет ресурсы и т.д. В комитете — статусные парни, включая ИТ-директора. Время — 1 час.

        Естественно, что протоколы и контроль.

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

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

        • Dimitriy

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

          Михаил,

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

          All,

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT