Классификация заявок в Service Desk: где теряется управление сервисом

Стоимость часа простоя ИТ-инфраструктуры за последний год заметно выросла. У многих компаний Service Desk уже давно внедрен, а вопрос управления сервисом нередко считается закрытым: заявки регистрируются, у каждой есть категория, отчеты формируются. Но внедрение классификации заявок в Service Desk само по себе не гарантирует ни срок решения, ни правильную очередность.

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

Путь заявки в Service Desk: от обращения до исполнителя

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

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

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

Так выглядит самый простой вариант работы Service Desk. В одном из аудитов ALP ИТ-служба фактически была замкнута на одном системном администраторе, который сам решал, что делать сначала, а что подождет, а руководство было убеждено в стабильности ИТ, несмотря на постоянный фон из жалоб и сбоев. Пришлось буквально заново оцифровать реальный путь заявки, чтобы найти, где он проваливается. Формально система была, а управления в ней не было.

Классификация заявок: что она дает и почему это только этап

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

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

Процесс обработки заявок можно построить по-разному. Кто-то классифицирует вручную. Этим занимается дежурный первой линии поддержки или руководитель, который знает специфику компании. Кто-то использует CRM или Help Desk-систему, где типы обращений заводятся заранее и заявка попадает в нужную очередь автоматически. Есть и вариант с алгоритмами на основе искусственного интеллекта (ИИ), обученными на истории обращений. Алгоритм предполагает тип обращения по тексту, а инженер подтверждает или поправляет его. Это ускоряет работу диспетчера.

Здесь сортировка заявок по типам заканчивается. Она отвечает на вопрос «что это за проблема», но не отвечает на вопрос «когда ее решат» и «в каком порядке, если задач одновременно несколько». Ответ на эти два вопроса дают не категории, а договоренности поверх них.

Зрелость классификации: от категории к разным правилам обслуживания

Дальнейшее развитие классификации заявок в компаниях с более зрелыми ИТ-процессами обычно идет по двум направлениям (о том, что в целом показывает независимый ИТ-аудит, подробнее — в материале «ИТ-аудит как прививка от потерь»). Первое — разделение обращений не только по объекту, но и по характеру задачи: у инцидента (что-то сломалось, нужно быстро восстановить работу) и запроса на обслуживание (ничего не сломано, нужно предоставить ресурс по заранее согласованной процедуре) разное время реакции. Без каталога типовых услуг закрепленные сроки SLA превращаются либо в усреднение по всем заявкам, либо в решение вручную по каждому обращению.

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

Где компании обычно о