RPA (роботизация) – "костыль" или автоматизация будущего? Идеи и практические примеры

Меня зовут Олег Филиппов. Я буду рассказывать про RPA, этим понятием в последнее время стало модно называть автоматизацию на основе имитации действий пользователя. Мы всегда это делаем, просто в последнее время это стали называть модно – Robotic Process Automation. 

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

Не все, что является имитацией действий пользователя, является RPA, и не все, что является RPA, является имитацией действий пользователя.

Тема моего доклада: «Роботизация – это костыль или все-таки реальная автоматизация?»

Сейчас до сих пор еще идут эти дискуссии. Кто-то считает, что RPA – это хорошо, и на основании этого мы будем все автоматизировать в будущем, что программисты станут не нужны, их нужно будет всех уволить. Приходит аналитик, делает определенные клики мышкой, и у всех все становится хорошо. А кто-то считает, что это очередные костыли, которые программисты используют для тестирования, а если это использовать в реальном крупном Production, то это реально не очень круто, не очень удобно.

Я попытаюсь в этой теме разобраться.

 

Средства автоматизации

 

 

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

 

AutoIt

 

 

AutoIt – это некая библиотечка, dll-ка, которую больше всего видели и знают 1С-ники в силу того, что она имеет у себя COM-объекты. Для AutoIt можно написать скрипты или использовать его, как COM. Можно написать ему скрипт, сказать: «Кликни мне сюда, потом кликни сюда, найди на экране этот рисуночек и кликни по нему». AutoIt с этой задачей вполне успешно и хорошо справляется. Конечно, с экраном, с рисунками и с кликами у него не очень получается – это не его задача. Но в целом, это достаточно большой скриптовый язык, он развитый, со своим редактором. Есть люди, которые на нем специализируются, есть русскоязычный отдельный форум, есть неплохая документация. Это все можно использовать. 

Даже если, в принципе, RPA не для вас, а просто есть какая-то система, с которой нужно интегрироваться, но у которой нет API (либо это SAP, либо это тоже что-то западное и очень дорогое) – берите библиотеку AutoIt. На Инфостарте статьи про нее есть. И пишете простой код: «Открой мне эту формочку, найди мне ее на экране, кликни» – у вас все получится. Конечно, это иногда ломается – а в случае с AutoIt это ломается часто, в силу того, что формочка поменяла свой цвет, или переехала по координатам, или монитор стал с другим разрешением. 

 

Sikuli

 

 

Дальше – Sikuli. Он приобрел определенную популярность в мире 1С с легкой подачи ребят, которые занимались автоматизированным тестированием – они его взяли за основу. 

Sikuli использует OpenCV – библиотеку компьютерного зрения, самую популярную для распознавания рисунков. У Sikuli очень клевый, красивый редактор скриптов. Если вы его откроете, посмотрите, там прямо видно – вы выделяете на экране скриншот, говорите Sikuli: «клик» по этой картинке. Дальше говорите: «Открыть такой-то файл», а дальше: «клик» по другой картинке. 

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

Сейчас в текущей версии SikuliX – не могу не сказать, что главным недостатком SikuliX является то, что она написана на Java – соответственно, движок требуется. Ее тоже можно использовать, и Sikuli уже вполне успешно, удобно и качественно работает с картинками – там есть уже элементы распознавания. Если вы изменили тему Windows, у вас картинка распознается. Уже не все так страшно, и этим пользоваться можно. 

Единственный недостаток – в Sikuli есть возможность кликать только по картинкам. Грубо говоря, вы не можете кликать по координатам и не можете совершать сторонние действия. Он достаточно ограничен и предназначен только для кликов по определенным картинкам, но 80% вопросов это решает.

 

Selenium

 

 

Selenium – уже более продвинутый, известный и продвигаемый инструмент в современном мире. Главным образом, в мире Web-разработки.

