RPA — технология автоматизации бизнес-процессов с использованием программных роботов выполняющих рутинные задачи. Она существует более 15 лет, и если для бизнеса это инструмент сокращения операционных затрат, то у ИТ-сообщества все еще есть опасения относительно ее использования несмотря на то, что роботы эффективно решают задачи бизнеса. В ИТ-службах многих компаний все еще думают над дилеммой – «отказать, нельзя использовать» или «отказать нельзя, использовать».
В интервью с CTO Primo RPA Михаилом Андреяновым разбираемся, как работает RPA и почему этот инструмент можно и нужно добавить в арсенал ИТ-отделов.
— Перед переходом к ключевым вопросам обсудим, что такое RPA и как эта технология работает в российских компаниях. Начнем с того, для чего же нужны RPA-роботы?
RPA-роботы способны выполнять действия, которые обычно выполняет человек в пользовательском интерфейсе приложений: ввод данных, заполнение форм, извлечение информации из различных источников, проверка и валидация данных, интеграция и синхронизация данных между системами, запуск и мониторинг отчетов, отправка уведомлений.
Соответственно, RPA-платформы подходят для применения в тех областях, где выполнение задач можно свести к алгоритмическим действиям. В таких рутинных процессах роботизация позволяет делать задачи быстрее, с меньшим числом ошибок. А еще – избавлять сотрудников от повторяемых, скучных, рутинных задач. Например, до сих пор в нашей стране огромное количество людей занимаются тем, что руками переносят данные из таблички в Excel в корпоративную систему 1C.
— Перейдем к технике. Робот работает с пользовательским интерфейсом. Если в интерфейсе что-то поменялось, как будет реагировать робот?
Платформы RPA используют очень разные инструменты для поиска нужного объекта на экране. Это может быть и использование алгоритмов компьютерного зрения для визуального поиска объектов, таких как поля и кнопки, и, в то же время, их идентификация по внутренним идентификаторам в операционной системе. В любом случае, при корректно разработанном сценарии вероятность сбоя робота невелика. К тому же сценарий робота определяет алгоритм его поведения в различных ситуациях. И обычно предусматривается возможность в любой непонятной ситуации остановить сценарий и обратиться за помощью к человеку.
— Как сильно RPA нагружает инфраструктуру?
В плане нагрузки на инфраструктуру ничего не меняется. Более того, иногда она снижается, так как робот сосредоточен исключительно на выполнении поставленных задач, без отвлечения на посторонние действия, такие как посещение социальных сетей. Он запускается, выполняет задачу и завершает сессию, высвобождая вычислительные мощности.
Например, есть компания с 70 операторами, у каждого из которых есть свой компьютер. Руководство этой компании планирует автоматизировать процессы, переложив работу операторов на программных роботов. Возникает вопрос: где разместить этих роботов? Одно из наиболее типовых решений – создание виртуальных рабочих мест.
— А с точки зрения информационной безопасности, могут ли быть риски?
Антивирусное ПО часто негативно реагирует на RPA-системы, воспринимая их сигнатуры как потенциальные угрозы. Однако более значимые вопросы для информационной безопасности касаются того, под какой учетной записью робот получает доступ к информационной системе (ИС). Если используется техническая учетная запись, это обычно не вызывает беспокойства.
В некоторых компаниях регламент запрещает создавать учетные записи для роботов, поскольку требуется персональная ответственность за действия в информационных системах компании. В этом случае нужно искать того, кто на себя возьмет ответственность и даст «учетку» RPA-роботу. Соответственно, возникает вопрос безопасного хранения паролей для учетных записей.
Также следует проработать стандартные вопросы: какие порты используют, какие протоколы. Это в целом универсальный момент.
— Есть ли разница между Windows и Linux в работе с RPA?
Инфраструктура не имеет значения. Однако роботы на базе Linux стали востребованы только с 2022 года. Это связано с несколькими факторами:
- во-первых, применение рабочих мест под управлением Linux было редкостью;
- во-вторых, экосистема бизнес-приложений, поддерживающих работу пользователей в Linux, также была не особо развита;
- в-третьих, чисто технологически возможности автоматизации работы с UI на Linux были существенно слабее по сравнению с Windows.
Тем не менее эксперименты с применением RPA на платформах Linux выполнялись давно. Наша платформа поддерживала работу роботов на Linux уже в 2021 году. В 2023 году мы реализовали поддержку работы в среде Linux для всех компонентов нашей платформы, включая студию разработки, и провели сертификацию на соответствие требованиям Astra Linux и РЕД ОС.
— Кто пишет сценарии для программных роботов?
Отличие RPA от множества других технологий ИТ в том, что она изначально задумывалась как способ быстрой автоматизации для людей без существенных навыков в области проектирования и разработки. Однако в настоящее время существует два основных сценария.
Первый – роботы разрабатываются бизнес-пользователями, освоившими принципы работы платформы RPA и автоматизирующими относительно простые сценарии с использованием NoCode и LowCode подходов.
Второй сценарий – когда роботы разрабатываются ИТ-специалистами, обладающими навыками разработки и работающими в составе бизнес-подразделения или в составе ИТ-подразделения. Для этого преимущественно используются подход LowCode и возможности по встраиванию программного кода в сценарий роботов. В этом случае могут быть созданы очень сложные многоступенчатые сценарии.
— Возникает ли проблема, если бизнес-подразделение настраивает роботов, а ИТ-отдел не контролирует соответствующие ИТ-системы?
Да, конечно. В среде ИТ-профессионалов в целом сложилось мнение, что RPA – это такой инструмент для быстрого и зачастую неправильного решения задачи. Правильное решение, с точки зрения классического подхода к построению ИТ-систем, – провести глубокое исследование задачи и разработать продуманное решение, учитывающее все особенности ИТ-ландшафта компании, работающее через API, а не через относительно ненадежный, подверженный изменениям визуальный интерфейс.
Роботы, написанные бизнес-подразделением для своих задач, часто с точки зрения ИТ представляют собой клубок проблем.
- Первая из них – кто виноват, когда робот ошибется. С одной стороны, бизнес-подразделение посмотрит на своего робота, с другой – привлечет ИТ к разбору ситуации, в создании которой ИТ принимал минимальное участие.
- Вторая проблема – проблема производительности. Информационные системы в компаниях проектируются и внедряются в расчете на заданные показатели нагрузки. Робот, в отличие от человека, может работать существенно быстрее и круглосуточно. Нагрузка от роботов, особенно при некорректно написанном сценарии, может привести к деградации работы информационных систем, и вот тут жизнь ИТ-службы начинает играть новыми красками.
- Третья проблема – отсутствие сквозных процессов управления изменениями в ИТ. В случае разработки роботов бизнесом у нас получается комплексная ИТ-система, включающая как роботов, за которых вроде бы отвечает бизнес, так и информационные системы, за которые отвечает ИТ. Изменения в любом звене этой комплексной системы влияют на ее работоспособность. И при изменениях на стороне ИТ бизнес может прибегать со словами «вы опять нам все тут сломали».
Все это вместе с общим отношением к технологии может приводить службу ИТ к выводу, что RPA – это опасная «игрушка», которую лучше не использовать.
— Тогда почему RPA все-таки проникает в компании?
В большинстве компаний ИТ перегружен задачами, и коллеги вынуждены отдавать приоритет наиболее приоритетным из них, отбрасывая на потом задачи, бизнес-выгода от применения которых менее значима для компании. Цитируя ИТ-директора из одной логистической компании: «Мы готовы взять на себя решение всех задач, но мы не можем позволить себе бесконечный рост штата, и наш бэклог забит на год вперед». А бизнес не всегда может ждать. И вот здесь RPA становится инструментом, с помощью которого бизнес начинает решать экономически обоснованные, но не самые приоритетные для компании задачи без привлечения службы ИТ и перетасовки ее бэклога.
— Как в этом случае ИТ-отделу находить баланс между порядком и хаосом в применении RPA?
Стоит принять способность бизнеса находить решение для своих задач и, условно, возглавить эту активность. Как максимум – сформировать компетенцию и команду RPA внутри ИТ, опираясь на поддержку наиболее заинтересованного бизнес-подразделения. Как минимум – вместе с бизнес-подразделением, планирующим применение RPA, определить понятный для обеих сторон набор правил и процессов, которые позволят минимизировать проблемы, о которых я рассказал выше.
Некоторые из наших заказчиков рассматривают RPA, изначально принесенный в компанию бизнес-подразделением, как инструмент команды ИТ по прототипизации и созданию быстрых временных решений для тех или иных задач. Разработка роботов выполняется быстрее классической разработки. И робот не обязан быть постоянным решением. На стыке этих двух положений возникает вариант использования роботов как временной автоматизации на период 6-12 месяцев с одновременной параллельной разработкой целевого решения и последующим выводом робота из эксплуатации. Бизнес при этом получает эффект от автоматизации уже через пару недель после постановки задачи, а ИТ работает в спокойном режиме, выстраивая надежный и производительный ИТ-ландшафт.
— Есть ли варианты применения RPA для задач самого ИТ?
Да. У наших заказчиков, например, программные роботы работают в процессах Service Desk – на этапах приема запросов, их классификации и распределения между исполнителями. Роботы могут применяться для автоматизации процедур предоставления доступа в тех случаях, когда компания еще не перешла к использованию единой системы класса Identity Management.
Также программные роботы могут быть применены для решения задач тестирования и мониторинга информационных систем. В случае с тестированием роботы вообще являются очень логичным решением, поскольку они изначально ориентированы на работу с UI, то есть полностью имитируют поведение пользователя. Это позволяет использовать их для UI-тестирования и для нагрузочного тестирования. В своей платформе, например, мы разработали комплекс инструментов, позволяющих разрабатывать сценарии тестирования и формировать отчеты в типовых для команд тестирования форматах.
Следствием возможностей применения роботов в тестировании является возможность их применения для мониторинга информационных систем. Роботы могут регулярно проходить все этапы сложных бизнес-процессов с рабочих мест в разных точках присутствия компании и обнаруживать сбои до того, как их увидит пользователь. Это особенно полезно в период после переноса новых версий информационных систем в продуктивную среду.