RPA-платформы: тонкости миграции

RPA-платформы: тонкости миграции

19.07.2022|СМИ о нас
RPA-платформы: тонкости миграции

Взвешенный подход

Актуальность перехода с имеющихся платформ, в большинстве случаев это UiPath и Blue Prism, на отечественные аналоги связана с тем, что в скором времени — через 6-12 месяцев — у российских клиентов заканчиваются сроки действия лицензий, и наши зарубежные коллеги не готовы их продлевать. Это амбициозная задача, решать которую предстоит в сжатые сроки.

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

iFellow работает с четырьмя российскими платформами – Primo, Sherpa, PIX и Robin. И в зависимости от ситуаций заказчиков мы рекомендуем то или иное решение, каждое обладает своими преимуществами.

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

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

Стоимость миграции

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

Почему может меняться стоимость эксплуатации, если вы просто переносите робота "баг-в-баг"? На практике новое решение будет функционировать на 10-20%, а иногда и на 40-50% медленнее, чем старое. В большинстве случае это связано с тем, что программисты и архитекторы недостаточно хорошо знают российскую платформу – и этот эффект временный. Роботы начнут работать быстрее, и скорость восстановится. Тем не менее на первом этапе, который мы оцениваем от полугода (время освоения технологии и переработки кода) заказчику потребуется больше лицензий и сервисных мощностей для поддержания прежнего уровня обработки процессов, что нужно учитывать.

Самый затратный пункт по деньгам и по времени — стоимость миграции. Мы не говорим, что нужно по новой закупить все серверы, но какое-то количество "железа" и полный объем лицензий приобрести придется. При этом самая дорогая составляющая перехода — это все равно работы. И сэкономить здесь можно с помощью таких инструментов, как конверторы. Так называют автоматические средства переноса кода: либо мы берем проект UiPath, загружаем в некий "черный ящик", и он выдает нам новый проект на новой платформе, либо конвертер представляет из себя вспомогательный инструмент, который может быть использован для ускорения сборки будущих роботов через работу с селекторами/скриптами и т.п.

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

RPA-конвертеры

Разберем инструменты переноса кода от российских решений Primo, Sherpa и PIX. Robin, на момент написания этого материала, конвертера не имеет.

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

Повторюсь, у обеих платформ, Primo и PIX, довольно высокий процент конвертации, но минус — их фокус на UiPath: при миграции с других решений их конвертеры вам не помогут.

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

Если говорить о реальной эффективности конвертеров, я бы обозначил параметры следующим образом: конвертация меньше 70% — плохо, мы потеряли логику процесса. Выше 85-90% — очень хорошо, значит, удалось полностью сохранить структуру. Фактически вы избежали 90-95% трудозатрат на разработку. Диапазон 70-85% — здесь многое зависит от ситуации, что называется, напильником надо будет поработать точно.

В идеале на проекте миграции у вас должны быть разработчики, знающие обе платформы — начальную и новую. Но в реальности людей с таким глубоким погружением мало, поэтому оптимальным вариантом видится перенос кода средствами конвертации, потом исправление ошибок и рефакторинг. На примере конвертеров Primo и PIX, которые переносят роботов "процесс в процесс", мы можем сказать, что рефакторинг после миграции дает результат — роботы значительно ускоряются. То есть это гарантированно небессмысленное упражнение. Можно назвать это пост-миграционной деятельностью, но в целом это задача по оптимизации кода.

Роль комьюнити

Мы часто слышим вопрос о миграции с Blue Prism — здесь пока не все так здорово: готового мигратора нет. Именно поэтому так важно объединяться: мы призываем владельцев Blue Prism идти к отечественным вендорам сообща и целенаправленно, запрашивать инструмент, тогда у того или иного производителя он обязательно появится.

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

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