Управление инцидентами Archives – Страница 14 из 18

Безвыходные инциденты

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

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

Функциональная эскалация

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

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

Who is incident manager?

Во многих ITSM-проектах менеджером процесса управления инцидентами назначают начальника отдела поддержки пользователей (Service Desk). Такой вариант обладает рядом понятных минусов. Основной – риск вытеснения функций менеджера сквозного процесса функциями руководителя отдела поддержки. Как следствие, сложности во взаимодействии со второй линией, риск появления изолированных самостийных видов поддержки, с поступлением обращений мимо первой линии, без регистрации в системе автоматизации. Особенно вероятна такая «параллельная реальность» в отделах сопровождения прикладных систем. Причина: первая линия относительно редко бывает достаточно компетентной, чтобы оказывать полноценную начальную поддержку по прикладному ПО. А значит и пользователями, и «прикладниками» может восприниматься как лишнее звено, только увеличивающее общее время обработки обращений….

Дмитрий Исайченко, 19 августа 2012, последний комментарий 12 сентября 2012

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

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

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

Влияние сбоев на ИТ-услуги

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

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

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

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

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

Доска аварий

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

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

Допрос с пристрастием

На днях меня попросили показать примеры вопросов, которые можно задавать пользователям для оценки их удовлетворенности итогами решения инцидента. То есть по итогам решения инцидента пользователь не просто должен сказать: "да работает/нет не работает", а дать "развернутый" ответ о том, как все прошло и насколько он счастлив. Я решил заодно и на портале упомянуть эту тему и важные моменты: Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы. Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы Пользователя не…

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

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

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

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

Оценка влияния инцидента

Ну наконец-то выходные и можно спокойно написать пару мыслей. Не раз уже обсуждали на семинарах проектирования подход к оценке уровня влияния инцидентов, поступающих от пользователей. Обычно влияние сказывается на приоритетах и нормативных сроках решения инцидентов, поэтому оценить влияние на начальном этапе чрезвычайно важно. Но, вспоминая, что на первой линии нам обычно доступны только сами пользователи с их суждениями о сложившейся ситуации, а объем диагностической информации минимален, приходится придумывать вопросы, которые специалист первой линии может задать пользователю и на основании ответов оценить влияние. К вопросам предъявляется ряд требований: пользователи могут дать ответ трактовка более-менее однозначна вопросов не много (обычно 2-4) Традиционную схему, которую часто приводят…

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

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

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

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

Управление инцидентами

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