Вы платили ServiceNow за Ferrari, а ездили на нём в магазин

В 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 или кастомизировать процессы глубже шаблона, упрётесь.

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

ITGLOBAL.COM внедрил ITAM от SimpleOne: автоматизация учета активов вместо Excel и переход к международной логистике

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

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

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

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

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

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

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

***

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

ссылка на оригинал статьи https://habr.com/ru/articles/1053390/