Привет! Тема с RPA становится всё более хайповой. Принцип работы программных роботов и отличие RPA от других способов автоматизации освещаются на тематических порталах. Я же решил сосредоточиться на подходах к моделированию RPA-процессов. Для примера выбрал процесс регистрации счета покупателю. Остановился именно на нем, так как этот процесс универсален и актуален для компаний любой отрасли и масштаба.
Обобщенно регистрацию счета можно представить так:
В каждом конкретном случае этот кейс будет организован по-разному. Менеджер может работать в CRM-системе. Заявка на счет может отправляться через BPM-систему. А в качестве учетной могут использоваться различные конфигурации 1С, SAP или Oracle.
В итоге процесс обработки счета автоматизируется лишь частично — на каждом из этапов, где работает та или иная система. Но вот на стыках между системами работают люди, причем их действия скучны и монотонны: они просто копируют данные из одной системы и вставляют в другую. Встает вопрос о интеграции систем между собой.
Какие-то системы уже в стандартной конфигурации могут содержать готовый функционал для интеграции. Сложность в том, что он не подойдет, если система, с которой выполняется интеграция, имеет неподдерживаемую версию или очень сильно дописана «под себя».
В этом случае решением может быть реализация собственной интеграции между системами. У этого решения есть недостаток — это дорогой и длительный проект. Иногда такая интеграция может быть невозможна из-за отсутствия API или закрытого исходного кода. Иногда нецелесообразна, например, в случае устаревшей системы, которую не планируется поддерживать в дальнейшем.
Технология RPA лучше всего показывает себя в рутинных задачах, где требуется простой перенос данных через заполнение форм, нажатие клавиш. В таких задачах не должно быть логики, которую нельзя представить в виде системы очень четких правил. Чем проще логика – тем дешевле реализовать такой процесс. Чем чаще он повторяется в бизнес-процессах компании, тем ощутимее будет выгода от его внедрения.
Робот выполняет процесс со скоростью немного превышающей скорость человека. На одном роботе может одновременно выполняться только одна задача. Поэтому, если с помощью автоматизации мы планируем переключить на робота операции, которые сейчас выполняются вручную, то RPA – подходящий вариант, если же данные должны обрабатываться с высокой скоростью – лучше рассмотреть другие способы.
В моем примере, где требуется простой перенос данных между системами и сверхчеловеческая скорость не обязательна, интеграция через RPA — оптимальное решение.
Конкретный кейс регистрации счета, который я смоделировал, выглядит следующим образом:
Робот берет на себя создание счета в 1С и отправку его в Диадок, таким образом процесс будет полностью автоматизирован.
Конечно, нет смысла описывать здесь пошаговую инструкцию, потому что в основном при моделировании выполняются повторяющиеся шаги. Да и в вашем случае реализация наверняка будет в чем-то отличаться. Я хочу рассказать скорее об общих подходах к реализации RPA-процессов и показать, как выполняются самые часто используемые шаги в дизайнере RPA.
RPA-процесс – это в первую очередь про взаимодействие с пользовательским интерфейсом. Робот должен повторить действия пользователя. А пользователь для навигации внутри окна приложения чаще всего использует клики мышкой по соответствующим визуальным элементам интерфейса. Если нужно закрыть окно, пользователь нажмет «крестик», для подтверждения действия — кнопку «ОК», если нужно ввести дату — предпочтет найти ее в выпадающем календаре. Чтобы повторить такое действие, в процессе записывается указатель для поиска нужного элемента. В общем случае это заголовок окна, где должен находиться элемент и его название. Приложения могут быть организованы по-разному, не всегда удается выделить такой текстовый указатель. В этом случае робот может ориентироваться по изображению, тогда в качестве указателя в процессе будет записана картинка.
Поиск элемента по указателю-картинке будет работать медленнее, чем поиск по текстовому указателю. Кроме того, такой поиск менее надежен: изменение разрешение экрана или фона под элементом – и робот может не найти элемент. Есть еще один вариант – использовать для навигации клавиши. С их помощью можно открывать приложения, перемещаться между элементами, нажимать кнопки. Поиск при этом не нужен. Это самый быстрый и надежный вариант, именно он самый предпочтительный для RPA. После него – текстовый указатели и в крайнем случае – поиск по изображению.
Для моделирования я взял бесплатную RPA систему от ELMA.
Создаю в дизайнере новый процесс.
Первое, что должен сделать робот – запустить приложение 1С. Надежнее всего работают действия, выполняемые нажатием клавиш. Поэтому запускаю 1С с помощью команды «Выполнить».
Для этого перемещаю на графическую модель процесса действие «Сочетание клавиш» и указываю, какие клавиши должны быть нажаты – Win + R. Далее перемещаю действие «Ввод текста» и указываю адрес исполняемого файла 1С, например, «C:\Program Files\1cv8\8.3.16.1063\bin\1cv8s.exe». И наконец действие «Сочетание клавиш», которое и должно нажать клавишу Enter.
Далее на экране появится окно выбора конфигурации 1С. В простейшем случае для выбора конфигурации можно так же использовать последовательность нажатия клавиш. Но если вы не знаете, какой по порядку будет выведена в списке нужная конфигурация, придется предусмотреть поиск с помощью указателя.
Для поиска указателя подходит специальный инструмент дизайнера — рекордер. Он позволяет записывать последовательность действий пользователя и автоматически определяет указатели. Когда рекордер запущен, он распознает элементы интерфейса на которые наведен указатель мыши и подсвечивает их зеленым цветом. Таким образом можно сориентироваться, к какому элементу будет применено записанное действие. Рекордер умеет записывать самые разные действия пользователя: перетаскивания элементов, прокрутку, клики мышью, нажатия клавиш и т.д.
Запускаю рекордер, навожу на название нужной конфигурации. После того, как она подсветилась зеленым, кликнем на нее. Затем Enter. Останавливаю запись и подтверждаю добавление действий в процесс.
Следующий шаг – ввод логина и пароля для входа в приложение. Пусть эти параметры передаются процессу в качестве аргументов вызова. Добавляю их в контекст процесса.
Теперь нужно ввести значения этих переменных в соответствующие поля 1С. Для этого воспользуюсь рекордером. В режиме записи после наведения на нужный элемент можно вызвать особое меню рекордера, позволяющее применить к элементу дополнительные действия. Например, вставку значения из контекстной переменной.
Записываю клик по полю «Пользователь», затем применяю к нему действие «Вставить», указав переменную login, затем Tab, функция «Вставить» для поля «Пароль» и наконец ввод клавиши Enter.
Если сейчас запустить воспроизведение процесса, дизайнер попросит вас указать значения контекстных переменных login и password, далее запустит 1С, выберет конфигурацию и залогинится в приложении. Теперь перед нами главное меню приложения.
Следующим действием нам нужно открыть форму «Документы покупателей». Скорее всего, вы уже догадались, что нужно для этого сделать: запускаем рекордер, кликаем по меню «Продажа», а затем по «Документы поставщиков».
Дальше нужно создать новый документ. В 1С нажимаю клавишу Insert. Добавляю это действие в процесс с помощью рекордера или вручную, перетащив из палитры действие «Сочетание клавиш».
1С попросит нас выбрать вид документа. Мне нужен «Счет на оплату покупателю».
Работа с таблицами и списками часто вызывает сложности. Не всегда определяются указатели. Или сложно с помощью простых действий, доступных роботу, построить процесс, требующий анализа таблицы, где много полей, много строк. Универсального способа тут нет, для каждой задачи подбирается свой подход.
Но в данном случае все просто. Можно или записать клик по нужному типу документа или воспользоваться строкой поиска вверху формы или начать набирать название нужного нам документа и 1С выделит его. Затем Enter, и мы готовы к вводу данных счета.
В шапке счета вводим дату счета, контрагента, договор, склад. Эти значения необходимо передать процессу в качестве входных аргументов, поэтому добавляю нужные переменные в контекст.
1С позволяет просто ввести эти значения в соответствующие поля, открывать формы справочников и выбирать в них не обязательно. Запускаю рекордер и с помощью быстрого меню записываю вставку значений контекстных переменных в нужные поля и перемещение между полями с помощью клавиши Tab
Теперь добавим строки счета. Очевидно, как моделировать работу с отдельной строкой. Но в каждом конкретном счете строк может быть сколько угодно. Нужно предусмотреть возможность передачи процессу произвольного количества строк, которые в свою очередь состоят из нескольких полей, и после этого добавление каждой полученной строки на форму в 1С.
Для передачи коллекции строк я создаю контекстную переменную с типом «Массив». Отдельная строка такой коллекции будет представлять собой текстовую строку с перечислением значений полей.
Чтобы процесс мог работать с отдельными полями строк, воспользуюсь действием «Сценарий». Это действие позволяет включить в логику процесса произвольный программный код на C#. В нашем случае программа будет вызываться в цикле и при каждом следующем выполнении брать следующую строку коллекции, выполнять ее разбор и присваивать значения полей соответствующим переменным. Для выхода из цикла я буду использовать специальную переменную с типом «Да/Нет», значение которой будет изменяться в коде сценария при разборе последней строки.
Чтобы организовать цикл выбираю действие «Повторять, пока…». Он представляет из себя контейнер, куда нужно поместить действия, которые должны повторяться.
Процесс почти готов. Используя те же приемы, что я показал выше, добавляю формирование печатной формы счета и сохранение его на диске, сохранение счета в системе и закрытие приложения.
Все базовые приемы моделирования на примере 1С подходят и для моделирования работы в любых других приложениях.
Следующая этап обработки счета – отправка его клиенту через Диадок. Создание счета в 1С и его отправку лучше моделировать как два разных процесса. Это позволит независимо их отлаживать и запускать на разных машинах.
Робот будет взаимодействовать с Диадок через web-интерфейс. Не во всех браузерах рекордеру удается хорошо распознать указатели. Лучше всего они определяются в IE и Firefox.
Для открытия web-страницы Диадок используем команду «Выполнить». В качестве параметра указываю «iexplore diadoc.kontur.ru». Дальше создайте необходимые входные параметры. Дальше используя рекордер моделирую логирование в системе, загрузку файла счета, ввод параметром и отправку. Там, где это возможно, выполняю действия при помощи нажатия клавиш, где нет – использую указатели.
В процессе появились две новые зоны ответственности: Робот и Администратор по роботизации. При выполнении процесса робот может столкнуться с чем-то, что мы не предусматривали при моделировании. Например, 1С выдаст непредвиденную ошибку или в Контур Диадок после обновления изменится интерфейс, и робот не найдет нужных контролов. В этом случае требуется, чтобы специалист, отвечающий за поддержку роботов, проверил, что пошло не так и восстановил работу робота. Описанный мной процесс предусматривает такую ситуацию. Получив статус задания робота «Ошибка», система создаст соответствующую задачу администратору, после его проверки робот запускается повторно.
Обобщенно регистрацию счета можно представить так:
- Менеджер по продажам отправляет бухгалтеру заявку на счет.
- Бухгалтер создает счет в учетной системе, формирует печатную форму счета и высылает ее обратно менеджеру.
- Если с покупателем ведется обмен электронными документами, то бухгалтер создает и отправляет ему счет в системе ЭДО.
В каждом конкретном случае этот кейс будет организован по-разному. Менеджер может работать в CRM-системе. Заявка на счет может отправляться через BPM-систему. А в качестве учетной могут использоваться различные конфигурации 1С, SAP или Oracle.
В итоге процесс обработки счета автоматизируется лишь частично — на каждом из этапов, где работает та или иная система. Но вот на стыках между системами работают люди, причем их действия скучны и монотонны: они просто копируют данные из одной системы и вставляют в другую. Встает вопрос о интеграции систем между собой.
Какие-то системы уже в стандартной конфигурации могут содержать готовый функционал для интеграции. Сложность в том, что он не подойдет, если система, с которой выполняется интеграция, имеет неподдерживаемую версию или очень сильно дописана «под себя».
В этом случае решением может быть реализация собственной интеграции между системами. У этого решения есть недостаток — это дорогой и длительный проект. Иногда такая интеграция может быть невозможна из-за отсутствия API или закрытого исходного кода. Иногда нецелесообразна, например, в случае устаревшей системы, которую не планируется поддерживать в дальнейшем.
Технология RPA лучше всего показывает себя в рутинных задачах, где требуется простой перенос данных через заполнение форм, нажатие клавиш. В таких задачах не должно быть логики, которую нельзя представить в виде системы очень четких правил. Чем проще логика – тем дешевле реализовать такой процесс. Чем чаще он повторяется в бизнес-процессах компании, тем ощутимее будет выгода от его внедрения.
Робот выполняет процесс со скоростью немного превышающей скорость человека. На одном роботе может одновременно выполняться только одна задача. Поэтому, если с помощью автоматизации мы планируем переключить на робота операции, которые сейчас выполняются вручную, то RPA – подходящий вариант, если же данные должны обрабатываться с высокой скоростью – лучше рассмотреть другие способы.
В моем примере, где требуется простой перенос данных между системами и сверхчеловеческая скорость не обязательна, интеграция через RPA — оптимальное решение.
Моделирование процесса в RPA
Конкретный кейс регистрации счета, который я смоделировал, выглядит следующим образом:
- Менеджер по продажам запускает процесс формирования счета в BPM-системе.
- Бухгалтер, получив заявку на счет, создает его в 1С, формирует печатную форму счета и прикладывает ее к задаче.
- Если в заявке была информация, что с покупателем есть договоренность и работе через ЭДО, то бухгалтер создает счет в Контур Диадок, прикрепляет к нему печатную форму и отправляет покупателю.
Робот берет на себя создание счета в 1С и отправку его в Диадок, таким образом процесс будет полностью автоматизирован.
Конечно, нет смысла описывать здесь пошаговую инструкцию, потому что в основном при моделировании выполняются повторяющиеся шаги. Да и в вашем случае реализация наверняка будет в чем-то отличаться. Я хочу рассказать скорее об общих подходах к реализации RPA-процессов и показать, как выполняются самые часто используемые шаги в дизайнере RPA.
RPA-процесс – это в первую очередь про взаимодействие с пользовательским интерфейсом. Робот должен повторить действия пользователя. А пользователь для навигации внутри окна приложения чаще всего использует клики мышкой по соответствующим визуальным элементам интерфейса. Если нужно закрыть окно, пользователь нажмет «крестик», для подтверждения действия — кнопку «ОК», если нужно ввести дату — предпочтет найти ее в выпадающем календаре. Чтобы повторить такое действие, в процессе записывается указатель для поиска нужного элемента. В общем случае это заголовок окна, где должен находиться элемент и его название. Приложения могут быть организованы по-разному, не всегда удается выделить такой текстовый указатель. В этом случае робот может ориентироваться по изображению, тогда в качестве указателя в процессе будет записана картинка.
Поиск элемента по указателю-картинке будет работать медленнее, чем поиск по текстовому указателю. Кроме того, такой поиск менее надежен: изменение разрешение экрана или фона под элементом – и робот может не найти элемент. Есть еще один вариант – использовать для навигации клавиши. С их помощью можно открывать приложения, перемещаться между элементами, нажимать кнопки. Поиск при этом не нужен. Это самый быстрый и надежный вариант, именно он самый предпочтительный для RPA. После него – текстовый указатели и в крайнем случае – поиск по изображению.
Для моделирования я взял бесплатную RPA систему от ELMA.
Вызов 1С
Создаю в дизайнере новый процесс.
Первое, что должен сделать робот – запустить приложение 1С. Надежнее всего работают действия, выполняемые нажатием клавиш. Поэтому запускаю 1С с помощью команды «Выполнить».
Для этого перемещаю на графическую модель процесса действие «Сочетание клавиш» и указываю, какие клавиши должны быть нажаты – Win + R. Далее перемещаю действие «Ввод текста» и указываю адрес исполняемого файла 1С, например, «C:\Program Files\1cv8\8.3.16.1063\bin\1cv8s.exe». И наконец действие «Сочетание клавиш», которое и должно нажать клавишу Enter.
Выбор конфигурации
Далее на экране появится окно выбора конфигурации 1С. В простейшем случае для выбора конфигурации можно так же использовать последовательность нажатия клавиш. Но если вы не знаете, какой по порядку будет выведена в списке нужная конфигурация, придется предусмотреть поиск с помощью указателя.
Для поиска указателя подходит специальный инструмент дизайнера — рекордер. Он позволяет записывать последовательность действий пользователя и автоматически определяет указатели. Когда рекордер запущен, он распознает элементы интерфейса на которые наведен указатель мыши и подсвечивает их зеленым цветом. Таким образом можно сориентироваться, к какому элементу будет применено записанное действие. Рекордер умеет записывать самые разные действия пользователя: перетаскивания элементов, прокрутку, клики мышью, нажатия клавиш и т.д.
Запускаю рекордер, навожу на название нужной конфигурации. После того, как она подсветилась зеленым, кликнем на нее. Затем Enter. Останавливаю запись и подтверждаю добавление действий в процесс.
Ввод логина-пароля
Следующий шаг – ввод логина и пароля для входа в приложение. Пусть эти параметры передаются процессу в качестве аргументов вызова. Добавляю их в контекст процесса.
Теперь нужно ввести значения этих переменных в соответствующие поля 1С. Для этого воспользуюсь рекордером. В режиме записи после наведения на нужный элемент можно вызвать особое меню рекордера, позволяющее применить к элементу дополнительные действия. Например, вставку значения из контекстной переменной.
Записываю клик по полю «Пользователь», затем применяю к нему действие «Вставить», указав переменную login, затем Tab, функция «Вставить» для поля «Пароль» и наконец ввод клавиши Enter.
Переход к форме «Документы поставщика»
Если сейчас запустить воспроизведение процесса, дизайнер попросит вас указать значения контекстных переменных login и password, далее запустит 1С, выберет конфигурацию и залогинится в приложении. Теперь перед нами главное меню приложения.
Следующим действием нам нужно открыть форму «Документы покупателей». Скорее всего, вы уже догадались, что нужно для этого сделать: запускаем рекордер, кликаем по меню «Продажа», а затем по «Документы поставщиков».
Новый документ
Дальше нужно создать новый документ. В 1С нажимаю клавишу Insert. Добавляю это действие в процесс с помощью рекордера или вручную, перетащив из палитры действие «Сочетание клавиш».
Выбор вида документа
1С попросит нас выбрать вид документа. Мне нужен «Счет на оплату покупателю».
Работа с таблицами и списками часто вызывает сложности. Не всегда определяются указатели. Или сложно с помощью простых действий, доступных роботу, построить процесс, требующий анализа таблицы, где много полей, много строк. Универсального способа тут нет, для каждой задачи подбирается свой подход.
Но в данном случае все просто. Можно или записать клик по нужному типу документа или воспользоваться строкой поиска вверху формы или начать набирать название нужного нам документа и 1С выделит его. Затем Enter, и мы готовы к вводу данных счета.
Шапка счета
В шапке счета вводим дату счета, контрагента, договор, склад. Эти значения необходимо передать процессу в качестве входных аргументов, поэтому добавляю нужные переменные в контекст.
1С позволяет просто ввести эти значения в соответствующие поля, открывать формы справочников и выбирать в них не обязательно. Запускаю рекордер и с помощью быстрого меню записываю вставку значений контекстных переменных в нужные поля и перемещение между полями с помощью клавиши Tab
Строка счета
Теперь добавим строки счета. Очевидно, как моделировать работу с отдельной строкой. Но в каждом конкретном счете строк может быть сколько угодно. Нужно предусмотреть возможность передачи процессу произвольного количества строк, которые в свою очередь состоят из нескольких полей, и после этого добавление каждой полученной строки на форму в 1С.
Для передачи коллекции строк я создаю контекстную переменную с типом «Массив». Отдельная строка такой коллекции будет представлять собой текстовую строку с перечислением значений полей.
Чтобы процесс мог работать с отдельными полями строк, воспользуюсь действием «Сценарий». Это действие позволяет включить в логику процесса произвольный программный код на C#. В нашем случае программа будет вызываться в цикле и при каждом следующем выполнении брать следующую строку коллекции, выполнять ее разбор и присваивать значения полей соответствующим переменным. Для выхода из цикла я буду использовать специальную переменную с типом «Да/Нет», значение которой будет изменяться в коде сценария при разборе последней строки.
Чтобы организовать цикл выбираю действие «Повторять, пока…». Он представляет из себя контейнер, куда нужно поместить действия, которые должны повторяться.
Печать, сохранение файла
Процесс почти готов. Используя те же приемы, что я показал выше, добавляю формирование печатной формы счета и сохранение его на диске, сохранение счета в системе и закрытие приложения.
Отправка счета в Контур Диадок
Все базовые приемы моделирования на примере 1С подходят и для моделирования работы в любых других приложениях.
Следующая этап обработки счета – отправка его клиенту через Диадок. Создание счета в 1С и его отправку лучше моделировать как два разных процесса. Это позволит независимо их отлаживать и запускать на разных машинах.
Робот будет взаимодействовать с Диадок через web-интерфейс. Не во всех браузерах рекордеру удается хорошо распознать указатели. Лучше всего они определяются в IE и Firefox.
Для открытия web-страницы Диадок используем команду «Выполнить». В качестве параметра указываю «iexplore diadoc.kontur.ru». Дальше создайте необходимые входные параметры. Дальше используя рекордер моделирую логирование в системе, загрузку файла счета, ввод параметром и отправку. Там, где это возможно, выполняю действия при помощи нажатия клавиш, где нет – использую указатели.
Подытожу
В процессе появились две новые зоны ответственности: Робот и Администратор по роботизации. При выполнении процесса робот может столкнуться с чем-то, что мы не предусматривали при моделировании. Например, 1С выдаст непредвиденную ошибку или в Контур Диадок после обновления изменится интерфейс, и робот не найдет нужных контролов. В этом случае требуется, чтобы специалист, отвечающий за поддержку роботов, проверил, что пошло не так и восстановил работу робота. Описанный мной процесс предусматривает такую ситуацию. Получив статус задания робота «Ошибка», система создаст соответствующую задачу администратору, после его проверки робот запускается повторно.
mixsture
1) вместо запуска конкретной версии 1с, используйте, пожалуйста, стартер. И тогда ваш робот не поломается при каждом обновлении платформы.
2) почему не воспользовались апи oData у 1с? это сразу дает вашей интеграции: гарантированный результат каждого действия, возможность читать и записывать любые данные в базе 1с. Подход RPA на задачах, где уже есть готовое апи — это дорого.
3) управление интерфейсом само по себе очень хрупкое:
а) Может сломаться при смене платформы 1с, но нечасто (иногда 1с меняет внешний вид элементов)
б) если брать «новые» конфигурации от 1с на управляемых формах, то проблем добавляется, т.к. там 1с сдвинулась в сторону адаптивности интерфейса к размеру формы. Поэтому любая кнопка может быть как в видимой части формы, так и прятаться в меню. А в видимой части формы элементы могут менять размер по ширине и взаимоположение (несколько элементов в строку могут разворачиваться в колонку при нехватке места).
в) сам windows может добавить вам проблем, запустив окно в развернутом на полный экран или обычном виде.
seregei-azarov Автор
1) Да, согласен, использовать стартер более правильное решение. Я демонстрировал общий принцип запуска приложения. Со стартером все точно так же, только запускаем другой файл.
2) OData позволяет перенести данные, но возможности по запуску каких-то обработок очень ограничены. В нашем случае робот печатает счет, через OData это скорее всего не реализовать.
3) Все верно. Это основной недостаток RPA. Какие-то изменения в интерфейсе, непредусмотренное поведение программ может сломать работу процесса.
Типичная обработка таких ситуаций: во-первых, автоматический перезапуск процесса. Если, например, ошибка была связана временным зависанием программы или каким-то
неожиданно всплывшим окном, то это решит проблему. Если это не помогло, задача эскалируется специалисту. Робот отправляет сообщение о ошибке по электронной почте,
или специалист узнает о ошибке через интерфейс оркестратора, или как в моем примере, BPM-система ставит задачу специалисту проверить робота.
а) RPA подразумевает быстрое моделирование, поэтому при небольших изменениях интерфейса восстановить работу робота можно также быстро.
б) именно поэтому лучше использовать нажатия клавиш или указатели. В большинстве случаев изменение размеров, взаимного расположения, видимость на экране не повлияют на работу процесса.
в) если это будет мешать работе процесса, то можно после загрузки приложения открыть его на полный экран через соответствующее сочетание клавиш.