Сервисные запросы без путаницы: где заканчивается запрос и начинается инцидент

В Service Desk большая часть обращений пользователей сводится к двум ситуациям: человек хочет получить что-то предусмотренное ИТ-службой или сообщает, что привычный сервис перестал работать. На практике эти обращения нередко попадают в одну очередь и обрабатываются по одинаковым правилам.

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

Сервисный запрос и инцидент: главное различие

Сервисный запрос — обращение пользователя за стандартной услугой, информацией или доступом, предоставление которых заранее предусмотрено ИТ-службой. Например, сотруднику нужен доступ к информационной системе, установка согласованного программного обеспечения или новое рабочее место.

Инцидент возникает, когда нормальная работа сервиса нарушена или существенно ухудшилась. Пользователь не просит предоставить новую услугу — он сообщает, что существующая работает неправильно.

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

Например, «предоставить доступ к системе» — запрос. «Вчера доступ был, а сегодня система не принимает учетные данные» — уже инцидент.

Почему нельзя обрабатывать их одинаково

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

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

Возникают проблемы и с отчетностью. Руководитель видит общее количество заявок, но не понимает, какая часть нагрузки связана со сбоями, а какая — с предоставлением стандартных услуг.

Какие обращения относятся к сервисным запросам

В каждой организации набор зависит от каталога услуг и внутренних процессов. Чаще всего к сервисным запросам относятся:

• создание и изменение учетных записей;
• предоставление или изменение прав доступа;
• установка разрешенного программного обеспечения;
• выдача оборудования и периферии;
• подключение к корпоративным ресурсам;
• запрос информации или консультации;
• организация стандартного рабочего места;
• выполнение типовых административных операций.

Главный признак — процедура заранее известна. Можно определить необходимые данные, исполнителей, согласующих, нормативный срок и ожидаемый результат.

Именно поэтому Service Request Management хорошо поддается автоматизации.

Где проходит граница в неоднозначных случаях

По формулировке пользователя определить тип обращения удается не всегда. Фраза «нужен доступ к CRM» может означать и новый запрос, и потерю ранее предоставленного доступа.

Классификацию лучше строить не по отдельным словам, а по фактической ситуации. Если пользователь никогда не имел доступа и хочет его получить — это сервисный запрос. Если доступ был предоставлен и перестал работать без запланированного изменения условий — необходимо зарегистрировать инцидент.

Другой пример — оборудование. Запрос нового монитора по утвержденной процедуре относится к предоставлению услуги. Если действующий монитор перестал включаться, речь идет о нарушении нормальной работы и требуется обработка инцидента.

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

Как Service Request Management связан с каталогом услуг

Service Request Management — практика управления сервисными запросами от регистрации до выполнения и закрытия. Чем более типовым является запрос, тем меньше ручных решений должно требоваться от службы поддержки.

Основой для этого становится каталог ИТ-услуг. Пользователь выбирает готовую услугу на портале самообслуживания и заполняет форму с необходимыми параметрами. Для предоставления доступа система может запросить название приложения и требуемую роль, для выдачи оборудования — тип устройства и подразделение сотрудника.

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

Нужен ли сервисным запросам SLA

Стандартные запросы тоже должны иметь контролируемые сроки. Однако SLA для них необязательно строить по тем же правилам, что и для инцидентов.

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

Такой подход делает обязательства понятными. Пользователь еще при выборе услуги может видеть ожидаемый срок исполнения, а Service Desk — автоматически контролировать его соблюдение.

Маршрутизация сервисных запросов

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

Еще больше времени экономит автоматизация стандартных операций. После получения необходимых согласований некоторые действия могут выполняться без участия специалиста либо запускать интеграционный сценарий.

При этом автоматизировать стоит устойчивый процесс. Если один и тот же запрос каждый раз требует индивидуального решения и непредсказуемого набора согласований, сначала необходимо разобраться с самой процедурой, а уже затем переносить ее в Service Desk.

Что дает правильная классификация

Отдельный учет инцидентов и сервисных запросов делает работу поддержки прозрачнее. Можно оценивать количество реальных сбоев, нагрузку от типовых операций, соблюдение разных SLA и востребованность услуг.

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

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

Сервисные запросы в ИнфраМенеджер

В ИнфраМенеджер сервисные запросы можно связать с каталогом услуг, формами регистрации, маршрутами согласования, ответственными подразделениями и SLA. Пользователь выбирает нужную услугу через портал самообслуживания, а дальнейший процесс строится по установленным для нее правилам.

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

7