Service desk у 38% крупного бизнеса только регистрирует обращения

Service desk используют во многих крупных российских компаниях, но единицы получают из него управленческие данные. По данным исследования BPMSoft и Softline, для 38% из них ITSM остается прежде всего системой регистрации обращений. Лишь 8% распространили сервисный подход за пределы ИТ. Там, где профильной ITSM-системы нет вовсе, картина не лучше. По данным исследования ЦИСК Okdesk, 58,5% компаний ведут сервисные процессы в программах, которые для этого не предназначены: от CRM и 1С до мессенджеров и таблиц. Журнал заявок отличается от сервисного контура тем, как организована работа с обращениями, а не самой платформой.

Главное за неделю — в дайджесте

Подпишитесь, чтобы не пропустить

Подписаться

Граница между журналом заявок и service desk

Сравним два сценария работы с одной и той же системой. В первом сотрудники обращаются в поддержку через чат, обходя ее: инженер отвечает, когда освободится, и обращение не фиксируется в учете. Во втором заявку сразу создают в service desk: связывают с услугой из каталога, задают срок и назначают ответственного на каждом этапе. Эти атрибуты и отделяют журнал заявок от service desk.

Чем service desk отличается от help desk

Help desk и service desk различаются по тому, как устроена работа с обращением. Help desk закрывает инцидент: у пользователя что-то сломалось, специалист починил, заявка закрыта. Service desk охватывает весь цикл обслуживания: от заявки по каталогу до контроля сроков и анализа загрузки специалистов. Так подразделение управляет сервисом для внутренних клиентов компании.

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

Между журналом заявок и зрелым service desk есть промежуточный уровень. 23% крупных компаний применяют ITSM как операционную платформу: управляют процессами, изменениями и активами, анализируют данные. Опрос охватил 39 компаний с выручкой более 20 млрд рублей. Авторы исследования называют различия между уровнями использования ITSM разрывом в зрелости.

Три признака зрелого service desk

Что должно появиться у заявки, чтобы система перестала быть журналом:

• Услуга из каталога. Сотрудник выбирает готовую позицию с описанием и сроком. Заявка сразу получает тип, категорию и маршрут к исполнителю.
• Срок и ответственный на этапе. Для услуги задают время реакции и время решения. Система автоматически назначает ответственного на каждом этапе, включая ожидание согласования.
• Журнал этапов. Система фиксирует начало и конец этапа. По заявке видны и работа специалиста, и пауза между подразделениями.

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

«Тема ITSM сегодня звучит иначе, чем несколько лет назад. Раньше она воспринималась как регистрация заявок, Service Desk, контроль SLA. Сегодня это часть организационного управления компанией в целом».

Александр Абрамкин, управляющий партнер, HeadExpert

Откуда компании приходят к единой точке обращений

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

По данным ЦИСК Okdesk, 58,5% компаний ведут сервисные процессы в непрофильных программах. Три группы из исследования:

• CRM, 1С или собственные разработки — 17,8%;
• мессенджеры — 12%;
• Excel и Google Таблицы — 8,7%.

На базовом уровне такие программы справляются с учетом обращений, но с ростом нагрузки в них повторяются одни и те же проблемы:

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

100% входящих запросов учитывают 53,9% компаний. Все действия по заявкам фиксируют 42,3%.

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

Единая точка обращений за пределами ИТ: АХО, HR и бухгалтерия

Service desk почти всегда начинается в ИТ: там уже есть учет заявок, дежурные смены и привычка измерять сроки. Заявка в АХО о сломанном кондиционере и заявка в кадры о справке при этом устроены одинаково: инициатор, услуга, срок, исполнитель. Если маршрут заявки задан в едином каталоге услуг, новое подразделение подключают к тому же сервисному контуру без отдельной системы. В исследовании BPMSoft и Softline распространение сервисного подхода за пределы ИТ относят к уровню Enterprise Service Management.

Так, по этому пути прошел холдинг «Вертолёты России». Проект начинали как импортозамещение: зарубежную платформу меняли на 1C:ITILIUM. Затем ИТ, АХО, кадры, бухгалтерию и управление автотранспортом объединили в одном сервисном контуре. Система работает более чем с тысячью корпоративных сервисов.

