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

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

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

Новостной поток, 21 декабря 2015, последний комментарий 25 декабря 2015

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

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

Новостной поток, 17 декабря 2015, последний комментарий 25 января 2017

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

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

Новостной поток, 15 декабря 2015, последний комментарий 22 декабря 2015

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

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

Решение без переназначений (опрос)

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

Дмитрий Исайченко, 14 июня 2015, последний комментарий 15 июня 2015

Герои в ИТ – повод задуматься

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

Новостной поток, 24 апреля 2015, последний комментарий 27 апреля 2015

Все на портал самообслуживания!

Недавно один из клиентов поделился достижением: "теперь у нас около 90% обращений регистрируется пользователями на портале самообслуживания, почта и телефон почти не используются". За счет этого разгрузилась первая линия, сократилось время обработки обращений, т.к. они маршрутизируются на вторую линию или во внешние компании автоматически, а данные, которые поступают от пользователя, содержат достаточно деталей из-за применения специализированных форм для разных типов обращений. Пример действительно интересный, многие к этому стремятся, но вот вопрос: везде ли достижимо такое состояние, какие условия должны быть выполнены и что нужно предпринять для того чтобы это случилось и принесло пользу, а не добавило работы? Начнем с условий, которые…

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

First Time Resolution (FTR) в разбивке по группам

В опубликованной нами книге «ITSM. Руководство по измерению» есть метрика First Time Resolution (FTR) для инцидентов, выраженная формулой 18 (страница 42). Метрика представлена в разрезе по рабочим группам, однако способ расчёта в разрезе по рабочим группам в книге подробно не рассматривается. Недавнее обсуждение показало, что это непростой вопрос, требующий некоторых пояснений. Напомним, что формула для расчета имеет вид: со следующим определением операндов: Sj — количество объектов, возвращённых на доработку в j-тую группу, Nj — общее количество объектов, обработанных за период силами j-той группы. А пояснений, собственно, всего два: по способу учёта возвратов на доработку; по определению операндов Sj и Nj….

Кто последний, тот и…

В редакцию портала поступил вопрос. Альберт, постоянный читатель и комментатор RealITSM, спрашивает: Коллеги, добрый день! Есть вопрос по определению ответственности по просрочкам в обращениях. Суть проблемы в следующем, в Service Desk настроено, что кто последний выполнил обращение, того и заявка в отчёте, но в случае же, если данное обращение просрочено, то просрочка также назначается на последнего исполнителя. На мой взгляд, это несправедливо, поскольку те сотрудники, по чьей вине обращение просрочено, избегают ответственности, передавая её на других исполнителей. Поделитесь, пожалуйста, своими идеями по данному вопросу: кто как решает данный вопрос, какие есть алгоритмы определения ответственности по просроченным обращениям? Редакция портала знает, как…

Вопрос из зала, 31 марта 2015, последний комментарий 11 апреля 2015

Инциденты, проблемы и производительность

Наверняка вам встречалась ситуация, когда конечные пользователи недовольны производительностью приложения, а внутри ИТ происходит перекладывание ответственности за "тормоза". Ответственные за программное обеспечение обвиняют ответственных за оборудование и наоборот или говорят пользователю, что так и должно быть. В чем сложность данной ситуации? 1. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными. Что делать: Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения….

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

Вопрос из зала: что делать с взаимосвязанными инцидентами?

Эльдар спрашивает у авторов и читателей нашего портала: Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну? Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей? Поделитесь опытом, коллеги?

Вопрос из зала, 18 марта 2015, последний комментарий 30 марта 2015

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

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

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