SLA для инцидентов и запросов: почему дедлайны должны быть разные

Чем отличается incident от service request

В ITIL это два разных процесса:

Incident — незапланированное прерывание или ухудшение сервиса. Что-то сломалось, что должно работать. Примеры:

• Не работает почта (Outlook не подключается)
• 1С перестала запускаться
• Принтер не печатает
• VPN отвалился
• Файлы пропали с общей папки

Service Request — запрос на стандартное изменение или предоставление. Что-то надо сделать, причём это нормальная операция. Примеры:

• Установить Adobe Reader
• Дать доступ к сетевой папке
• Создать почтовый ящик новому сотруднику
• Заказать новый ноутбук
• Сменить настройку в учётной записи

Принципиальная разница: incident — это потеря, которую нужно восстановить. Запрос — это плановое действие. Природа разная → и реакция нужна разная.

Почему дедлайны должны быть разные

Три причины:

1. Цена простоя. При инциденте бизнес теряет деньги каждый час. Пока 1С не работает — бухгалтер не может выставить счёт, операционка стоит. При запросе бизнес ничего не теряет, кроме «удобства»: Adobe Reader не критичен, можно открыть PDF через браузер.

Конкретный пример: 1 час простоя 1С для отдела бухгалтерии на 5 человек = ~7 500 руб потерь (5 чел × 1500 руб/час). А Adobe Reader, который ставят 3 дня — это не «потери», это «неудобство».

2. Эмоциональное состояние пользователя. При инциденте человек уже под стрессом — у него «горит». При запросе он спокойно подаёт заявку, понимая, что это плановая работа. Разные SLA соответствуют разным ожиданиям.

3. Распределение ресурсов команды. Если все заявки имеют одинаковый SLA «4 часа на реакцию», команда не может приоритизировать. Все одинаково «горящие». В итоге кто-то берёт что хочет, и реальные инциденты лежат, пока кто-то ставит Adobe Reader.

Матрица SLA для двух типов

Типовая матрица для внутренней корпоративной поддержки:

Сразу видно: при одинаковом приоритете «High» дедлайн на инцидент — 8 рабочих часов, на запрос — 2 рабочих дня (16 часов). Это в 2 раза. И это правильно.

Для запросов часто вообще не определяют Critical — потому что критического запроса не бывает. «Срочно установите Adobe» — это либо непонимание, что Adobe не критичен, либо это на самом деле инцидент (например, «нужно открыть документ для сделки» = инцидент с открытием PDF, не запрос на установку).

В TIQQET SLA настраивается отдельно для типа Incident и типа Service Request на уровне услуги, и для каждого приоритета свой дедлайн. Это даёт правильную картину сразу.

Почему часто всё-таки смешивают

На практике многие helpdesk-внедрения используют единый SLA для обоих типов. Причины:

1. Сложность настройки. Делать раздельные SLA = больше правил, больше шансов ошибиться
2. Сложность для пользователя. Пользователь не знает, инцидент это или запрос, и не должен этого решать
3. Категоризация в момент создания. Кто и когда отнесёт заявку к incident или request? Если оператор — это его дополнительная работа

Эти проблемы решаются:

• Пользователь выбирает услугу, а не «тип заявки». «Установка ПО» → автоматически Service Request. «Не работает 1С» → автоматически Incident.
• Тип определяется автоправилами на основе категории/услуги или ключевых слов в теме
• Триаж первой линии при необходимости меняет тип (5 секунд работы)

Главный аргумент в пользу разделения: через 3 месяца разделения SLA метрики становятся осмысленными. Видно, что 95% инцидентов решено в SLA (хорошо), и 60% запросов в SLA (вот тут проблема, не хватает ресурсов на плановые задачи). С единым SLA вы видели бы одну общую цифру «78% в SLA» и не понимали, что критично.

Как внедрить раздельные SLA

Поэтапный план:

1. Анализ текущих заявок — взять выборку 200 закрытых заявок и пометить тип (incident или request). Это покажет реальное распределение и насколько часто типы перепутаны сейчас
2. Категоризация услуг — пройти по списку услуг и назначить каждой дефолтный тип. «Установка ПО» = request, «не работает X» = incident
3. Настройка SLA — две матрицы дедлайнов (для инцидентов жёстче, для запросов мягче)
4. Пилот на 1-2 неделю — посмотреть, как работает, скорректировать
5. Обучение операторов — 30-минутная встреча с примерами «вот этот тикет это incident, вот этот — request, потому что...»
6. Регулярный аудит — раз в месяц смотреть выборку и проверять, корректно ли оператор отнёс

Через 2-3 месяца раздельные SLA становятся естественными, и команда удивляется, как раньше работали с одним.