Веб-разработчики активно используют Selenium. Каждый веб-разработчик знает, что он нужен для того, чтобы тестировать веб-приложения (имеются в виду end-to-end тесты) . Правильное тестирование – это такое, когда вы открываете приложение и тоже кликаете там мышкой по элементам – кликаете, вводите текст и т.д. При этом фишка Selenium в том, что он уже не ориентируется на картинки. У вас любое веб-приложение – это набор HTML/CSS элементов, и там есть идентификаторы элементов (так называемые селекторы). И Selenium уже привязывается к идентификаторам элементов, и там пишется определенный код: «Найди элемент с этим идентификатором, введи туда такое-то значение. Теперь найди элемент с другим идентификатором, введи в него другое значение». 

Selenium – это некий фреймворк, для которого есть адаптации под прочие языки. Для него есть еще две удобных IDE – Kantu и Katalon. Это уже интерактивная, интересная среда для того, чтобы с легкостью писать скрипты на Selenium без программирования. 

Крутая штука. В принципе с его помощью вы можете протестировать даже веб-клиент 1С, хотя и не рекомендовал бы это делать так.

 

AutoHotkey

 

 

AutoHotkey – это в принципе самый мощный и всеобъемлющий язык для всего, что я рассказал до этого, но он не содержит никакой IDE, никакого редактора скриптов. Это просто библиотека, которая запускает код. Работать с ним не очень удобно, зато он, наверное, самый продвинутый. Вы можете на нем функции, циклы, даже классы написать. Это прямо целый язык разработки.

 

 

После того, как я про все это рассказал, я скажу, что во всем этом главное…. это все бесплатно! Это все – основа RPA. Это – кликалки по экрану, вводилки текста и т.д. Это все можно использовать уже сейчас бесплатно. Вы уже можете автоматизировать те системы, которые не имеют средств автоматизации. Будь то какая-то легаси ИУС, либо какая-то мега-дорогая система – любое ПО, в котором у вас нет доступа к программистам, либо случаи, когда надо собрать одну строчку из десяти различных систем – это уже можно использовать. 

А дальше появляются некие люди, которые говорят: «Слушайте, все это бесплатно, а мы вам за несколько десятков миллионов можем внедрить RPA». 

Что они вкладывают в это понятие? Давайте посмотрим.

 

Что такое RPA?

 

 

Конечно, RPA – это, прежде всего, некая методология. Это не о технологии непосредственно – не о технологии кликалки или ввода текста, имитации действий пользователя. Да, это есть, это правильно, это основа того, что мы можем автоматизировать все без программиста. Но, прежде всего, RPA говорит не о технике, а об анализе. В RPA есть специальные люди, которые называются аналитики, которые приходят к вашему пользователю, бухгалтеру, и спрашивают у него: «А что ты делаешь?». 

Бухгалтер отвечает: «Мой рабочий день начинается с того, что я открываю письмо в OutLook, сохраняю его вложение в Excel, открываю этот файл и вбиваю вот эту строчку в этот Клиент-банк, эту строчку в этот клиент-банк, а вот эту строчку вот сюда, в SAP еще вбиваю. А потом все это выгружаю в другой Excel, и все это загружаю в 1С».

Аналитик спрашивает: «А где ты по факту принимаешь решение? Где тебе нужен мозг для этих целей?» 

Если мозг нужен, это автоматизировать трудно, а если выполняются чисто механические действия, их можно (и нужно!) автоматизировать. И если посчитать количество часов, когда выполняются чисто механические действия, и переложить их на зарплату бухгалтера, то можно предложить автоматизировать эти действия за сумму, сопоставимую с экономией в зарплате. 

Скажем: «Сейчас вы на это тратите суммарно 10 миллионов в месяц, а мы вам все это автоматизируем за 9 – вы получите профит, сэкономите, несмотря на то, что на автоматизацию будут потрачены деньги» 

