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

Семь преимуществ KEDB

База данных известных ошибок – хранилище информации обо всех характеристиках ИТ-инфраструктуры, которые могут привести к сбоям и способов исправления таких сбоев. База данных наполняется в рамках процесса управления проблемами и используется в процессе управления инцидентами, для того чтобы устранять сбои быстрее. Известный колумнист Симон Моррис написал большую статью про эту чудесную базу, и, в частности, привёл ключевые преимущества от её использования: Более быстрое восстановление услуг для пользователей. Стабильное качество обслуживания, за счёт использования одинаковых обходных решений. Уход от непродуктивной повторной работы, затрачиваемой на поиск одних и тех же решений разными специалистами. Уход от разницы в знаниях ИТ-специалистов – хранение данных…

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

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

Вопрос из зала, 12 апреля 2012, последний комментарий 17 апреля 2012

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

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

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

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

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

Вопрос из зала, 1 апреля 2012, последний комментарий 6 апреля 2012

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

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

Евгений Шилов, 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

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

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

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