Можно выделить два варианта миграции с зарубежных RPA-платформ. Первый — кастомная разработка решений с использованием open source RPA-библиотек. Этот вариант может быть интересен компаниям, которые не имеют своего центра компетенций по роботизации, используют небольшое количество роботов в бизнеспроцессах и не планируют их масштабировать.
Второй вариант — миграция на отечественную RPAплатформу. Для компаний, активно использующих RPA, в том числе в высоконагруженных процессах, имеющих собственный центр компетенций по роботизации и занимающихся масштабированием, это наиболее подходящее решение. В качестве дополнительных преимуществ миграции на отечественные RPA-платформы можно выделить более низкую стоимость лицензий, возможность приобретения бессрочных или даже безлимитных лицензий, а также русскоязычную поддержку.
За последние два года российские RPA-платформы стали гораздо более зрелыми и адаптированными под современные задачи бизнеса. Они обладают необходимой базовой функциональностью для автоматизации практически любых процессов. У некоторых платформ даже есть встроенные инструменты, помогающие ускорить процесс миграции с иностранного ПО. Сам процесс миграции несложный, но чтобы он прошел успешно, необходимо выполнить комплекс обязательных мероприятий.
Поскольку RPA-платформы в основном лицензируются по подписке, самое главное при миграции – завершить ее до окончания срока действия лицензий и сделать это максимально безболезненно. В идеале бизнес-пользователи не должны заметить, что произошла замена платформы — сервисы не остановились, а переключение прошло плавно и бесшовно. Добиться этого можно при грамотном планировании работ и качественной проверке результатов. Важно, чтобы компания сумела оперативно подготовить необходимую инфраструктуру,а команда миграции хорошо знала обе платформы — и старую, и новую.
Стоит обратить внимание и на обучение специалистов центра компетенций по роботизации работе с новой платформой. Обычно на этом этапе не возникает сложностей, поскольку команда уже знакома с технологией RPA, и освоить новый инструмент ей не составляет труда.
Прежде всего нужно провести экспресс-аудит имеющихся роботов. Он позволит определить, как они работают, насколько сложными являются процессы, какие технологические решения использовали разработчики, какая из отечественных платформ лучше подойдет для замены, а также насколько трудоемким будет переход на новую платформу.
После аудита и оценки трудоемкости миграции формируется «дорожная карта», в которой наиболее критичные для бизнеса и высоконагруженные процессы планируются к переносу в первую очередь. Это позволяет снизить риски их остановки или несвоевременного переключения. В случае, если сроки реализации «дорожной карты» выходят за рамки окончания действия текущих лицензий и какие-то из процессов придется временно выполнять в ручном режиме, такая приоритизация работ позволит минимизировать количество привлекаемого для этого персонала.
Для конвертации простых роботов или простых частей сложных роботов целесообразно использовать конвертеры, которые есть у некоторых отечественных платформ. Они позволяют оперативно получить черновик скрипта на новой платформе, что ускоряет процесс миграции. Однако возможности конвертеров ограниченны. Их применение можно сравнить с особенностями работы над машинным переводом текстов с одного языка на другой, который, как мы знаем, все равно требует участия человека, чтобы отредактировать получившийся текст и привести его к необходимому качеству. Примерно так же с конвертерами. Стоит учитывать, что при конвертации больших и сложных скриптов они могут только помешать — сконвертированный код почти наверняка будет содержать пропуски, на заполнение которых понадобится больше времени, чем на переписывание скриптов вручную.
Если у компании отсутствует документация по роботам или она находится не в лучшем состоянии, необходимо восстановить сценарии их работы. Команда, выполняющая миграцию, должна понимать, что делают роботы, а компания-заказчик – быть уверена на этапе приемосдаточных испытаний, что новые роботы работают не хуже старых. Без формализации сценариев этого не добиться, поэтому со стороны бизнеса необходимо привлечь аналитика или другого эксперта, с которым можно будет согласовывать сценарии и который поможет с подготовкой тестовых данных.
При миграции сложных процессов стоит задуматься о разработке unit-тестов для автоматизированного тестирования роботов и их отдельных частей. Это позволяет повысить качество решений и выявить недостатки до выхода на приемо-сдаточные испытания. У некоторых платформ такие инструменты доступны уже «из коробки», в других случаях понадобится разработать скрипты для проведения unit-тестов в ходе миграции. К слову, у IBS есть такие наработки, и они позволяют сэкономить дополнительное время.
Что касается запуска смигрированных роботов в промышленной среде, то важно продумать порядок их запуска. Иногда, например, имеет смысл переключать робота поэтапно, выделив пилотную зону, скажем, одно из подразделений, чтобы убедиться, что новый робот работает исправно, и уже после этого выполнять полное переключение.
Во-первых, не нужно запрашивать у бизнеса требования к роботизации. Однажды он уже прошел через эту процедуру, поэтому будет достаточно согласовать перечень сценариев. Остальное уже есть в виде исходных кодов и, возможно, эксплуатационной документации.
Во-вторых, в большинстве случаев не требуется «переписывать» роботов с нуля, вместо этого следует максимально использовать конвертеры.
В-третьих, не стоит при миграции выполнять доработку роботов, улучшать их или проводить рефакторинг. В этом случае процесс может затянуться — потребуется выполнение дополнительных работ, в том числе по аналитике, согласованию проектной документации и проч. Сначала мигрируем, потом занимаемся улучшениями.
Спрос на технологию RPA остается стабильно высоким, особенно в последнее время, и это относится к компаниям всех секторов. В условиях введения санкций и ухода с российского рынка многих зарубежных производителей ПО технология RPA может закрыть образовавшиеся из-за этого разрывы в автоматизированных бизнес-процессах. Например, ее целесообразно применять на проектах по замещению западного ПО на этапе опытной или опытно-промышленной эксплуатации для минимизации двойного ввода данных в информационные системы, а также она может применяться при миграции данных с западного ПО на отечественное. При этом сама миграция роботов может быть не такой простой, как кажется на первый взгляд. При наличии ограничений по срокам это важно понимать и учитывать при планировании проектов. Оптимальным решением будет обратиться за помощью к профессионалам.