Бизнес на этом языке разговаривает. Причем, это реальная автоматизация – аналитик записывает действия пользователя. Он включает в RPA-системе режим записи, и уже сама RPA-система начинает набрасывать действия пользователя. В любой RPA-системе все это можно отловить, чтобы уже получился бизнес-процесс:

• вот это мы оставляем один в один;

• вот здесь требуется ручное участие – сохранили файлик сюда;

• а здесь мы подумаем с программистом и что-то перепишем, потому что здесь можно сделать через API. 

В RPA можно использовать API – там, где это возможно. 

Допустим, у вас есть 1С и SAP. У SAP, конечно, есть API, но это очень дорого, программисты есть только где-то в Германии, проект на 10 миллионов и 5 лет. Соответственно, проще RPA. 

А для 1С – вот он программист, можно опубликовать данные по протоколу oData и что-то с ними сделать. 

Соответственно, часть будет забрана из SAP интерактивно, а в 1С передана программно. Это работает, и работает неплохо.

Еще раз:

• RPA – это прежде всего, анализ.

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

• В RPA у нас описывается бизнес-процесс. И грамотный аналитик должен расписать, что процесс у нас устроен вот так – эти вещи требуют людей и принятия от них решений, а здесь мы можем автоматизировать. Причем, к этому нужно подходить очень грамотно и качественно, чтобы автоматизировать некое число действий пользователя, которое с присутствием RPA уже не нужно выполнять. Это – хорошая метрика, потому что проект по RPA вам всегда даст какую-то эффективность, которую реально можно посчитать. Это автоматизация, которая увольняет. Да, конечно, автоматизация еще никогда никого не увольняла, но в RPA такое случается. Я до этого еще видел автоматизацию WMS, которая увольняла. 

• Ну и, конечно, RPA должно работать везде, с любой системой. Ее концепция заключается в том, что это – кликалка по любым элементам. В целом, конечно, все это очень похоже на историю с SikuliX, AutoIT и прочими библиотеками, которые уже сейчас позволяют это делать. Просто вся суть в том, что в современном мире это не считается проблемой. Дальше я уже объясню, почему это не такая большая проблема.

 

Рост RPA

 

 

Рассмотрим показатели инвестиций в различные отрасли по данным Grand View Research. Среди всех технологий сейчас в RPA идет больше всего инвестиций. Это не я придумал – это общемировой тренд. 

 

 

Эта картинка показывает, что крупные компании в Штатах туда сейчас вкладывают большое количество денег. А если туда вкладывается много денег – это не просто так. Это не временная история. Инвестиции чаще всего растянуты во времени. Если сегодня туда вложили очень большую прорву денег, значит, завтра это будет использоваться очень активно везде и повсеместно. Более того, в крупных компаниях, где легаси систем очень много, от них не избавятся никогда, там без RPA очень трудно что-то сделать – раньше мы вообще не могли ничего сделать. А сейчас можем.

 

 

А вот это – Forrester показал, что рост инвестиций рынка к 2021 году будет равен примерно трем миллиардам долларов. Не то, чтобы сильно впечатляющая цифра, но, тем не менее – это уже знак.

 

Лидеры рынка RPA-систем

Теперь непосредственно перейду к решениям:

 

 

Это – магический квадрат Gartner по продуктам RPA (лидеры, претенденты, визионеры, нишевые игроки). В чем его магичность? Каждый раз, когда я вижу магический квадрат Gartner, я знаю только одно – все, что здесь нарисовано, очень дорого. Чаще всего, это либо OpenSource, либо очень дорого.

 

 

Вот это – лидеры рынка. Их три:

• UiPath;

• Blue Prism;

• Automation Anywhere.

Чуть-чуть надо про них рассказать, что они по факту автоматизируют.

 

Automation Anywhere

 

 

Automation Anywhere – это, наверное, самая сложная и жуткая RPA-система, которую можно видеть, но, одновременно, самая мощная. 

 

 

Подразумевается, что с Automation Anywhere работает почти программист. 

На слайде видна последовательность действий, которая выполняется. Не самый лучший пример – но смотрите, сколько всего здесь можно. Здесь можно работать:

• с шифрованием, 

• со звуком, 

• какие-то базовые вещи с SAP (кстати, базовых вещей с 1С нет), 

• OCR есть, кстати – можно распознать любой текст с экрана, его куда-то вбить. Даже текст, который по факту не печатали. 

Это очень крутые, мощные механизмы.

 

Blue Prism

Следующий продукт – Blue Prism. 

 

 

 

• у него жуткий интерфейс;

• мало автоматизируемых действий;

• до сих пор нет нормального web, нет нормального оркестратора (что такое web и оркестратор, я чуть дальше расскажу).

 

 

Но, наверное, это самое старейшее решение по RPA и самое отработанное. Оно внедрено в множестве американских компаний.

 

UiPath

И, наверное, единственное, на что стоит обратить пристальное внимание – это UiPath.

 

 

 

 

Во-первых, он представлен в России, там есть русские партнеры, русская поддержка. Есть даже курс, часть даже на русском.

В принципе, интерфейс достаточно современный. 

• В нижней части интерфейса у нас Microsoft Workflow Foundation. 

• В центральной области классический Ribbon. Это – конструктор, это один из элементов RPA-системы. 

• И все остальное отчасти похоже на Visual Studio. Хорошо это или плохо – не знаю. Мне показалось, что с этим достаточно удобно, привычно работать.

У всех этих систем проблема в том, что они разработаны на западе, у них нет русского интерфейса и русской поддержки. Они закрытые. И более того, половина госкомпаний запрещают их использовать, а RPA все-таки часто используют в госкомпаниях, где требуется интеграция с легаси-решениями, где нельзя что-то автоматизировать на 1С.

 

RPA в России

 

 

Что можно предложить в этом случае? В России есть два RPA-решения. 

 

 

Решение ElectroNeek – сейчас активно развивается. Но, как видно на скриншоте, действий у него не так много, мало что с его помощью можно сделать. От UiPath недалеко ушел в плане интерфейса.

 

 

И Robin – по-моему, уже загнулся. Но тоже один из кейсов.

 

 

Этим продуктам далеко до западных аналогов. Они мало, что могут. Но хотя бы им можно позвонить, и они вам по-русски ответят. Это уже хорошо. Это плюс. И, наверное, их еще в госкомпаниях разрешают.

 

Обзор UiPath

 

 

Все-таки вернемся к UiPath. Остановлюсь на нем подробнее. Потому что он, все-таки, лидер. И, наверное, это то, что можно использовать.

Решение UiPath, как и любая RPA-система, состоит из трех элементов – это студия, оркестратор и робот.

• Студия – это то, что я показывал на скриншоте. Это среда разработки, в которой вы роботов разрабатываете.

• Оркестратор – это некая среда для запуска этих роботов. Они бывают запускаемые вручную и автоматически. В 10 утра, к примеру, зашли и запустили загрузку выписки банка.

• И, соответственно, сами роботы, которых можно оформить как отдельные приложения, которые можно запускать с помощью оркестратора – по-разному, кто как делает.

 

Применение RPA в 1С

 

 

Дошли до 1С. Все-таки, какие реальные кейсы более-менее подходят для RPA?

Постараюсь об этом рассказать.

 

 

Например, приходит к вам рано или поздно человек и говорит: «Я каждый день загружаю руками эту выписку из клиент-банка, сохраняю файлик, а потом его вношу в 1С. У меня есть DirectBank, но он отправляет мне SMS, и интерфейс у него другой – мне не нравится. Можно ли мои действия автоматизировать?»

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

 

 

Дальше есть куча западных систем. Какая-нибудь западная компания, у которой есть QuickBooks, который вы никогда в жизни не доработаете – к его разработчикам доступа нет, он жутко облачный. И бухгалтер каждый день открывает Excel и вбивает туда руками десяток проводок. Пожалуйста, это тоже автоматизируется. Нет систем, которые нельзя автоматизировать. Когда программисты сдались, ничего не могут сделать – открываем Excel, берем RPA – записываем последовательность действий и автоматизируем.

 

 

Какая-нибудь система с вот таким названием, которое я на слайде сгенерировал случайно, может быть, попал. Эти любимые советские «АСУ НИИ ФПКП ИнЕУ», которые были автоматизированы в 90-х годах какими-нибудь программистами на Access, на FoxPro, эта «история, которая до сих пор живет» – ее тоже можно автоматизировать, даже не боясь что-то сломать. Можно просто посмотреть, что люди делают и сделать то же самое посредством RPA, не влезая во внутреннюю структуру, не вникая, какие там таблицы, какие базы данных. Выгнав оттуда программистов – они нужны будут только на этапе, когда вам нужно будет правильно создать окошко. Пожалуйста.

 

 

Дальше – что-нибудь с криптографией, когда вам нужно будет подписать документ, который подписывается специальным криптоключом, программный доступ к которому возможен только через сертификацию ФСТЭК, а руками вы это делаете в три клика. Если вам нужно автоматизировать это на каждый день, для каждого документа – welcome, тоже RPA.

Задач много, задачи решаемые. 

Проблема с кликами по картинкам, про которую мы говорили, уже неактуальна. Понимаете, сколько денег вкладывается в машинное обучение, в распознавание изображений. Реально, они сейчас уже хорошо распознаются. Смена темы, смена интерфейса редко влияет на то, что у вас там что-то перестает работать. Уже даже элементарные кликалки по картинкам работают хорошо. 

Более того, 90% кода RPA не привязано к картинкам, оно привязано к WinAPI элементам, к хэндлам окон, доступ к которым вообще не меняется (чтобы он изменился, нужно вообще всю систему переписать). А вторая часть – там веб-интерфейс, там Selenium, там все привязано к элементам HTML – это тоже не так часто ломается. Но, конечно, ломается.

 

А если написать RPA на 1С?

 

 

Сейчас, наверное, у всех один вопрос: «А можно ли это реализовать на 1С?» Можно. Поскольку это все сейчас в тренде, я даже начал этим заниматься. Пока это некий личный проект, но в целом, когда я посмотрел, как работают существующие RPA-системы, которые есть на этом рынке, они все говорят – мы все с 1С интегрируемся, мы можем интеграцию. А как они интегрируются? Грубо говоря, поднимают HTTP-сервис и туда пушат данные по API, или ещё хуже – цепляются по COM и передают код. 

Все 1С-ники знают – есть запись действий пользователя, как минимум. Есть понимание структуры данных. Ничто не интегрируется с 1С лучше, чем сама 1С. В принципе, если у нас большая часть Enterprise-рынка внутри России на 1С, то вот эти западные RPA-системы нам не нужны. Конечно, они работают хорошо, но можно лучше! Если код можно написать на 1С, если можно выполнить внешнюю обработку, а действия пользователя использовать только для того, чтобы в этой внешней обработке правильно выбрать Excel-файлик и выгрузить этот файлик из SAP или из клиент-банка – это нужно, правильно и хорошо делать внутри самой 1С. А технология RPA не такая сложная. Мы делаем некий конструктор, там графическая схема – банальная.Делаем расширение, которое этих роботов получает и запускает. Все. Ничего хитрого нет.

 

 

В качестве конструктора выступает графическая схема в 1С.

Attended-роботы, которые запускаются руками – это расширение

Сейчас допиливается запуск Unattended-роботов через агента.

 

 

Распознавание изображений – все просто. Внешняя компонента, которая реализует библиотечка OpenCV. 

С Web можно работать через Selenium – ничего лучше не придумали

С окнами – три строчки на WinAPI, и можно получить хэндл любого окна и по нему кликнуть – никаких проблем не возникает. 

И работа с 1С – пожалуйста, любой код, который вы выполните, он может быть выполнен.

 

Когда лучше без RPA

 

 

Должен сказать для всех людей, которых я сейчас впечатлил – иногда лучше обойтись без RPA. 

Технология RPA – хорошая, крутая, современная, ее нужно использовать. Но использовать ее надо очень и очень аккуратно. И, конечно, правильно готовить. 

Пара слов о том, что же правильнее делать в итоге. 

• Конечно, если вы напишите любого RPA-робота – это круто. С его помощью можно делать базовые вещи, просто описав действия пользователя и чуть-чуть их подправив. Но потом надо позаботиться о том, чтобы этот робот работал, чтобы он не сбоил. Потому что это, все-таки, кликалка по действиям пользователя. И надо понимать, что если робот открывает окно, он ищет кнопку «Сохранить и закрыть». А если нет такой кнопочки – все, он тормознулся. В этот момент оркестратор пишет: «Робот ожидает появления окна» и все висит. А вы начнете разбираться, только если этот статус где-то увидите. 

• На самом деле, вам нужно в сам робот вставлять историю: «Если кнопочка появилась в течение 5 секунд, тогда робот продолжил работу». Или, если кнопочки не появилось, тогда вы записали ошибку в лог и отправили ее в почту или в Telegram сразу разработчикам, чтобы они открыли и увидели, что 1С вылетела с ошибкой «Поле объекта не обнаружено», и ваш робот дальше ничего сделать не может, пока программист эту ошибку не поправит. Когда это делал бухгалтер, то звонил бухгалтер. Теперь, если вы функцию бухгалтера переложили на робота, то робот должен выполнять все функции бухгалтера, включая звонки программистам 1С, говоря о том, что ваша программа не работает, в вашей программе есть ошибки. 

• Более того, нормальный RPA должен учитывать даже APDEX – если формочка открывается больше 15 секунд, то должно выйти сообщение, что робот выполнился, но формочка открывалась больше 15 секунд. Примерно такое: «Уважаемые разработчики, обратите внимание, что ваши роботы загрузят выписку банка не к 11 утра, а к 13, и директор расстроится, скажет, что ваша программа не работает, а ваши роботы все испортили».

• И, соответственно, если у системы есть API, если можно интегрироваться нормально через REST API, он открытый, доступный, простой, понятный. В этом случае не надо костылить роботов, они не для этого созданы. Это тоже можно решить с помощью RPA, но это не надо решать через RPA, надо написать нормальную интеграцию нормальными техническими средствами, которые будут работать, API будет поддерживаться. За поддержание API будет отвечать вебер.

Приведу простейший кейс, когда в RPA все будет плохо. Знаете, что такое АБ-тестирование? Дело в том, что интернет-проекты, сайты могут менять свой интерфейс, чтобы проверить, станет после этого проще жить или нет. Они тогда делают две версии интерфейса – часть пользователей заходит по интерфейсу А, а вторая часть пользователей заходит по интерфейсу Б. Если вы зашли по интерфейсу А и решили свои вопросы быстрее, значит, интерфейс А лучше. А если вопросы решились быстрее (или пользователи купили больше) с интерфейсом Б, значит, интерфейс Б лучше. Так вот, если банк проводит АБ-тестирование своего нового интерфейса, то в этом случае робот, который ориентирован на интерфейс А, в части кейсов получает себе интерфейс Б и не может завершить операцию успешно. Если мы его перезаписываем на интерфейс Б, а он опять попадает на интерфейс А, он опять не может завершить операцию успешно. В этом случае нас спасала только кнопочка «Вернуться в старый интерфейс», которая, слава богу, не поменялась. Такие кейсы могут быть. Они не очень приятные, их надо учитывать.

