Зачем нужен код в RPA, как меняется структура RPA-платформ, что добавит в них искусственный интеллект и есть ли специфика в проектах внедрения роботизации? Ажиотаж вокруг темы программной роботизации зачастую лишь мешает сформировать ясное представление о том, как развивается это перспективное технологическое направление, и оценить возможности, предоставляемые RPA. Добавить ясности мы попросили Артура Булякова, заместителя генерального директора молодой компании «Рондем», одной из ключевых областей деятельности которой является повышение операционной эффективности бизнеса посредством роботизации бизнес-процессов при помощи целого арсенала инструментов, включая и собственное решение — программной платформы Primo RPA.

- В каком направлении сегодня развиваются платформы RPA?

Рынок RPA становится все более зрелым. Это подтверждается и обзорами западных аналитиков, и нашими собственными наблюдениями и выводами, сформулированными по итогам общения с заказчиками. Спрос изменился: вместо «нам поставили задачу поставить роботов» мы все чаще получаем от заказчиков запросы типа «у нас есть задача, и мы понимаем, как робот поможет нам ее решить». От увлечения новой технологией рынок переходит к пониманию того, как она может помочь бизнесу. В том числе и к пониманию того, где помочь не может.

- Вслед за ростом осознанности меняется и структура платформ. Происходит их специализация под классы задач...

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

В крупных компаниях ситуация иная. В них процессы более сложные, а стек используемых систем и технологий может быть уникальным для каждой компании. Платформы RPA здесь часто встраиваются в общую стратегию автоматизации. На первый план выходят широта функционала предоставляемых инструментов, наличие режимов работы low-code и only-code, поддержка большого количества интеграций «из коробки», возможность создания собственных функциональных и интеграционных компонентов. Ключевыми пользователями становятся разработчики. Платформы, ориентированные на этот сегмент, предоставляют пользователю большие возможности, гибкость настройки и мощность, позволяют роботизировать процессы практически любой сложности.

- Какие тенденции программной роботизации вам представляются наиболее важными?

Самое интересное сегодня — стремление к автоматизации самой роботизации. В перспективе рынок надеется достичь такого идеального состояния, когда платформа роботизации сама находит операции и процессы, подлежащие роботизации, сама оценивает варианты и перспективность роботизации, предлагая пользователям принять решение «автоматизируем/не автоматизируем», и в случае автоматизации позволяет воспользоваться сценарием, который сама заранее готовит. Участие человека в этом случае будет сведено к принятию решения. Это идеальная картина. Понятно, что реализация будет какой-то иной, но сейчас мне важно определить именно картину целевого состояния. Технологии, активно развиваемые в рамках этого стрима, — Task Mining, Process Discovery, интеграция процессной аналитики Process Mining и функций машинного обучения в работе со сценариями. Это очень интересное направление, поскольку потенциально его реализация приведет к существенному расширению использования роботизации в компаниях и к сокращению накладных расходов на сам процесс роботизации. Мы активно вкладываемся в это направление. Но у него есть и ограничения. Пока не очень понятно, реализуема ли эта стратегия в крупных компаниях со сложными распределенными процессами и сильно кастомизированными информационными системами. Работаем путем проб и ошибок.

Не менее важная тенденция — будущие «войны» платформ роботизации в рамках одной организации. Наряду с отдельными (условно самостоятельными) платформами, поставляемыми вендорами RPA, в организации все чаще будут проникать «вторичные» платформы, поставляемые вместе с теми или иными информационными системами. Речь идет о ситуациях, когда компания, разрабатывающая, например, CRM, поставляет вместе со своей системой собственную платформу роботизации, ориентированную на решение задач «вокруг» системы. Пример — компания ServiceNow, недавно купившая платформу роботизации Intellibot и планирующая, помимо расширения присутствия у заказчиков, предложить им возможность роботизации интеграционных задач в рамках процессов. Как удастся нормализовать существование разнотипных платформ в рамках одной организации и единой стратегии роботизации, покажет только время.

- Нужен ли код в RPA? Если нужен, то для чего?

Практика показывает, что код в RPA не просто нужен, а жизненно необходим. Так называемый no-code хорош только в самых простых процессах: когда количество шагов невелико, логики и вычислений мало, да и взаимодействие с информационными системами ничем не усложнено. Если же процесс оказывается чуть сложнее тех, что отрабатывают на курсах, отсутствие возможности кодирования в лучшем случае переусложнит алгоритм робота и сделает его нечитаемым и сложным в развитии и сопровождении, а в худшем — превратит проект в нереализуемый. Возможность кодирования позволяет создать процесс практически любой сложности. Вы спросите: зачем тогда платформа RPA? Ведь все, казалось бы, можно изначально закодировать с нуля. Платформа RPA предоставляет среду, в которой многие вещи не нужно кодировать. Можно использовать готовые интеграционные компоненты, и в итоге реализовать процесс на платформе RPA даже с момента кодирования получится в разы быстрее, чем разрабатывать его с нуля. А поддерживать процесс на платформе RPA на порядок проще, чем поддерживать код, разработанный с нуля. Мы часто слышим критику no-code, который сравнивают с гирями на руках инженера, мешающими ему работать. Сейчас мы вообще наблюдаем массу случаев, когда разработчик не хочет работать с диаграммами, а требует привычный ему код. Как раз такую возможность мы и предусмотрели в платформе.

- Согласны ли вы с тем, что сегодня RPA становится еще одним языком программирования или еще одной средой разработки?

