ITSM — что это такое: процессы, ITIL и ITSM-системы простыми словами

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

Разберём, что такое ITSM простыми словами, чем он отличается от ITIL, какие процессы в него входят и с чего начать внедрение. Отдельно покажем, где ITSM пересекается с информационной безопасностью.

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

ITSM (IT Service Management, управление ИТ-услугами) — подход, при котором ИТ-отдел работает как поставщик услуг для бизнеса. Каждая услуга — почта, 1С, доступ в интернет, рабочее место — описана: кто ею пользуется, кто отвечает, какие сроки восстановления. Работа ИТ оценивается не по числу закрытых задач, а по тому, получает ли бизнес услуги в обещанном качестве.

Расшифровка ITSM — IT Service Management. На русском чаще говорят «управление ИТ-услугами» или «управление ИТ-сервисами», это одно и то же.

Главная мысль ITSM: пользователю не нужен сервер, ему нужно, чтобы работала 1С. Поэтому ИТ планирует работу от услуг, а не от железа. Сервер важен постольку, поскольку от него зависит услуга, и именно так ИТ объясняет бизнесу, на что идут деньги.

ITSM — это методология или программа?

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

• ITSM как подход — набор принципов и процессов: как принимать обращения, как вносить изменения, как управлять сроками. Это организационная часть, она не зависит от программы.
• ITSM-система — программа, в которой эти процессы автоматизированы: заявки, каталог услуг, SLA, база конфигураций, отчёты.

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

Чем ITSM отличается от ITIL

ITSM — сам подход к управлению ИТ как услугами, а ITIL (IT Infrastructure Library) — самый распространённый свод практик, описывающий, как этот подход реализовать. Проще говоря, ITSM отвечает на вопрос «что делать», а ITIL — «как это делают другие компании». Внедрять ITSM можно и без ITIL, опираясь на ISO/IEC 20000 или собственные правила.

ITIL появился в Великобритании в конце 1980-х как сборник лучших практик для государственных ИТ-служб. Самая распространённая версия — ITIL 4 2019 года: 34 практики в трёх группах (общего управления, управления услугами и технического управления) и семь руководящих принципов, например «начинайте с того, где вы сейчас» и «сосредоточьтесь на ценности». В начале 2026 года вышла ITIL (Version 5), сертификаты ITIL 4 при этом действуют.

ITIL и стандарт ISO/IEC 20000-1 различаются тем, что сертифицируют: по ITIL — людей, сдавших экзамен, а по ISO/IEC 20000-1 — саму систему управления услугами компании. Поэтому сервисные компании и интеграторы, которым нужно подтвердить зрелость процессов перед заказчиком, чаще идут к ISO/IEC 20000, а внутренние ИТ-службы — к ITIL как к справочнику.

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

Основные процессы ITSM

Ядро ITSM в большинстве компаний — пять процессов: управление инцидентами (быстро восстановить работу услуги), управление запросами (выполнить стандартную просьбу пользователя), управление проблемами (найти и устранить причину повторяющихся сбоев), управление изменениями (вносить изменения без аварий) и управление конфигурациями (знать, из чего состоит ИТ и как элементы связаны).

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

Процессы ITSM на одном примере

Возьмём компанию, где каждый понедельник утром перестаёт открываться 1С.

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

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

Роли в ITSM: кто за что отвечает

Процессы не работают без людей, за которыми они закреплены. В ITSM выделяют несколько ролей, и в небольшой компании один человек часто совмещает две-три из них.

• Владелец услуги отвечает за услугу целиком: что она даёт бизнесу, какие у неё сроки и сколько она стоит. Например, владелец услуги «1С» — руководитель группы, которая её сопровождает.
• Владелец процесса отвечает за то, чтобы процесс был описан и соблюдался: как регистрируются инциденты, как согласуются изменения.
• Диспетчер или первая линия принимает обращения, регистрирует и классифицирует их, решает простые и передаёт сложные дальше.
• Менеджер изменений следит, чтобы изменения проходили согласование и имели план отката.
• Совет по изменениям (CAB, Change Advisory Board) — группа, которая оценивает рискованные изменения: представители ИТ, бизнеса и, для изменений с влиянием на защиту, службы ИБ.

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

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

