Инцидент или запрос на обслуживание: в чём разница

Кратко

Инцидент — незапланированное событие: работало и перестало, или работает хуже обещанного. Запрос на обслуживание — плановая просьба о стандартном действии: доступ, учётная запись, консультация, оборудование. Разделяют их потому, что у них разная цель (восстановить против выполнить), разная срочность и разный порядок работы; смешивание превращает очередь в кашу, где срочное неотличимо от рутинного.

Определение через вопрос

Отличить одно от другого проще всего одним вопросом: было ли обещано, что так будет работать?

Если было и перестало — инцидент. Если не было и человек просит, чтобы стало, — запрос.

Граничный случай, который вызывает больше всего споров: «никогда не работало». Формально это не инцидент — ничего не ломалось. Практически с этим надо обращаться как с инцидентом, если функция обещана, и как с запросом на изменение, если не обещана. Разбирается это в одну строку вопросом «а должно было?».

Почему их не стоит смешивать

Три следствия, каждое из которых видно на практике.

Разные цели. У инцидента цель — восстановить работу как можно быстрее, пусть даже обходным путём. Причину можно найти потом. У запроса цель — выполнить правильно и полностью; спешка тут вредна, потому что неправильно выданный доступ хуже, чем выданный на час позже.

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

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

Практический выигрыш от разделения самый прозаический: срок для запроса можно обещать честно. «Доступ заводим за 4 рабочих часа» — выполнимое обещание, потому что шаги известны. «Любую проблему решаем за 4 часа» — нет.

Что меняется в настройке системы

Минимум, который стоит развести:

• Разные сроки. У инцидентов сроки от приоритета (см. Приоритет заявки), у запросов — фиксированные по типу запроса.
• Разная маршрутизация. Инциденты идут на дежурную линию, запросы — тому, кто их выполняет, часто в другое подразделение.
• Согласование только у запросов. Инцидент не согласовывают, его чинят. Требование согласовать восстановление работы — самая дорогая ошибка в устройстве службы.
• Разные отчёты. Смешанный отчёт по времени решения бессмыслен: он складывает пятиминутные пароли с трёхдневными диагностиками.

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

Что такое проблема и где она здесь

Третье понятие, которое часто путают с инцидентом.

Инцидент — этот пользователь не может работать сейчас.

Проблема — причина, из-за которой инциденты этого класса повторяются.

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

Практический порог, с которого стоит заводить отдельную запись о причине: третий однотипный инцидент за месяц. Раньше — преждевременно, случайность; позже — вы уже платите за неё регулярно. Подробнее о том, как из этого вырастает полноценная служба сервиса, — в статье Чем helpdesk отличается от service desk.

Частая ошибка: тип выбирает клиент

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

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

Рабочая схема другая:

• клиент выбирает тему, а не тип: «вход», «оплата», «доступы», «отчёты». Тему он знает;
• тип определяет служба при приёме, за пару секунд, по вопросу «было ли обещано, что так будет работать»;
• на входе действует безопасное умолчание: всё неразобранное считается инцидентом. Ошибиться в эту сторону дешевле: запрос, полежавший как инцидент, никому не вредит, а инцидент, полежавший как запрос, — это человек, который не может работать и которому никто не спешит.

Как проверить за полчаса

• Возьмите 50 последних обращений и проставьте тип заново, вручную. Доля запросов обычно удивляет: в службах, обслуживающих внутренних сотрудников, она часто больше половины.
• Посчитайте время решения отдельно по инцидентам и по запросам. Если раньше вы смотрели общее число — вы не смотрели ни на что.
• Найдите три самые частые темы среди инцидентов. Это кандидаты в проблемы, и заниматься надо ими, а не скоростью закрытия.
• Проверьте, требуется ли согласование где-нибудь на пути инцидента. Если да — это место, где люди ждут разрешения починить.

Связанные статьи

• Что такое тикет и как работает тикет-система
• Приоритет заявки: как его определяют через влияние и срочность
• Чем helpdesk отличается от service desk
• Статусы заявок