Система управления инцидентами: как выбрать
Кратко
Система управления инцидентами — программа, в которой каждый сбой или обращение фиксируется как отдельная запись с номером, статусом, приоритетом и сроком реакции, вместо того чтобы жить в почте или личных чатах сотрудников. Выбирают её по способности пройти полный цикл инцидента без потерь: принять из нужного канала, назначить ответственного, посчитать срок по рабочим часам, зафиксировать закрытие в аудите. Ниже — на что смотреть и как это проверить, а не поверить на слово описанию на сайте поставщика.
Актуально на 23 сентября 2026 года.
Что такое инцидент в этом контексте
Инцидент — событие, при котором услуга или процесс работает не так, как должен: не работает форма на сайте, клиент не может дозвониться, сотрудник не может войти в программу. Это не то же самое, что запрос на обслуживание (плановая просьба выдать доступ или оборудование) — разница разобрана в статье Инцидент или запрос на обслуживание: в чём разница. Не путать также с «проблемой» в терминологии ITIL — причиной, порождающей повторяющиеся инциденты: разбор — в статье Инцидент и проблема: разница в ITIL. Смешивать эти два потока в одной очереди без разметки — типичная причина, по которой отчёты о времени реакции не сходятся с ощущениями команды.
Из чего состоит система управления инцидентами
| Компонент | Зачем нужен | Как проверить на демо |
|---|---|---|
| Регистрация из всех каналов | Инцидент не теряется независимо от того, откуда пришло сообщение | Отправьте обращение из каждого нужного канала — почта, мессенджер, форма — и убедитесь, что каждое стало отдельной карточкой |
| Статусы и переходы между ними | Видно, на каком этапе обработка, и нельзя закрыть необработанный инцидент | Проверьте список статусов и правила, из какого в какой можно перейти |
| Приоритет | Разные сроки для критичного сбоя и мелкой неполадки | Задайте два инцидента с разным приоритетом и сравните расчётный срок |
| SLA по рабочим часам | Срок не выдаёт ложную просрочку по ночам и выходным | Создайте инцидент вечером и проверьте, с какого момента считается срок |
| Пауза счётчика | Срок не идёт, пока ответственность на стороне клиента | Переведите инцидент в статус ожидания ответа и проверьте, остановился ли счётчик |
| Эскалация | Просроченный или критичный инцидент не остаётся незамеченным | Смоделируйте просрочку и проверьте, получает ли руководитель уведомление |
| Журнал аудита | Видно, кто и когда менял статус, приоритет или исполнителя | Смените статус и приоритет тестового инцидента, откройте журнал и проверьте запись |
| Отчёт по инцидентам | За минуту видно число открытых, просроченных и среднее время закрытия | Откройте отчёт за прошлый месяц и сравните с ручным подсчётом по десяти карточкам |
Как считать среднее время закрытия инцидента
Формула простая, но в ней часто путают числитель со знаменателем:
Среднее время закрытия = сумма (время закрытия − время регистрации) по всем закрытым инцидентам / число закрытых инцидентов
Пример на пяти инцидентах с временем закрытия в часах: 2, 5, 1, 24, 3. Сумма — 35 часов, среднее — 7 часов. Единственный инцидент с 24 часами утроил среднее значение по группе — поэтому рядом со средним временем всегда стоит смотреть на медиану и на долю инцидентов, вышедших за целевой срок, иначе один затянувшийся случай маскирует хорошую работу по остальным.
Частые ошибки при выборе
- Считать любую систему заявок системой управления инцидентами. Без приоритета, SLA по рабочим часам и паузы счётчика это просто список обращений — сроки в отчётах будут неточными.
- Не проверять эскалацию заранее. Правило «руководитель узнаёт о просрочке автоматически» либо есть, либо его придётся строить руками поверх системы — это разная стоимость внедрения.
- Забыть про аудит. Без журнала действий нельзя разобрать спорную ситуацию — кто закрыл инцидент раньше времени и почему.
- Смешать инциденты и плановые запросы в одном потоке без разметки — отчёт по срокам реакции станет бессмысленным, потому что у двух разных типов задач разная нормальная скорость обработки.
Как это устроено в TehProf.kz Support
Заявка проходит через фиксированный набор статусов — «Новая», «В работе», «Ждём клиента», «На согласовании», «Выполнена», «Отменена» и другие, с явно заданными допустимыми переходами между ними (конечный автомат, не произвольная смена статуса). Статус «Ждём клиента» останавливает счётчик SLA — срок не растёт, пока ответственность на стороне клиента. Приоритет и сроки настраиваются по рабочему графику компании. Каждая смена статуса, приоритета или исполнителя фиксируется в разделе «История» — журнале аудита с фильтрами по пользователю, действию и дате; срок хранения записей зависит от тарифа: 7 дней на Free, 30 на Starter, 90 на Pro, 365 на Business, без ограничения на Enterprise. Подробно — в статьях Статусы заявок и История / Аудит.
Частые вопросы
Чем система управления инцидентами отличается от обычного списка заявок?
Наличием приоритета со своим сроком, счётчика SLA, который считается по рабочим часам и умеет останавливаться, и журнала аудита действий. Список заявок без этих трёх вещей не даёт честного отчёта о скорости реакции.
Нужна ли автоматизированная система управления инцидентами малому бизнесу?
Да, если обращения приходят больше чем из одного канала или их больше десятка в день — тогда ручной учёт в таблице или почте начинает терять часть обращений незаметно. Размер системы должен соответствовать размеру команды: избыточные процессы ITSM для двух-трёх операторов создают больше бюрократии, чем пользы.
Как проверить, что средства управления инцидентами действительно останавливают счётчик на выходных?
Создайте тестовый инцидент вечером пятницы с рабочим графиком «пн–пт, 9:00–18:00» и посмотрите, с какого момента система начинает отсчёт срока — таймер должен стартовать в понедельник утром, а не сразу при создании.
Что делать, если инциденты и плановые запросы смешаны в одной очереди?
Развести их через отдельный признак — тип обращения или отдельная очередь — и считать сроки реакции раздельно. Разница в природе двух типов задач разобрана в статье Инцидент или запрос на обслуживание: в чём разница.
Связанные статьи
- Что такое ITSM-система простыми словами
- ITIL: что это простыми словами
- Что такое helpdesk-система и как она работает
- Настройка SLA, приоритетов и крайнего срока
Нужна поддержка, которая так и работает?
TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.