Классификация обращений: инциденты, запросы, проблемы, изменения

Зачем классифицировать обращения

На первый взгляд всё просто: «пользователь попросил — мы сделали». На практике разные типы обращений требуют разных процессов. Инциденту нужно быстрое восстановление работы. Запросу — типовая процедура выполнения. Проблеме — глубокий анализ корневой причины. Изменению — согласование и оценка рисков.

Правильная классификация с самого начала даёт четыре эффекта:

• Корректный SLA. Восстановить критичный сервис за 2 часа и согласовать изменение в инфраструктуре за 2 недели — разные процессы с разными дедлайнами.
• Правильная маршрутизация. Инцидент идёт на дежурную линию, сервисный запрос — на команду выполнения, изменение — к владельцу процесса изменений.
• Осмысленная отчётность. Метрики по инцидентам (MTTR, доступность) и по запросам (время выполнения, объём) измеряются разными формулами.
• Профилактика. Анализ повторяющихся инцидентов выявляет проблемы — их можно решить на системном уровне, а не чинить по кругу.

Инцидент (Incident)

Определение по ITIL 4: неплановое прерывание или ухудшение IT-услуги. Любая ситуация, когда сервис не работает так, как должен.

Цель процесса: максимально быстро восстановить нормальную работу услуги. Необязательно устранить корневую причину — иногда достаточно временного решения (workaround), чтобы пользователь мог продолжить работу.

Примеры инцидентов

• Не работает электронная почта у отдельного пользователя
• Корпоративный портал недоступен для всех
• Принтер печатает с полосами
• Ноутбук не загружается
• Программа 1С выдаёт ошибку при проведении документа
• Замедлилась работа CRM для целого подразделения

Приоритизация инцидентов

Приоритет инцидента определяется по двум шкалам: impact (сколько пользователей затронуто) и urgency (насколько срочно нужно решение). Матрица — в статье о SLA.

Сервисный запрос (Service Request)

Определение: формальный запрос от пользователя на что-то стандартное — доступ, услугу, информацию, оборудование. В отличие от инцидента, ничего не сломано — просто пользователь хочет новую возможность.

Цель процесса: выполнить запрос по заранее описанной процедуре.

Примеры сервисных запросов

• Создание новой учётной записи для нового сотрудника
• Доступ к общей папке или информационной системе
• Установка стандартного ПО на рабочую станцию
• Выдача ноутбука командированному сотруднику
• Перенос корпоративной почты на новое устройство
• Расчёт отпускных в кадровой системе

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

Проблема (Problem)

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

Цель процесса управления проблемами: найти и устранить первопричину повторяющихся инцидентов. Это не про скорость — это про стратегическое снижение количества сбоев в будущем.

Примеры проблем

• Каждую среду около 14:00 замедляется работа базы данных (корневая причина: пересекающийся бэкап и плановая задача)
• У пользователей определённой модели ноутбука часто «зависает» Outlook (корневая причина: конфликт версий драйвера и Exchange-плагина)
• Нестабильная работа беспроводной сети в конференц-зале (корневая причина: физическое расположение точки доступа)

Управление проблемами делится на два режима:

• Реактивный — по факту серии инцидентов запускается расследование корневой причины.
• Проактивный — анализ тенденций и инфраструктуры с целью предсказать потенциальные проблемы заранее.

Временные решения (workaround)

Пока корневая причина не устранена, используется обходное решение — способ продолжить работу, несмотря на проблему. Workaround документируется в базе знаний: L1 и L2 обращаются к нему при повторении инцидентов. Это напрямую повышает FCR (см. KPI поддержки).

Изменение (Change)

Определение: любое добавление, модификация или удаление элемента IT-услуги или инфраструктуры, способное повлиять на её работу.

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

Три типа изменений (ITIL 4)

1. Стандартные изменения — низкий риск, типовая процедура. Не требуют отдельного согласования каждый раз — есть предварительно утверждённый шаблон. Например: плановое обновление антивирусных баз.
2. Нормальные изменения — требуют анализа и согласования. Например: обновление версии корпоративной CRM.
3. Экстренные изменения — проводятся срочно для устранения критичного инцидента или устранения угрозы безопасности. Согласование в упрощённой процедуре, но обязательно постфактум-разбор.

Примеры изменений

• Обновление версии операционной системы на серверах
• Добавление нового почтового домена
• Развёртывание нового модуля в ERP-системе
• Замена сетевого коммутатора в филиале
• Миграция базы данных на новое хранилище
• Изменение политики паролей в Active Directory

Сводное сравнение четырёх типов

Как правильно классифицировать на приёме

Оператор L1 при регистрации обращения задаёт пользователю два вопроса:

1. «Что-то перестало работать или работает хуже?» Если да — это инцидент. Дальше определяется приоритет.
2. «Вам нужно что-то новое или дополнительное?» Если да — это сервисный запрос. Подбирается шаблон.

Если ни один из вопросов не подходит, возможно, это требование изменения (например, «нам нужна новая политика доступа») — тогда обращение регистрируется как Request for Change (RFC) и идёт в процесс управления изменениями.

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

Типовые ошибки классификации

• Всё — инциденты. «Мы не делим на типы, всё у нас заявки» — звучит просто, но убивает отчётность и приоритизацию. Доступ к папке обрабатывается не так, как сбой почтового сервера.
• Инциденты регистрируются как проблемы. Приводит к тому, что процесс управления проблемами захлёбывается в рутине, а реальный анализ корневых причин не проводится.
• Изменения обрабатываются как запросы. Опасная практика: внесение изменения в продакшн без оценки рисков. Рано или поздно — инцидент по вине плохо продуманного изменения.
• Один тикет — несколько типов. Пользователь написал «не работает почта, и заодно создайте учётку новому сотруднику». Правильно — два обращения: инцидент и запрос.

Поддержка в ITSM-системе

Классификация должна быть удобной в инструменте:

• При создании заявки пользователь выбирает тип из понятного списка (не более 4–5 позиций) или описание проблемы автоматически подсказывает тип.
• Для сервисных запросов — каталог шаблонов с предзаполненными полями и согласованиями.
• Для инцидентов — простая форма с обязательным полем «что ожидалось vs что происходит».
• Для изменений — отдельная форма с полями оценки рисков, планом отката, окном работ.
• В отчётности — возможность разделять метрики по типам обращений.

Подробно о каталоге услуг и формах в нашей системе.

Вывод

Классификация обращений — это не академическая игра, а способ выстроить разумные ожидания и метрики. Четыре базовых типа (инцидент, запрос, проблема, изменение) покрывают 99% задач. Главное — единообразие: если разные операторы по-разному классифицируют одинаковые обращения, данные бесполезны.

Начните с описания 10–15 самых частых типов обращений у вас и их сопоставления с четырьмя базовыми категориями. Остальное добавляйте по мере появления. И не бойтесь менять классификацию обращения в ходе работы — если в процессе стало понятно, что это не запрос, а инцидент, корректируйте и идите дальше.