Рынок ITSM в России растёт каждый год, но большинство компаний всё ещё используют системы только для регистрации заявок. Эксперты обсудили, как отличить зрелое решение от классического сервис-деска, зачем нужна CMDB и что изменит ИИ.
- 1. Введение
- 2. Что такое ITSM и зачем он нужен бизнесу?
- 3. Структура современной ITSM-платформы
- 4. Выбор платформы: функциональность против стоимости владения
- 5. Основные сложности при внедрении
- 6. Тренды: ИИ-агенты, ESM и эволюция ITSM
- 7. Выводы
Введение
Российский рынок ITSM-систем прошёл путь от экзотики до полноценной индустрии с десятками вендоров и собственной методологией. Но за общими цифрами роста скрывается неоднородная картина: одни компании используют ITSM как полноценную операционную платформу, другие — лишь как систему регистрации обращений, а третьи вовсе не имеют централизованного решения.
На первый план выходят вопросы, которые не решаются одной лишь покупкой лицензии: как формализовать процессы, какие услуги оказывает ИТ, как измерить их качество и стоимость и, главное, как отличить действительно зрелое решение от классического Service Desk, который выдаётся за современный ITSM.
Эксперты ведущих российских разработчиков собрались в студии AM Live, чтобы разобрать, что происходит на рынке, как выбрать платформу под конкретные задачи и как пройти внедрение с минимальными потерями.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Фёдор Боков, инженер отдела развития, Security Vision.
- Дмитрий Сёмин, эксперт-практик по управлению услугами, SimpleOne, корпорация ITG.
- Олег Скрынник, управляющий партнёр Cleverics, Altevics.
Ведущий и модератор эфира — Илья Шабанов, генеральный директор «АМ Медиа».
Что такое ITSM и зачем он нужен бизнесу?
Олег Скрынник объяснил, что такое ITSM простыми словами: это идея, что работу ИТ-подразделения можно организовать так, будто оно предоставляет услуги. Как только мы говорим слово «услуга», сразу возникают вопросы: в чём она заключается, кому нужна, кто за неё платит, сколько она стоит и какие у неё параметры. Это то, что называют SLA — сервисное соглашение. Внутреннее ИТ-подразделение попадает в рамки: что оно должно делать, в какие сроки, какие заявки принимать. Это структурирование деятельности удобно и бизнесу, и ИТ.
Дмитрий Сёмин добавил важное уточнение: ITSM — это в первую очередь процесс, а не платформа. Платформа не даст ожидаемого результата, если процессы не выстроены. При этом ITSM — не конечная точка: дальше можно расширяться до ESM (Enterprise Service Management), где всё то же самое применяется к большему числу отделов.
Фёдор Боков обратил внимание, что ITSM-система не заставляет выстраивать процессы, а подстраивается под них.
Преимущества ITSM для бизнеса
Олег Скрынник ответил, что наличие ITSM не является важным фактором само по себе — работа ИТ-подразделения происходит и без него. Польза в том, что деятельность людей, оказывающих услуги, лучше структурируется и выполняется в рамках ожиданий, бизнес-требований и ограничений: по скорости, качеству и стоимости. Заявки можно обрабатывать по-разному, в том числе очень дорого для компании. А ИТ-бюджет в современных компаниях довольно большой, и там, где большие деньги, возникает вопрос, как они расходуются. Значит, нужно эту деятельность структурировать.
Дмитрий Сёмин добавил, что ITSM позволяет повысить прозрачность: раскрыть, что выполняло ИТ, в какой срок и сколько это стоило в рублях. Важное отличие ITSM от Service Desk — возможность контролировать повторяемость. С ITSM начинается проактивность: управление проблемами, контроль всех сущностей через ресурсно-сервисную модель, что позволяет снизить затраты в перспективе, не расширяя штат при росте инцидентов.
Дмитрий Сёмин, эксперт-практик по управлению услугами, SimpleOne, корпорация ITG
Илья Шабанов выделил четыре ключевых процесса ITSM: управление инцидентами, проблемами, изменениями и доступностью.
Олег Скрынник уточнил, что это базовые компоненты, но в современных сводах лучших практик (ITIL) процессов гораздо больше — в современной версии их 34. Он рассказал об истории развития ITSM в России: сначала акцент был на управлении заявками и инцидентами (Service Desk, Help Desk), потом появилась волна управления проблемами и изменениями, затем — управления уровнем услуг (каталог услуг, SLA, отчётность, прозрачность). Компании, последовательно прошедшие эти этапы, получали стройную целостную конструкцию.
В первом опросе зрители ответили, как организовано управление ИТ-услугами в их компании:
- Используют Service Desk для регистрации и закрытия заявок — 43%.
- Используют ITSM для управления услугами, SLA и конфигурациями (CMDB) — 21%.
- Используют ITSM-платформу, управляют инцидентами, проблемами и изменениями — 14%.
- Автоматизируют процессы и оценивают качество ИТ-сервисов по бизнес-метрикам — 13%.
- Обрабатывают обращения через почту, чаты и таблицы — 5%.
- Затруднились ответить — 4%.
Рисунок 2. Как организовано управление ИТ-услугами в вашей компании?
Структура современной ITSM-платформы
Илья Шабанов представил слайд с пятью слоями, из которых складывается современная ITSM-платформа: взаимодействие с пользователями, управление ИТ-услугами, данные об инфраструктуре, автоматизация и интеллект, управление и контроль. По его оценке, это далеко не полный перечень — в разных источниках таких «кирпичиков» насчитываются десятки, но эти пять образуют каркас, на который опирается зрелое решение.
Рисунок 3. Из чего состоит современный ITSM
Олег Скрынник связал эту схему с реальной проблемой рынка. Качество ITSM-систем в прошлые годы было невысоким, поэтому многие компании собирали нужную функциональность из разных продуктов: портал самообслуживания делали в одной системе, учёт конфигураций — во второй, отчётность — в третьей, а затем связывали их интеграциями. В результате возникает «зоопарк» решений, где даже добавление нового вида заявок превращается в многомесячный проект.
Выход — единая современная платформа, в которой все слои присутствуют изначально. Если какого-то блока не хватает, его должен добавить вендор, потому что рано или поздно он понадобится: компании последовательно движутся от Service Desk к инцидентам и проблемам, затем к CMDB, SLA и полноценной отчётности.
Дмитрий Сёмин предложил порядок освоения слоёв. Первым шагом выстраивается взаимодействие с пользователем, затем параллельно развиваются управление услугами и учёт инфраструктуры — они тесно связаны между собой. И только после этого настраивается автоматизация.
Ошибка при выборе системы часто состоит в том, что заказчик оценивает только те слои, которые нужны ему сегодня, и не учитывает рост компании. Через несколько лет возникает необходимость в автоматизации и контроле, а текущая платформа их не поддерживает, и переход на новую обходится значительно дороже, чем изначальный выбор решения с запасом функциональности.
Фёдор Боков добавил, что гибкие low-code-платформы позволяют не менять всё сразу, а постепенно отказываться от разрозненных систем: новый продукт интегрируется с существующими, после чего процессы переносятся внутрь единой платформы.
Илья Шабанов отметил, что логичным развитием этого подхода стала бы возможность программировать собственные доработки внутри самой ITSM — спрос на кастомизацию есть, и совмещение сервисной платформы с инструментами разработки выглядит востребованным.
Илья Шабанов, генеральный директор «АМ Медиа»
CMDB в структуре ITSM-платформы
Илья Шабанов напомнил, что CMDB нередко воспринимается как самостоятельный класс решений, хотя аналитики всё чаще считают её частью современной ITSM. Фёдор Боков подтвердил: CMDB — это связующее звено между учётом активов, где данные получают, нормализуют и дедуплицируют, и процессами, где эти конфигурационные единицы используются. Через ресурсно-сервисную модель просматриваются зависимости и влияние изменений, а уровнем выше возникают инциденты и проблемы, причины которых можно проследить до конкретных объектов.
Разницу между работой с CMDB и без неё участники разобрали на примере упавшего сервера. Дмитрий Сёмин объяснил: если учёта конфигураций нет, специалисты начинают вручную выяснять, что произошло, кто вносил изменения и какие системы затронуты. При наличии CMDB цепочка выстраивается от пострадавшей услуги вниз, к её конфигурационным единицам, а затем к недавним изменениям и данным мониторинга — время диагностики сокращается, а ответственные и связи уже зафиксированы в системе. При этом важно, чтобы CMDB актуализировалась.
Однако Олег Скрынник предупредил, что CMDB оправдана не всегда. В небольшой компании с простой инфраструктурой специалист найдёт причину сбоя и без неё, а затраты на ведение учёта окажутся лишними. Ценность CMDB растёт вместе со сложностью инфраструктуры: когда десятки инженеров и серверов, контейнеры и частные облака делают связи неочевидными, без структурированного реестра уже не обойтись.
Олег Скрынник, управляющий партнёр Cleverics, Altevics
Роль ИИ в ITSM
Дмитрий Сёмин отметил, что ИИ постепенно выходит за рамки эксплуатации: с его помощью уже можно формировать спецификации и типовые запросы для доработки самой ITSM-системы — то, для чего раньше требовалась команда сопровождения. Это снижает зависимость от штата разработчиков при адаптации платформы к меняющимся процессам.
Илья Шабанов поделился практическим опытом использования языковых моделей для формализации процессов: если продиктовать модели всё, что известно о том, как устроена работа, и передать документы с максимумом контекста, она помогает описать процесс, на который обычно не хватает времени из-за его рутинности. Перенос полученного описания на язык конкретной системы — уже дело техники.
Олег Скрынник обозначил границу возможностей ИИ. Задачи вроде написания плагина для системы или настройки кастомизации модель решает хорошо, если ей объяснить желаемый результат. Но там, где для решения задачи требуются стратегические знания, например при поиске способов увеличить прибыль, качество ответов модели пока недостаточно высоко. Граница будет сдвигаться, и прогресс в области ITSM и low-code-платформ за последние шесть-девять месяцев очень заметен.
Дмитрий Сёмин подчеркнул условие эффективности ИИ: система должна быть открыта к изменениям и свободна от вендор-локов. Чем больше в ней можно изменить без участия поставщика, тем проще агенту подстроить платформу под процессы конкретной компании.
Фёдор Боков уверен: всё, что не сопряжено с рисками, можно спокойно передавать агенту и автоматизировать. Исключение — операции вроде автоматической выдачи доступов и разблокировки учётных записей: они могут повлечь проблемы и требуют осторожности.
Во втором опросе выяснилось, какие задачи ITSM зрители готовы доверить ИИ (мультивыбор):
- Самообслуживание (ответы по базе знаний, создание и маршрутизация заявок) — 82%.
- Помощь инженерам (поиск похожих обращений, анализ переписки и подготовка статей) — 79%.
- Отчётность и аналитика (подготовка отчётов, поиск причин нарушений SLA) — 69%.
- Мониторинг (объединение оповещений и раннее выявление сбоев) — 65%.
- Типовые запросы (автоматическая выдача доступов, разблокировка учётных записей) — 47%.
- Управление проблемами (поиск связанных инцидентов и причин повторяющихся сбоев) — 46%.
- Управление изменениями (оценка влияния, рисков и плана отката) — 21%.
Рисунок 4. Какие задачи ITSM вы готовы доверить ИИ?
Выбор платформы: функциональность против стоимости владения
Илья Шабанов вывел на экран слайд с шестью ключевыми доменами оценки зрелости ITSM-платформы по версии Gartner Critical Capabilities for ITSM Platforms: core-функциональность (управление запросами, изменениями, проблемами, каталогом услуг, SLA), автоматизация и оркестрация, CMDB, отчётность и аналитика, портал самообслуживания и мультиканальное взаимодействие, инструменты для эффективной работы службы поддержки.
Рисунок 5. Как оценивать ITSM-платформы
Дмитрий Сёмин добавил, что не хватает гибкости самой платформы — возможности изменять всё быстро и легко без огромного штата программистов. Также отметил, что мало какие ITSM-системы дают полноценную отчётность — для этого есть отдельный класс BI (Business Intelligence). ITSM должна хорошо собирать данные и легко отдавать их в BI-систему, а не пытаться выполнять её функции.
Олег Скрынник заметил, что слайд — это стандартный план демонстрации ITSM-системы. Без отчётности не бывает ни одного демо, потому что вся история опирается на метрики, SLA и KPI.
Фёдор Боков не согласился с коллегой по отчётности: внутри ITSM-платформы должна быть своя отчётность, пусть не такая мощная, как в BI, но без неё никуда.
Фёдор Боков, инженер отдела развития, Security Vision
По поводу мультиканального взаимодействия Олег Скрынник сказал, что большой глубины здесь нет — это просто галочка, которая должна быть. Новизна находится в области ИИ-агентов, чат-ботов и ассистентов. Люди привыкли к такому опыту, как на портале Госуслуг с роботом Максом.
Илья Шабанов добавил, что важно объединение в единый пользовательский опыт: если пользователь начал общение по почте, а потом позвонил или написал в корпоративный чат, ИТ должны знать, что это тот же пользователь по той же заявке. Он отметил, что Gartner не выносит на первый план стоимость покупки и владения, а для российского рынка в 2026 году это важно: доработки, техподдержка, миграция — всё это надо считать на старте.
Блиц: как выбрать зрелую ITSM-систему?
Олег Скрынник:
«ITSM-система в компании обычно используется от 8 до 11 лет. Это покупка надолго, миграция — сложное и дорогое удовольствие. Меньше всего я бы смотрел на сравнение по функциональности: современные ITSM-системы хорошего класса, в том числе российские, довольно близки, и всё, что вы хотите, они умеют. Выбирать нужно с точки зрения совокупной стоимости владения. Система всегда развивается, кастомизируется, интегрируется. Это всё стоит денег и труда».
Дмитрий Сёмин:
«Функциональность современных ITSM-систем на верхнем уровне плюс-минус одинаковая. Дифференциация в трёх вещах:
- Гибкость: система должна позволять себя изменять и модифицировать постоянно, должно быть минимум вендор-локов.
- Возможность делать процессы, которые мы хотим, уходить от ITSM к ESM, потому что мы говорим про долгосрочное.
- Возможность работы с ИИ: как система взаимодействует с ИИ, как она умеет работать с локальными моделями».
Фёдор Боков:
«Соглашусь с коллегами: нет смысла смотреть на функциональность. Главное — понимать, что вы хотите от ITSM-системы, подходит ли она под ваши запросы и процессы. Стоит оценивать гибкость платформы и затраты на её адаптацию под ваши процессы. И без искусственного интеллекта никуда: насколько удобно с помощью ИИ-агента кастомизировать платформу, насколько он встроен и какие процессы поможет сделать самостоятельно».
В третьем опросе зрители рассказали, что больше всего мешает их компании управлять качеством ИТ-сервисов (мультивыбор):
- Слишком много ручных операций и согласований — 83%.
- Не хватает специалистов и ресурсов — 75%.
- Не определены владельцы и зоны ответственности за ИТ-сервисы — 58%.
- Нет понятных метрик качества сервисов и их влияния на бизнес — 52%.
- Нет актуальной картины ИТ-сервисов и зависимостей в CMDB — 41%.
- ITSM, мониторинг и другие системы плохо интегрированы — 17%.
- Устраняют инциденты, но не их первопричины — 16%.
Рисунок 6. Что больше всего мешает вашей компании управлять качеством ИТ-сервисов?
Основные сложности при внедрении
По словам Дмитрия Сёмина, сложности при внедрении очень разные и зависят от того, откуда стартует компания. Если старт идёт от Service Desk, который уже был, будет легче — специалисты уже приучены к работе в системе, хотя многое надо перестраивать под ITSM. Во многом компании встречают сопротивление ИТ: переход к полноценному ITSM с управлением услугами повышает прозрачность ИТ, а это любят не все ИТ-директора.
Отдельная история — миграция данных: важно не потерять исторические данные и перенести их в новую систему. Большая трудоёмкая часть — отстройка процессов: нужно всё выстроить и настроить так, чтобы не помешать текущей работе.
Олег Скрынник дополнил, что миграция ITSM-системы принципиально ничем не отличается от миграции любой другой ключевой системы компании: на неё много завязано, в ней много процессов и накопленных данных, к ней привыкли и пользователи, и ИТ-специалисты. Но за последние годы из-за тренда на импортозамещение айтишники научились очень круто решать вопросы миграции — дошли и до ITSM-систем.
Интересный тренд: раньше компании старались сохранить свои уникальные процессы и кастомизации, которые годами настраивали в ITSM-системе, и накопленные данные. Этот тренд ушёл в прошлое. Сейчас разговор про миграцию часто начинается с того, что процессы одинаковые и отрасль не сильно отличается, а особенности можно учесть в хорошей low-code-платформе. Миграция упрощается.
Олег Скрынник привёл пример, почему перенос данных может быть дорогим и бессмысленным. Корень любой ITSM-системы — каталог услуг. Миграция на новую систему — отличный повод пересмотреть каталог. Но тогда появляются две версии каталога: старая и новая, а заявки привязаны к старой версии. Привязать их к новой нельзя. Решать эту задачу долго и дорого. Пользуясь моментом, стоит улучшить сервисы и автоматизацию, а не просто заменить одну систему на другую.
Дмитрий Сёмин возразил: исторические заявки 15-летней давности действительно можно не переносить, но с CMDB ситуация иная. Если данные о конфигурационных единицах заносили вручную, без дискаверинга, и учёт держится на ручном контроле, отказ от переноса означает потерю накопленных данных. То же касается базы знаний: при наличии статей и описаний часть активных материалов стоит перенести.
Фёдор Боков согласился: перестроение и актуализация базы знаний и CMDB могут занять больше времени, чем перенос данных.
Илья Шабанов отметил, что основная проблема при новом внедрении — подходить к ITSM как к организационному проекту: формализовать процессы, понять, какие услуги оказывает ИТ. Если этого не сделать, получится попытка автоматизировать хаос.
Тренды: ИИ-агенты, ESM и эволюция ITSM
Илья Шабанов вывел слайд с ключевыми трендами рынка ITSM на ближайшие годы: ИИ-помощники и агенты, автоматизация с их помощью, интеграция с мониторингом и системами observability, CMDB как основа для крупных организаций, эволюция в сторону Enterprise Service Management, использование ITSM как средства оценки результативности ИТ (включая биллинг).
Рисунок 7. Ключевые тренды ITSM на 2027–2029 годы
Олег Скрынник:
«Пункт про ИИ сейчас наиболее важен, а остальное снижается в значимости. Второй важный тренд — ESM. Мы уже умеем отрабатывать по правилам, процессам, каталогам и SLA заявки ИТ; почему не делать то же самое для HR и других подразделений с сервисной составляющей? Это естественное движение, и оно очень заметно на рынке.
Более глубокий уровень ESM — сквозные заявки, в которых участвуют несколько подразделений: часть работы выполняет HR, часть — ИТ, часть — АХО. У каждого подразделения свой руководитель, свои KPI и свой бюджет. Поэтому нужно ответить на вопросы: как эта сквозная услуга называется, из каких этапов состоит, кто отвечает за неё целиком и по каким метрикам оценивается результат.
Система позволяет связать заявки разных подразделений в один процесс, но организационный вопрос — кто владелец услуги и как согласовать KPI разных отделов — сложнее технической автоматизации. Именно такие вопросы компании начали ставить и видеть в их решении ценность. Причём ESM переносит в бизнес-подразделения не только работу с заявками: из ITSM берутся CMDB (учёт объектов и связей между ними), управление изменениями и управление доступностью».
Дмитрий Сёмин согласился, что тренд на ESM идёт от бизнеса и задаётся сверху: после внедрения ITSM ИТ стал прозрачным, появилась возможность считать деньги — почему бы не распространить этот подход на АХО или бухгалтерию? Бизнес стремится управлять затратами и повышать прозрачность по всем направлениям, а ИТ стали первыми, кто начал это внедрять.
По функциональности Дмитрий Сёмин считает CMDB основой, но уже пройденным этапом: давно пришли к выводу, что необходима ресурсно-сервисная модель. Сейчас активно развивается ИИ, но главное — не переусердствовать: не стоит применять ИИ там, где достаточно простой автоматизации. Он нужен для задач, требующих логики, анализа и нестандартных решений. Помощники и агенты помогают собрать данные из разных источников, а observability позволяет ИИ рассмотреть проблему всесторонне. Важно, чтобы ИИ можно было встроить в любую платформу.
Фёдор Боков добавил, что каждому уровню зрелости соответствует своя автоматизация: при базовом сервис-деске — отказ от ручной обработки заявок, на следующем уровне — помощники и агенты, при выстроенных процессах — переход к ESM. Таким образом, каждая компания может выбрать решение, соответствующее её задачам.
Финальный опрос показал, планируют ли зрители после эфира внедрять или развивать ITSM в своей компании:
- Будут развивать текущие решения и процессы — 38%.
- Планируют запуск нового проекта — 31%.
- Возможно, но пока это не приоритет — 16%.
- Текущий подход устраивает — 11%.
- Не видят необходимости — 4%.
Рисунок 8. Планируете ли вы после эфира внедрять или развивать ITSM в своей компании?
Выводы
Обсуждение показало, что зрелость российского рынка ITSM измеряется не темпами роста, а глубиной использования. Формально почти все крупные компании имеют централизованную систему, однако большинство применяет её лишь для фиксации обращений. Возможности современных платформ остаются невостребованными, и этот зазор — главный резерв развития отрасли.
Главный акцент дискуссии сместился с технологий на управление. Программный продукт сам по себе не меняет качество сервиса: без описанных услуг, согласованных сроков и ответственных за результат автоматизация лишь фиксирует сложившийся порядок. Поэтому проект внедрения стоит оценивать по организационной готовности компании, а не по набору функций в демо-версии.
При выборе решения эксперты предложили отказаться от погони за максимальным списком возможностей. Продукты лидеров рынка близки по базовой функциональности, а реальная разница проявляется в стоимости эксплуатации на горизонте многих лет, свободе от привязки к вендору и способности адаптироваться без дорогих разработок. Именно эти параметры определяют, насколько комфортно система будет развиваться вместе с компанией.
Изменился и подход к переходу на новую платформу. Вместо механического переноса всего накопленного опыта рынок приходит к пересмотру унаследованных решений: устаревшие настройки и неинформативные архивы теряют смысл, тогда как структура конфигурационных единиц и корпоративные знания остаются ценностью, которую стоит сохранить.
Вектор дальнейшего развития задают два направления. Искусственный интеллект постепенно становится штатным участником сервисных процессов, но его отдача напрямую зависит от качества накопленных данных и дисциплины их ведения.
Параллельно сервисная логика выходит за границы ИТ — в HR, финансы и административные службы, где ключевым становится не техническое связывание заявок, а договорённость о едином владельце сквозной услуги и общих показателях результата. Оба тренда ведут к одному: ITSM превращается из инструмента поддержки в механизм управления эффективностью компании.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
