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

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

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

На что важно обратить внимание при миграции

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

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

Необходимые работы при миграции

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

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

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

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

При миграции сложных процессов стоит задумать-ся о разработке unit-тестов для автоматизированно-го тестирования роботов и их отдельных частей. Это позволяет повысить качество решений и выявить не-достатки до выхода на приемо-сдаточные испытания.  У некоторых платформ такие инструменты доступны уже “из коробки”, в других случаях понадобится раз-работать скрипты для проведения unit-тестов в ходе миграции. К слову, у IBS есть такие наработки, и они позволяют сэкономить дополнительное время.

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

Что не стоит делать на проекте по миграции

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

Во-вторых, в большинстве случаев не требуется “переписывать” роботов с нуля, вместо этого следует максимально использовать конвертеры.

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

Что дальше

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

Ростислав Братухин, руководитель направления роботизации и управления контентом,  компания IBS