ITSM-система — программа, которая автоматизирует процессы управления ИТ-услугами: принимает обращения и превращает их в заявки, считает сроки по SLA, ведёт каталог услуг и базу конфигураций, проводит изменения через согласование и строит отчёты о качестве услуг. Ядро любой ITSM-системы — Service Desk, через который проходят инциденты и запросы пользователей.

Чем ITSM-система отличается от Service Desk: Service Desk — точка контакта с пользователями и очередь заявок, а ITSM-система покрывает ещё и процессы «за кулисами» — изменения, проблемы, конфигурации, уровни услуг. Подробнее о Service Desk, Help Desk и тикет-системах — в статье Service Desk: что это простыми словами.

Типичный набор модулей ITSM-системы:

• Service Desk и портал самообслуживания;
• каталог услуг и управление SLA;
• управление изменениями и проблемами;
• CMDB — база конфигурационных единиц;
• база знаний;
• отчёты и дашборды по услугам.

На российском рынке ITSM-системы предлагают десятки вендоров, есть и open-source решения. Одно из них, GLPI, мы разбирали с точки зрения задач ИБ в статье GLPI для информационной безопасности.

Если ИТ-хелпдеск у вас уже есть, а службе ИБ не хватает учёта активов, уязвимостей и СКЗИ рядом с заявками, запросите демо КиберОснова SGRC: покажем, как этот учёт устроен в платформе.

Метрики ITSM: как понять, что подход работает

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

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

ITSM, ITAM и ESM: смежные понятия

Рядом с ITSM часто встречаются ещё две аббревиатуры: ITAM управляет ИТ-активами, а ESM переносит подход ITSM на службы за пределами ИТ.

ITAM (IT Asset Management, управление ИТ-активами) отвечает за жизненный цикл оборудования и ПО: закупка, учёт, лицензии, списание. ITSM нужны данные ITAM, чтобы понимать, с каким активом связана заявка или изменение. Чем ITAM отличается от CMDB, разобрали в статье ITAM и CMDB: что это.

ESM (Enterprise Service Management) — перенос подхода ITSM на другие службы компании: кадры, бухгалтерию, хозяйственную службу, юристов. Сотрудник заходит в один портал и заказывает и ноутбук, и справку с работы, и пропуск для гостя. Технически это та же ITSM-система с каталогом услуг, расширенным за пределы ИТ.

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

Зачем компании ITSM

ITSM не про красивые схемы, а про несколько конкретных изменений в работе ИТ:

• Прозрачность. Руководство видит, какие услуги даёт ИТ, сколько обращений по каждой и укладывается ли ИТ в сроки.
• Меньше повторных сбоев. Управление проблемами устраняет причины, а не симптомы.
• Меньше аварий после изменений. Изменение заранее оценивают и тестируют, а на случай сбоя готовят план отката.
• Знания не уходят с людьми. Решения и конфигурации записаны в системе, а не в памяти конкретного администратора.
• Разговор с бизнесом на одном языке. Вместо «нужен новый сервер» — «без него услуга 1С не выдержит рост числа пользователей».

Признаки, что компании пора внедрять ITSM

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

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

Как внедрить ITSM: с чего начать

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

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

Главная ошибка — начинать с выбора дорогой ITSM-системы и попытки внедрить все практики ITIL сразу. Через полгода у компании есть сложная программа, которой никто не пользуется. Надёжнее идти от одного процесса к следующему и автоматизировать то, о чём уже договорились.

Три мифа об ITSM

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

«Купим ITSM-систему — и будет ITSM». Программа автоматизирует договорённости, но не заменяет их. Если никто не решил, кто согласует изменения, система просто будет хранить неподписанные заявки.

«ITSM — это ITIL, а ITIL — это сертификаты». Курсы и сертификаты полезны специалистам, но для старта они не нужны. Достаточно понимать пять базовых процессов и начать с одного из них.

Как выбрать ITSM-систему

• Процессы, которые нужны сейчас. Если пока нужны только заявки и SLA, не платите за модули, которые не включите ещё два года.
• Российское ПО и хранение данных. В заявках и CMDB есть персональные данные сотрудников и сведения об инфраструктуре. Госзаказчикам и субъектам КИИ стоит заранее проверить ограничения на иностранное ПО: они зависят от категории организации и объекта.
• Облако или своя установка. Облако быстрее запустить, своя установка нужна для закрытого контура.
• CMDB. Есть ли встроенная база конфигураций и можно ли подключить внешнюю.
• Интеграции и API. Мониторинг, почта, Active Directory, системы ИБ.
• Стоимость владения. Лицензии на операторов, внедрение, доработки, поддержка.

Сравнивать системы лучше на своих сценариях: возьмите три типичных заявки и одно изменение и попросите вендора показать их путь целиком.

Как ITSM связан с информационной безопасностью

ITSM и информационная безопасность пересекаются, но не совпадают. ITSM отвечает за то, чтобы услуги работали. ИБ — за то, чтобы они работали безопасно и соответствовали требованиям регуляторов. Одни и те же объекты — серверы, программы, изменения — эти службы видят по-разному.

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

Отсюда практические выводы:

• Срочные изменения по безопасности нужны как отдельный тип изменения с ускоренным согласованием, иначе обычный цикл согласования съест сутки, отведённые на критическую уязвимость.
• Инцидент ИТ и инцидент ИБ — разные вещи. Падение сервера — инцидент ITSM, подозрение на взлом — инцидент ИБ со своим порядком реагирования и расследования. Если сервер упал из-за атаки, это оба инцидента сразу: восстановление согласуют с расследованием, чтобы не уничтожить следы. Как его выстроить, разобрали в статье управление инцидентами ИБ.
• CMDB для ИТ обычно не закрывает задачи ИБ. Типичная ITSM-CMDB знает, какой сервер обслуживает 1С. Службе ИБ нужно ещё знать, какие на нём уязвимости, какие средства защиты и СКЗИ установлены, к какой системе по классификации ФСТЭК он относится.

Последний пункт — причина, по которой в КиберОснова SGRC CMDB сделана как база для задач безопасности, а не как модуль ITSM-системы. Она не заменяет ITSM-систему, а работает рядом с ней: импортирует активы из Kaspersky Security Center и Zabbix и связывает их с уязвимостями из БДУ ФСТЭК, СЗИ, СКЗИ и требованиями приказа ФСТЭК № 117. Политики и регламенты под эти требования готовят в модуле документов ИБ.

Как выглядит связка активов, уязвимостей и СКЗИ на практике, покажем на демостенде — запросите демо.

Service Desk для ИБ в КиберОснова SGRC

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

Итог

• ITSM — подход, при котором ИТ работает как поставщик услуг для бизнеса с понятными сроками и ответственными.
• ITIL — самый известный свод практик ITSM, но не единственный и не обязательный.
• Базовые процессы ITSM — инциденты, запросы, проблемы, изменения и конфигурации.
• ITSM-система автоматизирует эти процессы, её ядро — Service Desk.
• Внедрять ITSM стоит по одному процессу, начиная с инцидентов и запросов.
• ITSM и ИБ пересекаются в изменениях и уязвимостях: по приказу ФСТЭК № 117 в ГИС и системах госорганов, ГУП и госучреждений критическую уязвимость устраняют или закрывают компенсирующими мерами за 24 часа, и процесс изменений должен это выдерживать.

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