Масштаб service desk в «Вертолётах России»:

• Поток обращений. Свыше 27 000 в месяц.
• Исполнители. С заявками работают 1200 человек.
• Поддержка системы. Ее ведут четыре специалиста. В контакт-центре работают восемь сотрудников.
• Экономический эффект. 10 млн рублей в год на операционных затратах.

В непрофильных подразделениях service desk работает по тому же принципу, что и в ИТ: для каждой услуги задают правила обработки. В хозяйственной службе у заявки на замену лампы есть срок и владелец, в кадрах заявки на справки попадают в очередь с установленным временем ответа.

Каталог услуг и маршрутизация заявки

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

Так устроена работа с заявками в общем центре обслуживания «Росводоканала». Он работает с 45 юридическими лицами и 15 000 сотрудников, штат — 147 человек. Систему в группе запустили в 2018 году на ИТ-задачах, а в 2022-м распространили на казначейство. 99,9% заявок, которые создают клиенты, сразу попадают к нужному исполнителю. Удобство работы с заявками оценивают на 97%.

Жизненный цикл заявки в service desk

Жизненный цикл заявки состоит из шести этапов, на каждом из которых меняется ее статус:

1. Регистрация. Запрос поступает от пользователя через портал самообслуживания, почту или телефон. Инцидент может завести и система мониторинга. Заявка получает регистрационный номер.
2. Классификация. Заявке присваивают категорию услуги и тип обращения: инцидент, запрос на обслуживание или запрос на изменение.
3. Приоритизация. По срочности и влиянию на бизнес определяют приоритет заявки и срок по SLA.
4. Назначение. Система по правилу маршрутизации, привязанному к услуге, направляет заявку на первую или сразу на вторую линию поддержки.
5. Решение. Специалист выполняет работу, а если ему не хватает квалификации или прав доступа, заявку эскалируют.
6. Закрытие. Сотрудник оценивает результат, а типовое решение отправляется в базу знаний.

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

В каталоге указывают результат услуги и срок ее оказания. Сотрудник заранее понимает, что и когда получит. Расплывчатые заявки вида «сделайте что-нибудь с почтой» до специалиста не доходят.

В группе «Росводоканал» каталог включает 660 позиций для ИТ, АХО, бухгалтерии и казначейства. В нем учитывают и алерты систем мониторинга АСУТП. Через каталог ежемесячно проходят 11 тысяч заявок. Им пользуются 5 тысяч сотрудников.

SLA: где заявка на самом деле стоит

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

Согласно исследованиям, 34,9% компаний вообще никак не контролируют SLA. Еще 15,3% респондентов не знакомы с этим термином. Там, где SLA не контролируют, сроки зависят от устных договоренностей и личной ответственности сотрудников. Отдельного механизма контроля нет.

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

По двум срокам и оценке сотрудника считают основные показатели поддержки:

• Доля решенных в срок. Соблюдение SLA по сервисам.
• Доля нарушений по командам. Показывает команды, в которых при текущей нагрузке чаще нарушаются сроки.
• Оценка сотрудника после закрытия. Показывает, как сам сотрудник оценивает качество сервиса.

Система считает показатели по журналу этапов, поэтому специалистам не нужно готовить для этого отдельную отчетность.

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

Евгений Биличенко, ИТ-директор, ТРЦ «Город Лефортово»

Бизнес задает приоритет заявки

На деле его чаще всего определяет первая линия поддержки, которая принимает запрос. Специалист видит очередь, но не контекст заявки: остановлена отгрузка, идет закрытие периода или простаивает склад. Бизнес оценивает срочность и влияние и по этой оценке определяет приоритет.

Например, по этой модели поддержку перестроил торгово-производственный холдинг «Русклимат». Оборот компании составляет 200 млрд рублей, штат — 8000 сотрудников, она работает в 180 городах. Проект охватил более 20 ИТ-команд и около 270 специалистов. Вместе с бизнесом потери от непрозрачности ИТ оценили в 94 млн рублей. Эти 94 млн рублей стали основанием для запуска проекта.

