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

Самое лучшее в ITSM по-русски

Этот декабрь выдался богатым на анонсы книжного рынка. Параллельно с книгой Романа Журавлёва коллектив авторов портала Real ITSM подготовил к изданию сборник собственных статей. Самое лучшее и практичное из мира ITSM уже доступно для загрузки в формате PDF. В сборнике вы найдёте: фундаментальные статьи: и напечатанные в альманахах itSMF, и выходившие в печатной прессе, и не издававшиеся ранее дотошные вопросы к западным ITSM-экспертам и их робкие точные ответы картинки и опечатки идеальную вёрстку линейки и градусники модели и формулы итоги многодневных дискуссий с вами на портале Real ITSM Читайте на здоровье. А свои отклики и замечания оставляйте здесь, в комментариях.

Управление проблемами и время решения инцидентов

Задача сокращения среднего времени решения инцидентов стоит перед многими руководителями. На традиционный вопрос «Как сделать так, чтобы инциденты решались быстрее?», есть не менее традиционный ответ «Давайте проанализируем, где теряется время». Здесь работает простая аналогия с подходом к сокращению затрат: начать надо с выявления наиболее затратных областей. Именно там усилия по сокращению затрат могут принести наибольшие результаты. Где же искать ответ? В книге ITIL Service Design в главе про управление доступностью есть любопытный раздел «Expanded incident lifecycle». Это метод, описывающий основные этапы решения инцидента с целью последующего анализа, за счёт чего можно сократить время обработки на каждом из этапов – быстрее…

Дмитрий Исайченко, 20 октября 2012, последний комментарий 25 октября 2012

Мировая статистика процессов INC, PRB и CHG

Компания Pink Elephant продолжает проект по сбору статистических данных о реальных значениях процессных метрик. Напомним, что ITIL рекомендует сравнивать организации, чтобы устранить имеющиеся недостатки в способностях по управлению процессами. Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге Pink Elephant. Сегодня появились обновлённые на июль 2012 года данные по процессам управления инцидентами, проблемами и изменениями. В опросе принимали участие организации из разных стран, различного размера и из разных отраслей. Некоторые выдержки из отчёта: На количество инцидентов в организации больше всего влияют (в порядке убывания значимости): размер организации, количество внутренних и внешних пользователей ИТ, длительность существования формального процесса управления инцидентами….

Новостной поток, 24 июля 2012, последний комментарий 26 июля 2012

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

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

Роман Журавлёв, 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

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

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

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