С платформы на платформу: трудности перевода

RPA
Публикации
Источник: Банковское обозрение
Поделиться:

За последние два-три месяца IТ-компания iFellow реализовала несколько проектов миграции с зарубежных платформ RPA на отечественные.

Рассмотрим опыт переноса программных роботов с американской платформы UiPATH на российские платформы PIX, Primo и Sherpa, а также опыт миграции роботов с британской Blue Prism на Sherpa и Primo.

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

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

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

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

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

И после этого наступает финальная стадия миграции — миграция решений с зарубежной RPA-платформы на российскую в No-Code-формате.

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

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

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

И третье, о чем хотелось бы сказать, — это перенос паттернов проектирования. Инструменты конвертации позволяют перенести стандартные последовательности, стандартные диаграммы, циклы/условия/операторы выбора и так далее, а также стандартные вызовы внешнего кода. Тут могут возникнуть трудности с реализацией паттерна state machine, имеющего индивидуальные особенности в разных платформах RPA. В полном объеме функционал state machine с помощью конверторов перенести нельзя, поскольку аналогичные паттерны в российских платформах просто отсутствуют.

Эксперт направления
Глеб Леонов

Глеб Леонов

Руководитель практик RPA и BI

Услуга

Свяжитесь с нами

Иконка мини логотипа

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

Задний фон блока

Файлы cookie обеспечивают работу наших сервисов. Используя наш сайт, вы соглашаетесь с нашими правилами в отношении этих файлов.