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

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

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

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

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

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

Олег Скрынник, 30 ноября 2011, последний комментарий 1 сентября 2014

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

Поступил очередной интересный вопрос от постоянного читателя. По согласованию с ним, мы выносим ситуацию на публичное обсуждение: Внедряем 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

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

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

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