Service Desk: что это простыми словами, отличие от Help Desk и как выбрать

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

Разберём, что такое Service Desk простыми словами, чем он отличается от Help Desk и тикет-системы, как работает заявка, что такое SLA и как выбрать систему, если заявки касаются не только ИТ, но и информационной безопасности.

Что такое Service Desk простыми словами

Service Desk — единая точка, куда сотрудники и клиенты отправляют обращения в ИТ-службу: сбои, запросы доступа, вопросы и заказы оборудования. Каждое обращение регистрируется как заявка с номером, категорией, приоритетом, исполнителем и сроком. Руководитель видит очередь целиком, а пользователь — статус своей заявки без звонков исполнителю.

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

Без Service Desk заявки теряются в почте и чатах. С ним у каждого обращения есть история: кто создал, кто взял, что ответили, когда закрыли и уложились ли в срок.

Help Desk и Service Desk: в чём разница

Help Desk — служба помощи, которая принимает обращения и чинит то, что сломалось: сбрасывает пароль, восстанавливает принтер, отвечает на вопрос. Service Desk шире: кроме сбоев он обрабатывает запросы на обслуживание по каталогу услуг, следит за сроками по SLA и связывает заявки с изменениями, активами и базой знаний.

На практике границу проводят по задачам, а не по названию программы:

Хелпдеск — это часто первая ступень. Компания начинает с простой очереди заявок, а когда обращений становится сотни в месяц, добавляет каталог услуг, SLA и связь с учётом активов — и получает Service Desk.

Что такое тикет-система

Тикет-система — программа, в которой каждое обращение превращается в тикет: карточку с номером, текстом, автором, исполнителем, статусом и перепиской. Тикет нельзя потерять, как письмо в общем ящике, а по номеру всегда видно, на каком этапе работа. Тикет-система — ядро любого Help Desk и Service Desk.

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

Чем тикет-система для техподдержки отличается от полноценного Service Desk: первая отвечает на вопрос «что пришло и кто этим занят», второй — ещё и «по каким правилам мы это делаем и соблюдаем ли их».

Как работает Service Desk: путь заявки

Типичный жизненный цикл заявки одинаков почти во всех системах:

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

Важная деталь — эскалация. Если срок по SLA подходит к концу, система сама уведомляет руководителя группы или поднимает приоритет. Так заявка не «зависает» у исполнителя, который ушёл в отпуск.

Пример: заявка на доступ к папке

Менеджер отдела продаж открывает портал и выбирает в каталоге услугу «Доступ к сетевой папке». Форма просит указать папку, тип доступа (чтение или запись) и срок. Заявка получает номер и уходит на согласование руководителю отдела, который отвечает за эту папку.

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

Через полгода аудитор спрашивает, почему у менеджера есть запись в папку финансового отдела. Ответ — в истории заявки: кто попросил, кто согласовал, кто выдал и когда. Если бы доступ выдали по просьбе в мессенджере, этот вопрос остался бы без ответа.

Основные функции системы Service Desk

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

• Портал самообслуживания — пользователь сам создаёт заявку, видит её статус и историю, находит ответ в базе знаний.
• Рабочее место оператора — очередь заявок с фильтрами, шаблоны ответов, переписка внутри карточки.
• Каналы приёма — веб-форма, почта, телефон, мессенджер, API для других систем.
• Каталог услуг — список того, что можно заказать, с формой и сроком для каждой услуги.
• SLA и календари — сроки реакции и решения с учётом рабочих часов и праздников.
• Маршрутизация и эскалация — правила, кому уходит заявка и что происходит при просрочке.
• База знаний — инструкции для пользователей и исполнителей, чтобы одни и те же вопросы не решали каждый раз заново.
• Отчёты — нагрузка по группам, соблюдение SLA, повторные обращения, самые частые проблемы.
• Связь с активами — заявка привязана к конкретному компьютеру, серверу или программе из CMDB.

Последний пункт часто недооценивают. Когда заявка «не печатает принтер» привязана к конкретному устройству, через полгода видно, что этот принтер ломается раз в месяц и его пора менять.

SLA в Service Desk: время реакции и время решения

SLA (Service Level Agreement) в Service Desk — договорённость о сроках обработки заявок. Обычно задают два срока: время реакции — когда исполнитель должен взять заявку в работу — и время решения — когда проблема должна быть устранена. Сроки зависят от приоритета заявки и обычно считаются в рабочих часах по календарю службы, а не в календарных сутках.