Что изменили в поддержке:

• Портал обращений. Устранили узкие места портала, через который сотрудники создают заявки.
• Расчет SLA. Изменили порядок расчета SLA.
• Клиентские метрики и обратная связь. Добавили показатели оценки сервиса со стороны бизнеса и расширили работу с отзывами.
• Модель приоритизации. Подразделение, где возникла заявка, определяет ее срочность и влияние.

В «Русклимате» доля заявок, требующих корректировки приоритета после создания, снизилась с 40% до 12%. За год их количество выросло на 18% без дополнительного найма. Компания оценивает подтвержденный эффект всей программы изменений более чем в 100 млн рублей.

Для приоритизации со стороны бизнеса ИТ и бизнесу нужны сопоставимые критерии. Когда потери оценивают в деньгах, влияние заявки можно сопоставить с бюджетом поддержки.

Нагрузка на первую линию и метрики поддержки

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

Так, в сети товаров для дома и ремонта «Лемана Про» поток составляет около 100 000 обращений в месяц. Из них 50–55 тысяч приходится на ИТ-поддержку. Первая линия состоит из 28 человек. По словам директора по ИТ-сервисам, индекс удовлетворенности CSI по результатам обслуживания составляет 93,7%.

Как поддержка работает с таким потоком:

• SLA-журнал. У каждого этапа обработки заявки есть отметки времени и ответственный.
• Владелец на этапе ожидания. Даже когда заявка стоит в очереди без исполнителя, за нее отвечает менеджер группы.
• Разбор системных причин. К данным ITSM-платформы подключили языковую модель, чтобы находить источники задержек и заранее готовить команды к пикам нагрузки.
• Оценка от сотрудника. Ее ставят на каждом закрытом обращении — по ней считают индекс удовлетворенности.

Заявки распределяют между двумя линиями поддержки:

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

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

База знаний и портал самообслуживания в service desk

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

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

Смена платформы service desk не пересобирает процессы

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

По данным опроса IBS и «РТК ИТ Плюс» за 2024 год, 76% компаний в России используют ITSM-системы. 48% собирались в течение года заместить иностранные решения после ухода западных вендоров. 37% респондентов отметили, что внедрение ITSM позволило ускорить выполнение задач как минимум вдвое.

Например, торговая сеть «Лента» начала проект в сентябре 2024 года с аудита процессов и анализа фактической работы поддержки. Разработку в первые месяцы не вели. Новую систему запустили в июне 2025 года сразу на всю сеть. Аварийность снизилась на 45% относительно предыдущей платформы. Количество выполняемых изменений выросло на 70%.

С чего начинать запуск service desk на среднем предприятии

На первом этапе service desk запускают с единой точкой обращений и одной базой знаний. Так начинал Щербинский лифтостроительный завод с 1300 сотрудников.

Шаги запуска service desk на предприятии

На заводе внедрение проходило так:

1. Базовая версия. Систему запустили за два рабочих дня и отказались от бумажных обращений.
2. Единый вход. Сотрудники создают заявки через личный кабинет вместо звонков и записок.
3. База знаний. 7 внутренних и 14 внешних разделов, чтобы сотрудники решали типовые вопросы через самообслуживание.
4. Инвентаризация активов. ИТ-оборудование разметили QR-кодами, чтобы связывать заявку с конкретной техникой и видеть историю ее ремонтов.
5. Интеграция с мониторингом. Zabbix автоматически создает заявки по сбоям, о которых сотрудники обычно не сообщают.

Сейчас в service desk завода 1100 заявок в месяц, 600 пользователей, 20 функциональных команд и 167 услуг. Время реакции на заявку сократилось с 2–3 дней до одного часа. Количество обработанных заявок выросло на 50% без расширения штата. Кейс опубликован в блоге вендора ITSM 365 со слов руководителя отдела развития ИТ-сервисов завода.

Что считать результатом внедрения service desk

Журнал заявок и зрелый service desk могут называться одинаково, но дают руководителю разные управленческие данные. Поэтому при оценке учитывают, какие признаки зрелого service desk появились в работе.

Разницу показывают четыре признака:

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

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