Поделиться
Выбираем RPA-платформу прямо сейчас, или Как закрыть потребности рынка в условиях импортозамещения
Геополитическая ситуация бросила серьезный вызов российскому бизнесу, и ИТ-специалисты отправились на рынок в поисках аналогов иностранного ПО. Большой ажиотаж возник вокруг RPA-платформ, ведь бОльшая часть крупного бизнеса давно пользовалась западными продуктами. CNews не первый год следит за тем, как развивается роботизация и в мире, и в России. По итогам более чем полугодовой импортозамещающей гонки мы готовы поделиться своим мнением о том, какой должна быть современная RPA-платформа для российского бизнеса.
Оптимизируем процесс и вовлекаем сотрудников
RPA-платформа привычно — это инструмент программистов. Бизнес приходит к айтишникам и ставит задачу по автоматизации какой-либо рутинной работы. Выяснение подробностей, погружение в процесс, доработки — решение может очень затянуться или вовсе отойти «в конец очереди». И тут может показаться, что было бы здорово сделать пользователем RPA-платформы человека из бизнеса, то есть сделать No-Code-продукт. Но такой подход не подошел российскому бизнесу.
Так как продукты — и для ИТ, и для бизнеса, то должна быть возможность удобно писать код и удобно собирать роботов.
Программировать так программировать
Российские айтишники, адепты объектно-ориентированного программирования, ждут от российских платформ не то что равного функционала, а буквально улучшенного по сравнению с западными аналогами. Например, хотят создавать шаблоны кода или иметь писать полноценные подпрограммы. Причем часто акцент делается на возможности писать собственные классы и в полной мере исповедания постулатов объектно-ориентированного программирования: инкапсуляция, наследование и полиморфизм. Но часто разработчики, желая угодить пользователям, не учитывают потребность использовать классы, заявленные в любых других пространствах имен, что ограничивает возможности программирования.
Важный пункт, о котором надо упомянуть: программный код в роботе должен быть непараметризуемым. Это защищает от изменений в программном коде и позволяет избежать «черного ящика», который перечеркивает все плюсы роботизации. Также это удобно для использования в других роботах: удобнее, чтобы код сохранялся в виде пакета с действием и мог быть импортирован в другую Студию, то есть переиспользован — максимальная оптимизация.
Еще выяснилось, что не все Low-Code-RPA-продукты подходят для работы большим компаниям с точки зрения безопасности, и об этом мы рассказываем ниже.
Не забываем про информационную безопасность
В начале статьи мы определились, что RPA-платформа должна быть Low-Code-продуктом. Получается, доверяем большому количеству человек самое уязвимое, что есть в программном роботе — код. Важно, чтобы любая работа с кодом была под контролем. Мы выяснили, что многим российским компаниям, особенно с госучастием, важно, чтобы любое действие платформы подписывалось ключом для защиты робота от возможности подмены действий злоумышленником. Это нужно для того, чтобы понимать, кто и какие изменения внес в код.
Также актуальна ролевая модель, с помощью которой можно управлять правами доступа сотрудников на разных роботов на действия. Как это работает: например, бизнес-пользователь имеет доступ только к тем сценариям роботов, доступ к которым разрешен, при этом может не иметь доступа к роботам и машинам в продуктивной среде. Робот тоже может быть ограничен в правах, и должен имеет право на запуск только на конкретных машинах. Например, роботы юридического отдела имеют доступы на запуск только в контуре, созданном только для их запуска, роботы других отделов не имеют к ним доступа. Ну, а шифрование схем и сценариев — вишенка на торте требований информационной безопасности.
И, как нам подсказали знающие люди, сам код не должен компилироваться при каждом выполнении робота, а должен быть неизменяем. Потому что это один из ключевых аспектов информационной безопасности — неизменяемый программный код.
Кроссплатформенность кроссплатформенности рознь
Российские RPA-платформы давно пытаются прийти к кроссплатформенности. Но максимально к ней приблизились не все. Пользователям сейчас важно, чтобы роботы могли работать на любой операционной системе, особенно на импортозамещающей.
Обратившись к импортозамещению, мы не можем не обратить внимание на важный момент: что у RPA-платформ «под капотом».
Там, в недрах продукта, часто оказываются проприетарные программные компоненты, например, Microsoft .NET. На такие детали стали обращать внимание бдительные службы информационной безопасности.
К тому же важно, чтобы для создания роботов можно было использовать Java и Python для создания роботов. Так как Python, например, — поставляемый компонент вместе с различными дистрибутивами Linux (включая импортозамещающие, например, AstraLinux), в то время как .NET официально поддерживается только на нескольких дистрибутивах и не гарантирует работоспособность.
Независимость от технологий компаний, которые в любой момент могут уйти с российского рынка, — важный пункт при выборе RPA-платформы. И если развивать тему независимости в данном ключе, то стоит отметить, что благодаря использованию Java и Python возможен запуск роботов под отечественными процессорами.
Еще важна возможность не привязываться к конкретному языку программирования. Это позволяет не нанимать разработчика со знанием конкретного языка, а использовать штатные ресурсы программистов. Благодаря этому можно существенно упростить и удешевить разработку программных роботов.
Программные роботы, в очередь!
Уж чего точно не хватает отечественным RPA-платформам, так это продуманной работы с очередями, как в западных аналогах. Ведь для задач, которые решают программные роботы, недостаточно использовать готовое Open Source решение Kafka MQ или RabbitMQ — по этому пути пошло много российских вендоров.
При роботизации процессов, связанных с обработкой данных, очередь берет на себя функции распределения нагрузки между машинами и роботами, передачи данных от внешних систем к роботам и в обратном направлении, контроля обработки элементов. А это значит, что очереди платформы роботизации должны позволять работать с разными типами данных, устанавливать приоритеты обработки элементов, задавать элементам различные тэги. Наличие внешнего API у очереди позволит взаимодействовать с элементами не только роботам, но и внешним системам.
Также очередь становится центральным связующим звеном, с помощью которого выстраиваются сложные процессы. Важно умение очереди автоматически запускать процессы обработки по условию, например, по достижению количества элементов в очереди или наступлении конкретного времени. При этом очередь не просто запускает обработку данных, а сама определяет, сколько роботов и на каких машинах можно запустить, в зависимости от ролевой модели и потребностей робота.
Оркестратор должен быть удобным инструментом со множеством возможностей и функций. Это «сердце» системы при масштабной роботизации.
Следующий шаг в роботизации
Если несколько лет назад можно было услышать, что RPA — это костыль, временное решение, то сегодня крупные компании относятся к выбору продуктов для роботизации не менее серьезно, чем к выбору любых других решений. Это неудивительно, ведь программные роботы становятся умнее благодаря искусственному интеллекту.
Сейчас уже недостаточно просто роботизировать задачу. Общемировой тренд — сквозная роботизация процесса. Робот взаимодействует с человеком в процессе работы и становится полноценным участником рабочего процесса. Диалоговые окна, голос — это только стартовый набор для «умного» цифрового сотрудника.
А что в итоге
На российском рынке сейчас много RPA-разработчиков. Идеальной платформы не существует — надо выбирать платформу, исходя из своих задач. Надо определиться с приоритетами, составить чек-лист и выбрать самый подходящий для себя вариант.
Короткая ссылка
