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

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

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

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

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

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

Дмитрий Исайченко, 5 сентября 2011, последний комментарий 24 октября 2022

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

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

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

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

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

Новостной поток, 9 июня 2011, последний комментарий 14 июня 2011

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

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

Дмитрий Исайченко, 2 июня 2011, последний комментарий 2 января 2020

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

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

Олег Скрынник, 11 апреля 2011, последний комментарий 13 апреля 2011

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

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

Дмитрий Исайченко, 27 марта 2011, последний комментарий 1 сентября 2014

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

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

О вреде целевых значений для KPI

Каждые выходные мы с ребёнком ходим на лыжах. Обычных, беговых. В этом году – в ближайший парк в 10 минутах от дома, хотя в прошлые годы испробовали все парки Москвы и часть – Подмосковья. Я заметил интересную вещь. Раньше мы как-то планировали время – сколько мы собираемся кататься, и от этого выбирали себе маршрут. В этом году я перестал смотреть на часы, и мы катаемся столько, сколько нам хочется, лишь в конце узнавая время. Забавно, что каждый раз получается по-разному: от часа до трёх, но каждый раз мы получаем максимум удовольствия. Вывод: отсутствие целевого значения максимизирует полезный результат. Проверено практикой….

Олег Скрынник, 18 февраля 2011, последний комментарий 2 апреля 2012

Золотая середина

Какие мы, люди, все-таки вредные. Летом нам жарко, зимой холодно; на море влажно, в пустыне сухо; гололед скользко, песок и соль грязно. Такая же беда у нас проявляется и в управлении процессами. Трудно дозвониться до первой линии – плохо, легко дозвониться, но не помогают сразу, а говорят, что разберутся и перезвонят – тоже плохо. Что делать бедным менеджерам в условиях ограниченности ресурсов? В одном из проектов решали такую задачку. Есть две метрики: "Доступность первой линии" и "Количество обращений пользователей решенных на первой линии". Понятно, что улучшение показателей по первой метрике, с учетом ограниченности ресурсов, ведет к ухудшению показателей по второй метрике….

Евгений Шилов, 17 января 2011, последний комментарий 19 января 2011

Качество ИТ-сервисов. При чем тут процессы?

Тема для обсуждения предложена читателем нашего портала. (См. раздел "Задать вопрос"). "Как с помощью ITSM-процессов улучшить качество ИТ-услуг? Есть несколько процессов. Все эти процессы, конечно, косвенно влияют на качество сервисов, инциденты решаются своевременно, проблемы не остаются без внимания, изменения не приводят к новым инцидентам. Однако, если взглянуть на статистику, то оказывается, что количество инцидентов не только не уменьшается, но даже потихоньку растет, соответственно можно сказать, что качество сервисов по основному показателю ухудшается. Корень проблемы видится в том, что имеющиеся метрики и построенная на них система мотивации нацелены исключительно на качество работы процессов (своевременная и упорядоченная обработка инцидентов, проблем и т.п.). В…

Евгений Шилов, 27 декабря 2010, последний комментарий 18 января 2011

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

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

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