Санкционное давление и тенденция перехода на отечественный софт укрепляют доверие к российским производителям на рынках, включая мировой. Разработчики цифровых технологий с каждым днём улучшают качество своих решений, чтобы максимально приблизиться к зарубежным аналогам и даже превосходить их. К примеру, многие российские платформы RPA сегодня заменяют аналоги, перенося все данные при миграции практически один в один. Сам процесс довольно быстрый и незатратный. Здесь главное знать о возможных рисках и детально изучить план перехода. В этой статье эксперт по развитию направлений RPA и BI компании «Первый Бит» Кирилл Воробьев рассказывает, как провести импортозамещение RPA максимально комфортно и эффективно.

Особенности переноса процессов в другое ПО

Миграция с зарубежной RPA-системы - процесс достаточно емкий и не особо ресурсозатратный (по сравнению, например, с импортозамещением системы ERP), ведь прототип уже имеется, и всё, что нужно сделать - перенести данные на новую платформу. Здесь всегда будут задействованы цифровые технологии и люди. Поэтому при выборе вендора или интегратора важно проверить на качество саму платформу и уровень компетентности команды внедренцев.

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

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

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

После предварительного анализа миграции, в течение 2-3 месяцев возможно перенести порядка 30-40 “роботов” с точностью один в один как в первоначальном варианте на зарубежной платформе.

Шаг 1. Анализ и оценка миграции

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

Шаг 2. Согласование требований и ограничений; приоритизация

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

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

Шаг 4. Запуск проекта

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

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

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

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

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

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

Заключение

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

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

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