Матрица приоритетов инцидентов: шаблон, примеры и автоматизация эскалаций по SLA

Когда в очереди стоят упавшая ERP и неработающий принтер, служба поддержки должна без споров знать, за что браться первым. Управление инцидентами решает это матрицей приоритетов инцидентов: оценки влияния и срочности дают уровень приоритета, а он задаёт сроки и правила эскалации.

Управлением инцидентами (Incident Management) называют практику, цель которой минимизировать негативное влияние инцидентов, как можно быстрее восстановив нормальную работу услуги. Инцидент при этом определяется как незапланированное прерывание услуги или снижение её качества. Обе формулировки взяты из глоссария ITIL 4 (PeopleCert / AXELOS). Назначение практики сохранено и в ITIL (Version 5), которую PeopleCert анонсировала в январе 2026 года.

В компаниях говорят «процесс управления инцидентами», ITIL 4 называет его практикой. ITIL 4 действует параллельно с новой версией, вывод его модулей намечен на 31 декабря 2027 года.

Запрос на обслуживание (Service Request) отличается от инцидента тем, что ничего не сломалось: пользователь просит выдать доступ или установить программу. Проблемой называют причину одного или нескольких инцидентов. Её ищет и устраняет управление проблемами, а управление инцидентами восстанавливает работу услуги, хотя бы обходным путём.

Этапы процесса: регистрация, классификация и назначение приоритета, диагностика, эскалация при необходимости, решение, закрытие. Приоритет назначают на втором шаге, ещё до диагностики, поэтому ошибка в нём сдвигает всю очередь.

Матрицей приоритетов инцидентов называют таблицу, которая по двум оценкам, влиянию и срочности, однозначно выдаёт уровень приоритета. Оператор отвечает на два вопроса: насколько велик ущерб и как быстро он растёт. На пересечении строки и столбца стоит приоритет, от P1 до P5, а от него зависят очерёдность работ, целевые сроки и правила эскалации.

Что даёт матрица:

· Единые правила. Очередь строится по критериям, а не по принципу «кто громче просит».

· Предсказуемые сроки. Каждому уровню соответствуют нормативы реакции и решения из соглашения об уровне обслуживания (SLA).

· Основание для эскалации. Порог считается от норматива, а не от настроения исполнителя.

· Сопоставимая отчётность. Распределение по приоритетам сравнимо между месяцами и группами, на нём строятся метрики Service Desk.

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

Влияние инцидента показывает масштаб ущерба для бизнеса: сколько пользователей и площадок затронуто, какой процесс остановлен, каковы финансовые и репутационные последствия. Срочность показывает, как быстро ущерб растёт и сколько бизнес может ждать восстановления. Влияние отвечает на вопрос «насколько плохо», срочность на вопрос «как скоро станет хуже». Массовый сбой с обходным решением и сбой у одного кассира в час пик требуют разной реакции, поэтому оси не объединяют.

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

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

· Среднее: затронуто одно подразделение, филиал или группа пользователей; услуга работает с деградацией.

· Низкое: затронут один сотрудник или некритичная функция, процесс продолжается.

Числовые пороги, например сколько пользователей считать подразделением, компания задаёт сама.

· Высокая: ущерб растёт с каждой минутой, обходного решения нет, сбой совпал с жёстким сроком бизнеса: закрытие периода, отгрузка, сдача отчётности.

· Средняя: обходное решение есть, но неудобное; ущерб нарастает в течение дня.

· Низкая: обходное решение работает, ущерб не растёт, исправление можно запланировать.

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

Ниже распространённый шаблон 3 × 3 с пятью уровнями (такой приводит, например, чек-лист IT Process Maps). Вдоль строки и столбца приоритет меняется на одну ступень, поэтому одинаковые уровни лежат на диагоналях.

· Высокое влияние + высокая срочность → P1 Критический.

· Высокое влияние + средняя срочность → P2 Высокий.

· Высокое влияние + низкая срочность → P3 Средний.

· Среднее влияние + высокая срочность → P2 Высокий.

· Среднее влияние + средняя срочность → P3 Средний.

· Среднее влияние + низкая срочность → P4 Низкий.

· Низкое влияние + высокая срочность → P3 Средний.

· Низкое влияние + средняя срочность → P4 Низкий.

· Низкое влияние + низкая срочность → P5 Плановый.

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

Вариант с четырьмя уровнями. P4 и P5 объединяют в P4 «Низкий». Так удобнее небольшой службе поддержки без очереди плановых работ.

Как адаптировать шаблон. Если бывают сбои масштаба всей организации, над строкой «Высокое» добавляют четвёртый уровень влияния, «Критическое», где P1 ставится уже при средней срочности. Для критичных услуг корректируют ячейки: скажем, инцидент на платёжной услуге не опускается ниже P3. Правки фиксируют в регламенте.

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

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

P1 часто совпадает со значительным инцидентом (Major Incident), но не равен ему автоматически. Условия объявления значительного инцидента фиксируют заранее: например, недоступность критичной услуги для всей компании, ущерб для внешних клиентов, угроза информационной безопасности. Дальше работает отдельная процедура со своим регламентом.

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

Сбой затрагивает подразделение или группу, но есть обходное решение. Работа в рабочее время в общей очереди, уведомления получают заявитель и исполнитель.

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

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

Классификация инцидентов по категории и определение приоритета решают разные задачи. Категория («что сломалось»: сеть, ERP, печать) определяет группу исполнителей, приоритет определяет порядок и скорость. Ниже восемь ситуаций, разобранных по шаблону.

· Недоступна ERP в день закрытия периода. Влияние высокое, срочность высокая, итог P1: остановлен учёт всей компании, срок не сдвинуть.

· Не работает почта у всей компании. Влияние высокое, срочность средняя, итог P2. Спорный случай: сбой массовый, но есть мессенджер и телефон. Если через почту идёт работа с клиентами, итог P1.

· Сбой кассовой системы в одном розничном магазине. Влияние среднее, срочность высокая, итог P2: выручка теряется каждую минуту; сбой во всей сети уже P1.

· Не открывается отчёт у руководителя перед советом директоров. Влияние низкое, срочность высокая, итог P3. Спорный случай: один пользователь, но критичная роль. Если регламент считает подготовку к совету критичным процессом, итог P2.

· Медленно работает CRM в одном филиале. Влияние среднее, срочность средняя, итог P3: работа идёт, но медленнее.

· Отказал один из двух серверов кластера, резерва нет. Влияние низкое, срочность средняя, итог P4. Спорный случай: пользователи сбоя не видят, но второй отказ остановит услугу. Регламент может поднимать такие случаи до P3.

· Не работает корпоративный портал с новостями. Влияние среднее, срочность низкая, итог P4: затронуты все, но работа не стоит.

· У одного сотрудника не печатает принтер. Влияние низкое, срочность низкая, итог P5: рядом есть другой принтер.

Решение по спорным случаям принимают один раз и записывают в регламент. Проверка: два оператора по одной ситуации получают одинаковый приоритет.

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

SLA фиксирует согласованные параметры услуги, включая сроки. Время реакции и время решения инцидента считают таймеры, оба запускаются при регистрации. Таймер решения встаёт на паузу, пока ждут ответа заявителя (или поставщика, если это предусмотрено SLA), и возобновляется, если заявитель не подтвердил решение. Для P1 и P2 обычно считают календарное время, для остальных рабочее.

ITIL конкретных сроков не устанавливает, значения ниже приведены как пример, а не норма ITIL. Источники здесь расходятся: у IT Process Maps решение для высшего приоритета занимает 1 час, у InvGate 4 часа.

· P1 Критический (остановлен критичный процесс всей компании): реакция 15 минут, решение 4 часа, режим 24/7.

· P2 Высокий (деградация критичной услуги или сбой у подразделения в жёсткий срок): реакция 30 минут, решение 8 часов, режим 24/7.

· P3 Средний (сбой у подразделения, есть обходное решение): реакция 2 рабочих часа, решение 1 рабочий день, рабочие часы.

· P4 Низкий (сбой у одного сотрудника): реакция 4 рабочих часа, решение 3 рабочих дня, рабочие часы.

· P5 Плановый (косметический дефект): реакция 1 рабочий день, решение по плану работ, рабочие часы.

Это пример: конкретные значения согласуются с бизнесом в SLA.

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

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

Первая линия (L1) работает как Service Desk и решает типовые инциденты. На второй линии (L2) профильные специалисты, на третьей (L3) разработчики и администраторы, дальше внешний поставщик. Инцидент передают, если у исполнителя нет компетенций или доступа либо исчерпано время линии.

Цепочка: специалист, руководитель группы, менеджер процесса, ИТ-директор. Поводы: угроза или факт нарушения SLA, нужны ресурсы или решение, которое исполнитель принять не может, жалоба заказчика.

