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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2025

Управление проблемами

Всё об управлении проблемами

Координатор проблем в слабой матрице

В процессе управления проблемами есть такая роль: координатор проблем. Как правило, эта роль предполагает ответственность за диагностику и решение проблем в какой-то предметной области, в том числе, с привлечением специалистов из смежных областей. И иногда я слышу от заказчиков вопрос: «А кто, собственно, должен быть координатором той или иной проблемы»? Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто…

Major incident – когда становится горячо…

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…»  Что такое значительный инцидент? В теории значительный  инцидент – это инцидент с самым высоким влиянием и…

Управление событиями и рейтинги

Интересная идея была озвучена Аугусто Барросом (Augusto Barros), исследовательским директором Gartner в его недавней публикации в авторском блоге. Фокусом его интересов является информационная безопасность. В своей публикации он отмечает, что индустрия средств мониторинга событий и инцидентов безопасности изменилась за последние несколько лет. Ранее они работали следующим образом: одно или несколько средств отслеживания событий безопасности генерировали некоторый поток этих событий и присваивали им определенные степени критичности. Имелся некоторый пул сотрудников невысокой квалификации, которые в непрерывном режиме отслеживали этот поток и обрабатывали его в соответствии со скриптами, осуществляя требуемую эскалацию на профильные группы, а также проводя дополнительные расследования событий в силу своих возможностей.  Очевидно, что с тотальной цифровизацией такой…

Опыт гибкого управления проблемами

Своим практическим опытом о том, как сочетать в одной организации методы гибкой разработки и классического процесса эксплуатации услуг, с нами делится Ян Джонс (Ian Jones), консультант KPMG Australia. В одной неназванной организации методы гибкой разработки были приняты как стандарт исполнения проектов и успешно применялись достаточное время. При реализации ITSM инициатив возникло желание использовать их и для организации процесса управления проблемами. Изначально организация использовала Scrum для координации этих работ, но этот подход показал себя не с лучшей стороны. После чего, была предпринята более успешная попытка применения "бережливой" практики Kanban. Для того, чтобы объяснить различия между этими двумя методиками приведем небольшую таблицу.   Kanban Scrum Планирование работ В объеме…

Болевые точки управления проблемами

В группе BACK2ITSM опубликована заметка о "болевых точках" процесса управления проблемами, содержащая некоторые рекомендации по минимизации рисков, этими точками вызываемых. Автор, не углубляясь излишне в философские вопросы, напоминает нам перечень областей, применительно к которым в рамках управления проблемами необходимо осуществлять регулярный анализ. Эти области анализа следующие: выявленные события и полученные уведомления об ошибках в инфраструктуре, а также характер трендов в появлении событий и уведомлений; зарегистрированные инциденты и тренды в возникновении инцидентов; ИТ-сервисы, по которым были выявлены события, поступили уведомлениями, возникли инциденты. Если имеет место негативный тренд или негативное влияние на ИТ-услуги, как известно, необходимо подробно разобраться в проблемах – провести…

STAR WARS и Управление проблемами

Совсем недавно на нашем портале обсуждалось место процесса управления проблемами в организационной структуре, исходя из его назначения и задач. На смежную тему на портале компании EasyVista опубликована "трилогия" Кристофера Моргана (Cristopher Morgan) – "Зачем Дарту Вейдеру нужен менеджер процесса управления проблемами" ("Why Darth Vader Needed a Problem Manager"). Часть 1  Часть 2 Часть 3  В этой публикации Морган на примере катастрофы звезды смерти и других драматических сцен великой киносаги выделяет ключевые области, на которые необходимо обратить внимание при реализации этого процесса, а также ясно показывает что произойдет, если этого не сделать. Надеемся, это легкое и полезное тематическое чтение развлечет вас и если не поможет улучшить ваши процессы, то…

И снова (N+C)/(O+C)

Про метрику продуктивности процесса управления проблемами, которая рассчитывается по этой формуле, я уже писал и неоднократно (и на портале, и в книге). Однако жизнь показала, что эту формулу можно еще немного улучшить, уточнив определение операнда C. Это позволит повысить защищенность метрики по отношению к активностям, которые не приносят ценности, а лишь имитируют кипучую деятельность. Например, представьте, что менеджер проблем просто закрывает большинство поступивших проблем с кодом закрытия «Решение нецелесообразно». Работа кипит, пользы никакой, KPI близок к единице. Или регистрируются дубли, которые сразу и закрываются с соответствующим признаком. В книжке дается рекомендация не включать такие проблемы в расчет С. Но можно…

Вопрос из зала: где должен быть Problem management?

Читатель нашего портала Дмитрий интересуется управлением проблемами: Добрый день,  Внутри команды Service Managers  возникло бурное обсуждение, откуда должен предоставляться Problem Management, так как в ITIL нет четкого описания ( или мы его не нашли), кто за это отвечает ( понятно, тут не обойтисть без Problem Manager)  и откуда  (ServiceDesk?) , есть лишь описание , что проблемы поднимаються со 2-й линни в Problem Management процесс. Cреди вариантов есть такие мнение: 1) Не должен предоставляться Service Desk, так как возникает конфликт интересов, и всегда должен предоставляться на уровнях  2 или 3 линий поддержки, которая обязательно находится не в ServiceDesk 2) Предоствляется из…

Более 3 часов уходит у 65% компаний на анализ проблем, связанных с приложениями

AppDynamics совместно с Enterprise Management Associates (EMA) опубликовала в августе отчет об исследовании, основанном на опросе 302 специалистов и менеджеров, отвечающих за управление приложениями. По данным отчёта, для проблем, связанных с приложениями и выходящих за пределы компетенции 1-й линии поддержки: 65% компаний требуется более 3 часов на определение корневой причины; ​ 77% компаний требуется более 5 человеко-часов на решение.  (Графики из статьи, опубликованной Anand Akela в корпоративном блоге AppDynamics) Некоторые факты из отчёта: Только 30% компаний имеют в настоящее время специализированные решения для мониторинга приложений Не более 50% приобретённых инструментов используются для мониторинга приложений 27% проблем, связанных с приложениями, обнаруживаются с помощью систем…

Когда Problem Management – проблема.

Как понять, что можно существенно улучшить процесс управления проблемами (Problem Management)? В недавно опубликованном посте «When Problem Management is the Problem» Michael Keeling задаётся вопросом, почему, несмотря на то, что человечество занимается решением проблем всю свою историю, нельзя сказать, что эта практика полностью изучена, освоена и не вызывает вопросов. Если говорить об ITSM, то, по мнению автора, во многих организациях процесс управления проблемами работает не так, как им хотелось бы. Более того, иногда приглашённые для анализа такой ситуации консультанты приходят к выводу, что реализованный процесс управления проблемами на самом деле является частью проблемы. Если вы подозреваете, что процесс управления проблемами…

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

Стюарт Рэнс (Stuart Rance) в своем блоге опубликовал интересный материал, посвященный управлению проблемами. Он предлагает обратить внимание на 5 важных советов, которые могут помочь в улучшении данного процесса. Совет 1. Регистрируйте проблемы Добейтесь того, чтобы проблемы регистрировались для часто повторяющихся инцидентов и инцидентов с высоким влиянием. Выберите TOP5 или TOP10 проблем и сосредоточьтесь на них. Решение проблем имеющих максимальное влияние позволит добиться максимального эффекта. Совет 2. Сосредоточьтесь на обходных решениях, а не корневых причинах. Не тратьте недели на поиски корневой причины, в то время как бизнес не может нормально работать. Начните с выявления способов идентификации инцидентов связанных с данной проблемой и обходных решений, которые помогут…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM