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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

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

Про самый знаменитый процесс управления ИТ-услугами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Необходимые составляющие управления инцидентами

Индийский ITSM-эксперт Киран Паббатхи (Kiran Kumar Pabbathi) поделился собственными лучшими практиками процесса управления инцидентами. В структуре описания процесса, которую он предлагает, несколько разделов: Причины важности управления инцидентами (они же задачи, они же цели). Что находится в охвате процесса Что остается вне охвата процесса Матрица ролей и обязанностей RACI Обязательные составляющие успешного управления инцидентами, такие как: Отдельная процедура для значительных инцидентов Документация: планы, политика и формат отчетов Обновляемая база знаний и база известных ошибок Обязательный обзор и разбор полетов по значительным инцидентам, и регулярный анализ всех остальных Ясное понимание всеми участниками процесса целевых уровней услуг, включая услуги внешних подрядчиков Список контактных данных ключевого персонала…

Задачка: сложности с календарями

Давайте рассмотрим простую и довольно распространенную ситуацию. Допустим, Вы пообещали пользователям, что определенные виды обращений будут решаться/выполняться за 4 часа по времени рабочего дня пользователя. Предложение простое и понятное пользователям и ИТ-специалистам. Но как все усложняется, если организация живет в нескольких часовых поясах. Например: День 1. Пользователь из Владивостока в 11 утра по своему времени обратился в поддержку, первая линия решила, что надо назначить это обращение группе ИТ-специалистов в Москве. Но в это время в Москве еще 3-00 и ИТ-специалисты еще не начали свою работу. Придя в 9 утра по московскому времени на работу, ИТ-специалисты провели диагностику, выявили причину и отправили обращение ИТ-специалистам Владивостока для применения локального решения. Допустим, у них на…

Наконец-то: новые экзамены ITIL 2011 на русском языке

Долгожданные новости поступают из компании APMG, официального (на текущий момент) распорядителя экзаменационной линейки ITIL.  В конце апреля все экзаменационные институты получили извещение о готовности перевода ряда экзаменов на различные мировые языки. В частности, говорится в нем о русифицированных ITIL Intermediate RCV и OSA. 28 мая 2013 года будут опубликованы пробные, а еще чуть позже экзаменационным институтам предложено продавать настоящие экзамены на нашем родном языке. Сроки локализации остальных экзаменов ITIL пока не разглашаются. Мы будем держать вас в курсе развития событий и с удовольствием поможем подготовиться к экзаменам на литературном русском языке.

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM