ИТ-услуги не совершенны. Безусловно, во время разработки услуги и их компоненты тестируются и проверяются, однако все равно некоторые ошибки остаются незамеченными, а некоторые риски не возможно предсказать. В процессе эксплуатации эти ошибки и уязвимости проявляют или могут проявить себя инцидентами. Согласно ITIL4
Проблема – это причина или потенциальная причина инцидента или инцидентов (произошедших, текущих или будущих).
Лучшие практики и эксперты рекомендуют ИТ-организациям выстраивать управление проблемами, как важную способность организации. Но иногда в организациях могут возникнуть вопросы, а действительно ли нужно регистрировать проблемы и дальше их анализировать, устранять и совершать прочие управленческие активности, если в этих организациях и так уже прекрасно работает управление инцидентами, инциденты быстро обнаруживаются, специалисты обучены и есть большая база знаний, позволяющая в короткие сроки эти инциденты устранять? Что даст дополнительно управление проблемами? Откуда брать информацию для регистрации проблем и в чем могут быть сложности?
На нашем вебинаре “Управление проблемами – где взять проблемы” (RuTube, YouTube) подробно разбираются эти вопросы, а в завершении мы делимся рекомендациями по организации выявления проблем, основанными как на советах лучших практик, так и на нашем проектном опыте.
Для желающих поделиться своим опытом или задать вопрос всегда есть возможность оставить комментарий, а обсудить проблему с проблемами вживую можно на нашем курсе VAP: Управление поддержкой ИТ-услуг.
Основная сложность с Problem Management, на мой субъективный взгляд, вызвана тем, что как в “первоисточнике”, так и в других публикациях описание процесса начинается с регистрации проблемы, а не с ее выявления. Именно по этой причине меня заинтриговало название – “где взять проблемы”. Но, к сожалению, тема на мой взгляд так и не раскрыта. Из перечисленных источников регистрации проблем понятен только случай с вендорами. Но они, как правило, сообщают о проблемах вместе с решением и эта ветка скорее в Cahge Management. Анализ инцидентов – совершенно правильное направление, поскольку в соответствии с “первоисточником” проблемы проявляются через инциденты. Но что такое анализ инцидентов, как его следует проводить для выявления проблем? Упоминание “Мажорных” инцидентов в качестве кандидатов на проблемы мне представляется абсолютно неверным, поскольку инцидент, даже “мажорный”, вовсе не означает однозначное наличие проблемы. Необходимы методики и инструменты, позволяющие выявить наличие проблем в принципе, и затем уже позволяющие сузить область поиска если не конкретных CI, то хотя бы до problem area.
В качестве примера – https://www.corisys.ru/2024/07/18/itil-problem-management/