Ниже для P1-P4 показано, кому передают инцидент и на какой доле норматива уведомляют руководителей. Пороги приведены как пример.

· P1. Функциональная эскалация: сразу на L2 и дежурного L3, при необходимости поставщику. Иерархическая: при регистрации уведомляют руководителя группы и менеджера процесса, на 50% норматива ИТ-директора и владельца услуги. Каналы: звонок, мессенджер, e-mail.

· P2. Функциональная эскалация: на L2, если L1 не решил за 25% норматива. Иерархическая: на 50% руководитель группы, на 75% менеджер процесса, при нарушении ИТ-директор. Каналы: мессенджер, e-mail.

· P3. Функциональная эскалация: на L2, если L1 не решил за 50% норматива. Иерархическая: на 75% руководитель группы, при нарушении менеджер процесса. Каналы: e-mail, уведомление в системе.

· P4. Функциональная эскалация: на L2 при нехватке компетенций L1. Иерархическая: на 90% руководитель группы. Канал: уведомление в системе.

Чем выше приоритет, тем раньше порог и быстрее канал.

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

Регламент надёжнее, когда его исполняет ITSM-система (IT Service Management, система управления ИТ-услугами), а не память оператора. Для автоматической приоритизации инцидентов в систему переносят:

· справочники влияния и срочности с критериями;

· таблицу расчёта приоритета;

· подстановку критичности услуги из каталога ИТ-услуг;

· таймеры SLA с календарями рабочего времени и праздников;

· правила эскалации по порогам;

· уведомления по каналам из матрицы эскалаций;

· маршрутизацию по группам в зависимости от категории;

· запрет ручной смены приоритета без комментария;

· отчёт по нарушениям сроков.

Классификацию обращений можно частично отдать ИИ: модель предлагает категорию и услугу по тексту, а приоритет по-прежнему считает матрица.

По данным исследования BPMSoft и Softline «ITSM 2026: карта зрелости российского рынка», 82% опрошенных крупных компаний автоматизировали управление инцидентами.

В продукте BPMSoft «Управление ИТ-услугами» управление инцидентами автоматизируется вместе с запросами, проблемами, изменениями, каталогом услуг и SLA. Всего в продукте более 20 процессов управления с учётом ITIL 4. Low-code платформа BPMSoft позволяет настроить справочники, правила и бизнес-процессы под регламент компании без программирования.

В проекте ТМК на решении ITSM box (разработка партнёра Lasmera из ГК IT Expert на платформе BPMSoft) автоматизированы процессы ITIL 4, включая управление инцидентами, и работают три линии поддержки.

Запросите демонстрацию «Управления ИТ-услугами»: покажем, как настроить приоритеты и эскалации под ваш SLA.

· Приоритет выбирает пользователь. Почти все заявки становятся срочными.

· Размытые критерии шкал. «Значительное влияние» каждый понимает по-своему, и одинаковые инциденты получают разный приоритет.

· Слишком много уровней. Операторы путаются в соседних уровнях и выбирают наугад.

· Приоритет повышают вручную, чтобы уложиться в срок. Отчёты о соблюдении SLA перестают отражать реальность, а честные P3 ждут дольше.

· Одни сроки для всех услуг. Критичная услуга получает тот же норматив, что и вспомогательная, и бизнес считает SLA формальностью.

· Эскалация без адресата и без действия. Уведомление уходит в общий ящик, и реагировать на него никто не обязан.

· Матрицу не пересматривают. После изменений в каталоге услуг критичность устаревает, а расчёт приоритета опирается на старые данные.

1. Соберите перечень услуг и вместе с владельцами определите критичность каждой.

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

3. Утвердите матрицу и сроки реакции и решения в SLA для каждой услуги или группы услуг.

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

5. Настройте в ITSM-системе справочники, расчёт приоритета, таймеры и правила эскалации.

6. Обучите первую линию на разобранных примерах, включая спорные случаи.

7. Через квартал сверьте распределение инцидентов по приоритетам с ожиданиями и скорректируйте критерии или ячейки матрицы. Дальше пересматривайте её после каждого заметного изменения каталога услуг.

Хватает четырёх или пяти уровней. Пять удобны, когда есть отдельная очередь плановых работ и косметических дефектов. Четыре подходят небольшой команде с однородным потоком обращений: P4 и P5 объединяют в один низкий приоритет. Больше пяти уровней вводить не стоит, операторы перестают их различать. Выбор фиксируют в регламенте вместе с матрицей.

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

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

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

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