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

Запросы на обслуживание vs. Инциденты

Инцидент Запрос на обслуживание

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

В чем отличие

Что говорят лучшие практики? ITIL дает описание управления инцидентами и запросами на обслуживание в руководствах по одноименным практиками.

Начнем с назначения:

Управление инцидентами — минимизация негативного влияния инцидентов за счёт скорейшего восстановления нормальной работы услуги

Управление запросами на обслуживание — поддерживать согласованное качество услуги, выполняя все предопределённые инициируемые пользователями запросы эффективным и удобным для пользователей способом

Управление инцидентами — это деятельность, направленная на выявление, диагностику и последующее устранение прерывания или деградации качества услуги. Например: невозможность распечатать документ, отсутствие доступа к СХД, медленная загрузка страницы сайта.

Запросы на обслуживание — это обращения в Сервис Деск, не связанные с инцидентами. Исходя из назначения, это все предопределенные запросы, поддерживающие качество услуги. Например:

  • Запрос на выполнение сервисных операций (обращения по поводу замены картриджа)
  • Запрос информации (консультация)
  • Запрос на предоставление ресурса (доступ к информационной системе)
  • Обратная связь, жалоба/благодарность

Что общего

И выполнением запросов на обслуживание, и обработкой спроса на инциденты занимается Сервис Деск, а значит, что это одна и та же команда.

Ожидания пользователей относительно сроков выполнения запросов на обслуживание и инцидентов должны быть чётко обозначены и реалистичны (в SLA должны быть обозначены сроки выполнения).

Обе практики существенно влияют на удовлетворённость пользователей и заказчиков

Эффективность практик зависит от уровня взаимодействия разных команд

Зачем разделять

Несмотря на то, что эти обращения обрабатывает команда Сервис Деска и они регистрируются в одной системе ITSM (зачастую все как инциденты), важно рассматривать инциденты и запросы на обслуживание отдельно. Запросы достаточно просто выполнять в установленный срок, а инциденты надо решать как можно быстрее.

Почему это важно

Инциденты представляют собой незапланированную работу или работу, вызванную прерыванием. Доля инцидентов от общего количества тикетов в работе Сервис Деска это показатель того, как часто приходится работать в режиме «пожарной машины».

Запросы на обслуживание можно и нужно планировать. Например, при проектировании услуги мы предполагаем, что пользователям потребуется предоставить доступ к услуге, консультировать, реагировать на другие запросы, связанные с услугой.  Вся эта деятельность осуществляются в соответствии со стандартным рабочим процессом, который по большей части предсказуем. А еще лучше все подобные рутинные операции автоматизировать.

Инциденты – как маркер вашей работы

А каково соотношение инцидентов и запросов на обслуживание у вас? Отслеживаете ли вы эти параметры?

Если вы учитываете инциденты и запросы общим числом (все, как инциденты), то вам трудно будет проиллюстрировать работу Сервис Деска. Почему? Потому что:

Во-первых, управление инцидентами является источником данных для управления доступности. Запросы на обслуживания учитываемые, как инциденты, точно будут искажать статистику по доступности услуги.

Во-вторых, со временем общий тренд количества инцидентов должен снижаться. Верно? Если мы ориентированы не только на количество обработанных инцидентов, а и на качество, то сбоев должно быть меньше (а для этого должно постараться и управление проблемами). По мере совершенствования ИТ все меньше вещей должно ломаться, а тенденция к росту инцидентов указывает на обратное.

В-третьих, инциденты лучше предотвращать, а не героически устранять!

Разделив учет инцидентов и запросов на обслуживание, вы можете увидеть сами, а также показать вашим заказчикам сколько ресурсов и времени тратится на экстренность в помощи, а не “лечение”, предотвращение возникающих сбоев.

В-четвертых, отделив инциденты от запросов, можно лучше сфокусироваться на анализе информации о категории инцидентов, уровне влияния, частоте, скорости восстановления – т.е. деятельности по совершенствованию.

Запросы на обслуживание поддержка согласованного качества услуг

Рассматривая запросы, вы гораздо лучшее представляете, какой объем работ можно планировать. Стандартизация с помощью процессов и процедур помогает оптимизации и автоматизации.

В завершении

Проанализируйте свой целевой и фактический показатель решенных обращений без эскалации, т.е. на первой линии поддержки (first level resolution, FLR). Если вы не разделяете инциденты и запросы на обслуживание, то общий показатель FLR вас может вполне устраивать. Однако, ситуация может не отражать количество ваших усилий, затрачиваемых на планируемую повседневную деятельность и работу по оказании экстренной помощи вашему бизнесу.

Возможно именно здесь находится один из ваших резервов в совершенствовании работы Сервис Деска.

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 2

  • Лилия

    Огоньский пост!

    У нас часто наоборот — в запросах содержится инцидент. Например, не сформировался документ, надо его сформировать техподдержке.

    Заводится как типовой запрос на обслуживание по типовому пути.

    А мне кажется, что документ не сформировался — это отклонение от правильной работы процесса, то есть что-то пошло не так (ну явно надо бы в корзинку с инцидентами классифицировать), и надо заводить как инцидент.

    • Игорь Фадеев

      Интересный подход. В запросах содержится инцидент... А как они все же учитываются: Как запросы или инциденты?

      Согласно определению, Инцидент – незапланированное прерывание или деградация качества услуги.

      Не сформировался документ... Он формируется сам, автоматически, или вручную?

      Если вручную не формируется, то, вероятно, это м.б. запросом («подскажите, проконсультируйте, научите...сформировать документ, у меня не получается...»). Если документ формируется автоматически (по времени, по событию), и это что-то не работает так, как должно работать, то это, вероятно, инцидент.

      Все же их надо различать.


Добавить комментарий для Игорь ФадеевОтменить ответ

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM