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

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

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

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

Борьба за своевременность решения

Правда, здорово, когда своевременность решения инцидентов в вашей организации составляет более 95%? Даже отраслевая статистика ниже – средний уровень своевременности решения находится на уровне 82%, и только 13% компаний добрались до лидерских 96-100% («IT Service Management Metrics Benchmarks», Pink Elephant, 2013). Так что больше 95% – это действительно круто. Или нет? Многие конечные пользователи считают, что нет. И вполне обоснованно, потому что высоких показателей своевременности несложно добиться просто увеличением целевого времени решения. И вот ИТ-отчетность вся в зеленой зоне, а пользователи жалуются – инциденты решаются неприемлемо долго. Своевременность – это косвенный показатель. Он вполне годится для процессного контроля, но с…

Major incident – когда становится горячо…

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…»  Что такое значительный инцидент? В теории значительный  инцидент – это инцидент с самым высоким влиянием и…

Управление событиями и рейтинги

Интересная идея была озвучена Аугусто Барросом (Augusto Barros), исследовательским директором Gartner в его недавней публикации в авторском блоге. Фокусом его интересов является информационная безопасность. В своей публикации он отмечает, что индустрия средств мониторинга событий и инцидентов безопасности изменилась за последние несколько лет. Ранее они работали следующим образом: одно или несколько средств отслеживания событий безопасности генерировали некоторый поток этих событий и присваивали им определенные степени критичности. Имелся некоторый пул сотрудников невысокой квалификации, которые в непрерывном режиме отслеживали этот поток и обрабатывали его в соответствии со скриптами, осуществляя требуемую эскалацию на профильные группы, а также проводя дополнительные расследования событий в силу своих возможностей.  Очевидно, что с тотальной цифровизацией такой…

Процессная математика. Скорость решения инцидентов

Назначение процесса управления инцидентами – скорейшее устранение нарушений в предоставлении услуг. Если сервисные запросы достаточно выполнять своевременно (в установленный срок), то инциденты надо решать как можно быстрее. Но KPI процесса управления инцидентами традиционно основаны именно на своевременности. Думал на тему, как можно мотивировать решать не просто вовремя, а как можно быстрее. Результаты размышлений дискуссионные, хочу мнения коллег. Собственно, «лобовой» подход прост. Для инцидентов, помимо своевременности, вводим KPI на среднее время решения. Затем для своевременности и среднего времени решения определяем целевые и граничные значения, объединяем оба показателя подходящим алгоритмом агрегирования, и задача решена. Но среднее время решения инцидентов – это очень…

Ожидания и злоупотребления

Деятельность по поддержке пользователей организована в огромном множестве компаний. И измеряется она более-менее стандартно уже много лет. Одним из основных показателей качества поддержки является метрика своевременности, которая, упрощенно говоря, определяется как доля обращений, решенных в рамках норматива, от общего количества обработанных обращений. У этой формулы есть свои изъяны, и мы много писали об этом – и на портале, и в статьях, и в нашей книге про измерение ITSM-процессов. Но сейчас не об этом. Бывает так, что исполнитель не имеет возможности обработать запрос не по своей вине, а потому что пользователь не предоставил ему всей информации, или не может обеспечить доступ в…

Открыть нельзя переоткрыть

Где в предложении, вынесенном в заголовок, нужно поставить запятую? Речь, конечно же, об инцидентах. «Переоткрывать» (reopen, повторно открывать) закрытый инцидент или открывать новый? Обсуждение этого простого вопроса регулярно возникает на курсах по ITIL, и иногда бывает довольно бурным, поскольку различные организации практикуют различные подходы. ITIL на этот счёт ограничивается следующими соображениями [ITIL v3 2011, SO, 4.2.5.10] «…разумно предопределить правила относительно того, может ли инцидент переоткрываться, и, если может, то при каких условиях. Например, может иметь смысл договориться о том, что, если инцидент снова проявляется в течение одного рабочего дня, он может быть переоткрыт, после же этого срока должен создаваться новый…

STAR WARS и Управление проблемами

