Управление проблемами Archives – Страница 7 из 8

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

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

Евгений Шилов, 31 марта 2012, последний комментарий 11 мая 2017

Совмещение ролей

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

Михаил Тобурдановский, 23 марта 2012, последний комментарий 26 марта 2012

Техника “пяти причин”

Продолжаю рассказывать на примерах о приросте полезности и содержательности новой редакции библиотеки ITIL. Отдельно остановлюсь на методе анализа 5-Why's, который описан в процесс управления проблемами. В комментариях на нашем портале такой вопрос уже поднимался: а что есть истинная корневая причина инцидентов? Принтер не работает, потому что сгорел нагревательный элемент. Он сгорел, потому что в электрической сети сильные перепады напряжения. Напряжение скачет, потому что нестабильно работает подстанция. Она работает нестабильно, потому что устарела. Подстанция устарела, потому что… Так вот: этот метод диктует, что после пятого «потому что» истинная причина инцидента будет найдена. А скорее всего, подсказывает здравый смысл, на одном из…

Константин Нарыжный, 29 февраля 2012, последний комментарий 1 марта 2012

Что хорошего в ITIL 2011?

Чем библиотека ITIL 2011 лучше, чем ITIL 2007? Короткий ответ: структурностью и практической полезностью. Сейчас расскажу. Про структурность: стало однозначно лучше. Например, авторы всё-таки договорились о том, что такое "назначение" и "задачи" ("Purpose & Objectives") процесса, и согласились с Дмитрием Исайченко, что цели процесса у каждого поставщика услуг – уникальные, поэтому перечисления "Goals" теперь нет вообще. Структура описания теперь совпадает во всех пяти книгах, для всех 26 процессов. Полезности прибавилось ещё больше. Собственно, из-за практических примеров, упоминания всевозможных прикладных техник и приёмов и вырос объём книг. Я вживую увидел это в описании процесса управления проблемами. В версии 2007 были описаны техники…

Константин Нарыжный, 17 февраля 2012, последний комментарий 17 февраля 2012

Нетехнические проблемы

Процесс управления проблемами часто считают процессом устранения ошибок в ИТ-инфраструктуре. Получается своего рода «компенсатор», корректирующий ошибки, заложенные на этапе проектирования и внедрения и проявляющиеся в ходе эксплуатации информационных систем. Однако многие инциденты (предотвращением которых занимается процесс управления проблемами) связаны не с техническими ошибками, а с организацией труда – исполнением, взаимодействием, принятием решений, контролем. Поэтому на моей практике ряд компаний (кто-то постепенно, кто-то сразу – при проектировании процесса) включили оргвопросы в охват управления проблемами. Управлять такими проблемами сложнее, чем проблемами в инфраструктуре. Но не управлять ими – значит сознательно лишать себя части возможностей по улучшению. Думаю, это один из признаков зрелой организации,…

Дмитрий Исайченко, 26 ноября 2011, последний комментарий 13 мая 2015

Занимательная арифметика: управление рисками

ITSM сообщество продолжает читать и считать ITILv3 2011. Неугомонный Ян ван Бон решил проверить, изменилась ли ITIL в том, что касается одной из его любимых известных ошибок: указали ли наконец авторы, что управление проблемами – лишь форма управления рисками? В результате проведенных Яном подсчетов выяснилось, что новая редакция библиотеки в целом существенно больше внимания уделяет управлению рисками. Вывод сделан путем сравнения числа упоминаний сочетания risk management в тексте ITIL 2007 и 2011 года. Вот результаты этого упражнения: Risk Management в ITIL 2007: Service Strategy v3: 16 Service Design v3: 26 Service Transition v3: 29 Service Operation v3: 6 Continual…

Новостной поток, 15 сентября 2011, последний комментарий 26 сентября 2011

Инциденты и проблемы

В очередной раз в обсуждении с заказчиком я сталкиваюсь с серьёзным непониманием отличий процесса управления проблемами от управления инцидентами. Корневых причин такого непонимания (простите за каламбур) я вижу две: невнятный текст про взаимодействие этих процессов в книгах ITIL (в частности, однозначная рекомендация привлечения PRB к решению major-инцидентов) и отсутствие специфичных алгоритмов обработки проблем в средствах автоматизации процессов ITSM, по которым зачастую осознают процессы как заказчики, так и консультанты. Размышляя об этом явлении, хотел бы сформулировать основные отличия этих процессов. Главный тезис заключается в том, что процесс управления проблемами – это не «медленный» инцидент-менеджмент и не «другой» инцидент-менеджмент, который работает по…

Дмитрий Исайченко, 5 сентября 2011, последний комментарий 24 октября 2022

О рисках проблем и проблемах рисков

Скептик рассуждает о различиях в сути таких явлений как Риск и Проблема. Про сходство давно и хорошо написал Ян ван Бон (и не только), но Скептик, отдавая должное классику, тем не менее утверждает, что на практике управление проблемами и управление рисками – очень разные вещи. Аргументы и комментарии – в блоге Скептика.

Опять они. ITIL не работает в облаках

Bob Lewis и Rick LiaBraaten рассуждают о том, как ITIL не работает при использовании облачных решений. Сомнению подвергаются возможности управления доступностью, производительностью, изменениями, проблемами и поставщиками. Основные аргументы связаны с отсутствием в ITIL методов, а у команд ИТ – инструментов для мониторинга и анализа облачной инфраструктуры и/или услуг, предоставляемых SaaS-поставщиками. Полностью рассуждения Боба и Рика доступны на CIO.com

Новостной поток, 13 января 2011, последний комментарий 13 января 2011

Вторая жизнь HP OV SD 4.5

Компания Prolin сдержала свое слово (см. "Прародители HP OV SD могут дать ей второй шанс") и выпустила продукт под названием Power Server, который вместе с выпущенным ранее Smart Client 10, призван заменить HP OV SD 4.5. По словам производителя, продукты построены на базе современных технологий, что дает прирост производительности по сравнению с HP OV SD 4.5, при этом клиент обладает некоторыми возможностями, которых не было в HP OV SD 4.5. Кроме того, Power Server может работать параллельно с HP OV SD Application Server, что позволяет произвести переход постепенно, с минимальными рисками. Для компаний, которым полюбилась старая-добрая и такая родная HP…

Евгений Шилов, 12 декабря 2010, последний комментарий 24 декабря 2010

Измеряем Problem management

Среди прочих интересных моментов из проектной практики в одном из свежих проектов появилась идея (на мой взгляд разумная) по "основной метрике" процесса управления проблемами. Задача – иметь возможность мерять насколько реально работает процесс. Сложность – традиционные метрики типа отношение количества решенных проблем к количеству открытых проблем и аналогичные обладают двумя существенными недостатками: а) они не стимулируют регистрировать новые проблемы и б) поскольку они не нормированы, для них сложно определить правила установки целевых значений. Решение – метрика, вычисляемая по формуле ниже. N – количество новых проблем, зарегистрированных за период и не закрытых на момент его окончания (это необходимо для нормировки);C –…

Дмитрий Исайченко, 1 декабря 2010, последний комментарий 24 августа 2015

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

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

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