Все заявки в ИТ-службу «средние» или все «срочные»: где заканчивается ответственность заказчика и начинается приоритизация

В HelpDesk ИТ-службы группы компаний 1 245 заявок из 1 297 имели приоритет «Средний». Не потому, что всё было средним: в 31 заявке текст содержал «срочно», «критично», «простой», «блокирует работу» — и 27 из них тоже стояли как «Средний». Шкала приоритетов существовала в системе, но не использовалась.

При этом скорость не пострадала: 81,5% заявок закрывались в пределах суток. Как так? Ответ на этот вопрос мы нашли при разборе всего массива заявок, и он одновременно успокаивает и настораживает.

Что такое приоритизация заявок: влияние и срочность. Приоритет заявки в ИТ-службу складывается из двух независимых оценок: влияния — что остановилось и у скольких людей — и срочности — стоит ли работа прямо сейчас или есть обход. Влияние знает только заказчик; перевод его в класс события, срок и маршрут — ответственность службы. Когда обе роли записаны в договоре, спор о сроках заканчивается до того, как начался.

Почему скорость не пострадала

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

• затронутый сервис — остановка 1С, почты или доступа к облаку выше, чем периферия;
• число затронутых пользователей — сбой сети в офисе выше, чем один ноутбук;
• ключевые слова обращения — «не работает у всех», «не можем отгружать», «простой».

Это работало. Опытная первая линия ранжирует очередь лучше формальной шкалы, потому что видит контекст, а не поле в форме. Именно поэтому при неработающей шкале служба оставалась быстрой.

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

Две крайности и их цена

«Всё среднее». Внутренняя приоритизация — неявная договорённость. Пока обе стороны довольны, её не видно. Как только возникает спор о сроке — «почему мою заявку делали три дня?» — сослаться не на что. В договоре записано «Средний», в договоре записан срок для «Среднего», срок соблюдён. Заказчик прав по ощущениям, служба права по документу, и оба недовольны.

«Всё срочно». Обратная крайность возникает, когда заказчик понимает, что приоритет влияет на срок, и начинает помечать срочным всё подряд. Дальше — развилка. Либо служба перестаёт различать заявки и возвращается к внутренней приоритизации (см. предыдущий пункт). Либо она честно относится к каждой «срочной» как к остановке процесса — и тогда должна держать штат под пиковую одновременную нагрузку. Стоимость сопровождения при этом растёт кратно, а платит за неё заказчик.

Ни одна из крайностей не защищает ни заказчика, ни исполнителя. Выход — разделить ответственность.

Кто за что отвечает

Разделение простое, и его стоит записать в договоре.

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

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

Заказчик не должен разбираться в классах событий. Служба не должна угадывать, что стоит за словом «срочно». Матрица делает это разделение явным.

Матрица «влияние × срочность»

Строка — влияние, его оценивает постановщик. Столбец — срочность по факту: стоит ли работа прямо сейчас. Ячейка — класс события, который назначает служба.

Четыре класса в ячейках — те же, что на нашей странице сопровождения по SLA: остановка важного процесса, серьёзный сбой, обычная заявка, плановая задача. Для каждого записаны канал, порядок передачи дальше и сроки — раздельно для начала работы и для её завершения. Матрица — это способ попасть в нужный класс, не споря о словах. Как классы событий записываются в договоре, мы разбирали в статье «SLA в ИТ-аутсорсинге».

Обратите внимание на правый столбец: если работу можно планировать, класс — «плановая задача» независимо от влияния. Установка ПО на все 50 рабочих мест — большое влияние, но не срочность. Это защищает очередь от заявок, которые «срочные», потому что о них вспомнили в пятницу.

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

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

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

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

«Установить программу на 50 рабочих мест». Влияние большое — затронуты все, — но работу можно назначить на дату. Класс — плановая задача, срок согласуется с постановщиком. Без правого столбца матрицы такая заявка попадает в срочные, потому что о ней вспомнили в пятницу вечером, и вытесняет из очереди реальный инцидент.

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

Как договориться: три шага

1. Список критичных сервисов. Вместе с руководителями подразделений назовите системы, остановка которых стоит денег: касса, отгрузка, платежи, закрытие периода, производственная линия. Список — часть договора, а не приложение к переписке.
2. Обязательное поле «влияние». Три варианта из первого столбца матрицы. Без него заявка не регистрируется. Это единственное, что добавляется к работе постановщика, — и оно занимает пять секунд.
3. Ориентир по приоритету по умолчанию. Доля заявок с приоритетом по умолчанию — не выше 70%. В кейсе она составляла 96%. Если после внедрения матрицы доля не падает, значит, поле «влияние» заполняют формально, и нужно разбираться с координаторами, а не с формой.

Матрица с четырьмя классами, границами ответственности и двумя крайностями собрана в одном файле — «Матрица приоритетов „влияние × срочность“». Его можно приложить к договору или к регламенту HelpDesk.

Что это меняет для службы

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

В кейсе внедрение матрицы идёт вместе с заказчиком: список критичных сервисов согласуется с руководителями подразделений, поле «влияние» становится обязательным. Это одно из изменений в процессе, к которым привёл анализ массива заявок, — рядом с правилами обработки автоалертов и правилом 35% на одного инженера.

Классы событий под ваши критичные системы, реакция до 15 минут на остановку важного процесса и отчёт по соблюдению сроков в разрезе классов — это сопровождение по SLA, где спор о срочности происходит один раз, до подписания договора.