Пример матрицы SLA для внутренней ИТ-службы:

Это пример, а не норма: сроки компания устанавливает сама, исходя из штата и критичности систем. Главное — чтобы система считала их автоматически и показывала, какие заявки близки к просрочке.

Отдельная тема — календари. Если служба работает с 9 до 18 по будням, заявка, созданная в пятницу в 17:30 со сроком решения 4 часа, должна получить срок в понедельник, а не в субботу. Без рабочих календарей отчёты по SLA показывают ложные просрочки.

Линии поддержки: кто решает заявку

В Service Desk заявки обычно разбирают по линиям. Это не бюрократия, а способ не отвлекать опытных специалистов на сброс паролей.

• Первая линия принимает все обращения, регистрирует и классифицирует их, решает простые: сброс пароля, консультация, типовая настройка по инструкции. Хорошая первая линия закрывает большую часть потока сама.
• Вторая линия — профильные администраторы: серверы, сеть, 1С, средства защиты. Сюда уходит то, что не решилось по инструкции.
• Третья линия — разработчики, вендор, внешний подрядчик. К ним заявка попадает, когда проблема в самом продукте или требует доработки.

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

Service Desk, ITSM и ITIL: как связаны понятия

ITSM (IT Service Management) — подход к управлению ИТ как набором услуг для бизнеса. ITIL — самая известная библиотека практик ITSM: она описывает, как организовать управление инцидентами, запросами, изменениями, проблемами и конфигурациями.

Service Desk в этой схеме — точка контакта между пользователями и ИТ. Через него проходят инциденты и запросы на обслуживание, а остальные процессы ITSM (управление изменениями, проблемами, конфигурациями) получают из него данные. Поэтому «ITSM-система» и «Service Desk» часто продают как одно и то же, хотя ITSM — шире. Процессы ITSM и отличие от ITIL подробно разобрали в статье ITSM: что это такое.

Для небольшой компании полный набор процессов ITIL избыточен. Достаточно трёх вещей: единая очередь заявок, понятные сроки и учёт активов, к которым заявки относятся. Подробнее об учёте активов — в статье ITAM и CMDB: что это и зачем. Если активы у вас пока живут в таблицах, запросите демо КиберОснова SGRC: покажем, как их учитывают в платформе.

Метрики Service Desk: что считать

Отчёт «закрыто 340 заявок» ничего не говорит о качестве работы. Полезнее пять показателей:

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

Service Desk и CMDB: зачем связывать заявки с активами

CMDB (Configuration Management Database) — база конфигурационных единиц: компьютеров, серверов, программ, сетевого оборудования и связей между ними. Как она устроена, разобрали в статье CMDB: что это и как работает.

Связка Service Desk и CMDB даёт три практических результата:

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

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

Service Desk для информационной безопасности

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

Для ИБ заявка — ещё и доказательство. Пункт 38 приказа ФСТЭК России № 117 от 11.04.2025 требует контролировать устранение уязвимостей в ГИС и иных системах госорганов, ГУП и госучреждений: уязвимость критического уровня устраняют или закрывают компенсирующими мерами не более чем за 24 часа, высокого — не более чем за 7 календарных дней. Дата закрытия заявки показывает проверяющему, что срок соблюдён.

Какие ещё меры требует приказ и как их закрыть в платформе, разобрали на странице приказ ФСТЭК № 117. Приказ действует с 1 марта 2026 года для государственных информационных систем и систем госорганов, ГУП и госучреждений и заменил приказ № 17.

Чем Service Desk для ИБ отличается от общего ИТ-хелпдеска:

• Доступ к заявкам ограничен. Заявку о подозрительной активности не должны видеть все операторы первой линии.
• История неизменяема. Для расследования важно, что запись нельзя тихо поправить задним числом.
• Заявки связаны с объектами учёта ИБ — с уязвимостями, СКЗИ, системами из реестра, а не только с компьютерами.
• Отчёты нужны для проверки, а не только для руководителя ИТ: сколько уязвимостей устранено, в какие сроки, кто согласовал доступ.

Если заявки по безопасности уже приходят в общий ИТ-хелпдеск, начните с отдельной категории с закрытым доступом и обязательными полями. Процесс работы с инцидентами описан в статье управление инцидентами ИБ, с уязвимостями — на странице учёта уязвимостей по БДУ ФСТЭК.

