Роботизация процессов

Современные компании активно используют process mining для поиска узких мест в своих бизнес-процессах. У многих из них сформировано понимание ценности этой технологии ее используют для поиска инсайтов в больших массивах информации. Такая аналитика очень актуальна для предприятий, начинающих роботизировать свои процессы. Process mining помогает выявить узкие места автоматизации и связать существующие разрозненные IT-системы в единое целое.

Оптимизация автоматизации

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

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

Однако, отсюда же вытекает и основная сложность внедрения process mining с его помощью можно легко получить инсайты, но самые первые результаты и рекомендации выглядят очевидными, понятными и без привлечения ИИ. Например, process mining может показать точку в процессе, в которой документ долгое время ожидает ввода дополнительных данных от сотрудника. Такое узкое место может быть просто устранено роботом, который автоматически дополнит документ необходимыми данными. Подобная рекомендация может показаться простой и очевидной. Поэтому для неспециалистов ценность внедрения process mining сильно снижается, а инициаторам роботизации приходится постепенно идти от явных инсайтов к скрытым, постепенно раскрывая ценность использования process mining.

Первые шаги: тестирование и выбор платформы

Для тестирования работы и возможностей process mining лучше выбирать небольшие проекты. При выборе платформы для process mining важно учесть ряд критических факторов: гибкость системы, функциональность, возможность простой интеграции с разными системами и стоимость лицензий. Одним из интересных решений является UiPath Process Mining, в котором есть встроенный модуль ETL, для компаний, только начинающих внедрение process mining, это большое преимущество. Его наличие внутри решения сильно облегчает развертывание в IT-системах.

Внедрение process mining всегда сопряжено с проблемой подготовки данных, которую обычно решают созданием специального пула подготовленных данных, для которых нужен выделенный data-сервер. Это дорогое удовольствие. PM дает возможность избежать этого, выгружая данные на собственные сервера, что позволяет не тратить финансы на поддержание работы внешних серверов и зарплаты обслуживающему персоналу.

Трудности перевода

При внедрении process mining в работу компании обычно бывает две основных сложности. Первая большие объемы данных, которые нужно анализировать. Вторая долгая автоматизация и наличие большого количества legacy-систем. Обе эти проблемы приводят к тому, что данных внутри компании много, но их невозможно анализировать, потому что они находятся в несвязанных друг с другом системах или представлены большим набором менеджерских дашбордов.

Кроме того сами процессы в компании могут быть устроены очень сложно, хотя

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

Усложнять ситуацию может и большая длительность процессов. Например, долгая переписка сотрудников, ищущих потерянную платежку. С помощью process mining можно связывать родственные процессы в один, упрощая таким образом работу с ними. Также можно точно определить кто и что делал, и иметь перед глазами визуализированную цепочку действий всех участников.

Process mining помогает в десятки раз ускорить восстановление процессов и делать это всего в несколько кликов, в отличие от ручного режима. С process mining поиск узких мест и выявление отклонений в процессах происходит практически в автоматическом режиме. Появляется объективность и достоверность, когда данные говорят сами за себя. Отпадает потребность в интервью с пользователями процесса. Аналитика появляется как на самом общем уровне, так и на уровне максимальной детализации по каждому сотруднику:

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

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

По данным исследования Deloitte 36% руководителей считает фрагментарные процессы главнейшим барьером для масштабирования автоматизации. Вендоры стараются сделать максимально простым и бесшовным процесс взаимодействия человека с RPA-системами, выстраивая оптимальную архитектуру своих решений. Таким образом можно значительно упростить автоматизацию длительных процессов, требующих участия человека.

В статье мы расскажем:

- как можно организовать работу с большим количеством документов,

- как в эту работу вовлечь бизнес-пользователей, когда это необходимо,

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

Начнем с реального примера.

Кейс страховой компании: как с помощью RPA достигнуть эффективности в 122 ПШЕ

Крупная страховая компания России обрабатывает более 24 тыс. договоров в день. Для этих целей в компании был создан операционный центр, который принимает договора от агентов и заносит данные договоров в базу. Роботизация в компании началась как оптимизация работы центра. Компания планировала перенести на операционный центр дополнительные функции, не увеличивая при этом численность персонала. Для этого была поставлена задача автоматизации текущих задач центра. Для успеха проекта достаточно было автоматизировать 100 ПШЕ (полных штатных единиц), этих ресурсов хватало на выполнение дополнительных функций.

Проект по роботизации начался в компании в 2017 году и за это время удалось всего на трех процессах (один из которых обработка поступающих договоров страхования) достичь эффективности в 122 ПШЕ. Роботы помогают сотрудникам центра обрабатывать гораздо больший объем документов, снизив вероятность ошибок до минимума. Сегодня в компании полностью автоматизированы обработка и учет договоров страхования, а также процесс по поиску убытков.

