Импортозамещение RPA на практике: уроки перехода на российские платформы роботизации
Анализируем опыт нынешних проектов миграции с западных платформ RPA на отечественные
— Насколько массовой стала нынешняя волна миграции на российские платформы RPA? И многие ли из заказчиков западных решений решили начать проекты миграции уже в краткосрочной перспективе?
Сейчас очень многие крупные заказчики находятся в процессе переноса. Уверен, что до конца года решение о сроках перехода и платформах для миграции примут практически все российские заказчики западных RPA-продуктов.
Уже есть немало тех, кто успешно перешел на российские платформы. Например, розничная сеть «Лента» на конференции RPA-2022, которую проводило ваше издательство, поделилась своим опытом миграции с Blue Prism на Primo RPA. Компания начала свой проект перехода в апреле и планирует полностью завершить его в октябре. Правда, у нее не так много роботов.
— На какие аспекты перехода и на какие особенности российских решений обращают первостепенное внимание заказчики, приступающие к миграции на российские платформы RPA?
В первую очередь — на готовность внутренней команды к переходу. Если в компании есть собственная команда роботизаторов, то ее мнение о выборе платформы, на которую нужно переходить, играет решающую роль. На это мнение влияют, во-первых, паттерны проектирования: у ведущих западных вендоров они отличаются. (Например, в продуктах Blue Prism и UiPath задачи управления роботами решаются по-разному.) Выбирая новую платформу, команда, скорее всего, выберет ту, где стиль создания роботов ближе к тому, с которым она уже имела дело. Во-вторых, на решение влияет желание сохранить кодовую базу: большинство платформ основано на C#, но есть и те, что написаны на PowerShell, Java и других языках, поэтому разработчики скорее перейдут на платформу, которая основана на том же языке программирования. И, в-третьих, поскольку миграцию нужно провести в очень сжатые сроки, команде нужны инструменты, позволяющие автоматизировать этот переход. На сегодняшний день инструменты для переноса кодов с одной платформы на другую уже выпустили все серьезные игроки рынка RPA.
— Насколько ресурсоемким оказывается переход с западных платформ RPA на отечественные?
Российские заказчики оказались в полной растерянности относительно того, на какую платформу и каким образом осуществлять миграцию, поэтому, хотя деньги, конечно, все считают, особо не мелочатся. Со своей стороны, и мы, как интегратор, рассказываем клиентам, что и в какие сроки можно сделать. Торг, конечно, идет, но никто с ним не затягивает, поскольку все заинтересованы побыстрее осуществить миграцию и перейти к нормальной работе.
Что касается ресурсоемкости, то затраты на миграцию оказываются в целом гораздо ниже, чем на разработку новых роботов с нуля. При переходе с одной зрелой платформы на другую, тоже зрелую, эта экономия была бы двух- или даже трехкратной. Но, поскольку в российских платформах RPA имеются не все функции и возможности, которые есть в западных, какую-то часть миграции приходится осуществлять вручную. Трудоемкость перехода получается достаточно высокой, и реальная экономия достигает всего 50–60% по сравнению с разработкой с нуля. При этом мы не берем в расчет расходы на оборудование (исходим из того, что закупка дополнительных серверов, скорее всего, не потребуется) и лицензии, поскольку предполагаем, что они уже куплены, причем стоимость лицензий на российское ПО существенно ниже, чем на западное.
— Какие есть возможности для снижения ресурсоемкости миграции на российские RPA?
Самые главные инструменты для этого — средства конвертации. Правда, они пока не настолько совершенны, чтобы автоматически переносить с платформы на платформу все 100% кода. Очевидно, что если в проекте есть много самописных вставок, то автоматически их перенести не удастся, поскольку создатели средств конвертации о них ничего не знают. Кроме того, код для Blue Prism переносится гораздо сложнее, чем написанный для UiPath.
Было бы, конечно, замечательно автоматически переносить более 90% блоков кода — такие проекты можно было бы считать идеальными. На практике, если инструмент не обеспечивает автоматической конвертации 70% блоков, пользоваться им невозможно — доля ручного труда оказывается очень высокой.
Есть, например, инструменты для миграции на платформы PIX Robotix, Primo RPA и Sherpa RPA. Но они могут лишь помочь осуществить переход и как-то облегчить его. Обеспечить миграцию под ключ они не в силах.
Помимо средств конвертации кода, есть также инструменты для переноса очередей заданий, метаданных, селекторов и прочих специфических сущностей.
Важно понимать, что для успешного перехода с одной платформы на другую у вас должны быть эксперты, которые хорошо знакомы с обеими платформами. Чтобы специалисты по роботизации стали такими экспертами, они должны поучаствовать хотя бы в паре проектов, и такие проекты как раз сейчас реализуются. Когда у специалистов накопится достаточно опыта, переходить с платформы на платформу станет гораздо легче.
— Насколько надежно работают инсталляции RPA после перехода на российские платформы?
К сожалению, инсталляции отечественных платформ роботизации работают существенно менее стабильно, чем инсталляции западных RPA-продуктов. Это сейчас один из самых важных вопросов, который тревожит российских заказчиков, что неудивительно: если в компании работают десятки и сотни роботов, то руководителям, которые за них отвечают, нужно быть уверенными в их стабильности, в противном случае они едва ли решатся взять на себя какие-либо обязательства по договорам SLA.
Причина нестабильности, на мой взгляд, кроется в том, что отечественные разработчики создали хорошие технологические ядра, но не позаботились о том, чтобы обеспечить достойный пользовательский опыт, в первую очередь это касается эксплуатации и поддержки систем RPA.
Эту проблему нельзя отнести к категории легко решаемых. Тем не менее есть множество примеров того, как отечественные вендоры оперативно решают возникающие после миграции проблемы с нестабильной работой роботов. В целом с апреля по август их стабильность существенно повысилась, хотя, конечно, до уровня мировых лидеров пока далеко. Могу предположить, что выйти на этот уровень российским разработчикам удастся где-то через год-полтора.
— Возникают ли в ходе миграции проблемы в бизнес-процессах, в которых используются технологии RPA?
Поскольку миграцию нужно осуществлять быстро, заказчики переносят свои наработки «как есть», не модифицируя бизнес-процессы. Другое дело — если какие-то из этих процессов не работают. Тогда и роботы, которые их поддерживают, не переносятся.
Самые большие сложности возникают с миграцией достаточно старых, унаследованных роботов, созданных лет пять назад: зачастую их коды плохо документированы, разработчики из организаций ушли, поэтому не совсем понятно, как эти роботы функционируют, и неясно, что с ними делать. Участники проектов миграции RPA пытаются провести реверс-инжиниринг и воссоздать схему работы бизнес-процессов с участием этих роботов, но далеко не всегда это удается сделать. К счастью, такие ситуации встречаются довольно редко.
— Остаются ли проекты перехода на российские RPA в рамках чисто технологических проектов или, напротив, в них вынуждены активно участвовать также представители бизнес-подразделений?
За последние несколько месяцев мне встречались и проекты с активным вовлечением бизнес-заказчиков, и проекты, в которых такого вовлечения не было. Вывод однозначный: активное вовлечение пользователей крайне желательно. Если в проектах разработки, чтобы получить достойный результат, достаточно иметь четкое и детальное техническое задание, то в проектах роботизации так не получится, поскольку знания о том, как бизнес-процессы реально работают, содержатся не в регламентах, а в головах участников или руководителей этих процессов. Необходимо тесно общаться с теми, кто знает свои бизнес-процессы изнутри, — только тогда мы сможем создать робота, в точности повторяющего действия людей в этих процессах.
В проектах миграции ситуация аналогичная. Сотруднику достаточно всего получаса-часа, чтобы показать, что и как он делает на рабочем месте, и создатель робота уже будет ясно понимать алгоритм его действий. Не вовлекая сотрудника в проект RPA-миграции, сделать правильно работающего робота будет очень трудно.
— На какие ключевые факторы успеха проектов миграции на российские RPA-платформы следует обратить внимание тем, кто сейчас рассматривает возможность такого перехода?
Самый главный фактор успеха — тесное взаимодействие бизнес-заказчиков с командами роботизации. К счастью, в России сложилось эффективное комьюнити специалистов по RPA, среди которых есть и вендоры, и интеграторы, и заказчики, в том числе лидеры роботизации. Эти специалисты с готовностью делятся своим опытом и рекомендациями. В одиночку справиться с последствиями ухода западных вендоров не получится — всем нужно взяться за руки и действовать сообща. Поэтому тех, кто заинтересован в роботизации, мы призываем вливаться в комьюнити, тесно общаться, задавать вопросы и изучать лучшие отечественные практики.
На российском рынке роботизации мы сейчас наблюдаем достаточно редкую ситуацию дружеского соперничества. В ходе конференции RPA 2022 я пообщался с множеством людей и от всех слышал слова благодарности в адрес конкурентов за то, что они мотивируют развиваться и совершенствоваться. Никто не жаловался на то, что кто-то из конкурентов им помешал или перебежал дорожку. Сейчас обстоятельства таковы, что есть большой рынок и, чтобы занять на нем достойные позиции, нужно просто стать лучше. По крайней мере, мы пока не чувствуем, что конкуренты толкают друг друга локтями.
Со своей стороны, в ходе общения с заказчиками мы не утверждаем, что какая-то из российских RPA-платформ лучше, а какая-то хуже. Напротив, мы разъясняем им, что эти продукты по-разному решают разные классы задач, поэтому следует выбирать платформу исходя из конкретных потребностей и задач, которые перед вами стоят.
