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

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

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

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

Вопрос из зала: Обходное решение проблемы или типовое решение инцидента?

Владимир спрашивает: И снова о проблемах… в продолжении последнего семинара Евгения Шилова. Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007. В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал. Проблемой в данном случае является ошибка в книге. Инцидентом низкий бал на экзамене. Решением инцидента является апелляция, результатов экзамена. Обходным решением проблемы является исключение из экзамена вопросов связанных с ошибкой. Структурным решением является переиздание книг. Вопросы: Может ли проблем менеджмент предложить в качестве обходного решение каждый раз писать апелляцию (допустим раньше инцидент решался просто повторной сдачей экзамена…

Жажда проблем

Несколько раз слышал от разных людей "Не работает у нас управление проблемами, т.к. проблем нет, соответственно и решать нечего".  Можно было бы за такие успехи порадоваться, если бы не одно сомнение, которое заключается в том, что практика показывает, что проблемы есть всегда. Просто не каждую проблему готовы таковой считать и тратить на нее время. Многим из курса ITIL запомнилась взаимосвязь проблем с повторяющимися инцидентами вызванными ошибкой в инфраструктуре. И, соответственно, раз не видим повторяющиеся инциденты, значит и проблем нет.  Однако есть еще одно соображение, про которое иногда почему-то забывают. Решение проблемы, по сути, это устранение ошибки в инфраструктуре, при этом…

Вопрос из зала: Нужно ли разделять оперативное и полное решение инцидента

Марина спрашивает: Подскажите, пжл, нужно ли разделять оперативное решение инцидента и полное решение инцидента? например: не формируется автоматически отчет (перестал работать функционал некой системы Х). например, пользователь может вручную создавать этот отчет (оперативное решение=обходной вариант), а исправление кода в системе Х (например, отчет не формируется из-за ошибки в коде) это уже полное решение инцидента? не смешиваются ли здесь понятия — решение проблемы?

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

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

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

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

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

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

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

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

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

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

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

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…

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

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM