В 2022 году ServiceNow полностью прекратил работу с российскими клиентами — вместе с официальными партнёрами, облачной инфраструктурой и поддержкой. Для компаний, у которых на платформе были выстроены сквозные процессы от обработки инцидентов до контроля SLA и CMDB, это означало, что система формально ещё работает, но продлить лицензию, получить обновление или расширить функционал — уже некому. Одни компании мигрировали экстренно за месяц-четыре, когда лицензия заканчивалась и выбора не оставалось. Другие растянули переход на год-два, параллельно работая в старой системе. Часть продолжает работать в серой зоне и откладывает решение.

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

Сегодня об этом рассказывает Евгений Котухов, технологический партнер SimpleOne, ITSM/ITAM-эксперт

Как ServiceNow реально использовался и почему это важно при выборе замены

ServiceNow позиционировался как платформа для автоматизации любых бизнес-процессов — от ИТ до HR и юридического отдела.

На практике большинство российских компаний использовали его значительно уже: сервис деск, обработка инцидентов, запросов и изменений, контроль SLA.

CMDB — база конфигурационных данных — была у тех, кто дошёл до более зрелой эксплуатации платформы, но и там нередко существовала формально: данные вносились нерегулярно, связи между элементами не поддерживались в актуальном состоянии. Полный потенциал ServiceNow как единой платформы для всех подразделений компании в России использовали единицы.

Отдельный пласт — учёт ИТ-активов и лицензий, если он вёлся в ServiceNow ITAM: реестр оборудования, лицензионный комплаенс, связи активов с CI в CMDB. Эти данные мигрировать сложнее всего — у них своя структура, и при небрежном переносе вы получите на новом месте тот же рассинхрон между активами, конфигурациями и финансовым учётом, что был раньше.

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

Расставьте приоритеты: сначала данные, потом цели

При переходе с ServiceNow еще до выбора системы нужно решить вопрос миграции данных, он напрямую влияет и на требования к инструменту, и на оценку стоимости перехода. На платформе обычно накоплено разное: история инцидентов и изменений, данные CMDB, конфигурации процессов, SLA-метрики. Часть этого компании обязаны хранить по внутренним регламентам или требованиям регулятора — тогда их точно нужно перенести. Другая часть компаний тащит за собой годы накопленного мусора: CMDB, которая давно разошлась с реальностью, процессы под давно уволившихся людей, инциденты пятилетней давности, которые никто не чистил. Для них начать с чистого листа — не потеря, а возможность выстроить базу данных правильно с самого начала.

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

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

  • Среднее время закрытия инцидента, 

  • Процент заявок в срок, 

  • Доля обращений через портал самообслуживания, 

  • Актуальность CMDB в процентах покрытия.

Как выбрать

Прежде чем смотреть на конкретные системы — честный вопрос к себе: каким ServiceNow был у вас на самом деле?

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

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

Сценарий «нам бы тикеты принимать». ServiceNow использовался как сервис-деск: заявки, инциденты, изменения, SLA — и всё. Девяносто процентов платформы простаивало, а вы за него платили. Таким компаниям подходит специализированная ITSM-система в коробке: она делает ровно это, разворачивается быстро и не просит денег за модули, которые вы и в ServiceNow не открывали. Расплата — потолок: захотите подключить HR или кастомизировать процессы глубже шаблона, упрётесь.

Интерфейс SimpleOne ITSM
Интерфейс SimpleOne ITSM

Сценарий «у нас тут CMDB и активы». Вы дошли до зрелой эксплуатации: база конфигураций, учёт активов, связь инцидента с конкретным железом — когда что-то падает, видно, что это, чьё и на гарантии ли. Это уже не сервис-деск, это ITSM-платформа с CMDB и ITAM в одном контуре, и заменять её коробкой — значит разорвать связку «инцидент ↔ актив», которую вы годами выстраивали. Главная боль перехода — не функции, а миграция CMDB: перенести её так, чтобы она не разошлась с реальностью в первый же месяц.

Интерфейс SimpleOne ITAM
Интерфейс SimpleOne ITAM

Сценарий «на этом работает половина компании». ServiceNow вышел за пределы ИТ: заявки в HR, согласования у юристов, процессы финансистов — единая сервисная платформа, ровно как её и задумывали. В России таких единицы, но если вы из них — вам нужна не ITSM-система, а ESM-платформа с Low-code, иначе придётся держать рядом ещё три инструмента, каждый со своей лицензией и своей точкой отказа.

Интерфейс SimpleOne ESM
Интерфейс SimpleOne ESM

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

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

Как не повторить старую конфигурацию на новом месте

Самая распространённая ошибка при переходе с ServiceNow — попытка перенести все существующие процессы один в один. Логика понятна: люди привыкли к определённому порядку работы, регламенты написаны под текущую конфигурацию, и любое отклонение воспринимается как риск. В результате новая система настраивается под старые процессы, включая те, которые работали плохо или не работали вовсе.

Новая платформа — это точка, в которой процессы можно пересмотреть. Если инцидент второй линии в среднем висел три дня не потому что так задумано, а потому что маршрутизация была неудобной — это меняется при настройке новой системы, а не после. Если портал самообслуживания в ServiceNow использовало 15% сотрудников, потому что он был неудобным — это тоже повод настроить иначе, а не воспроизвести то же самое.

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

***

А вы уже проходили этот переход? Расскажите, что выбрали и обо что споткнулись.

Комментарии (3)


  1. Makakiss
    29.06.2026 12:23

    Мужики, я 15 лет в айти. Заголовок прям в душу. У нас был ServiceNow три года и из всей платформы мы использовали инциденты, запросы и SLA. CMDB для галочки, ITAM не открывали вообще ни разу. Платили как за космический корабль а ездили в магазин за хлебом, автор не соврал

    Самое смешное - когда всё отключилось выяснилось что половину процессов мы и так делали мимо системы. Критичные инциденты разбирали в телеге, эскалации через звонки, SLA я контролировал в экселе потому что отчёт в сервиснау строился 40 секунд и каждый раз врал по разному

    Когда начали выбирать замену первым делом написали ТЗ "хотим как было". Вендор посчитал, финдир увидел цифру и чуть не упал. Сели, выкинули половину, оказалось нам реально нужно 30% от того что было. За треть цены. И работает лучше

    Единственное что добавлю - если переносите CMDB один в один вы переносите мусор. У нас в старой системе было 1200 активов, живых оказалось 750. Мы начали с чистого листа и не жалеем. Татьяна Михайловна из бухгалтерии правда до сих пор спрашивает куда делись 450 единиц с баланса но это уже другая история)


  1. Esmi_17
    29.06.2026 12:23

    Статья хорошая но хочу подсветить один момент который тут обошли. Проблема ServiceNow в России была не в том что его много или мало использовали. Проблема в том что он создавал иллюзию зрелости процессов. Компания покупала платформу, вендор приезжал с консультантами, настраивал ITIL by the book, все получали красивые дашборды и считали что у них теперь зрелый ITSM. А по факту процессы держались на конфигурации вендора а не на понимании команды. Когда платформу выдернули - выяснилось что люди не понимают собственные процессы без интерфейса который им подсказывал следующий шаг


    1. Evgenii_ESM Автор
      29.06.2026 12:23

      Спасибо за дополнение, полностью согласен. Честно говоря, я осознанно обошёл этот момент для многих ServiceNow благодаря маркетингу лучшая в мире система, но не для меня.

      По сути, вы описываете общую проблематику любого инструмента. Многие заказчики хотят максимально всё предусмотреть в системе: подсказки, чёткие следующие шаги, тотальную автоматизацию. Но у такого подхода есть ряд проблем, две из которых очевидны.

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

      Желание выстроить единый жёсткий процесс понятно. Но нельзя прибивать всё гвоздями иначе потом придётся отдирать. 80% задач действительно идут по запланированному маршруту, и под них жёсткий процесс оправдан, а вот для оставшихся 20% маршрут должен уметь гибко и оперативно перестраиваться и эту гибкость нужно закладывать с самого начала.