rpa роботизация что это
RPA: роботизация процесса регистрации счета. Наиболее полное руководство
Привет! Тема с RPA становится всё более хайповой. Принцип работы программных роботов и отличие RPA от других способов автоматизации освещаются на тематических порталах. Я же решил сосредоточиться на подходах к моделированию RPA-процессов. Для примера выбрал процесс регистрации счета покупателю. Остановился именно на нем, так как этот процесс универсален и актуален для компаний любой отрасли и масштаба.
В итоге процесс обработки счета автоматизируется лишь частично — на каждом из этапов, где работает та или иная система. Но вот на стыках между системами работают люди, причем их действия скучны и монотонны: они просто копируют данные из одной системы и вставляют в другую. Встает вопрос о интеграции систем между собой.
Какие-то системы уже в стандартной конфигурации могут содержать готовый функционал для интеграции. Сложность в том, что он не подойдет, если система, с которой выполняется интеграция, имеет неподдерживаемую версию или очень сильно дописана «под себя».
В этом случае решением может быть реализация собственной интеграции между системами. У этого решения есть недостаток — это дорогой и длительный проект. Иногда такая интеграция может быть невозможна из-за отсутствия API или закрытого исходного кода. Иногда нецелесообразна, например, в случае устаревшей системы, которую не планируется поддерживать в дальнейшем.
Технология RPA лучше всего показывает себя в рутинных задачах, где требуется простой перенос данных через заполнение форм, нажатие клавиш. В таких задачах не должно быть логики, которую нельзя представить в виде системы очень четких правил. Чем проще логика – тем дешевле реализовать такой процесс. Чем чаще он повторяется в бизнес-процессах компании, тем ощутимее будет выгода от его внедрения.
Робот выполняет процесс со скоростью немного превышающей скорость человека. На одном роботе может одновременно выполняться только одна задача. Поэтому, если с помощью автоматизации мы планируем переключить на робота операции, которые сейчас выполняются вручную, то RPA – подходящий вариант, если же данные должны обрабатываться с высокой скоростью – лучше рассмотреть другие способы.
В моем примере, где требуется простой перенос данных между системами и сверхчеловеческая скорость не обязательна, интеграция через RPA — оптимальное решение.
Моделирование процесса в RPA
Конкретный кейс регистрации счета, который я смоделировал, выглядит следующим образом:
Робот берет на себя создание счета в 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С выдаст непредвиденную ошибку или в Контур Диадок после обновления изменится интерфейс, и робот не найдет нужных контролов. В этом случае требуется, чтобы специалист, отвечающий за поддержку роботов, проверил, что пошло не так и восстановил работу робота. Описанный мной процесс предусматривает такую ситуацию. Получив статус задания робота «Ошибка», система создаст соответствующую задачу администратору, после его проверки робот запускается повторно.
Основы RPA: программные роботы и зачем они нужны
Многие наши читатели хорошо знают, что такое RPA, но тем не менее, мы часто встречаем на Хабре вопросы о программных роботах, и поэтому решили подготовить статью об основах роботизированной автоматизации. Те, кто не до конца понимают, что же такое программные роботы, смогут узнать что-то новое, а опытные читатели повторят основы RPA.
Статья написана при поддержке технического эксперта UiPath: Кристины Виролайнен.
Зачем нужен RPA
«. если бы вы были фермером, стали бы вы покупать трактор с позитронным мозгом, жатку, борону, доильный аппарат, автомобиль и так далее — всё с позитронным мозгом? Или приобрели бы обычную технику и одного позитронного робота, который мог бы на ней работать? Причем хочу вас предупредить, что второй вариант в пятьдесят, а то и в сто раз дешевше.»
А. Азимов «Стальные пещеры» 1953 г.
Введем определение: Robotic Process Automation — роботизированная автоматизация бизнес-процессов, такая автоматизация базируется не на классическом подходе с использованием программирования и API систем, а на применении программных роботов, которые работают с пользовательским интерфейсом (GUI) ваших систем. При этом роботы могут работать и с API, если системы его предоставляют.
Применение RPA
Два главных эффекта от внедрения роботизации — RPA обеспечивает бизнесу снижение затрат и повышение эффективности рабочих процессов.
IТ-специалисты полагаются на RPA для развертывания приложений и мониторинга сетевых устройств. RPA является идеальным решением для удаленного управления IТ-инфраструктурой, потому что может находить и устранять проблемы быстрее, чем человек, и делать это в режиме 24/7.
Финансовые и бухгалтерские отделы используют RPA для устранения человеческих ошибок и оптимизации времени ввода данных: обработка списаний, поступлений, выставление счетов — всё это задачи для робота.
В центрах обработки клиентских запросов и в приложениях для обслуживания клиентов роботы могут помогать сотрудникам поддержки, повышая их производительность. Таким образом, человеческие ресурсы могут быть перераспределены для решения более сложных вопросов. Робот найдет информацию о клиенте сразу во всех системах и представит сотруднику поддержки полную информацию с историей его обслуживания. Таким образом сотрудник контакт-центра тратит свои ресурсы на помощь клиенту, а не на работу с бизнес-приложениями и поиск информации.
Отделы кадров полагаются на роботов в оформлении сотрудников, отпусков, больничных, переводов и увольнений. Например, обработка запросов от сотрудников с помощью RPA позволяет автоматически формировать и предоставлять необходимые справки и документы. Роботы могут проводить поиск и обработку резюме и откликов кандидатов — список задач не ограничен.
RPA обеспечивает интеграцию корпоративных приложений, упрощая рабочий процесс для отделов продаж. Благодаря автоматизированной роботизации отделы продаж сокращают циклы продаж и повышают показатели конверсии.
Аутсорсеры бизнес-процессов (BPO) могут легко использовать RPA для оптимизации управления клиентскими операциями.
Роботы способны быстро взять на себя возросшую нагрузку. Например, во время пандемии в рамках господдержки были введены льготные кредиты для предприятий малого и среднего бизнеса. Это привело к большому потоку заявок на такой кредит. Один банк, решая проблему возросшей нагрузки на персонал, за 3 недели роботизировал процесс обработки и проверки заявок на льготный кредит. Это позволило принимать большее число заявок и помогло многим предприятиям: в день робот обрабатывал от 500 до 1500 заявок, а средняя скорость работы с одной заявкой увеличилась в 5 раз. Банку удалось снять рутинную нагрузку с 3000 своих сотрудников, что позволило им работать в штатном режиме.
RPA — роботы, которые не видны
В течение многих лет роботы играли важную роль в производстве. Под роботами обычно привыкли понимать устройства, выполняющие полезную работу без участия человека. Все мы хорошо представляем себе завод и роботов, которые насыпают продукт, упаковывают, наклеивают этикетки, и делают массу другой полезной работы. Но существуют и программные роботы — эти программы способны производить вычисления и автономно решать поставленные им задачи.
По сути программные роботы имитируют действия человека: они могут видеть элементы открытых приложений; понимать, где находятся кнопки, поля для ввода, текст, таблицы и другие интерактивные элементы интерфейса. Роботы «знают», что им нужно сделать — нажать на кнопку, ввести данные, и делают это. Главная сила программных роботов — их способность взаимодействовать с пользовательским интерфейсом. Это дает возможность автоматизировать длинные сквозные процессы, в которых задействовано множество систем. При этом мы не привязываемся к наличию API у систем: могут быть роботизированы как стандартные офисные приложения, так и сложные ERP-системы, и даже самописные или legacy-приложения, классическая интеграция с которыми невозможна. В общем, любые системы и приложения, с которыми может работать человек, могут быть автоматизированы с использованием роботов.
Робота можно представить, как умного стажера: вы даете ему задачу скопировать данные из файла Excel и занести их все в 1С, или наоборот. С этой задачей идеально справится робот, но, конечно, он умеет не только копировать и переносить данные. Робот также может проводить простую аналитику, а с помощью ИИ — обрабатывать данные по сложным алгоритмам. Классическими примерами использования роботов являются финансовые процессы: проведение сверок с контрагентами, расчет заработной платы, обработка больничных листов и др.
Чтобы не запутаться в терминологии, добавим: робот — программа, которая выполняет роботизированные процессы. Один робот может выполнять и процессы для бухгалтерии, и процессы для кадров. Вы можете роботизировать несколько процессов, имея всего одну лицензию робота.
Преимущества роботизации в компании
Благодаря RPA можно по-новому взглянуть на бизнес-процессы. Эта технология позволяет автоматизировать множество корпоративных функций: от бэк-офиса до удаленной IТ-инфраструктуры. Вот основные преимущества роботизации:
Сотрудники могут сосредоточиться на более интеллектуальной работе, а не на повторяющихся рутинных задачах. Избавившись от необходимости выполнять повторяющиеся механические задачи, у людей появляется время максимально использовать свой потенциал, они вдохновляются решением сложных нетривиальных задач. Производительность труда в таком коллективе возрастает.
Роботы не ошибаются — возможность ошибки полностью исключена. Человек может некорректно вводить текстовые и цифровые данные, робот же всегда действует по указанной инструкции и никогда не опечатывается.
Робот — цифровой сотрудник, который справится с работой, которую можно делать по инструкции. Он отлично выполняет такие операции, как:
Копировать и распознавать текст.
Вставлять скопированный текст в другие системы и формы.
Выполнять действия в приложениях.
Работать со сканами документов. Роботы могут использовать сторонние движки для распознавания текста, чтобы потом работать с текстом.
Работать с базами данных и госсистемами.
Отправлять сообщения в мессенджерах.
Выполнять другие простые и рутинные операции.
RPA значительно сокращает время, необходимое для выполнения широкого спектра бизнес-процессов, включая обработку поступлений, обслуживание клиентов и любые другие процессы, требующие доступа к нескольким существующим IТ-системам. Производительность предприятия возрастает по мере сокращения времени рабочего цикла и транзакций.
Бизнес-аналитика более надежна и легкодоступна. Каждая транзакция, совершенная с помощью RPA, записывается в журнал. С помощью этих данных можно всесторонне анализировать любые завершенные процессы.
Если необходимо, робот может спрашивать у человека помощи и ждать его ответа.
Выполняет операции в 10-20 раз быстрее человека.
Не ошибается и работает 24/7.
Помогает бизнесу расти без увеличения персонала.
Какие есть альтернативы?
У роботизации есть два основных конкурента:
Ничего не менять и работать по-старому.
Использовать классическую автоматизацию бизнес-процессов.
У каждого из путей есть свои плюсы и минусы. Программные роботы — не панацея: если процесс имеет большое число ветвлений и исключений, или часто требуется принятие интеллектуальных решений человеком — лучшим вариантом будет оставить этот процесс на ручном исполнении.
Классическая автоматизация может выигрывать тогда, когда требуется автоматизация работы в одной системе. Например, в статье «Лайфхаки для роботизации 1С» мы отмечаем, что при необходимости автоматизации работы в 1С и, уже имея компетенции разработки в этой системе, дешевле будет провести автоматизацию классическим способом.
Однако, когда в процессе задействовано более одной системы, роботизация значительно обходит по эффективности классическую автоматизацию.
RPA-решения имеют целый ряд преимуществ по сравнению с сервисами для классической автоматизации бизнес-процессов. В первую очередь это:
Простота реализации: роботизация одного процесса занимает 2 месяца, а если роботизация поставлена на поток — то этот процесс можно сократить до двух недель. Выше мы привели пример робота, разработанного за 3 недели, и в этом же банке есть робот, разработанный за рекордных 3 дня.
Быстрый эффект — 6 месяцев до возврата инвестиций, ROI.
Роботы требуют минимум изменений в действующих IТ-системах, поскольку в этом случае работа происхолит с пользовательским интерфейсом.
Выводы
Программные роботы — эффективный инструмент по оптимизации бизнес-процессов. По сравнению с классической разработкой RPA-системы проще разворачиваются, быстрее окупаются и требуют минимальных изменений в существующих IT-системах. Параллельная автоматизация нескольких процессов с помощью одного робота позволяет повышать экономическую выгоду каждой лицензии. Сегодня программные роботы всё больше завоевывают рынок и становятся движущей силой цифровой трансформации компаний.
RPA | Роботизация процессов глазами аналитика
Последние полтора года я занимаюсь внедрением и развитием в компании блока RPA на одной из популярных платформ.
Четкого проекта внедрения не было: руководство подсмотрело у дружественных организаций «модную» технологию, дало мне задачу прощупать тему и бросило подразделениям клич по сбору заявок на автоматизацию.
Эта публикация зародилась как план выступления перед коллегами, заинтересованными во внедрении роботизации и знакомыми лишь с рекламными материалами. Признаюсь, что при переносе этих мыслей на публичный ресурс мне было сложно определиться с целевой аудиторией и вырезать только подходящий ей фрагмент. Бизнес-заказчикам, менеджерам проектов и просто интересующимся она должна дать упорядоченное представление о технологии и общих подходах. В остальном это личные впечатления человека, который любит решать процессные задачи и недостаточно усидчив для того, чтобы быть программистом. Технические детали намеренно опущены – разработчикам я здесь ничего интересного не расскажу.
Что такое робот и что он умеет
С точки зрения участия в бизнес-процессах компании робот – это виртуальный сотрудник-оператор. Вот как живой, только:
Уже читали это в презентациях? Ну ок, это правда.
Он оперирует формальной логикой:
Более сложный пример: Сценарий обработки входящих сообщений, в котором для двух типов сообщений реализованы разные алгоритмы обработки. Определение типа сообщения было реализовано по стабильно повторяющейся теме одного из типов. При очередном обновлении сервиса тема изменилась. Робот успешно выполнял сценарий без сбоев, но выбирал при этом неправильную с точки зрения бизнеса обработку.
Важный вывод из этого пункта: в изменяющихся условиях формально успешное выполнение сценария не гарантирует корректный бизнес-результат! Этот результат необходимо своевременно контролировать – хорошо, если это происходит естественным образом при его обработке на последующих этапах процесса.
У сотрудника-оператора есть старший сотрудник или начальник, к которому можно обратиться при возникновении непредвиденных ситуаций. Для робота тоже должны быть такие кураторы по каждому процессу.
Сотрудник работает на своем ПК или в терминальной сессии, каждый робот также работает в своем собственном окружении. Если бы и можно было запустить в одной сессии несколько роботов, это привело бы к печальным последствиям: попробуйте с коллегой подключить к одному компьютеру две клавиатуры и набирать каждый свой текст.
С точки зрения автоматизируемых приложений робот – это обычный пользователь, который нажимает на кнопки, вводит и считывает данные. Если приложение лицензируется по количеству одновременных подключений – робот займет лицензию при работе в нем.
Помимо взаимодействия с экранными формами приложений, роботы на используемой мной платформе умеют:
Существует и альтернативная форма использования – виртуальный помощник: робот запущен в окружении реального пользователя, который при необходимости запускает тот или иной сценарий, или робот сам реагирует на наступление предусмотренного события. Напоминает использование макросов, только для разработки подобных сценариев не требуются специальные навыки (зато требуются лицензии RPA).
Задачи, которые решает робот
Что роботизировать
Итак, мы используем виртуального сотрудника, чтобы он выполнял формализованные сценарии.
С точки зрения эффекта от роботизации приоритет должен быть за несложными, но продолжительными и часто повторяющимися процессами. Тут все просто:
У меня уже год в очереди висит задача, выполнение которой сэкономит одному сотруднику один раз в месяц по часу времени. Я к ней приступлю тогда, когда закончатся задачи с более ощутимым эффектом.
Точки входа и выхода для робота должны быть плавно встроены в общий процесс, чтобы не нужно было прилагать значительных усилий для передачи задания роботу или сбору результатов его работы.
Помимо высвобождения человеко-часов есть и менее очевидный фактор – цена ошибки. В хорошо формализованном процессе вероятность незамеченной ошибки у робота ниже, чем у человека.
В предыдущем разделе я упоминал про возможность некорректного с точки зрения бизнеса результата – обратите внимание на приведенные формулировки и оцените условия выполнения интересующего сценария. Также отлично показывает себя практика, когда робот перепроверяет результат работы человека по заданным правилам и передает на ручной разбор выявленные проблемы.
Плохо подходят под роботизацию процессы:
Но часто и здесь есть выход – комбинировать роботизацию с ручным принятием решений:
Не стоит запускать роботизацию и там, где она попросту не нужна, или заказчик пытается в своем представлении подменить роботом доработку конкретного приложения.
Пример 1:
– Мне нужно, чтобы робот отслеживал получение новых писем на общий почтовый ящик и при поступлении новых пересылал их по списку рассылки.
– Попросите администраторов настроить переадресацию на почтовом сервере.
Пример 2:
– Мы каждое утро печатаем огромное количество документов. Можно сделать так, чтобы мы пришли утром, а робот уже все напечатал, мы подпишем и отправим?
– Технически это возможно, но есть несколько вопросов: Кто будет контролировать ночью наличие бумаги, краски и качество печати? Удобно будет потом фасовать напечатанное по стопкам и подписывать? Удобно будет контролировать и отмечать, что подписали и отправили? С учетом всего этого, много времени сэкономит такая автоматизация?
–…
Тем не менее, использование роботов – отличный выход, если выполнение необходимых операций возможно, а автоматизация средствами самой системы потребует значительных временных и финансовых ресурсов.
Несколько примеров направлений, подходящих под роботизацию:
Управление рисками
Поговорим о том, что может пойти не так:
| Риск | Комментарий | Как управлять |
|---|---|---|
| Ошибки логики сценария | Ошибка разработчика. Ошибаются все – вопрос в том, насколько грубо и насколько сложно исправить ситуацию. | Хорошая читаемость сценария уменьшает вероятность появления ошибок и упрощает их поиск и исправление. По возможности должно быть предусмотрено рецензирование сценариев. Разработчик и заказчик в первое время после внедрения или доработки сценария наблюдают за результатами запусков. |
| Ошибки постановки задачи | Во многих случаях на этапе сбора требований описывают только самый простой вариант развития событий. Даже после наводящих вопросов не вспоминают все ситуации, когда что-то идет не по плану, и не упоминают необязательные диалоговые окна и уведомления, которые может выдавать приложение. Это нормально. Мы потому и роботизируем эти операции, что они механические и при их выполнении исполнитель часто действует неосознанно. | По возможности привлекать экспертов к постановке задач. Разработчику придется уточнять последовательность действий когда неописанная ситуация возникнет при разработке или уже в эксплуатации сценария. |
| Сбой платформы RPA | Проблемы непосредственно с функционалом роботов: закончился срок действия лицензий, зависло приложение робота, сбой на стороне модуля управления запуском роботов. | Необходимы наблюдение и контроль. |
| Сбой окружения | Что-то в окружении робота мешает выполнить сценарий. Например: * cистемные уведомления, которые блокируют доступ к формам приложений: уведомления об обновлениях windows, отчеты об ошибках, уведомления службы предотвращения выполнения и т.п. * нет свободной оперативной памяти * переполнен диск. | Все системные уведомления для робота необходимо отключить. За оперативной памятью и диском необходимо наблюдение. |
| Сбой инфраструктуры | Недоступны связанные с выполнением сценария внутренние сервисы. Например, робот не может отправить уведомление из-за сбоя почтового сервера или выложить файл на сетевой диск из-за проблем в дата-центре. | Это аварии в масштабах компании, которые устраняет IT. |
| Сбой целевого сервиса | Недоступны целевые для сценария сайты или приложения. | Необходимо обращаться к администраторам и службам поддержки соответствующих ресурсов. |
| Обновление автоматизируемого сайта/приложения | При работе с внешними системами это самая острая проблема RPA. Хорошо, если есть тестовая среда и регламентирован порядок обновления. Но это часто не так даже с системами, используемыми внутри компании, не говоря уже про внешние. Просто в один прекрасный момент они начинают вести себя по-другому в части, критичной для сценария. И тут два варианта: 1) при выполнении сценария происходит сбой: робот не находит нужное окно, кнопку, поле в таблице и т.п. 2) Сбоя не происходит, но результат становится некорректным. | В первом случае все просто: разработчик получает уведомление о возникшем сбое, при анализе понимает, что произошло обновление, и выполняет доработку сценария. Иногда требуется незначительная правка, иногда изменение логики сценария. Это будни. Во втором случае помогут своевременный контроль результата и фантазия разработчика, предусматривающего лишние проверки «на всякий случай». |
| Некорректные бизнес-настройки | Без предупреждения изменены или не актуализированы нетехнические настройки, за которые отвечает бизнес. Например, бизнес-пользователи по каким-то причинам производят замену сертификата, используемого в сценарии обмена сообщениями, робот продолжает использовать старый – возникает сбой. | Всегда должен быть куратор от бизнеса, который следит за актуальными настройками и своевременно оповещает о внесении изменений. |
| Потеря компетенции у бизнес-пользователей | После роботизации процесса у бывших исполнителей появляется соблазн полностью отстраниться от участия в процессе, в том числе в разборе сложных ситуаций и ручном исполнении в случае сбоя. А в случае замены сотрудников может возникнуть ситуация, когда уже никто со стороны бизнеса не знает, как выполнить нужные операции. | Это снова про куратора процесса. Также должен быть определен план действий (или смирение с потерями) в аварийном случае, когда сбой роботизации невозможно оперативно устранить. В некоторых случаях стоит оформить и сохранить инструкции по выполнению операций. |
| Безопасность | Робот со временем обрастает связкой «ключей от всех дверей». Взлом сервера скомпрометирует все учетные данные, которые там хранятся. | С осторожностью назначать права доступа. При необходимости изолировать окружение робота от корпоративных ресурсов. Хранить используемые в сценариях пароли только в зашифрованном виде. И вообще, специалисты ИБ могут давать отличные советы, когда не заняты затягиванием согласований. Кстати, некоторые из платформ RPA прошли сертификацию на соответствие стандартам ИБ. |
Всё это либо общие для IT риски, либо следствия неопределенности при работе с неподконтрольными сервисами и приложениями. При «классической автоматизации» работы с внешними веб-сервисами точно так же возникнет сбой при неожиданном изменении последних.
Идеальный пример с точки зрения управления рисками: RPA внедряется в компании с единственной целью – «загнать» десятки роботов в SAP конкретную информационную систему. Экономический эффект просчитан, разработкой сценариев занимаются опытные специалисты, сформулированы детальные ТЗ с привлечением экспертов, все взаимодействие регламентировано, среды контролируются, отлажен порядок тестирования.
Но это лишь один из вариантов использования роботов.
О постановке задач
Условно можно выделить два подхода к постановке задач:
| «Сверху» | «Снизу» |
|---|---|
| Задачу ставит подразделение или лицо, которое управляет бизнес-процессом | Задачу ставит конечный исполнитель операции или его непосредственный руководитель |
| Заказчик видит весь процесс и может явно выделить этапы, где необходимо вмешательство ответственных сотрудников, а где механическая работа, которую стоит отдать роботу | Заказчик видит свою ежедневную деятельность и стремится избавиться от рутинной работы |
| Заказчик может оценить трудозатраты, эффект от роботизации, критичные сроки и точки соприкосновения этапов | Заказчик оперирует понятиями «долго» и «неудобно», точки входа и выхода робота могут быть выбраны нерационально, задачи разных заказчиков могут пересекаться и даже противоречить друг другу |
| На выходе получается роботизированный бизнес-процесс | На выходе получается роботизированная операция |
Первый подход дает более понятный эффект для организации, но требует наличия культуры управления проектами и бизнес-процессами.
При втором подходе нужно более внимательно анализировать запросы заказчиков на целесообразность и непротиворечивость. Но он не так уж и плох, не отменяет положительный, хоть и неопределенный, эффект от внедрения, а из реализованных порознь операций тоже можно впоследствии собрать цельный процесс.
Исходя из обозначенных ранее рисков, при постановке задачи необходимо:
О сроках
Срок разработки и запуска в эксплуатацию сценария не может быть постоянной величиной, он зависит от:
В простом случае со сценарием проверки новостей на сайте можно управиться за пару часов разработки. Самые сложные задачи, которые у меня были, требовали до 2 недель разработки. В качестве «сферической» средней величины можно взять 1-3 дня чистого времени.
Очень часто в процессе разработки сценария выявляются неописанные постановкой ситуации, постановка расширяется, что также влияет на срок запуска.
Есть еще и непрогнозируемые факторы простоя:
Замечу, что RPA хорошо вписывается в гибкие подходы.
Часто можно уже через несколько часов разработки показать заказчику прототип сценария с хотя бы частично реализованной бизнес-логикой, на этом этапе могут быть выявлены дополнительные требования, о которых не вспомнили при постановке задачи. Разумеется, на этом разработка не заканчивается – предстоит проработка деталей и работа над отказоустойчивостью. Последним можно пренебречь разве что в «одноразовых» сценариях, что позволяет очень оперативно прийти на помощь бизнесу.
А иногда заказчики заинтересованы в поэтапном внедрении с оценкой промежуточных результатов.
Архитектура
Минимально необходимых компонента всего два:
Робот, который выполняет один из доступных сценариев по команде
Робот должен быть запущен в интерфейсной сессии, иначе он не сможет взаимодействовать с экранными формами приложений. Есть несколько вариантов в каком окружении запускать робота, это может быть:
Или в этом окружении должны быть установлены и настроены приложения, которые использует робот при выполнении сценариев, или робот может использовать RDP/Citrix подключение к удаленному серверу с необходимыми приложениями.
В такой конфигурации уже можно запускать сценарии вручную, в определенных случаях этого будет достаточно. Напомню, что в этом случае робот может «общаться» с пользователем с помощью диалоговых окон.
В предлагаемый вендорами комплект также входит компонент управления запуском сценариев. Помимо собственно запуска он может:
У меня же управление реализовано на стороне SQL сервера.
Связка RPA с другими сервисами позволяет существенно расширить возможности роботизации:
Выбор платформы
О знакомстве с функционалом
Вендоров RPA несколько десятков. При первичной выборке я обращал внимание прежде всего на наличие открытой документации и пробного периода – и это исключило почти всех.
Как можно получить представление о конкретном решении:
О стоимости
Несмотря на ажиотаж вокруг технологии роботизации, стоимость внедрения и эксплуатации не обязательно высока.
Существуют даже бесплатные версии платформ RPA, имеющие некоторые ограничения (не обязательно функциональные). Отдельные возможности можно реализовать и на решениях, не относящихся к миру RPA: средства автоматизации управления web-браузером, макросы, сценарные языки, системы автоматизации тестирования и т.д.
В качестве примера крайности: в организации малого бизнеса используется бесплатная платформа RPA, разработкой несложных сценариев занимается штатный IT-специалист. Бизнес несет расходы только на инфраструктуру.
Другая крайность: использование десятков и сотен роботов в условиях высокой нагрузки, большие команды разработки из сертифицированных разработчиков. И на лицензии, и на ФОТ порядок затрат будет в десятках миллионов рублей в год. Становятся заметными расходы на инфраструктуру.
Посередине между ними варианты с покупкой минимально необходимого набора лицензий на коммерческие версии платформ с использованием штатного модуля управления запуском (порядок затрат на лицензии в миллионах рублей в год), так и без него (от нескольких сот тысяч рублей в год).
Есть разные варианты привязки лицензии на робота и Студию, но общий подход такой: «один одновременно запущенный экземпляр = одна лицензия».
Чего не хватает в используемой платформе RPA
Платформы RPA регулярно обновляются и приобретают новые возможности.
Но вендоры так сконцентрированы на добавлении функционала, что часто не обращают внимания на удобство использования при разработке сценариев.
Кстати, баги с этими обновлениями тоже появляются.
Все мои пожелания сводятся к процессу разработки сценариев:
По моему мнению, идеологически неправильно представлять операции с экранными формами приложений и сайтов в виде простой последовательности действий. Это выглядит лаконично и легко для восприятия, но не способствует грамотному подходу к отказоустойчивости.
Простой пример: робот нажал на кнопку (а точнее попытался нажать) и 5 минут ждет появления сообщения «ОК». Если сообщение появилось – хорошо, если нет – возникает сбой. А если приложение «вылетело» через 10 секунд после нажатия кнопки? А если через две минуты возникло сообщение об ошибке? Робот все равно будет ждать 5 минут, не сможет выполнить второе действие – чтение сообщения, и только тогда выведет сбой.
Я использую собственные шаблоны и библиотеки, в которых это учтено, но от их использования в сценарии страдает читаемость, гораздо удобнее и нагляднее был бы встроенный контейнер по примеру тест-кейса:
| Что сделать | Что должно произойти | Чего точно не должно произойти |
|---|---|---|
| Нажать кнопку | Появилось сообщение «ОК» | Не должно появиться сообщение об ошибке Приложение не должно пропасть из списка запущенных процессов |
У меня еще есть опция периодически повторять инициирующее действие (а если приложение просто не среагировало на нажатие кнопки?).
Здесь смысл не столько в том, что неудобно и плохо читается, а в том, что это должен быть стандарт работы с экранными формами.
Не хватает многопоточности в рамках сценария.
Даже имеющийся контейнер параллельной работы всего лишь выполняет действия из потоков поочередно, ожидание одного потока тормозит другой.
Хотелось бы иметь возможность в дополнение к основному процессу, например:
Как развитие предыдущего пункта – автоматический выбор настроек мне только мешает, приходится специально каждый раз переоткрывать формы настроек, проверять, перевыбирать, исправлять. Это касается:
Явное указание этих настроек при инициации вместо присвоения значений «по умолчанию» было бы гораздо лучше.
Требования к разработчикам сценариев
Подходы к разработке
Любой сценарий и состоит из действий (Activity). Они выполняют полезные операции: кликнуть мышкой, присвоить переменной значение, объединить файлы pdf в один и т.п. В их свойствах разработчик сценария уточняет, как именно нужно выполнить действие.
Вендоры платформ предлагают большой набор готовых действий, что позволяет «программировать квадратиками» без навыков разработки.
Существуют даже специальные версии Студии, ориентированные на бизнес-пользователей и предельно упрощающей процесс разработки сценариев и скрывающие «лишние» настройки. Впрочем, создать в них получится только простые линейные сценарии.
Некоторые платформы RPA предоставляют возможность использовать только заранее предусмотренные вендором действия.
Некоторые – предусматривают возможность расширения за счет:
Обучение
Технология RPA легка в освоении, общий принцип работы в большинстве случаев интуитивно понятен.
Хорошо, если вендор поддерживает портал с актуальной документацией и форум, где можно найти ответы на многие вопросы.
Для некоторых платформ также есть специальные порталы с обучающими курсами и возможностью получения сертификатов. Там клиенты могут самостоятельно обучать своих сотрудников… вырвав их из рабочего процесса на несколько недель.
Ключевые навыки
Каким же должен быть разработчик сценариев RPA? Не обязательно опытным программистом, это мы уже выяснили.
Работа с заказчиками, обследование процессов, поиск обходных решений, предложение лучшего варианта реализации, анализ возможных точек сбоя, разработка алгоритмов как в части сценария, так и в части формализации бизнес-процесса – для этого нужно быть прежде всего аналитиком. Подход «просто делать что сказали» здесь работает плохо.
Ну что ж, я не все понимаю в этой жизни.
Если сузить вопрос до перечисления навыков и технологий, то это прежде всего:
Следующие навыки менее важны, требуются не всегда и/или придут с опытом:
На старте внедрения о последних трех пунктах я имел лишь приблизительное представление.
Уверенные навыки работы с данными и алгоритмами мне дала работа аналитиком в целом и с базами данных в частности.
Заключение
Я выделяю 3 ключевые особенности технологии RPA, которые отличают роботизацию от «классической» автоматизации и других решений создания сценариев:
Благодаря этому у роботизации широкие возможности применения для бизнеса разных масштабов.
RPA не только дает инструменты решения прикладных задач, но и настраивает на работу прежде всего с процессами, не ограничиваясь автоматизацией конкретных информационных систем. Роботизация способствует постановке правильных вопросов и даже может помочь на пути формализации бизнес-процессов.
Мне же, как аналитику: