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

Управление черными ящиками

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

Роман Журавлёв, 13 июня 2012, последний комментарий 16 июня 2012

Смотрим на инциденты расширенными глазами

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении. Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы. Момент возникновения инцидента, то есть, момент, когда пользователь ощутил снижение качества ИТ-услуги Обнаружение, то есть промежуток времени от возникновения до момента получения поставщиком ИТ-услуг информации об инциденте Диагностика, то есть время на поиск причины инцидента Исправление, то есть время на…

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

Семь преимуществ 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

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

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

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