Периодически в наших публикациях и на наших курсах поднимаются интересные вопросы, которые вызывают активный отклик и обсуждение как в аудитории, так и за ее пределами. Практически в каждой группе, обсуждая вопросы управления поддержкой, мы сталкиваемся с тем, что почти все обращения пользователей могут регистрироваться и отслеживаться как инциденты. В контексте работы Сервис Деска, у многих компаний инцидентами считаются не только ошибки аппаратного или программного обеспечения, но и запросы на обслуживание. А так ли это на самом деле? Нужно ли разделять эти два понятия и нужно ли их измерять отдельно?
В чем отличие
Что говорят лучшие практики? ITIL дает описание управления инцидентами и запросами на обслуживание в руководствах по одноименным практиками.
Начнем с назначения:
Управление инцидентами – минимизация негативного влияния инцидентов за счёт скорейшего восстановления нормальной работы услуги
Управление запросами на обслуживание – поддерживать согласованное качество услуги, выполняя все предопределённые инициируемые пользователями запросы эффективным и удобным для пользователей способом
Управление инцидентами — это деятельность, направленная на выявление, диагностику и последующее устранение прерывания или деградации качества услуги. Например: невозможность распечатать документ, отсутствие доступа к СХД, медленная загрузка страницы сайта.
Запросы на обслуживание — это обращения в Сервис Деск, не связанные с инцидентами. Исходя из назначения, это все предопределенные запросы, поддерживающие качество услуги. Например:
- Запрос на выполнение сервисных операций (обращения по поводу замены картриджа)
- Запрос информации (консультация)
- Запрос на предоставление ресурса (доступ к информационной системе)
- Обратная связь, жалоба/благодарность
Что общего
И выполнением запросов на обслуживание, и обработкой спроса на инциденты занимается Сервис Деск, а значит, что это одна и та же команда.
Ожидания пользователей относительно сроков выполнения запросов на обслуживание и инцидентов должны быть чётко обозначены и реалистичны (в SLA должны быть обозначены сроки выполнения).
Обе практики существенно влияют на удовлетворённость пользователей и заказчиков
Эффективность практик зависит от уровня взаимодействия разных команд
Зачем разделять
Несмотря на то, что эти обращения обрабатывает команда Сервис Деска и они регистрируются в одной системе ITSM (зачастую все как инциденты), важно рассматривать инциденты и запросы на обслуживание отдельно. Запросы достаточно просто выполнять в установленный срок, а инциденты надо решать как можно быстрее.
Почему это важно
Инциденты представляют собой незапланированную работу или работу, вызванную прерыванием. Доля инцидентов от общего количества тикетов в работе Сервис Деска это показатель того, как часто приходится работать в режиме «пожарной машины».
Запросы на обслуживание можно и нужно планировать. Например, при проектировании услуги мы предполагаем, что пользователям потребуется предоставить доступ к услуге, консультировать, реагировать на другие запросы, связанные с услугой. Вся эта деятельность осуществляются в соответствии со стандартным рабочим процессом, который по большей части предсказуем. А еще лучше все подобные рутинные операции автоматизировать.
Инциденты – как маркер вашей работы
А каково соотношение инцидентов и запросов на обслуживание у вас? Отслеживаете ли вы эти параметры?
Если вы учитываете инциденты и запросы общим числом (все, как инциденты), то вам трудно будет проиллюстрировать работу Сервис Деска. Почему? Потому что:
Во-первых, управление инцидентами является источником данных для управления доступности. Запросы на обслуживания учитываемые, как инциденты, точно будут искажать статистику по доступности услуги.
Во-вторых, со временем общий тренд количества инцидентов должен снижаться. Верно? Если мы ориентированы не только на количество обработанных инцидентов, а и на качество, то сбоев должно быть меньше (а для этого должно постараться и управление проблемами). По мере совершенствования ИТ все меньше вещей должно ломаться, а тенденция к росту инцидентов указывает на обратное.
В-третьих, инциденты лучше предотвращать, а не героически устранять!
Разделив учет инцидентов и запросов на обслуживание, вы можете увидеть сами, а также показать вашим заказчикам сколько ресурсов и времени тратится на экстренность в помощи, а не “лечение”, предотвращение возникающих сбоев.
В-четвертых, отделив инциденты от запросов, можно лучше сфокусироваться на анализе информации о категории инцидентов, уровне влияния, частоте, скорости восстановления – т.е. деятельности по совершенствованию.
Запросы на обслуживание – поддержка согласованного качества услуг
Рассматривая запросы, вы гораздо лучшее представляете, какой объем работ можно планировать. Стандартизация с помощью процессов и процедур помогает оптимизации и автоматизации.
В завершении
Проанализируйте свой целевой и фактический показатель решенных обращений без эскалации, т.е. на первой линии поддержки (first level resolution, FLR). Если вы не разделяете инциденты и запросы на обслуживание, то общий показатель FLR вас может вполне устраивать. Однако, ситуация может не отражать количество ваших усилий, затрачиваемых на планируемую повседневную деятельность и работу по оказании экстренной помощи вашему бизнесу.
Возможно именно здесь находится один из ваших резервов в совершенствовании работы Сервис Деска.
Огоньский пост!
У нас часто наоборот – в запросах содержится инцидент. Например, не сформировался документ, надо его сформировать техподдержке.
Заводится как типовой запрос на обслуживание по типовому пути.
А мне кажется, что документ не сформировался – это отклонение от правильной работы процесса, то есть что-то пошло не так (ну явно надо бы в корзинку с инцидентами классифицировать), и надо заводить как инцидент.