Средой разработки — да. Языком — нет. У развитых RPA-платформ есть все атрибуты профессиональных IDE: точки останова, комментарии, watch, locals и т. д. Языком же RPA назвать трудно, так как у диаграмм отсутствует атрибутика собственно языка. Языки программирования, конечно, гораздо более гибкие и, разумеется, требуют совершенно иных знаний. Скорее, RPA можно сравнить с конструктором, где у тебя есть разные готовые детали и ты их комбинируешь, а встроенные средства low-code и only-code позволяют сделать то, на что детали не рассчитаны или для чего в данном случае неудобны.

- Что качественно нового способно привнести в RPA использование средств искусственного интеллекта?

Искусственный интеллект — очень широкое понятие. Если кратко, цель роботизации — выполнить те задачи, которые исторически были возложены на человека. Это задачи, которые не могли быть просто реализованы в информационных системах: анализ бумажных документов и заполнение полей формы, принятие решения о следующем шаге процесса на основании явных и неявных критериев, анализа тональности голосовых и текстовых обращений и многое другое. Поэтому использование технологий искусственного интеллекта — это естественный путь развития RPA. Понимая это, мы уже на первом этапе создания платформы Primo RPA интегрировали в нее функции распознавания текста за счет интеграции с российскими и зарубежными платформами искусственного интеллекта.

Но это пока только базовый уровень. Перейти к следующему — например, отдать роботу право самостоятельного принятия решения в процессе — пока достаточно сложно. Проблема не техническая, а скорее организационная. Персонализация ответственности — достаточно сильный элемент в структуре управления современными компаниями. Робот не мыслит понятием персональной ответственности. Кто будет отвечать в случае неверного решения? Какова допустимая цена ошибки? Как может быть выполнен переходный процесс передачи ответственности от человека к роботу? Однозначных ответов на эти вопросы пока нет. И это замедляет дальнейшие шаги по интеграции искусственного интеллекта в RPA.

- Похоже, RPA-проекты сталкиваются с теми же проблемами, что и обычные ИТ-проекты автоматизации и интеграции. Так ли это? Или во внедрении RPA есть какая-то специфика?

По нашему ощущению, проекты RPA сталкиваются даже с большим набором проблем, чем обычный проект автоматизации. Можно назвать это проблемой роста направления. Спрос и количество внедрений существенно увеличились, а инструменты работы с возражениями и предубеждениями еще не наработаны.

Проблемы — на стороне бизнеса, который обычно и является целевым заказчиком. Это страх того, что RPA заменит живых людей. Для кого-то — это риск «упасть» в должности, для кого-то — риск потери работы. Здесь нет единых и пригодных для всех рецептов. В каждом конкретном случае мы и наши партнеры работаем с заказчиком, с конкретными пользователями для решения такой проблемы.

Кроме того, существуют трудности на стороне ИТ и информационной безопасности. Для служб информационной безопасности роботы обладают признаками, условно, вредоносного кода. Лезут в интерфейсы, управляют мышкой, оперируют защищенными данными. К тому же нет однозначных, принятых отраслью и регуляторами принципов классификации платформы RPA как объекта защиты. Является ли она отдельной информационной системой или подсистемой какой-либо существующей информационной системы? Рассматривать ли ее как единое целое или делить на сегменты в соответствии с теми процессами, которые она роботизирует? Здесь масса вопросов. Решаем их в каждом конкретном проекте.

В части ИТ мы видим попытки увязать цикл разработки роботов с жизненным циклом разработки ПО, что достаточно проблематично вследствие различий в процессах разработки.

Полагаю, с этими проблемами сталкивается любой производитель платформ RPA и любой интегратор. И тут поможет только время: на основе практики внедрений и использования будет выработана одна или несколько моделей использования RPA. Способствовать этому сможет открытый обмен опытом в рамках статей, конференций, митапов.

- Как сохранить уже сделанные инвестиции в программную роботизацию при переходе на новую RPA-платформу?

Здесь все относительно просто. Как и в случае с «большими» информационными системами, важно документировать выполненные настройки в вендорнезависимых системах. Причем под настройками я понимаю не только сам сценарий автоматизации, но и более общую информацию: что было сделано, зачем, для кого, какие целевые критерии и ограничения были приняты во внимание. Тогда можно сохранить вложения, сделанные в аналитику.

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

- Что нужно от RPA-решений тем бизнес-пользователям, которые самостоятельно разрабатывают новые сценарии развития бизнеса?

С нашей точки зрения, важны три компонента. Первое — простота платформы, ее понятность и возможность сделать первых роботов в режиме no-code. Второе — широта предоставляемых готовых компонентов, что дает пользователю возможность собирать сценарии максимально быстро и не прибегать к написанию кода. И третье — наличие поддерживающей инфраструктуры на стороне производителя платформы RPA. Речь о тренингах, документации. Для решения этой задачи мы сделали абсолютно бесплатным обучающий тренинг по нашей платформе. И планируем создавать новые на той же основе.

- Что особенного есть в платформе Primo RPA для поддержки работы бизнес-аналитиков?

В этом году мы вывели на рынок продукт Primo Workshop, призванный облегчить труд аналитика при сборе бизнес-требований, упростить коммуникацию между разработчиком и аналитиком при оценке сроков и трудоемкости реализации бизнес-процессов. Используя наш продукт, аналитик получает централизованный «портфель» проекта, а разработчик — готовые «слепки» интерфейсов (не столько снимки экрана, сколько внутреннее содержание на программном уровне), которые помогут ему оценить сложность интеграции и даже позволят начать производство робота еще до получения доступа к информационным системам.

- Как бизнес-аналитикам самостоятельно настроить и проверить бизнес-процессы без привлечения ИТ-специалистов?

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