Когда меньше – это больше: выбираем подход к миграции ITSM-системы

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

В подготовке статьи приняли участие Юрий Ерин, Евгений Шилов и Олег Скрынник. Они профессионально занимаются ИТ-менеджментом и автоматизацией ITSM с 2000-х годов, непосредственно участвовали в десятках проектов, их профессионализм подтвержден международными сертификатами. Можно верить.

Готовые решения вроде Altevics предпочтительнее: они обеспечивают быстрый старт и используют современные low-code технологии. Глубокая кастомизация часто приводит к долгосрочным проблемам и повышенным затратам.

Многие из нас знают эту старую пословицу: «Переезд хуже пожара». В мире информационных технологий она обретает новый, технологически насыщенный смысл. Тенденция, радикально усилившаяся после 2022 года, превратила миграцию с устаревших или нежелательных платформ (особенно зарубежного происхождения) из теоретической возможности в насущную, часто жёсткую необходимость для многих российских компаний. Потребность в технологическом суверенитете, ограничения зарубежных вендоров, «схлопывание» технической поддержки, отсутствие обновлений (в том числе безопасности) вынуждает руководителей ИТ искать замену очень многим системам и оперативно мигрировать на оставшиеся доступные решения. Всё это совершенно не новость, в этих условиях мы находимся уже больше трёх лет.

В первую очередь «переезжают» бизнес-системы: ERP, CRM, MRP, самое критичное для работы организаций. Скажем честно: сама по себе любая миграция уже по определению связана с большой головной болью, солидными затратами и высокими рисками. Это отнюдь не просто перенос данных из точки А в точку Б, и уж тем более не любимая системными администраторами команда «uninstall», затем запуск «setup.exe». Миграция, как правило, сложный проект, масштаб проблем и финансовое бремя которого растёт пропорционально размеру компании – особенно это заметно для средних и крупных предприятий. Здесь счёт идёт на десятки миллионов рублей и сотни человеко-дней.

Когда же дело касается именно миграции ITSM-системы, градус сложности взлетает ещё выше. Почему? Потому что ITSM-система – это не просто инструмент учёта заявок или работ. Современные ITSM-системы автоматизируют с десяток (а то и больше!) критически важных ИТ-процессов согласно ITIL: управление инцидентами, проблемами и известными ошибками, изменениями, конфигурациями, уровнем услуг, доступностью, контрактами и поставщиками и т.д. Более того, во многих организациях применение ITSM (IT Service Management) плавно переросло в полноценное управление корпоративными услугами (ESM, Enterprise Service Management), отвечающее за запросы от самых разных департаментов: от IT и HR до бухгалтерии и эксплуатации зданий, офисов, магазинов. Таким образом, перенос всех этих тонко настроенных процессов в новую среду с сохранением их целостности и работоспособности – задача сложная.

"Миграция может стать не только переходом на другую систему автоматизации, но переходом на другие/новые технологии, которые появились в современных продуктах, не обремененных долгой историей и архитектурой, придуманной много лет назад. Одним из примеров технологических решений, оказывающих значимое влияние на изменение подхода к автоматизации, является встроенный в систему BPMN-движок, позволяющий легко, быстро и наглядно настроить сложные процессы обработки (например, ЗНО, ЗНИ, операции с активами и так далее). Главное не переусердствовать с использованием BPMN, чтобы не пришлось всю логику работы системы отрисовывать в графическом виде. Это может привести к обратному эффекту – усложнению настройки системы и снижению наглядности работы процессов."

Соблазн «переехать постепенно» – переносить процессы поэтапно – на практике чаще всего разбивается о суровую реальность. Вся прелесть (и одновременно проклятие) ITSM как раз в глубокой, неразрывной связности его внутренних механизмов. Попробуйте перенести управление инцидентами, когда новый, выбранный и установленный инструмент ещё не знает о конфигурационных единицах (КЕ) из базы данных управления конфигурациями (CMDB). А эта CMDB, в свою очередь, невозможна без правильно настроенного процесса управления изменениями, обеспечивающего актуальность вносимых данных. Управление изменениями плотно взаимодействует с управлением разработкой программного обеспечения, а разработка ПО – с управлением уровнем услуг (SLM)… Разорвать этот круговорот взаимозависимостей на изолированные «переездные» волны крайне непросто. Система автоматизации даёт ценность, а процессы эффективны только когда все они работают синхронно, слаженно. Минимум функциональности для запуска требует переноса гигантского пласта автоматизаций сразу. Хотелось бы одномоментно, за выходные, но мы понимаем, что так не получится.

И это ещё не все сюрпризы: ITSM-система за время своей работы (годы) обрастает невероятным количеством данных, скриптов и адаптаций «под себя». Сотни настроенных полей, десятки интеграций, автоматические сценарии, сложные правила назначения и согласования, правила и пороги эскалации – всё это кропотливо создавалось годами и неразрывно привязано к текущей системе. Базы данных конфигурационных единиц, детализированные реестры ИТ-активов, данные об используемом ПО и лицензиях, истории устранения инцидентов и выполнения изменений, а также плановых и регламентных работ – всё это не просто желательно, а обязательно должно быть перенесено в новую систему. Если же переносить не всё, то придётся определить границу: что переезжает, что остаётся в архиве. Например, по моему опыту, перенос исторических записей о запросах, инцидентах, работах очень редко попадает в охват миграции. Однако и без них остаётся много накопленных данных.

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

Может, тогда отложить миграцию «на потом»? Многие так делают, однако есть факторы, которые мешают оставаться на старой системе. Перечислим их кратко:

И вот здесь вступает в игру ключевой фактор времени: миграция ITSM-системы в какой-либо компании – событие редкое, происходящее по моим наблюдениям раз в 5–8 лет. Это затратный и достаточно сложный проект. Его особенность такова: если выбор системы и выбор подхода к миграции сделан, то следующий шанс сделать новый выбор, получше, будет весьма нескоро. Среднее время работы сотрудника на одном месте меньше, чем время жизни ITSM-системы в организации.

Итак. Сложность, дороговизна и редкость подобных миграций означают одно: ошибиться с выбором подхода к миграции и выбора новой системы сегодня – значит получить долгосрочные и неприятные последствия завтра. В этой статье мы сфокусируемся именно на выборе подхода к миграции и внедрению новой системы. Собственно выбор конкретной ITSM-системы из доступных на рынке – отдельная тема, которую мы уже разбирали (https://cleverics.ru/ideas/itsm-system-selection-criteria).

После вдумчивого (и, возможно, слегка панического) осознания масштаба предстоящего «пожарно-эвакуационного» мероприятия перед ИТ-руководством встаёт фундаментальная развилка. Традиционно на рынке используются два принципиально разных подхода к тому, как именно осуществлять миграцию.

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

Первый путь: глубокий кастом. Его суть заключается в создании решения (самостоятельно или вместе с вендором), тотально заточенного под уникальные процессы, специфику структуры, регуляторные требования, менталитет и привычки сотрудников конкретной организации. Это попытка построить идеально подогнанный под себя ITSM-корабль.

Наверняка можно придумать и что-то посередине, но мы остановимся на крайностях, чтобы не сбивать фокус. Вопрос выбора подхода не праздный: от него зависят не только бюджет и сроки, но и долгосрочный эффект от замены ITSM-системы (или его отсутствие). Какой путь сулит меньше потраченных нервных клеток и больше ощутимых результатов?

Нужно понимать: универсального ответа нет. К примеру, путь на этой развилке во многом зависит от зрелости ИТ-процессов в вашей компании и готовности команды (да и бизнеса в целом) к изменениям. А ещё от установленных ограничений по срокам, наличия необходимых компетенций внутри организации, ожиданий помощи от вендора… Влияющих факторов довольно много.

Поэтому далее для ясности и объективного, насколько это возможно, сравнения рассмотрим каждый из этих двух подходов подробнее, по порядку.

Переходим к детальному анализу первого подхода: создание полностью кастомизированного решения «под ключ». Эта стратегия выглядит привлекательно как минимум на этапе планирования. Идея проста: вместо того, чтобы адаптировать свои процессы под ИТ-систему, будем адаптировать ИТ-систему под свои процессы. Цель – получить инструмент, который не потребует переучивания сотрудников, пересмотра регламентов, переделки принципов интеграций с другими системами. Звучит как мечта процессного консультанта, уверенного в своих силах и знающего, чего он хочет.

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

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

Второй: абсолютная зрелость и стабильность. То есть ИТ-процессы давно и хорошо формализованы, неизменны годами и имеют статус «идеальных». Менять их – только сделать хуже.

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

К этому списку, конечно, стоит отнестись критически. Как практикующий эксперт, я довольно часто слышу первый, второй, третий пункты или их комбинации. Не выдают ли клиенты желаемое за действительное? Например, жёсткость процессов может быть обусловлена не особенностями отрасли или компании, а присущей компании зашкаливающей степени бюрократии. То есть мы имеем внутренний фактор, а вовсе не внешний, а вместе с ним – «удобное» объяснение собственной уникальности. Аналогично и про второй кейс – компаний, где ITSM-процессы выстроены, отлажены и неизменны, на всю Россию максимум десяток. Вероятность, что ваша компания входит в их число, не так уж велика. Третий кейс также разбивается о суровую реальность: свободных ресурсов сейчас нет ни у кого, и в ближайшие 5-10 лет не будет.

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

Принципиальное обновление системы (даже при желании команды) становится технически сложным или требует полной пересборки – фактически, новой миграции. Компания навсегда теряет возможность использовать инновации вендора, исправления безопасности, оптимизации производительности и получает законсервированный продукт.

Обновления от вендора могут приносить не только исправления ошибок, которых в давно существующей системе может и не быть (или быть не так много), но и новые функциональные возможности, поддержку новых технологий и окружающих программных продуктов (самый простой пример – браузеров, новых версия мобильных ОС). Кроме того, не стоит забывать об обновлениях, связанных с безопасностью.

Обновления от вендора важны, так как они привносят в систему новую функциональность, новые модули. Это позволяет процессам организации развиваться, не застывать на месте. К сожалению, на рынке представлены в том числе ITSM-системы, развитие которых со стороны вендоров уже давно замерло – ничего значимого не происходит долгие годы, дорожные карты отсутствуют или формальны. Но даже и в этих случаях получение и применение обновлений безопасности является критичным.

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

Напоследок отмечу также груз технологического долга. Каждая нестандартная доработка, каждый уникальный скрипт или недокументированный костыль становится кирпичиком в стене будущих проблем. Добавление или обновление функциональности или интеграция с новыми сервисами и системами превращаются в многонедельное копание в «чужом коде» (часто без документации). Это дорого.

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

Первый из них – создание в организации своей собственной ITSM-системы, почти с нуля. Это, конечно же, предельный кейс «кастома»: самописная система, разработанная внутри организации, максимально точно и полно учитывающая особенности этой организации. На мой взгляд, для ITSM-систем это крайне нецелесообразно: компании зачастую недооценивают сложность задачи, связанность процессов и наличие (отсутствие) требуемых методологических компетенций как внутри, так и на рынке (попробуйте сейчас найти адекватного ITSM-консультанта или методолога, да ещё свободного под ваш проект). Поэтому задача из «напишем под себя хорошее» превращается в долгострой, имеющий риск свестись к очередному трекеру заявок. Это тем более странно в 2025 году, так как выбор готового есть, и неплохой, а для компетентных ресурсов наверняка есть другие задачи, где можно увлечься внутренней разработкой. Самописная ITSM-система – это не только дорого и долго, но и требует постоянной поддержки и развития, что отвлекает ресурсы от основных бизнес-задач.

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

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

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

Основное преимущество такого подхода – возможность достичь быстрой отдачи от инвестиций. Типичный срок запуска ключевых процессов – от одного до трёх месяцев (в зависимости, разумеется, от выбранной вами ITSM-системы и команды внедрения). Такие короткие сроки позволяют организации значительно раньше получить практическую пользу от вложений по сравнению с проектами глубокой кастомизации. Важным достоинством является доступ к «встроенным» в систему индустриальным практикам: современные системы изначально содержат выверенные шаблоны процессов управления инцидентами, проблемами, изменениями и другими областями ITIL, позволяя избежать типичных ошибок «самодельных» решений.

Простота дальнейшего развития – ещё один важный плюс. «Коробочные» решения получают централизованные обновления от вендора: новые функции, исправления уязвимостей, улучшения интерфейса внедряются без необходимости перепроектировать архитектуру или выделять значительные внутренние ресурсы на доработки. По сути, эти ресурсы уже выделил вендор. Также упрощается интеграционный ландшафт: многие платформы предлагают предварительно настроенные коннекторы к популярным системам мониторинга, управления идентификацией (IAM/IDM), BI-инструментам, либо предоставляют гибкие API для разработки специфических интеграций.

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

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

Вернёмся на полшага назад. Что же собой представляет хорошая ITSM-коробка?

С учётом того, что ITSM недавно отпраздновал своё 25-летие, современные программные решения этого класса далеки от примитивных систем прошлого. Они обеспечивают из коробки комплексную автоматизацию всех ключевых ITIL-процессов – от операционных (управление инцидентами, проблемами, изменениями, конфигурациями…) до тактических (управления уровнем услуг, каталогом услуг, сервисной экономикой, мощностями…). Важным преимуществом стали развитые визуальные и аналитические возможности: интерактивные дашборды и отчёты в реальном времени, позволяющие отслеживать эффективность команд, динамику процессов и соблюдение соглашений об уровне услуг. Поддержка различных каналов коммуникации – через веб-порталы, мессенджеры, мобильные приложения или Email – сделала их полноценными платформами для сервисного взаимодействия.

Отдельно стоит остановиться на low-code. Эта концепция в современных ITSM-системах, к счастью, вышла за рамки маркетингового лозунга. Под этим термином скрывается принципиально иной подход к работе с платформой, где программирование уступает место визуальным конструкторам, перетаскиваемым элементам интерфейса и предварительно настроенным шаблонам элементов, форм, процессов… Всё это позволяет бизнес-аналитикам существенно расширять функциональность системы без глубокого погружения в разработку, при этом сохраняя контроль над логикой работы как системы в целом, так и её составных частей.

В части ITSM практическая реализация low-code проявляется в нескольких ключевых сценариях. Настройка рабочих процессов – один из наиболее востребованных примеров. Визуальные редакторы позволяют проектировать сложные цепочки обработки заявок прямо в нотации BPMN: так, можно буквально за несколько часов построить сложный маршрут для конкретного вида запросов с нужными согласованиями, автоматической проверкой доступности конфигурационных единиц, определением требуемых параметров и отправкой уведомлений заинтересованным лицам.

Даже разработка интеграций переходит в плоскость low-code. Вместо использования готовых коннекторов, которых вечно не хватает, или написания сложных программ и скриптов, специалисты могут использовать графический интерфейс для настройки взаимодействия между несколькими системами. Например, интеграция с Zabbix или Prometheus может автоматически превращать сообщения о критичных событиях в инциденты, или разбирать входящий поток сообщений электронной почты, или вызывать по API систему управления доступом, и многое другое.

Работа с данными и интерфейсами пользователя также переходит на принципы low-code. Адаптация форм под специфические требования, добавление новых полей или создание кастомных дашбордов для отчётности – всё это выполняется через интуитивные визуальные редакторы. Скорость достижения результата вырастает многократно: вы запускаете систему с базовой конфигурацией, а точечные адаптации выполняете постепенно, по мере возникновения потребностей. Это настоящая демократизация ITSM-разработки, где рутинные задачи перестают зависеть исключительно от дефицитных программистов или сотрудников интегратора.

Сейчас многие (если не все) вендоры относят свои системы к low-code системам. Но что такое low-code? Это возможность конфигурирования автоматизации процессов с минимальным написанием низкоуровневого кода. Так быстрее и проще, так как не требуется глубокого знания языков программирования. Минимизация кода достигается тем, что вендор создает готовый набор кубиков (визуальных или в виде готовых методов для встроенного упрощенного языка) и разработчику остается собрать из этих кубиков своё решение.

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

Внимательный читатель уже давно заметил, что автор при рассмотрении и «кастома», и «коробки», склоняется к тому, что «коробка» – это оптимальный выбор на данный момент. Однако это субъективное мнение, которое нуждается в доказательной базе, или, как минимум, чёткой аргументации. Мы работаем в области информационных технологий, а потому любим всё раскладывать по полочкам. Что мешает нам сделать таблицу сравнения двух подходов? Ничего не мешает. Основываясь на проектах миграции ITSM- и ESM-систем в России в последние годы (2022–2025 гг.), получаем следующую картину для компании среднего размера:

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

Представьте, что вы приобрели полный комплект мебели для нескольких жилых комнат своей квартиры. Например, от ранее популярного «вендора» с названием из четырёх букв и большими синими магазинами. В доставленных вам коробках есть всё необходимое для сборки – детали, модули, крепления и даже инструкции. Будет ли сборка быстрее, если вы начнёте сразу сверлить в панелях дополнительные отверстия или красить их в новые, необычные цвета? Вряд ли. Внедрение готовой ITSM-системы в 2025 году происходит по схожему принципу: скорость и предсказуемость достигаются не за счёт творческих экспериментов, а благодаря строгому следованию заводской инструкции.

Возьмём для примера типовой проект «Быстрого старта», используемый при внедрении ITSM-системы Altevics.

Такой поэтапный, но чётко структурированный подход минимизирует риски и позволяет быстро получить работоспособную ITSM-систему.

Миграция ITSM-системы – не самоцель, а возможность повысить эффективность работы ИТ-департамента за счёт отказа от «наследства». Как мы убедились, современные коробочные решения кардинально изменили правила игры. Их главные преимущества заключаются не только в скорости запуска базовой функциональности, но и в экономии внутренних ресурсов вашей ИТ-команды. Длинные, ресурсоемкие проекты кастомизации остаются в прошлом.

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

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