Учёт уязвимостей, СКЗИ и документов ИБ, к которым будут привязаны заявки, в КиберОснова SGRC уже работает. Запросите демо — покажем его на демостенде.

Виды Service Desk

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

• Внутренний Service Desk — ИТ-служба обслуживает сотрудников своей компании. Самый частый сценарий.
• Внешний Service Desk — сервисная компания или интегратор обслуживает клиентов по договору. Здесь SLA — часть договора, а отчёт по срокам — основание для оплаты или штрафа.
• Корпоративный (Enterprise) Service Desk — одна система для ИТ, кадров, бухгалтерии, хозяйственной службы и безопасности. Пользователь заходит в один портал, а заявка уходит в нужный отдел.
• Облачный и коробочный. Облачный подключают быстрее и платят подпиской, коробочный ставят на свои серверы и отвечают за обновления сами.

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

Как выбрать Service Desk: критерии

Рынок систем Service Desk в России большой: есть коробочные и облачные продукты, open-source решения вроде GLPI и отраслевые системы. О том, где GLPI справляется с задачами ИБ, а где нет, — в статье GLPI для информационной безопасности.

При выборе проверьте по списку:

1. Где хранятся данные. В заявках есть ФИО, телефоны, должности сотрудников — это персональные данные. Уточните, что облачный сервис хранит их в России.
2. Реестр российского ПО. Для госзаказчиков и субъектов КИИ это часто требование закупки, для остальных — плюс к долгой поддержке.
3. Облако или своя установка. Облако быстрее запустить, своя установка нужна, если заявки касаются закрытого контура.
4. SLA и календари. Система должна считать сроки в рабочих часах, учитывать праздники и разные графики групп.
5. Каналы приёма. Минимум — портал и почта. Если пользователи привыкли писать в мессенджер, нужен и он.
6. Связь с активами. Встроенная CMDB или интеграция с вашей системой учёта.
7. API. Чтобы заявки создавались автоматически из мониторинга, сканера уязвимостей или SIEM.
8. Разграничение доступа. Возможность закрыть категорию заявок от части операторов.
9. Отчёты. Соблюдение SLA, нагрузка, выгрузка для руководства и проверяющих.
10. Стоимость владения. Цена лицензии на оператора плюс внедрение, доработки и поддержка.

Как внедрить Service Desk: пять шагов

1. Соберите текущий поток. Посмотрите за месяц, откуда приходят обращения и какие самые частые. Это будущие категории и каталог услуг.
2. Опишите правила. Категории, приоритеты, сроки SLA, кто за что отвечает, что происходит при просрочке.
3. Запустите один канал. Начните с портала или почты, а звонки и сообщения в мессенджер оператор переносит в заявки сам.
4. Подключите активы. Если есть CMDB или хотя бы список компьютеров — привяжите заявки к ним с первого дня.
5. Через месяц пересмотрите. Отчёт покажет, где SLA нереалистичен, какие категории лишние и какие вопросы пора вынести в базу знаний.

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

Service Desk в КиберОснова SGRC

В КиберОснова SGRC Service Desk строим рядом с учётом активов, уязвимостей и СКЗИ — там, где у службы ИБ уже лежат данные. Задача модуля — чтобы заявка ссылалась на объект учёта, а её история становилась частью доказательной базы для проверки.

Сейчас подключаем компании к пилоту: собираем требования ИТ- и ИБ-служб и настроим процессы вместе с участниками пилота. Если вы выбираете Service Desk и вам важна связь заявок с активами и требованиями ФСТЭК — оставьте заявку на участие.

Итог

• Service Desk — единая точка приёма обращений, где каждое обращение становится заявкой с номером, исполнителем и сроком.
• Help Desk чинит то, что сломалось; Service Desk добавляет каталог услуг, SLA и связь с активами.
• Тикет-система — ядро обоих: без неё нет ни очереди, ни истории.
• SLA задаёт время реакции и время решения и считается в рабочих часах по календарю.
• Связка с CMDB показывает контекст заявки и проблемные активы.
• Для ИБ заявка — доказательство контроля: по приказу ФСТЭК № 117 критические уязвимости закрывают за 24 часа, высокие — за 7 календарных дней.

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