5 советов по улучшению управления проблемами

TipsСтюарт Рэнс (Stuart Rance) в своем блоге опубликовал интересный материал, посвященный управлению проблемами. Он предлагает обратить внимание на 5 важных советов, которые могут помочь в улучшении данного процесса.

Совет 1. Регистрируйте проблемы

Добейтесь того, чтобы проблемы регистрировались для часто повторяющихся инцидентов и инцидентов с высоким влиянием. Выберите TOP5 или TOP10 проблем и сосредоточьтесь на них. Решение проблем имеющих максимальное влияние позволит добиться максимального эффекта.

Совет 2. Сосредоточьтесь на обходных решениях, а не корневых причинах.

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

Совет 3. Сосредоточьтесь на возможностях по совершенствованию, а не на поисках виноватого.

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

Совет 4. Учитесь техникам анализа

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

Совет 5. Определите метрики процесса управления проблемами с акцентом на потребности бизнеса

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

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

ИТ: Вы зарегистрировали 500 инцидентов за прошлую неделю. И мы все решили в согласованное время.
Заказчик: Это конечно здорово, что вы выполняете свои обязательства в этой области...
ИТ: Мы ожидаем еще больше инцидентов на следующей неделе. Надеемся, что их количество перевалит отметку 1000 и мы тоже сможем их решить в установленное время.
Заказчик: !!&***!!$?

 

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

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

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

  1. Александр Трофимов

    >>Совет 2. Сосредоточьтесь на обходных решениях, а не корневых причинах.

    Простите? А зачем мне тогда заводить проблему? Обходное решение я найду в рамках процесса управления инцидентами. Собственно, его я найду и вообще без всякого процесса, или буду уволен 😉

    1. Nargiza Suleymanova

      Вроде как есть два типа обходных решений (ну я с двуми встречалась, и даже ITIL про них говорит): 1. разрабатывается в рамках управления инцидентами, применяется к конкретному инциденту, 2. разрабатывается в рамках управления проблемами, являясь временным решением для множества инцидентов. Они по сути "немного" разные. 🙂

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

      Второй тип — временное, обходное решение для множества инцидентов (в народе его еще называют костыль), которое обычно передается на первую линию — в процесс управления инцидентами, пока 2-ая и 3-я разбираются с постоянным решением проблемы. Не придумала/не вспомнила аналогий с принтерами, но поделюсь примером из жизни: платежи не садятся на счета, абоненты уходят в блокировку, временное решение — написать, протестить и запустить скрипт, который запускается по определенному графику, делает выборку затронутых абонентов и выводит их из блокировки. Причем временное решение тут — автоматизированное.

      И, кстати, зачастую бывает так, что временное решение по проблеме оказывается весьма долгоиграющим, потому что постоянное решение, хоть и разработано в рамках процесса, но оказывается слишком дорогим или затратным по ресурсам (бывает много разных вариантов ) и его в итоге не принимают. Так и живут ИТ с временным решением по проблеме 🙂 С инцидентами такой ситуации не встречала.

      1. Александр Трофимов

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

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

        1. Nargiza Suleymanova

          В целом второй тип проблем не обязателен. 

          Я про типы обходных/временных решений, не про типы проблем 🙂

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

          Трешка- имеется ввиду приоритет инцидента? Ну так и у проблем есть своя система приоритезации, которая (обычно) перенимает логику присвоения приоритетов у инцидентов. Про привязку- верно: можно один иницидент сделать родительским, а другие привязывать к нему как дочерние и решать инциденты (не проблемы) в рамках процесса управления инцидентами.

          С другой стороны, можно кучу инцидентов привязать к проблеме и тут у нас обоюдная выгода: инциденты предоставляют необходимую для анализа проблемы информации (как часть root cause analysis), а за это получают обходное/временное решение, которое скопом эти инциденты решает и закрывает. Как-то так 🙂

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

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

          1. Александр Трофимов

            Я отвечу только на это, пожалуй:

            >>а вот минимизация количества инцидентов путем устранения корневой причины

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

            З.Ы. "Трёшка" у меня это третья линия.

  2. Леонид

    Совет 4. Учитесь техникам анализа — опечатка

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

  3. Андрей

    Совет 2. Сосредоточьтесь на обходных решениях, а не корневых причинах.

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

    Совет 3. Сосредоточьтесь на возможностях по совершенствованию, а не на поисках виноватого.

    — Есть такое высказывание: у каждой аварии(инцидента, сбоя и т.д.) есть конкретные фамилия, имя и отчество. К сожалению, в большинстве случаев виноваты люди и единственное решение здесь — максимальное использование средства автоматизации. Средства автоматизации не обладают "человеческим фактором".

    Совет 4. Учитесь техникам анализа

    — прежде всего, не каждому это дано. А во-вторых, это задача высшей школы.

    Анектдот хороший.:)) 

     

     

  4. dimych

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

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

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

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

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

СЕН
27
ОКТ
1