Главное что нужно знать – технология RPA очень дорогая во владении. Ее использовать можно, но надо понимать, что владение API стоит 10 рублей, а владение RPA стоит 100 рублей. Но это не признак того, что это плохо. Это нужно, можно, важно использовать. Там, где вы сейчас клиенту говорите, что вы с этим не можете интегрироваться – не надо говорить «не можем». Нет слова «Не могу» у разработчиков. Есть слова: «Мы применим другую технологию, но все равно поможем вам это сделать. У вас все будет работать круто, но техподдержка будет стоить несколько дороже, а разработка – дешевле».

 

Вопросы:

• Сама по себе эта роботизация кроме обслуживания, разработки и т.д. все-таки предполагает поддержку окружения. Имеется в виду, что нужно содержать рабочую станцию и т.д. Какой тогда смысл автоматизации? В чем разница? Если мы автоматизировали, мы же просто сделали функцию, которая делает то же самое, что и человек.

• Чем дальше и больше мир движется вперед, тем дешевле становится оборудование и дороже труд людей. Роботизация – это не про оборудование, это про труд людей.

• А поддержка самого окружения – это тоже труд людей.

• Конечно, но мы экономим труд бухгалтеров, рядовых сотрудников, операторов. Труд ИТ-шников никто не экономит. Более того, его становится больше. В будущем должны остаться только ИТ-шники.

• Но стратегически никакой разницы нет, получается.

• Стратегически мы уберем бухгалтеров и оставим ИТ-шников. 10 бухгалтеров уволим, оставим одного ИТ-шника. По-моему, это стратегически очень удобно. Мне, как ИТ-шнику, по крайней мере, нравится идея.

• Можно же это реализовать через API, еще и админов уволить.

• Если можно через API реализовать, то да. А если нельзя, тогда RPA.

• Вопрос по веб-клиенту 1С и Selenium – вы как-то их упомянули в связке.

• Да, я их в связке упомянул. У меня завтра будет доклад касательно веб-приложений на 1С. Там я расскажу некий лайфхак, он не самый простой, но после этого вы поймете, как можно клиент 1С подружить с Selenium. 

• В целом, это работает?

• В целом, работать может.

• Хочу уточнить – правильно ли я понимаю, что RPA – это, фактически, те же самые AutoIT, AutoHotkey, просто коммерческие дороже.

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

• Можно ли сказать, что SikuliX – это тоже RPA?

• Товарищи из RPA, наверное, с тобой бы не согласились. SikuliX – это средство автоматизации. А RPA – это подходы к автоматизации. Это все равно, что сказать, что человек, который занимается DevOps – это DevOps. DevOps – это процесс, это не человек.

• RPA – это подход?

• Да.

• То есть, можно применить этот подход и автоматизировать с помощью SikuliX?

• Наверное, да. Но если применить подход RPA , только SikuliX использовать не получится. SikuliX только кликает по картинкам. А RPA должен кроме этого поддерживать еще, как минимум, веб и WinAPI. Только картинки – это не совсем RPA. В SikuliX нет бизнес-процесса, ты его там не нарисуешь не покажешь пользователю один в один и т.д.

• Систем бесплатных нет, все коммерческие?

• У UiPath есть Community Edition, которую можно использовать в личных целях без ограничений. Ее можно попробовать, поставить, посмотреть, убедиться, что это круто работает, а потом купить, если собрался ее использовать в коммерческих целях.

• А есть какие-то решения RPA, которые интегрируются с Android-устройствами или с Android-приложениями? 

• У западных крутых вендоров RPA-систем есть решения под Android-устройства, по-моему, даже под iOs, они туда вложили кучу денег. Касательно людей, которые автоматизируют на SikuliX, есть программа под Android, кликалка по действиям. Она тоже использует подход RPA на Android. Работает, в принципе, неплохо – мы ее даже в продакшен используем.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.