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

В чем отличие

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

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

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

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

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

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

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

Что общего

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В завершении

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

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