На Хабре мы активно делимся интересными кейсами по роботизации наших клиентов, рассказываем о своих продуктах и их новых фичах. Одна из главных целей наших материалов — показать ценность RPA-решений для бизнеса. Однако, в комментариях к нашим постам очень часто разгораются нешуточные дискуссии по поводу полезности и нужности RPA. Наши наблюдения показывают, что чаще всего скептически к сервисам роботизации относятся IT-специалисты. Мы решили поговорить об этом подробнее и попросили технического эксперта UiPath Валентина Драздова ответить на самые распространенные возражения по поводу внедрения автоматизированной роботизации и RPA-систем. 

Возражение #1

RPA-платформы работают с пользовательским интерфейсом, но часто он работает медленно и не предоставляет всей информации. Практически все современные системы предоставляют API, используя которые можно интегрировать разные системы на программном уровне, что будет гораздо надежнее и быстрее, чем использовать RPA.  

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

Даже опытный программист потратит в лучшем случае несколько дней на то, чтобы изучить API одной системы. А когда вам нужно «подружить» две, три или даже больше систем — тут не обойтись без действительно очень дорогого разработчика, который будет писать и отлаживать интеграцию между этими системами несколько месяцев.  

Предлагаемый RPA подход — работать с пользовательским интерфейсом, не требует высокой квалификации от разработчика. Ему достаточно просто увидеть, как с несколькими системами работает профильный специалист — и он повторит это в короткие сроки не погружаясь в особенности работы API. Что касается того, что в пользовательском интерфейсе отображаются не все данные — встает вопрос «А нужны ли они»? Если сегодня ваши сотрудники объединяют информацию между несколькими системами без доступа к скрытой технической информации, значит она им и не нужна.

В тех случаях, когда по тем или иным причинам интеграция с одной из систем с помощью пользовательского интерфейса невозможна, у платформы UiPath предусмотрено применение всех возможностей платформ .NET Framework и .NET Core, в том числе: использование сторонних программных модулей, подключение к базам данным и взаимодействие с любыми современными веб-сервисами. Для начинающих разработчиков UiPath предоставляет готовый набор активностей, используя которые можно выполнять указанные выше операции, а для опытных разработчиков предоставляется возможность писать собственный программный код непосредственно при настройке робота. 

Таким образом можно комбинировать разные подходы: с одними системами работать по API, а с другими — через пользовательский интерфейс, и все это с использованием одного универсального инструмента — UiPath.

Возражение #2

RPA взаимодействует с графическим интерфейсом, что требует серьезных познаний в GUI и навыков написания UI-скриптов. Грамотному разработчику гораздо быстрее решить задачу с использованием классического программирования, чем тратить время на то, чтобы разобраться с чужими графическими интерфейсами и запрограммировать их. 

Мы замечаем, что довольно часто RPA путают с автокликерами. Это не просто так, ведь действительно можно сказать, что корни RPA лежат именно там. На самом же деле RPA — это гораздо более широкое понятие. 

Действительно, написание хорошего автокликера требовало глубоких познаний в том, как устроено GUI, необходимо было тщательно изучить язык скриптования пользовательского интерфейса.

Когда мы говорим про RPA, то важно учитывать тот факт, что это не просто красивый термин, а целый набор методологий и инструментов по автоматизации повторяющихся действий и задач. RPA-платформы используют для взаимодействия с пользовательским интерфейсом селекторы (описания элементов интерфейса на языке XML), а вместо того, чтобы требовать от разработчиков написания этих селекторов, пишут их самостоятельно, давая разработчикам возможность просто указывать «Селектор какого элемента интерфейса нужно получить». 

Помимо селекторов важно то, как настраивается бизнес-логика роботов. В платформе UiPath имеется сразу два режима разработки роботов:

1. Профессиональный, где интерфейс похож на профессиональную IDE для программистов, позволяет разрабатывать роботов применяя возможности программирования с .NET Framework и .NET Core.

2. Для бизнес-пользователей, в котором все максимально упрощено настолько, что даже далекие от программирования люди могут создавать своих роботов. 

Важно отметить, что в России есть несколько крупных организаций, в которых роботов делают не программисты с многолетним опытом, а самые обычные люди других специальностей, которых еще называют citizen developers.

Возражение #3

Решения на базе RPA привязываются к графическому интерфейсу приложений и систем. Мода на интерфейсы меняется очень часто, одно небольшое изменение интерфейса на форме может привести к полной остановке из-за того, что робот не сможет найти нужную кнопку. Из этого следует вывод, что гораздо надежнее потратить больше времени на интеграцию программными способами через API.

Многие этого не замечают, но на самом деле технологии очень быстро развиваются, выходят новые версии старых серверных решений, появляются новые языки программирования, базы данных. Хорошие разработчики всегда стремятся как можно скорее избавиться от всего старого и начать пользоваться новым. Но с другой стороны пользователи не готовы часто наблюдать изменения интерфейсов, в связи с чем одна из самых главных проблем большинства разработчиков — как изменять серверную архитектуру, но при этом оставлять пользовательский интерфейс прежним. 

Изменение серверной архитектуры, как правило, несет с собой значительные изменения в API, что требует постоянного контроля за ним со стороны разработчиков интеграционных модулей. Если сравнить частоту изменения пользовательского интерфейса и внутренней кухни систем, то можно сказать, что на одно изменение кнопки в пользовательском интерфейсе будет несколько изменений в методах API. 

И здесь стоит задаться вопросом «Почему тогда обновление API не влияет на работу интеграции, а изменение пользовательского интерфейса должно?» 

Ответ прост: все адекватные разработчики используют схему “Development — Test —  Production”, суть которой заключается в том, что на одном сервере происходит разработка, на втором тестирование (в том числе интеграционных модулей, которые связываются с этой системой), а на третьем — работает проверенная версия: которой пользуются сотрудники (основной сервер).

Когда в целевой системе изменяется API, разработчики интеграционных модулей видят это именно на тестовом сервере. Тут важно отметить, что точно так же можно проверять на тестовом сервере и роботов. Если у вас робот перестанет работать на тестовом сервере — вы не будете устанавливать обновление на главный сервер, пока не внесете необходимые изменения.  

Опытные программисты могут возразить, что при разработке своих интеграционных модулей они пишут всевозможные модульные тесты (автотесты) и при обновлении целевой системы просто запускают тестирование одной кнопкой, после чего сразу видят, где сломалась интеграция. Действительно, большинство RPA-платформ не поддерживают такую функцию, чего нельзя сказать о UiPath. 

UiPath Test Manager позволяет создавать автотесты для роботов и запускать все тесты как вручную, так и по наступлению какого-нибудь события. Точно так же, как автотесты   в обычном программировании, тесты UiPath покажут вам, где и почему происходит ошибка. 

А теперь давайте подумаем, что произойдет, если не будет схемы “Development — Test — Production”? Обычно такая ситуация возникает при использовании внешних или облачных сервисов. При обновлении API внешней системы программная интеграция откажет сразу же и ваше предприятие действительно остановится. А вот при обновлении пользовательского интерфейса почти все системы дают возможность временно вернуться к старому дизайну. Добавление одного клика мышки во всех роботов очень быстро исправляет ситуацию и ваше предприятие продолжает работу, а  RPA-разработчики спокойно занимаются адаптацией роботов под новый дизайн.