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

Эстафета в управлении инцидентами

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

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

Мобильные участники процессов

Последнее время все чаще при проектировании процессов приходится слышать о мобильных сотрудниках, которые не сидят на месте, а перемещаются в пространстве с завидной периодичностью, поэтому привязывать их к рабочему месту невозможно, поэтому ждать от них быстрой реакции на запросы на согласование или назначенные задачи нереально. Кто эти люди? Да, кто угодно: от руководителей, которые постоянно на совещаниях или командировках, до технических специалистов, которые на выездах, на рабочих местах пользователей. Что от них требуется? Обычно ничего сверхестественного: дать ответ по запросу на согласование, взять в работу назначенное обращение или задание, отчитаться о выполненной работе. Что нужно для решения задачи? Предоставить интерфейс для…

Евгений Шилов, 18 марта 2014, последний комментарий 21 марта 2014

Major / Critical Incident Management: важная темная область

На прошедшем в начале этой недели курсе мы с его участниками обсуждали инциденты, для которых не очень хорошо работают привычные процедуры, описанные в книжках. Участники называли такие инциденты "критическими", я по привычке "значительными". Что мы в ходе этого обсуждения выяснили: Во-первых, годное определение значительного инцидента не так-то просто найти в литературе. Например, словарь ITIL говорит, что Major Incident – The highest category of impact for an incident. A major incident results in significant disruption to the business.(Значительный инцидент – Наивысшая категория влияния, применяемая инцидента. Значительный инцидент вызывает существенные потери для бизнеса.) Если Critical или Major – действительно лишь значение параметра "Impact", то не…

Роман Журавлёв, 28 февраля 2014, последний комментарий 24 апреля 2015

Измерение процессов. Incident Management. Часть 3

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

Дмитрий Исайченко, 11 января 2014, последний комментарий 7 марта 2014

Маршрутизация обращений пользователей

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

Евгений Шилов, 7 декабря 2013, последний комментарий 3 февраля 2014

О моем инциденте замолвите слово…

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

Константин Нарыжный, 1 декабря 2013, последний комментарий 11 декабря 2013

Карточные фокусы, или Победа сил разума над силами добра

Иногда процессы (процедуры/правила/формализация) берут верх над сервисами (ценностью/пользой/удовлетворённостью). То есть всё делается строго по правилам, а результат даёт обратный. Поделюсь парой примеров из недавнего опыта. Пример 1. Поддержка пользователей и устранение инцидентов. Время от времени наш ребёнок, студент одного из питерских институтов, приезжает домой в Москву. А потом уезжает обратно. Чтобы эти путешествия были чуть менее накладны, при покупке билетов мы используем карточку "Сапсан молодёжная", она даёт 15% скидки при покупке билетов на поезда Сапсан. Так получилось, что купленный на сегодняшний вечер билет мы решили поменять на сегодняшнее же, но утро. Для этого на сайте, где продаются билеты, по старому…

Роман Журавлёв, 26 октября 2013, последний комментарий 1 ноября 2013

ITIL: чтобы не отучаться, можно улучшить

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

Новостной поток, 5 сентября 2013, последний комментарий 17 сентября 2013

Отделяем инциденты от запросов

Использую на курсах аналогию, когда рассказываю о процессах управления инцидентами и выполнения запросов на обслуживание. Оцените и покритикуйте, коллеги. ITIL® пишет о том, что эти два процесса могут быть одним (как, например, в ISO 20000:2011), но лучше их разделять, потому что: Инцидент – это обычно событие неожиданное, в то время как запрос на обслуживание можно и нужно планировать… хотя «туманные» области всегда останутся… (С) ITIL Service Operation, TSO, 2011 Представьте себя владельцем новенькой автомастерской. Вы решаете задачу: сколько потребуется автомехаников, чтобы обеспечить спрос на ваши услуги? Решение должно отталкиваться от объёма и структуры этого спроса. Зачем люди приезжают в автосервис? Мне кажется, в трёх случаях:…

Константин Нарыжный, 15 августа 2013, последний комментарий 28 августа 2013

Как применить статусы, раз уж они есть?

Мария спрашивает: Как можно перевести статусы инцидентов "Pending Other (ожидание другого исполнителя?) ", "Referred (передан на рассмотрение)", " Resolved (решен)", т.е. к каким ситуациям их применять? Мы используем систему HPSM и решили расшифровать статусы для исполнителей. Быстро найти в интернете адекватную информацию не удалось. Буду благодарна за помощь! Уважаемые специалисты по адаптации жизни к HPSM и по статусам инцидентов – предлагайте варианты, пожалуйста!

Вопрос из зала, 8 августа 2013, последний комментарий 12 августа 2013

Записки с полей:Типовые заявки

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

Евгений Шилов, 31 июля 2013, последний комментарий 14 августа 2013

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

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

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