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

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

Опубликовано 9 июля 2015
Рубрики: Обо всём на свете, Управление проблемами
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

 

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

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

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

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

    • Nargiza Suleymanova

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

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

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

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

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

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

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

        • Nargiza Suleymanova

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

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

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

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

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

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

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

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

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

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

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

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

  • Nick Shikov

    Nick Shikov

    Шуточный диалог в конце статьи вызвал не поддельную улыбку

  • Леонид

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

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

  • Андрей

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

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

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

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

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

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

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

     

     

  • dimych

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

    • Nargiza Suleymanova

      Поэтому у нас сначала "Кто виноват?", а уже потом "Что делать?" 🙂

  • Олег Шиловский

    Олег Шиловский

    Всё верноо. Осталось найти человека в компании с достаточным уровнем полномочий, который будет продуктивно это делать…

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

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

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