Что делать, если продукт перестал соответствовать потребностям или больше не поддерживается вендором? Можно притворяться, что проблемы нет с вами в комнате, допиливать своими силами, подставлять «костыли» из других систем — или решиться на миграцию. 

Привет, Хабр! Меня зовут Ксения, я — бизнес-аналитик в ITSM 365, организую переезды клиентов на наш сервис деск.

Опыт накоплен большой, давайте вместе разберемся на реальных кейсах:

• внешняя и внутренняя миграция — в чем разница;

• зачем мигрировать на новую конфигурацию продукта;

• как подготовиться к переезду и минимизировать риски;

• для кого миграция — не выход, и что делать в этом случае.

Типы миграции: особенности и опыт клиентов

Миграция — важный этап жизненного цикла ИТ-инфраструктуры, который делает ее современнее и эффективнее. Мы в своей практике сталкиваемся с двумя основными вариантами переезда.

• Внешняя миграция — замена одной системы на другую

Особенности:

1. Разная логика работы систем — например, другой подход к работе с заявками. Команде придется перестраивать рабочие привычки, адаптация потребует времени!

2. Проблемы с API — нередко возникает несовместимость форматов данных, появляются сложности из-за различий в архитектуре, лимитах и так далее.

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

Кейс:

Сети ветеринарных клиник «Белый Клык» и «Центр» мигрировали с иностранной сервис деск системы на ITSM 365. Чтобы ускорить переезд, ИТ-отдел подготовил подробное ТЗ. В нем описали процессы саппорта и других отделов и сформулировали основные задачи по доработке платформы. 

Затем подключили новый сервис деск к корпоративному домену, настроили аутентификацию SSO, импортировали справочник сотрудников и отделов из Active Directory, перенесли статьи базы знаний, загрузили информацию об ИТ-активах.

Для удобства пользователей заранее запустили информационную кампанию и провели обучение на основе сопоставления с предыдущим решением.

Миграцию удалось полностью завершить всего за 2 месяца.

• Внутренняя миграция — переезд на новую конфигурацию продукта

Особенности:

1. Совместимость кастомизаций — доработки, выполненные на старой конфигурации, на новой могут работать не так, как ожидается.

2. Миграция данных — переносить данные «внутри продукта» намного проще, так как можно использовать базу данных старой конфигурации из-за схожести архитектуры.

3. Обучение пользователей —  в новых конфигурациях обычно есть визуальные и архитектурные изменения, поэтому пользователям может потребоваться небольшое обучение.

Кейс:

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

План переезда на новую конфигурацию включал перенос следующих данных:

• заявки, комментарии к ним, приложенные файлы и спецификации, а также количественные показатели по выполненным заявкам в разрезе клиентов и в разрезе исполнителей;

• отделы, сотрудники, контактные лица, клиенты и объекты обслуживания;

• связь пользователей ключевого клиента с Active Directory;

• договоры обслуживания и каталог услуг.

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

Миграцию полностью завершили за 3 недели. Добиться такой скорости удалось за счет небольшого количества данных для переноса и отсутствия кастомизаций.

Апгрейд системы как повод для миграции

Рынок не стоит на месте, меняется и устройство решений. Далее расскажем, как мы переработали наш продукт и зачем мигрируют на новую конфигурацию.

• Почему решили пересобрать ITSM 365

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

1. «Автоматизация — это боль»

   Архитектура старой версии ITSM 365 не позволяла быстро внедрять новые функции, для автоматизации процессов приходилось писать скрипты. 

2. «Базовая аналитика — не очень»

   Дашборды в базе включали минимальный набор метрик. Чтобы получить более детальную картину, нужно было значительно дорабатывать и настраивать виджеты.

3. «Интерфейс перегружен»

   Многие были недовольны навигацией и структурой меню, в системе было сложно ориентироваться.

Вместо множества отдельных доработок мы решили перезапустить продукт с нуля — так появилась новая конфигурация ITSM 365. 

• Какие ключевые фичи реализовали?

Система изменилась довольно сильно, пользователи получили следующие преимущества.

1. Обновление архитектуры системы

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

2. Настройка правил автоматизации через интерфейс оператора

   Добавили возможность автоматизации без использования скриптов — набор действий и условий расширяется с каждым релизом. Система автоматически классифицирует заявки, назначает ответственных, добавляет комментарии, меняет статусы без участия сотрудников. 

   

3. Расширенные дашборды

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

   

4. Пересобранный интерфейс

   Отказались от многоуровневого верхнего меню, настроили основное левое меню под роли сотрудников, унифицировали компоновку блоков в родственных объектах, пересмотрели стартовые страницы для разных групп пользователей. 

   Новый интерфейс упрощает взаимодействие с продуктом, фокусирует внимание на важных задачах и ускоряет адаптацию к системе.

Важная особенность — все релизные новинки теперь выходят на новой конфигурации. Среди них — модуль искусственного интеллекта, интеграция с WhatsApp, функциональности новостей и организации встреч. 

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

Как мигрировать, чтобы не пожалеть об этом

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

Этап 1. Аудит текущего состояния

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

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

Этап 2. Выбор новой системы

• Определяем недостатки текущей системы и анализируем, что хотелось бы видеть после переезда.

• Составляем таблицу сравнения функций текущей и пула новых систем.

• Тестируем демо-версии решений из шорт-листа, оцениваем удобство настроек и качество поддержки.

• Собираем отзывы сотрудников, которые будут работать в системе.

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

• Составляем итоговое техническое задание по переезду, оценивая риски, затраты и сроки. 

Этап 3. Подготовка среды для миграции

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

• Адаптируем доработки старой системы к новой среде, переносим настройки.

• Проверяем новый настроенный продукт на соответствие требованиям.

Этап 4. Перенос данных

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

• Проводим поэтапный перенос данных, учитывая взаимосвязи и порядок.

• Проверяем корректность импортированных данных, при необходимости вносим правки.

Этап 5. Комплексное тестирование

Последовательность следующая: тестируем функционал на части пользователей → выявляем проблемные точки → фиксируем изменения, которые необходимо внести → дорабатываем систему.

Шаги выполняем по кругу, пока не достигнем нужного результата.

Что проверяем:

• корректность переноса данных,

• работу настроек и интеграций,

• отрабатывание автоматизаций,

• UX для конечных пользователей.

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

Этап 6. Передача в прод

• Когда все готово к переезду, оповещаем пользователей о работе в новой системе.

• Проводим обучение и разбираем сложности точечно, если требуется.

• Переводим сотрудников на новый продукт, спустя время снимаем обратную связь.

• По получению обратной связи — вносим изменения.

Миграция успешно завершена, можно выдохнуть с облегчением!

Какие риски бывают и как их минимизировать

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

• Технические мины

Здесь имеем в виду неполный перенос настроек, потери данных, неучтенные в документации ручные процессы. Причины могут крыться в некорректных требованиях, ограничениях новой системы или банальной невнимательности.

Как предотвращать:

1. Детально ознакомиться со всеми особенностями, возможностями и ограничениями новой системы.

2. Изучать кейсы, с которыми сотрудники сталкиваются ежедневно, и  фиксировать все в техническом задании.

3. Подготовить подробное техническое задание с необходимыми процессами, проанализировав, что точно нужно учесть на новом продукте

4. Проводить перенос поэтапно, проверяя корректность перенесенных данных и кастомизаций.

• Саботирование изменений

Иногда при переезде основная трудность кроется в нежелании сотрудников обучаться работе в новой системе или откровенном игнорировании нового инструмента. 

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

• Когда миграция — не выход

Для клиентов с большим количеством настроенных процессов бывает лучше оставить все, как есть. Переезд в их случае — очень трудозатратный, зачастую финансово не оправданный проект.

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

5 советов перед стартом работы в новой системе

1. Тестируйте больше, чем кажется нужным — все риски проявляются в prod.

2. Сохраните доступ к предыдущей системе, чтобы возвращаться к данным и обеспечить психологический комфорт пользователей.

3. Закрыв возможность работы на старом стенде, дайте ссылку на новое решение и инструкцию по авторизации.

4. Не планируйте окончательный переезд перед выходными! Оперативность подключения — наше все.

5. Имейте план Б — даже для самых невероятных сценариев.

И помните, идеальных миграций не бывает — бывают хорошо подготовленные!

Чтобы бесплатно протестировать service desk ITSM 365 в течение двух недель и узнать о возможностях для миграции в вашем конкретном случае, оставьте заявку на нашем сайте.

Наши специалисты проконсультируют вас и откроют доступ к демо-стенду.