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

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

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

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

Измеряем Incident management

Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management». Примеров метрик по процессу управления инцидентами множество. Пожалуй, это самый изученный с точки зрения измерения процесс ITSM. Однако в очередном проекте мы в который раз столкнулись с вопросом: как реализовать метрику, которая бы показывала долю ответственности заданной группы поддержки в нарушении сроков обработки инцидентов. Вопрос давний и непростой. Сложности связаны с тем, что в обработке одного инцидента могут принять участие несколько групп (за счёт функциональной эскалации). Традиционное решение «вешать просрочку» на последнюю группу, обрабатывавшую инцидент, обладает рядом очевидных минусов. В самом деле, эта группа могла получить…

Разработка и эксплуатация

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

Service Desk снова всех спасает и выручает

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

Посчитаем срок решения инцидента?

Поступил очередной интересный вопрос от постоянного читателя. По согласованию с ним, мы выносим ситуацию на публичное обсуждение: Внедряем ServiceDesk в своей организации с 400+ пользователями, учитывая рекомендации ITILv3 Очереди не используются, в связи с малым количеством пользователей и сотрудников СТП (3 человека на тех поддержке), кроме этого есть программисты и аналитики в самом отделе. Количество инцидентов=100/месяц Столкнулся с показателями, не понятно, что считать за время решения инцидента в некоторых ситуациях: 1. Пользователь запросил для некой автоматизированной системы ввести некую "фичу". После анализа выяснилось что требуется доработка ПО, что займет 2 недели. Запрос передан программисту, который выполнил данный запрос. 2. Пользователь…

Инциденты и проблемы

В очередной раз в обсуждении с заказчиком я сталкиваюсь с серьёзным непониманием отличий процесса управления проблемами от управления инцидентами. Корневых причин такого непонимания (простите за каламбур) я вижу две: невнятный текст про взаимодействие этих процессов в книгах ITIL (в частности, однозначная рекомендация привлечения PRB к решению major-инцидентов) и отсутствие специфичных алгоритмов обработки проблем в средствах автоматизации процессов ITSM, по которым зачастую осознают процессы как заказчики, так и консультанты. Размышляя об этом явлении, хотел бы сформулировать основные отличия этих процессов. Главный тезис заключается в том, что процесс управления проблемами – это не «медленный» инцидент-менеджмент и не «другой» инцидент-менеджмент, который работает по…

Неописуемые инциденты

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

Советы по приоритетам

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

Управление инцидентами и запросами пользователей

Уже давно бродит эта тема. А последней каплей стало то, что за последние 2-3 недели я обсуждал её 3 (!) раза с разными людьми. И так, вопрос: «Насколько осмысленно (или в каких случаях) выделять обработку сервисных запросов и управление инцидентами в отдельные процессы»? За: Соответствие ITIL v3. Строго говоря, тут надо учесть, что понятие «процесс» в ITIL v3 используется довольно неоднозначно. Но средства автоматизации ITSM-процессов «меряются» количеством процессов, а значит для вендоров – это плюс. И раз уж заговорили про вендоров ITSM-продуктов, надо упомянуть, что такое деление (на инциденты и сервисные запросы) стимулируется рядом программных продуктов, в которых сервисные запросы…

Думать о клиенте

Мне казалось, что та байка давно осталась в прошлом. Помните, когда ИТ-служба запрашивает по электронной почте подтверждение о восстановлении работы той самой электронной почты? Оказывается, мир ещё не ушёл вперёд. Свежий случай приключился сегодня при общении с известной компанией, предоставляющей беспроводной доступ в Интернет почти по всей Москве и большой части Подмосковья. Высокие технологии, высокая скорость, всё как положено. Только вот скорость неожиданно упала до 10 кбит/с, с постоянными разрывами соединения. На этот случай техническая поддержка предложила замечательное решение – скачать и установить обновление размером 21 мегабайт. Желающие могут сопоставить размер обновления и скорость, получив время решения проблемы, измеряемое почти…

Разрушители легенд: приоритеты и сроки инцидентов

Внимательно читаем ISO 20000 и не перестаем удивляться. Часть 2, страница 20, черным по белому: "Targets for resolution should be based on priority." Мне неизвестно, откуда взята эта рекомендация (в ITIL я такого утверждения не помню). И хорошо, что не в первой части стандарта (то есть не требование, а рекомендация). И так, легенда: срок инцидента должен рассчитываться на основании приоритета. В моем понимании это – широко распространенное заблуждение и пример серьезного непонимания модели определения приоритета на основании уровня влияния и срочности, описанной в ITIL. По идее приоритезация работ (любых, не только устранения инцидентов) должна способствовать своевременности их исполнения. Однако расчет…

Подгоняем метрики под “ответ”

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM