Опыт миграций ITSM-систем: типичные ошибки и как их избежать

Миграция ITSM — это не просто замена очередной ИТ-системы

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

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

Дальше разберем по очереди самые типичные проблемы, с которыми сталкиваются наши клиенты в 2024–2025 годах, планируя и выполняя миграции своих ITSM- и ESM-систем.

Ошибка №1: неудачный выбор программного продукта

Самая фундаментальная ошибка, способная перечеркнуть весь проект миграции еще до его начала, — это выбор неподходящего ПО. Незрелая, сырая разработка с ограниченной функциональностью или, что еще опаснее, устаревшая платформа, позиционирующаяся как «современное low-code решение», не просто разочарует — она аннулирует все потенциальные выгоды перехода. Месяцы усилий, значительные бюджеты, и все ради системы, которая функционально уступает старой или требует таких костылей для базовых задач, что становится непонятно, а нужно ли было вообще куда-то мигрировать.

Главный миф, подстерегающий ИТ-руководителей сегодня — иллюзия широкого выбора. Заглянем в реестр отечественного ПО — в нем найдем более 20 систем, относящихся к классу ITSM/ESM. Это создает ощущение роскоши выбора, обилия вариантов для миграции. Осталось только придумать критерии и, собственно, устроить конкурс. Однако реальность немного отличается от таких ожиданий.

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

Как избежать потерь времени и мук выбора? Вот что точно не работает:

• Составление максимально детальных критериев и «проверка» претендентов на соответствие им. Почему не работает? Да потому что при сегодняшнем уровне развития технологий по всем вашим критериям ответ вендора будет «Да, можем!». За скобками останется — правда ли, как долго, как дорого? Лукавство вендора может остаться незамеченным.
• Принятие на веру заверений вендора, например «low-code!», «все процессы!», «глубокая кастомизация!», «коннекторы из коробки!». Проверяйте, не доверяйте. За большинством таких утверждений стоят скромные возможности и бедная функциональность.
• Особое внимание возрасту продукта. Проверенное годами не может быть плохим, верно? Нет, может. То, что разрабатывалось 10–15 лет назад, скорее всего, будет уже устаревшим.
• Акцент на количество внедрений. Аналогично: то, что выбрали десятки компаний, наверное, и нам подойдет? Не факт. Выбор, как показывает опыт, может быть иллюзорным, навязанным сверху, сбоку, политически или еще как-то.

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

Второе: сравнивайте не ПО, а все то, что кажется, на первый взгляд, второстепенным. А именно: методологическую проработанность, наличие открытого исходного кода (да, среди «больших» систем такое встречается), реальность заявленного «low-code», наличие универсального механизма интеграций (он окупится многократно).

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

Подробнее вопрос выбора ПО для ITSM мы разбираем в статье «Критерии выбора ITSM-системы».

Ошибка №2: неудачный подход к миграции

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

Увлечение глубокой, фундаментальной кастомизацией под себя — это очень долго и дорого. Каждая новая доработка, каждое отклонение от «коробочной» логики:

• Съедает ценное время и ресурсы. Разработка, тестирование и отладка сложных кастомных решений требуют месяцев работы высококвалифицированных (а потому дорогих) специалистов.
• Имеет долгосрочные последствия. Каждый кастомный модуль или измененный процесс имеет шансы стать техническим долгом. Например, применение обновлений ПО от вендора превращается в кошмар проверки совместимости и ручной разбор конфликтов слияния.
• Несет новые риски. Версия от вендора прошла множество тестов силами вендора, и каждый новый релиз снова и снова их проходит. Ваши доработки тестируете вы сами, при этом по опыту тестируется зачастую лишь созданная функциональность, да и та только «по главной дороге». Исключения, дополнения, отклонения отлавливать сложно. Проводить полное регрессионное тестирование — дорого. Поэтому риски дефектов, остановки системы и нарушения целостности данных резко возрастают.
• Отходит от лучших практик. Современные лидирующие ITSM-платформы в своей «коробке» уже заточены под лучшие мировые методологии. Переделывая их под себя, вы часто ломаете именно те механизмы, которые призваны повышать эффективность.

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

Что это дает:

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

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

Подробнее вопрос выбора подхода мы разбираем в статье «Когда меньше — это больше: выбираем подход к миграции ITSM-системы».

Ошибка №3: обязательный перенос всех исторических данных

Пройдены первые две ловушки: ПО выбрано хорошее, стратегия миграции принята верная. Казалось бы, самое сложное позади? Не спешите. Опасная иллюзия, подстерегающая проект миграции — восприятие полного переноса всех исторических данных как обязательного, незыблемого требования. «У нас 5/10 лет истории! Мы обязаны ее сохранить!» — звучит вроде бы убедительно. Однако слепое следование такой установке превращает миграцию в технический кошмар с затратами, многократно превышающими выгоды.

Идея перенести все сталкивается с суровой реальностью:

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

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

1. Не переносить вообще. Например, данные о закрытых обращениях. Кажется, что они очень нужны, но стоимость их переноса существенно выше получаемых выгод (как правило, в выгоды записывают построение отчетности на исторических данных и возможность посмотреть историю конкретного обращения — для этого можно оставить старую систему в режиме «только для чтения»).
2. Переносить частично. Например, при переносе данных о конфигурационных единицах бывает важно не потерять историю работ с ними (когда и кем установлено, кто согласовал доступы, какие модификации выполнялись), но не так важно сохранить вспомогательную информацию (история изменения атрибутов).
3. Заменить на интеграцию. Например, сведения об организационной структуре не нужно переносить, так как их можно регулярно забирать из мастер-источника.
4. Переносить, но не автоматически. Например, каталог ИТ-услуг. Есть соблазн его просто «скопировать», но если новая система методологически более продумана, то копирование нанесет вред. Лучше каталог реструктурировать, обновить, и только потом загружать в целевую систему. В этом же разделе находятся SLA и контракты с подрядчиками.

Пункты списка выше расположены в порядке увеличения затрат (как правило).

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

Ошибка №4: старые процессы на новой платформе

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

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

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

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

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

Ошибка №5: форсирование сроков и недооценка сложности

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

• «ITSM/ESM — это всего лишь продвинутая система регистрации заявок». Это радикальное упрощение сводит всю мощь платформы управления услугами к функции сервис-деска, игнорируя ее системообразующую роль.
• «Миграция за три месяца реальна». Уверенность, что такой проект, особенно в средней или крупной компании с сотнями сотрудников, тысячами пользователей и сложной инфраструктурой, можно завершить в сроки, типичные для замены гораздо более простых инструментов.

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

• управление обращениями (запросами на обслуживание)
• управление инцидентами
• управление проблемами
• управление изменениями
• управление конфигурациями
• управление ИТ–активами
• управление уровнем услуг (SLA), управление каталогом услуг
• управление релизами
• управление мощностями
• управление ИТ–бюджетом
• …

Эти процессы тесно переплетены: успех одного (например, быстрого решения инцидента) зависит от данных и состояния других (например, актуальности CMDB для поиска зависимостей).

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

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

Далее, ITSM/ESM-система никогда не находится в одиночестве. Она интегрирована с большим числом других систем, и большую часть интеграций придется включать в охват проекта миграции:

• аутентификация, SSO, синхронизация учетных записей с Active Directory, LDAP;
• коммуникации, интеграция с корпоративной электронной почтой, подключение к системам мгновенных сообщений;
• системы управления доступом (IDM), автоматизация создания/блокировки учетных записей, предоставления и отзыва доступа;
• аналитика (BI), выгрузка данных для отчетности, дашбордов, прогнозов;
• инфраструктурный мониторинг, автоматическое создание инцидентов или иных объектов на основе событий в инфраструктуре;
• обнаружение элементов инфраструктуры (Discovery), автоматическое или полуавтоматическое наполнение и актуализация CMDB данными о конфигурационных единицах (CI);
• связанные сервисные платформы, обмен данными с другими ITSM/ESM-системами (например, если в компании используется несколько продуктов) или системами подрядчиков, смежников.

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

Установка произвольного короткого срока (вроде 3 месяцев), его громкое объявление или взятые на себя обязательства перед руководством без учета этих факторов гарантированно ведет к срыву сроков и обещаний, выгоранию команды, техническому долгу, низкому качеству реализации, конфликту с вендором и, в итоге, к существенному удорожанию проекта миграции. Реалистичный план — не признак медлительности, а проверенный способ снижения рисков.

Заключение

Может показаться, что автор статьи ставил себе задачу читателя запугать: ошибки, риски… Это вовсе не так. Строго говоря, ничего принципиально сложного в миграции ITSM-системы нет. Понятная задача, известный спектр вариантов решения. В конце концов, не первая и не последняя замена ИТ-системы: да, несколько специфичной, но все же.

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

Удачи в миграции ITSM!