Миграция ИТ-систем: роль командообразования для успеха проекта

Успех миграции ИТ-систем зависит не только от технологий, но и от команды: ответственных, правил работы с данными и четкого плана перехода

С 2022 года отечественные компании активно переходят с западных на российские ERP-системы. Как правильно начать процесс миграции? Как при этом не остановить бизнес и достигнуть успешных результатов? На эти вопросы отвечает генеральный директор и основательница группы компаний «Формула» Ольга Васильева.

- Ольга, что самое важное необходимо предусмотреть в самом начале процесса миграции ИТ-систем, чтобы все прошло гладко для бизнеса?

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

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

- А как правильно распределить сотрудников по участкам — разве обычный письменный приказ руководства эту проблему не решает?

- Увы, но проблемы часто возникают, когда сотрудников принудительно назначают каким-то приказом, а по факту человек даже не понимает: зачем, что, куда его назначили?

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

- Какие могут быть контрольные точки, чтобы руководитель в процессе понимал, что все идет как надо?  

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

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

- Если компания крупная, и у нее множество данных накопилось за годы работы — все ли надо переносить в новую систему или тут важна очистка данных? И как ее проводить?

- Для того, чтобы правильно очистить данные, те, кто этим процессом занимается, ответственен за него, должны понимать, что такое дедубликация, что такое очистка, то есть разбираться в этой терминологии. Для этого нужно проводить установочные сессии и разбирать с заказчиком проектную технологию, объяснять сотрудникам, что это такое. Иногда этот процесс бывает достаточно объемным — например, мы недавно вели проект, где у заказчика было 130 тысяч записей номенклатуры. При этом далеко не все из старой системы нужно переводить в новую, поэтому важно перед миграцией, конечно же, провести очистку данных — это значит пометить на удаление какие-то ненужные объекты, провести дедублицирование, найти дубли, их тоже пометить на удаление, определить неактуальные для переноса данные. Некоторые заказчики, например, определяют, что им нужно перенести только те данные, которые есть в движениях документов за последние 3-4 года. Такого рода правила крайне важно определить перед стартом процесса очистки, чтобы сделать дизайн будущей миграции.

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

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

- Как понять, что процесс миграции прошел успешно?

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

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

ссылка на публикацию companies.rbc.ru