Совсем недавно на нашем портале обсуждалось место процесса управления проблемами в организационной структуре, исходя из его назначения и задач. На смежную тему на портале компании EasyVista опубликована "трилогия" Кристофера Моргана (Cristopher Morgan) – "Зачем Дарту Вейдеру нужен менеджер процесса управления проблемами" ("Why Darth Vader Needed a Problem Manager"). Часть 1  Часть 2 Часть 3  В этой публикации Морган на примере катастрофы звезды смерти и других драматических сцен великой киносаги выделяет ключевые области, на которые необходимо обратить внимание при реализации этого процесса, а также ясно показывает что произойдет, если этого не сделать. Надеемся, это легкое и полезное тематическое чтение развлечет вас и если не поможет улучшить ваши процессы, то…

Не все First Call Resolutions (FCR) одинаково полезны

Иногда очень полезно возвращаться к истокам. Свежий взгляд на одну из часто используемых метрик процесса управления инцидентами в разделе блогов компании SysAid опубликовал Грег Сэнкер (Greg Sanker). Казалось бы, высокое значение широко применяемой метрики о доле обращений в службу поддержку, разрешенных с первого звонка, хорошо для всех. С этим трудно спорить, т.к. достоверно известно, что пользователи, обращения которых разрешались прямо в момент звонка куда более счастливы, чем те которым не так повезло. Высокий уровень этого показателя демонстрирует то, насколько хорошо мы справляемся с потоком обращений. При увеличении этого показателя среднее время разрешения зачастую уменьшается. Класс! А теперь если посмотреть на ситуацию глазами пользователей, то все становится совсем не так радужно. По большому счету, пользователям нужна…

Книга «Спасите сервис! Руководство по организации и совершенствованию управления инцидентами» теперь в России

Вышла в свет новая книга, посвященная ITSM и изданная в России при непосредственном участии Cleverics,— «Спасите сервис! Руководство по организации и совершенствованию управления инцидентами», создателями которой являются соавтор ITIL Николь Конбой и один из авторов метода ISM (Integrated Service Management) Ян ван Бон. Как отмечают сами авторы, эта книга — результат объединения двух дисциплин: теории и архитектуры менеджмента с одной стороны и проверенных практик — с другой. Она содержит большое количество теоретических выкладок и основ, необходимых для понимания ключевых практик управления инцидентами. Вместе с тем, большое внимание уделяется практике, а именно наиболее эффективным решениям задачи управления инцидентами, включая большой набор шаблонов,…

Service Desk: как лучше понять пользователя?

Simon Kent в своей статье предлагает поменять подход к диалогу с пользователями, обращающимися в службу поддержки. По мнению автора, службы Service Desk зачастую неправильно трактуют стоящую перед ними задачу, вследствие чего не достигают нужных результатов. Автор формулирует проблему следующим образом: службы Service Desk все свои усилия тратят на… предоставление сервисов. Чрезмерный фокус на сервисе как таковом, подкреплённый рекомендациями ITIL, по мнению автора, мешает службам Service Desk сосредоточиться на том, что реально важно при устранении инцидентов: обеспечение пользователя именно теми возможностями, которые нужны ему для осуществления своей текущей бизнес-задачи. Автор приводит следующий пример: пользователь испытывает проблемы с печатью некоего документа и…

Решение без переназначений (результаты)

В июне нами был проведён опрос «Решение без переназначений». Вопрос был поставлен следующим образом: какая доля обращений за технической поддержкой, поступающих от пользователей, решается без переназначений? Пришло время обсудить результаты. За время проведения опроса поступило 15 ответов. Маловато для статистически значимого результата (может быть, было бы правильно предусмотреть ещё один вариант ответа «Неизвестно»?). Но будем опираться на эту выборку. Тем более что результаты, на мой взгляд, вполне ожидаемы: в среднем коммерческие поставщики услуг продемонстрировали более высокий результат. Это, вероятно, вызвано двумя основными факторами. Во-первых, у коммерческих поставщиков на одного заказчика, как правило, приходится меньшее число групп. И во-вторых, коммерческие поставщики в…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;