IТ-архитектура этого решения- оркестратор, база данных, виртуальная машина-робот- все это развернуто на отдельном сервере и работает с несколькими системами: полисной, системой сканирования, бухгалтерской системой, системой урегулирования убытков, а также с системами источниками данных (работа с файлами).

Обработка одного договора человеком занимала 5 минут, у робота это занимает чуть больше 1 минуты.

Роботы работают на 80% быстрее человека, а 70% всех задач они выполняют без его участия. Окупаемость роботизации всех трех процессов составила 8 месяцев.

Что под капотом: техническая реализация оркестровки

Кейс, приведенный выше, является примером автоматизации фрагментированных процессов, то есть процессов, которые разделены на этапы и требуют участия человека между этими этапами. Для описания таких процессов также используется термин human-in-the-loop. Автоматизация фрагментированных процессов достаточно новая функциональность для RPA-систем. В решениях UiPath она стала доступна с появлением Action Center. Робот, столкнувшийся с каким-либо бизнес-исключением или ошибкой, может создать задачу пользователю и отправиться выполнять другие задачи. После того, как человек даст свой ответ, первый свободный робот продолжит выполнять процесс. Рассмотрим упрощенный пример того, как автоматизация таких процессов может быть реализована. Мы создали простой процесс приема и обработки страхового договора. Документ поступает на вход, сотрудник извлекает из него данные и принимает решение, требует ли этот договор согласования. Если договор удовлетворяет формальным требованиям, он заносится в учетную систему. Этот пример является довольно простым для роботизации, сложности возникают, когда приходится обрабатывать большое количество таких договоров.

Мы предлагаем решать задачу обработки большого количества документов в процессах human-in-the-loopс помощью процесса оркестровки, который проверяет что именно происходит с интересующими нас объектами. Изобразим наш пример на схеме, процесс состоит из четырех этапов:

Робот, исполняющий процесс оркестровки получает договоры и параллельно отправляет их в очередь на обработку. После того, как все элементы отправлены, процесс встает на паузу, а робот освобождается. Очереди являются реализацией Message Queue и подробнее о них мы расскажем в следующих постах.

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

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

Процесс оркестровки постоянно следит, что происходит с элементами нашей очереди, и как только какой-нибудь из них обогащается данными, процесс проверяет требует ли этот договор согласования (в нашем простом примере мы отправляем на согласование договора, у которых высокая сумма выплат). Если нам нужно согласование, процесс создает задачу человеку в Action Center, если согласование не требуется, процесс создает задачу роботу на ввод данных в учетную систему.

Таким образом процесс оркестровки полностью берёт на себя управление обработкой: заносит элементы в очередь, раздает задачи роботам и людям, следит за статусом их исполнения.

Список задач для роботов выглядит следующим образом:

В нашем случае работают 2 робота, они берут задачи из списка на выполнение. На скриншоте нижний процесс InsContract_Main и есть наш процесс оркестровки. Он стоит на паузе, ожидая, пока какой-нибудь из элементов очереди обновится. На вход поступили 10 документов, соответственно добавилось 10 элементов в очередь, и на каждый элемент инициировался свой процесс InsContract_DU - распознавание и извлечение данных. Как мы видим, 4 таких процесса уже успешно завершилось, два документа из четырех не требуют согласования, и поэтому процесс оркестровки создал две задачи InsContract_EnterApprovedContract - процесс заведения договора в учетную систему, мы видим их первыми на экране.

Перейдем к задачам для людей, их мы можем увидеть в Action Center. На скриншоте отображен список задач и открыта задача типа Согласование договора.

Форма, которую вы видите на экране, создана с помощью low-code. Таким образом, задачи могут иметь любое представление. Для данного примера мы создали форму в которой виден сам документ, и слева от него отображаются нужные нам данные.

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

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

Пример отчета:

Как это было разработано?

Для реализации этого примера мы использовали активности из блока Long Running, они созданы специально для работы с фрагментированными процессами:

При отправке элемента в очередь мы использовали активности Add Queue Item And Get Reference/Wait For Queue Item And Resume.

При добавлении элемента в очередь автоматически запускается процесс обработки: для этого мы использовали триггеры на очередь - функциональность оркестратора.

Для создания задач по вводу данных в учетную систему - Start Job And Get Reference/Wait for Job and Resume.

Для создания задачи для человека в Action Center Create Form Task/Wait For Form Task and Resume.

Для параллельной обработки всех документов активность Parallel For Each.

Часть процесса оркестрации выглядит следующим образом

Итоги

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

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов (в этой публикации)

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Личные кабинеты, чат-боты и dream team

Роботизация бизнес-процессов на примере закупок (2 кейса)

Роботизация бизнес-процесса- это когда все или часть задач конкретного бизнес-процесса выполняют не сотрудники, а система. Таким образом, у сотрудников высвобождается время на выполнение других задач или участие сотрудников исключается полностью (в идеале).

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

Кейс #1: Роботизация процесса проверки поставщиков

На нашем заводе юридическая проверка поставщиков это обязательная процедура перед заключением договора поставки. В зависимости от категории поставщика и суммы закупки, каждый контрагент (ИП или юр. лицо) должен предоставить от 10 до 20 сканов документов.

ВАЖНО!Чтобы не только правильно выполнялась процедура проверки, но вовремя запрашивалась и поступала информация от поставщиков, вовремя выполнялись и передавались задачи между всем участниками процесса проверки, включая поставщиков.

Для роботизации процесса проверки поставщиков в ERP мы связали в одну систему следующие компоненты:

• ERP-система (рабочее место сотрудников).

• Сайт компании (интеграция с ERP и сервисом DaData.ru).

• Почта Gmail (интеграция с ERP и сайтом).

• Сервис DaData.ru (интеграция с сайтом и ERP).

• Сервис 1С:Контрагент (интеграция с ERP).

На сайте компании разработана форма для самостоятельного заполнения контрагентом.

Для простоты заполнения к форме сайта подключен сервис DaData.ru - это и заполнение поле из общедоступных справочников и автоматическое заполнение связанных полей.

1, 2, 3, 4 - Заполнение по справочникам из сервиса DaData.ru

5 - Список компетенций поставщиков и подрядчиков из ERP

Все формы на сайте адаптивные, можно легко заполнить на смартфоне.

Адаптивная форма для заполнения на смартфоне

Заполненная на сайте форма отправляется в ERP, где автоматически преобразуется в данные - создаются элементы справочников (контрагенты, контактные лица), документ проверки поставщика, задачи для сотрудников, письма с уведомлениями поставщиков.

Пользовательский интерфейс в ERP для проверки поставщика

1. Текущее состояние проверки поставщика.

2. Статус предквалификации (отдельный бизнес-процесс, здесь не рассматривается).

3. Автоматическое определение статуса контрагента (действующий или в состоянии ликвидации).

4. Досье контрагента на дату начала проверки (автоматически сохранено в PDF).

5. Досье контрагента на дату открытия документа проверки (динамическое формирование отчета).

6. Блок проверки документов (с возможностью автоматического запроса дополнительных документов, которые изначально не запрашиваются на сайте).

7. Автоматическая проверка соответствия кодов ОКВЭД контрагента предмету закупки.

8. Автоматическая проверка срока регистрации контрагента.

9. Автоматические задачи сотрудникам, история действий по проверке, автоматические письма контрагенту.

Робот автоматически отклоняет проверку контрагентас отрицательным результатом по 10 признакам, и одновременным уведомлением по email поставщика о причине.

1 - Робот автоматически устанавливает отрицательный статус проверки и завершает бизнес-процесс проверки.

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

3 - Менеджер по закупкам всегда может обосновать проведение проверки, отправив ответственному задачу на согласование (бизнес-процесс проверки будет автоматически инициирован при положительном согласовании).

10 причин автоматического не прохождения проверки контрагента

Автоматическое письмо поставщику от робота, что проверка не пройдена

Когда у робота нет причин отклонять проверку,в ERP автоматически стартует бизнес-процесси сотрудники начинают получать автоматические задачи.

Автоматическая задача пользователю от робота в ERP

1 - Назначен ответственный

2 - Установлен крайний срок выполнения задачи

3 - Ссылка на документ проверки поставщика

Таким образом,робот автоматически ставит задачи разным сотрудникам(или ролям) при переходе бизнес-процесса проверки на разные этапы.

История автоматических задач по проверке поставщика в ERP

Все задачи для сотрудников имеют сроки выполнения.Настройки всегда можно изменить в ERP (в пользовательском режиме).

1 - Настройки адресации ролей и сроков выполнения задач ответственными.

2 - Настройка служебных ролей для ожидающих процессов.

3 - Настройка срока ожидания повторного предоставления документов поставщиком (после чего проверка завершается автоматически с отрицательным результатом).

Настройки бизнес-процесса для робота проверки поставщиков

Когда в процессе проверки поставщикасотрудник выявляет недочеты, он устанавливает переключатель в положение "Не соответствует" и указывает причину в комментарии.

Контрагент получает автоматическое письмо по emailдля устранения выявленных замечаний:

1 - Замечание по каждому документу.

2 - Уникальная ссылка с ограниченным сроком действия.

Форма на сайте, открытая по уникальной ссылке из письма, предлагает загрузитьтолько те документы, которые запрошеныу контрагента повторно.

Сгенерированная форма на сайте для повторной отправки документов для проверки контрагента

Циклов повторного запроса может быть несколько, пока контрагент не устранит все замечания и не предоставит требуемые от него документы.

История автоматических писем в ERP в документе проверки контрагента

Все шаблоны автоматических писем настраиваются в ERP (в пользовательском режиме).

1 - Настройки почтовых ящиков для уведомлений.

2 - Настройка почтовых ящиков для загрузки данных с сайта.

3 - Настройка шаблонов автоматических email для различных событий.

Настройки почтовой подсистемы робота проверки поставщиков

Плюсы роботизации бизнес-процесса проверки поставщиков:

1. Из процесса проверки исключен один сотрудник - менеджер по закупкам.

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

2. Поставщики самостоятельно предоставляют данные через сайт.

Высвобождается время у менеджера по документообороту для запроса документов по email, и у поставщика для выяснения вопросов и пересылки писем.

3. Робот автоматически проверяет поставщиков по 10 признакам.

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

4. Робот автоматически ставит задачи сотрудникам разных подразделений.

Сотрудникам не нужно думать о том, кому передать результат своей работы, а задачи не будут забыты или просрочены.

5. Робот автоматически пишет письма поставщикам.

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

6. Не нужно увеличивать штат сотрудников при увеличении числа поставщиков.

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

7. Новые поставщики приходят самостоятельно через сайт компании.

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

Мы разработали и более простых роботов, которые являются частью подсистемы проверки поставщиков. Например,робот проверки статуса ликвидации организаций.

Настройки робота проверки статуса ликвидации всех контрагентов в ERP

Ежедневно ночью робот автоматически проверяет всю базу контрагентов в ERP и актуализирует статус ликвидации по каждому ИП и юр. лицу (интеграция с сервисом DaData.ru).

При обнаружения признака ликвидации у контрагента:

1 - Робот автоматически уведомляет ответственных сотрудников.

2 - Робот приостанавливает оплаты в счет контрагента.

3 - Робот маркирует карточку контрагента в ERP.

Виджет проверки статуса ликвидации в карточке поставщика в ERP

Кейс #2: Роботизация процесса запроса КП у поставщиков

Процесс сбора, обработки и согласования коммерческих предложений не менее трудоемкий, чем процесс проверки поставщиков:

• Поиск поставщиков и подрядчиков.

• Запрос коммерческих предложений и их сбор.

• Сравнение предложений и выбор наилучшего поставщика.

• Подготовка аналитической записки и согласование с руководителем.

Нужно учесть, что разные поставщики присылают коммерческие предложения в разной форме, часто не указывают элементарных условий (цены указаны с НДС или без, сроки поставки, наличие и сроки гарантии, способ доставки и т.п.). Процесс повторяется заново.

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

• ERP-система (рабочее место сотрудников).

• Сайт компании (интеграция с ERP).

• Почта Gmail (интеграция с ERP и сайтом).

Шаг 1:Менеджер выбирает позиции (1) для запроса предложений через сайт (2).

Выбор позиций номенклатуры для запроса КП через сайт

Выбор позиций номенклатуры для запроса КП через сайт

Шаг 2:Робот автоматически выбирает (1), и показывает менеджеру подходящих поставщиков (2) и контактных лиц (3) с заполненными email (4), а также компетенции, результаты проверок и последние поставки (5).

Робот выбрал подходящих поставщиков и контактных лиц для запроса КП

Шаг 3:Менеджер выполняет визуальную проверку и запрашивает КП через сайт.

Шаг 4:Для каждого контрагента робот автоматически создает письмо со ссылкой для заполнения коммерческого предложения.

Робот создал и отправил письма с запромо КП каждому поставщикуПисьма, отправленные роботом из ERP

На сайте разработана динамическая форма для заполнения поставщиком коммерческого предложения:

1. Условия оплаты (налогообложение, цены с НДС или без, ставка НДС,наличие отсрочки и размер аванса).

2. Условия поставки (способ и срок доставки, наличие и срок гарантии).

3. Товары к поставке (цены, особые условия гарантии, сроков поставки или аналоги).

Форма на сайте для заполнения коммерческого предложения поставщиком

Таблицу товаров к поставке можно скачать в Excel.

Форму коммерческого предложения можно заполнить прямо в смартфоне

Важно!Чтобы поставщик не тратил время на подготовку формы коммерческого предложения, ее можно:

• Скачать уже заполненную прямо на сайте.

• Распечатать, поставить подпись и печать.

• Отсканировать и загрузить на сайт.

Печатная форма коммерческого предложения для скачивания с сайта

Одну форму коммерческого предложения на сайте можно заполнять несколько раз.Заполненные данные автоматически сохраняются в кеш и не будут потеряны.

Такие образом, все коммерческие предложения поступают в ERP автоматически.

После окончания срока приема предложений, в ERP автоматически формируется аналитическая записка.

Робот автоматически формирует аналитическую запискуи сравнивает все предложения от поставщиков по одним и тем же критериям (1), и ранжирует претендентов (2) в порядке убывания.

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

Мы разработали и других роботов, которые работают в режиме 24/7 и облегчают жизнь.

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

В последнее время все чаще слышно про RPA или Robotic Process Automation. С одной стороны, говорят о его эффективности для банковского сектора и крупных корпораций, с другой про применимость и в среднем, и даже в малом бизнесе. На днях на Хабре вышла обзорная статья про интеллектуальную обработку документов с помощью RPA и мы подумали, что хабравчанам также будет интересен рассказ про наш опыт реализации такого проекта в деталях.

Он был выполнен для одного из крупнейших ритейлеров в РФ и Европе. Его магазины можно найти везде: в одной только Москве и области их десятки, а по всей России больше сотни. Это фантастическое количество товаров, поставщиков, поставок и связанного с ними документооборота, которого с каждым месяцем становится больше и больше.

Большая часть документов проходит по ЭДО. Но в нем работают не все поставщики, и бремя сверки бумажной документации перед оплатой ложится на плечи бухгалтеров. Совсем не редки случаи, когда цены в заказах и документах на оплату разнятся, причин расхождения может быть много. При этом объем документооборота растет, и этот процесс превращается в ужасную механическую кабалу для целого штата бухгалтеров-сверщиков.

Идеальный сценарий для RPA! А для нас отличная возможность показать, как он грамотно и продуктивно реализуется.

С чем предстояло работать

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

Описанные выше проблемы возникали на этапе обработки документов. На стороне заказчика каждый день на эту задачу тратилось 72 часа. Это 9 полноценных бухгалтерских рабочих дней! Роботизации этого проекта от нас и ждали.

Как видите, большая часть этого процесса механическая рутина. Идеальная цель для автоматизации! Однако классический путь доработки ERP-системы с интеграцией ее с СХД был заказчику закрыт: бэклог команд, занимающихся сопровождением и развитием этих систем, был расписан на месяцы вперед, а доработка системы сложна и дорога. В общем, классический кейс а давайте лучше робота: с ним не нужно будет дорабатывать информационные системы.

В качестве платформы роботизации был выбран UiPath: абсолютный лидер на рынке РФ и один из лидеров глобального рынка RPA, кроме того, уже обкатанный в головном офисе нашего партнера в Европе.

Чего мы хотели от робота?

У этой роботизации было несколько основных и вспомогательных целей. Основные цели были достаточно стандартные: процесс нужно было автоматизировать не менее чем на 90% (звучит впечатляюще, но для мира RPA это норма), сократив затраты на него по сравнению с ручным трудом. Второстепенные цели были любопытнее:

выявить аномальные расхождения, которые человек может пропустить;

снизить риск ошибки специалистов по товарному предложению;

предотвратить расширение штата бухгалтеров при увеличении объемов поставок;

ускорить проведение оплат поставщикам.

На основе всего этого мы поставили перед собой такие задачи:

разработать роботов, которые будут выполнять работу бухгалтеров;

разработать сервис их взаимодействия с бухгалтерами и СТП; не допускающий использования вил и факелов

реализовать процесс извлечения данных из сканов бумажных документов;

интегрировать роботов с системой распознавания бумажных документов.

Ну и как же без дополнительных требований от заказчика:

runtime-лицензии роботов должны использоваться максимально эффективно. Лишние действия, задержки все это должно быть сведено к минимуму;

решение должно быть надежным и отказоустойчивым. При падениях, по словам заказчика, роботы сами должны себя поднимать!

отсутствие у роботов дублирования функций;

приоритизация срочных задач (например, отчетов);

минимизация поддержки решения после ввода в эксплуатацию;

автоматический онлайн-расчет окупаемости (дэшборд в Confluence);

и еще, чтоб участников процесса письмами/уведомлениями не спамило.

Подход к проблеме и проект

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

Итак, сформулировав процесс AS-IS, мы декомпозировали его на подпроцессы для роботизации. Получилось вот так:

На этом этапе было важно распределить задачи между подпроцессами и понять, что будет являться минимальной неделимой единицей обработки информации в роботизированной системе. Для нас ею стала приёмка заказа, по которой требовалось определить расхождение в стоимости. Каждую приёмку нужно было обрабатывать в контексте своего заказа, т.е. если в одном заказе несколько приёмок, они должны обрабатываться последовательно.

Однотипные задачи мы сразу стали собирать в совместную обработку, помня о требовании об эффективном расходовании runtime-лицензии. На практике это значило, что если нужно выгрузить из ЭХД 10 доков, то открывать его мы будем 1 раз, выгружать нужное и 1 раз закрывать, а не открывать и закрывать для каждого документа.

Архитектуру системы полностью определило решение формировать списки задач для каждого роботизируемого процесса в СУБД (MS SQL). Тем более что, как мы выяснили, отчёт из учетной системы (на базе СУБД ORACLE) можно выгружать запросом. Поэтому мы решили сделать Link к БД учетной системы и настроить Job в БД для регулярной выгрузки новых приемок, готовых к сопоставлению. Этот Job будет также анализировать полученные данные и переводить приемки на нужный этап обработки: Требует согласования с СТП, Требует выгрузки в систему распознавания, Передать в оплату и т.д.

Роботу оставалась только грязная работа по выполнению механических операций в соответствии с установленным статусом.

Что еще нужно было определить перед тем, как приступить к работе?

Архитектура распознания документов

Наш робоподопечный должен был уметь распознавать документы такое зрение ему мы сделали на известной платформе ABBYY FlexiCapture. У нее есть, во-первых, готовые шаблоны распознавания для первичных документов (мы лишь немного докрутили их под примеры заказчика). Во-вторых, она предоставляет удобный интерфейс для верификации результатов распознавания, а это экономит время тому, кто верифицирует.

В этом процессе было несколько критически важных точек: качественное извлечение табличной части документа; проверка артикулов в БД (да, номенклатура также выгружалась из БД ERP-системы); сверка суммы документов; проверка совпадения штрихкода на документе и в ERP.

Формирование интерфейса

Для взаимодействия с пользователями изначально планировали использовать Jira, но затем мы приняли решение упростить интерфейс. Мы разработали собственный сервис по взаимодействию с пользователями. Если требуется согласовать расхождение, робот присылает сотруднику по товарному предложению ссылку в письме. При переходе по ней формируется web-страница, при этом проверяется, не был ли этот заказ уже согласован, а также имеет ли данный человек все необходимые права. На этой странице сотрудник выполняет согласование и вводит комментарий. После этого приемка в БД получает соответствующий статус для дальнейшей обработки роботом.

Что важно отслеживать в такой ситуации? Согласованные приемки, сотрудника, который их согласовал, а также его возможный комментарий. Но главное обязательно нужно выполнить дополнительную проверку согласования бухгалтером (в компании уже был случай, когда СТП по ошибке согласовал очень крупное расхождение в цене).

Формирование отчетности

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

Всего отчетов было реализовано четыре:

отчет по задачам бухгалтеров (требуются ли действия от бухгалтера?);

отчет главного бухгалтера (по задачам всех бухгалтеров);

общий отчет по выявленным расхождениям;

детальный отчет по расхождениям (с суммами по приёмкам и по поставщикам).

Каждый из них формируется на основе вьюхи из БД, в которой есть все необходимые данные. Роботу остается только сделать запрос, красиво и удобно его оформить и предоставить пользователю на блюдечке с голубой каемочкой.

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

Формирование графиков в Confluence

Помимо отчетов, робот также должен был строить real-time графики окупаемости самого себя. Для этого был разработан набор представлений в БД, в которых рассчитываются ключевые метрики робота. Методология расчета метрик включает в себя все затраты на роботизацию процесса, в том числе стоимость лицензий, серверов, стоимость наших услуг, а также зарплату бухгалтеров, ведь полностью мы их не исключили из процесса. Для отображения графика на странице в Confluence используется плагин Database Query.

С какими трудностями мы столкнулись

Если и бывают проекты, которые проходят без сучка и задоринки, то редко и наша роботизация не стала исключением. В процессе мы столкнулись с несколькими затруднениями в реализации задуманного и решили их.

Проблемы при заказе отчетов как сделать так, чтобы робот выполнял приоритетные задачи раньше других?

После реализации персонализированных отчетов мы столкнулись с проблемой приоритизации задач.

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

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

Таким образом, при наличии в очереди задач на формирование отчета, робот практически сразу брался за их выполнение.

Как заставить робота самого себя поднимать

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

Например, если учетная система падает во время исполнения роботом задачи, он должен через фиксированное время делать еще одну попытку. Если система остается недоступна несколько часов, робот должен писать заявку в поддержку этой системы в Jira.

В качестве основы всех процессов мы использовали Enhanced REFramework. Нас устраивали его расширенное логирование и централизованная обработка исключений.

Робот копил информацию о произошедших ошибках и выполнял соответствующие действия в зависимости от типа ошибки. В алгоритмы обработки ошибок были заложены попытки решить проблему локально, например, перезапустить текущую страницу в браузере. Если это не удавалось, то ошибка передавалась на централизованную обработку. Если ошибка повторялась 3 раза, то робот переходил к следующей приемке, а для этой устанавливался статус Завершено с ошибкой с отправкой уведомления администратору.

Переиспользование частоиспользуемых процессов (инвоуков)

Ввиду большого количества разрабатываемых процессов встает вопрос о переиспользовании повторяющихся разработок. Например, во все наши процессы входит взаимодействие с базой данных, во многие получение и отправка писем, открытие и закрытие учетных систем. Все разработанные последовательности действий, которые могут быть переиспользованы, мы собрали в отдельные библиотеки и объединили в nuget-пакеты по области их применения. Пакеты хранятся в оркестраторе и GIT, соответственно, все разработчики имеют доступ к актуальной версии.

Кастомные активности

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

работа с БД (получение данных по приемкам, по отчетам, сохранение статусов и т.д.);

работа с почтой (получение запросов от бухгалтеров, отправка уведомлений);

работа с Excel (форматирование, группировка, сортировка и т.д.);

работа с учетными системами (авторизация, проверка ошибок).

Все это используется в разных роботизируемых процессах разными роботами и хранится в Оркестраторе, оставаясь доступным для всех разработчиков.

Курьезный случай исчезновение штрихкодов

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

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

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

Пришлось-таки подключить команду сопровождения этой учетной системы. Мы совместно настроили расширенную трассировку процесса и уже на первом же тестовом прогоне обнаружили место сбоя. Виновником был java-скрипт на стороне учетной системы. Коллеги выпустили патч и проблема исчезла.

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

Результаты

Как мы говорили в самом начале, от нас требовалась оптимизация рабочего процесса на 90%. Как вычислить этот показатель? Для этого нужно сравнить время, которое будет потрачено на нужный процесс с роботом и без него. Мы определили, сколько занимали все составляющие роботизированной работы выгрузка актов, работа в ABBYY, составление отчетов и даже написание писем; задали резерв на обслуживание робота.

И выяснили, что с задачами, на которые штат бухгалтеров ежедневно тратил время девяти полностью занятых профессионалов, робот справляется примерно за половину одного рабочего дня (0,47 рабочего дня, если быть точным). Точный показатель 94% оптимизации. Это была победа!

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

В частности, прямо сейчас мы роботизируем для него два других процесса, в том числе обработку актов сверки поставщиков.

Спасибо всем дочитавшим до этого момента. Если у вас возникли вопросы, мы будем рады на них ответить!

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

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

Часто такие надстройки слетают при обновлении версии базовой конфигурации 1С, что требует как минимум их повторного включения, а чаще повторной разработки с учетом изменения внутренней кухни конфигурации от вендора.

Рассказываем о том, как при помощи UI Framework избежать подобных проблем роботизации в 1С. Благодаря этому фреймворку UiPath можно роботизировать процессы, в которых участвует несколько приложений, систем и сайтов, гораздо быстрее, чем при помощи программирования в 1С. Подробности ищите в посте.

Статья написана при поддержке архитектора, технического специалиста UiPath: Валентина Драздова.

Попытки обойти проблемы 1С снаружи

Некоторые разработчики не встраивают свои решения непосредственно в конфигурацию 1С, а создают отдельно стоящие приложения, которые обращаются непосредственно к 1С с использованием интерфейсов COM-объектов или взаимодействуют с сервером 1С через web-сервисы. Как правило, такой подход действительно устраняет проблему при обновлении конфигурации, так как обновление не влияет на внешнее ПО, а интерфейсы COM-объектов и веб-сервисов меняются крайне редко. Недостатком данного подхода является то, что от разработчиков требуется больше компетенций, чем просто программирование в 1С, а следовательно больше затрат на тестирование совместимости, что влечет за собой увеличение общей стоимости проекта.

Роботизация как ключ к быстром изменениям

С тех пор, как в Россию пришли решения на базе RPA разработчики начали применять данную технологию для роботизации. Важным преимуществом RPA является то, что такие решения не требуют глубоких знаний в профессиональной разработке ПО, а также использования COM-объектов и web-сервисов, RPA-разработчику необходимо лишь показать, как эту задачу делает реальный человек. Таким образом роботизацией могут заниматься те, у кого есть экспертиза не в программировании, а в своем деле, которое требует автоматизации бизнес-процессов.

Вызовы для RPA со стороны 1C

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

Практически все RPA-решения взаимодействуют с интерфейсами одними и теми же способами:

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

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

3. Зашитые координаты кнопок и полей на окнах самый простой и быстрый метод, но он не работает при использовании других разрешений экрана, ломается при любом изменении расположений элементов интерфейса;

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

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

UI Framework универсальная таблетка от UiPath

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

При работе с UI Framework разработчик RPA может выбирать индивидуально для каждого компонента каким именно методом робот будет его искать:

Default режим по умолчанию. Использует собственные алгоритмы для анализа элементов управления форм на основании тех самых идентификаторов. Данный метод подходит для большинства приложений.

AA режим использования средств Microsoft Active Accessibility. В данном режиме UiPath использует интерфейс специальных возможностей Windows, который позволяет людям с плохим зрением взаимодействовать с программами. В основном данный метод наиболее применим для старых приложений, реализованных на чистом WinAPI без применения современных технологий.

UIA режим использования средств Microsoft UI Automation. В данном режиме UiPath использует методы доступа, предоставляемые для современных приложений Windows. Как правило, это приложения, использующие технологии WPF и универсальные приложения Windows (известные так же, как приложения магазина Windows 8/Windows 10).

Методики поиска Ui Framework надежнее, чем способы с координатами или изображением. Однако, только одного корректного выбора UI Framework недостаточно. Например, на формах ввода документов 1С можно встретить следующую проблему существует несколько полей, и ни одно поле не помечено специальными идентификаторами. Как результат после выбора одного поля робот видит его в нескольких местах сразу:

Использование разных режимов работы с интерфейсами позволяет достичь более высоких результатов при определении тех или иных компонентов управления в 1С, однако, только их недостаточно, и именно здесь приходят на помощь дополнительные средства:

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

Якоря В дополнении к параметрам искомого элемента управления можно добавить информацию об элементе, который находится рядом. Без данного средства крайне сложно реализовать ввод информации в текстовое поле 1С, так как идентификаторы у таких полей меняются постоянно, а текста в них либо нет (если это ввод нового документа), либо он непостоянен (если это получение информации). Якорь позволяет указать на то, что рядом (слева, сверху, по диагонали, итд) с искомым полем должен располагаться еще один элемент, например, надпись или кнопка, которые уже точно содержат фиксированный текст.

При этом UiPath позволяет добавить сразу несколько якорей специально для тех случаев, когда у вас есть сразу несколько похожих полей на экране.

Поиск по изображению иногда бывают такие случаи, что робот в 1С может найти два идентичных элемента, даже несмотря на то, что используются якоря. Как правило, такое может произойти, когда у вас имеется, например, поле Поиск и кнопка Поиск. Так как 1С старательно жонглирует параметрами отображаемых элементов управления робот может не увидеть чем является каждый компонент. В таких случаях имеет смысл включить дополнительную проверку по изображению: изображение кнопки точно будет отличаться от изображения поля.

Повторное использование действий

Скорость создания роботов для 1С явно меньше, чем для большинства других приложений. Чтобы сократить сроки разработки новых процессов, UiPath предоставляет возможности повторного использования существующих разработок.

Сформированные селекторы можно добавить в репозиторий объектов и использовать повторно, тем самым сокращая время на роботизацию одинаковых элементов.

Репозиторий объектов располагается на компьютере разработчика, что дает возможность применять добавленные селекторы во всех проектах, которыми он занимается. Если роботизацией занимается команда разработчиков - имеется возможность создания репозитория в специальной UI-библиотеке. UI-библиотеки можно распространять через оркестратор UiPath, благодаря чему все разработчики и роботы всегда будут иметь доступ к последней версии селекторов.

Помимо хранения репозитория объектов в UI-библиоетках можно создавать такие же последовательности, блок схемы и конечные автоматы, как и в обычных проектах. После публикации и использования - они будут доступны в виде набора готовых активностей. Например, если в нескольких проектах необходимо искать контрагента в 1С - можно выделить этот блок в библиотеку и просто вызывать его. В случае, если в 1С произойдет изменение интерфейса - разработчику достаточно изменить только библиотеку, а не десяток проектов, где необходимо выполнить это действие.

Адаптация к изменениям

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

Единственное, что может помешать роботу изменение подписей у полей и кнопок, или изменение расположений элементов, которые являются якорями. Однако, в этом случае исправление робота занимает короткое время: разработчику необходимо открыть студию, найти нужный блок, где идет работа с полем или кнопкой, исправить якорь в соответствии с изменением интерфейса и опубликовать новую версию. Благодаря возможностям оркестратора UiPath новую версию получат все пользователи сразу после того, как администратор нажмет кнопку Обновить до новой версии.

Во избежание подобных ситуаций рекомендуется использовать UiPath Test Suite, который позволяет выполнить тестирование совместимости роботов и обновленных интерфейсов до введения новой версии программ на продуктив. Помимо тестирования самих роботов, UiPath Test Suite позволяет вам тестировать любые другие приложения на предмет корректности работы сквозных процессах. Подробнее о UiPath Test Suite вы сможете прочесть в нашем блоге совсем скоро.

Computer Vision дополнительная таблетка для сложных случаев

Несмотря на большие возможности поиска элементов управления в UI Framework в платформе 1С существует гораздо больше проблем для RPA-разработчиков, чем изначально можно предположить. Например, одной из сложностей при роботизации 1С являются таблицы. Если с веб-версией таблиц роботы от UiPath справляются очень легко, то вот волшебные Windows-таблицы, которые умеют превращаться в деревья, иногда ставят UI Framework в тупик. Однако, там где нельзя получить доступ к данным напрямую техническим способом имеется возможность использовать компьютерное зрение. Мы уже рассказывали о преимуществах компьютерного зрения при работе с удаленными рабочими столами. Однако, хотим лишь указать на то, что проблема с таблицами и прочими сложностями платформы 1С, отлично решается именно с использованием Computer Vision.

Кейс: как с помощью RPA заносить данные в 1С

В видео показан процесс обработки электронной почты, поступающей от сотрудников склада. Робот комбинирует позиции по контрагентам и договорам, после чего вводит информацию в 1С.

Еще несколько плюсов роботизации 1С с помощью UiPath

Роботы от UiPath ценны тем, что они не ограничивают вас в одном конкретном приложении. Если по поводу того, что запрограммировать 1С надежнее, чем роботизировать еще можно поспорить, то с фактом, что благодаря роботам вы можете роботизировать процессы, в которых участвует несколько приложений, систем и сайтов, гораздо быстрее, чем при помощи программирования в 1С уже сложно не согласиться.

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