Uipath

Решения SAP на сегодня являются самыми распространенными ERP-системами в мире. Они умеют интегрировать между собой разные бизнес-процессы, упрощают работу отраслевых специалистов за счет огромного количества шаблонных решений. Но освоение сотрудниками систем SAP, разворачивание и внедрение их в производство являются масштабными и сложными задачами. Последние тенденции здесь использование специализированных RPA-решений для автоматизации и упрощения работы. В этой статье мы рассматриваем основные барьеры, сложности и преимущества автоматизации работы с SAP-системами с помощью RPA, а также даем гайд-инструкцию по старту роботизации SAP в UiPath Studio.

Драйверы автоматизации

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

Исследование SAPinsider Benchmark Report, опубликованное летом 2020 года, в ходе которого организаторы опросили более 200 клиентов SAP, показало, что они все чаще внедряют технологии автоматизации, чтобы полностью охватить цифровую трансформацию, максимизировать эффективность процессов и создать полноценный work-life баланс для своих сотрудников.

Потребность в автоматизации объясняется двумя основными причинами. Во-первых, у SAP сложный интерфейс, требующий времени на обучение работе с ним. И вторая проблема в конце 2027 года поддержка пакета бизнес-приложений SAP Business Suite 7 закончится. Останется лишь один вариант мигрировать заранее на SAP S/4HANA.

(SAP S/4HANA это новая система планирования ресурсов предприятия (ERP) на основе ИИ и машинного обучения.).

Поддержку этой системы продлили как минимум до конца 2040 года.

Первый драйвер роботизированной автоматизации это сами сотрудники, у которых есть потребность сосредоточить свои усилия на интеллектуальной деятельности вместо рутины. Второй неминуемый переход компаний на SAP S/4HANA.

Согласно данным того же исследования основными задачами автоматизации для клиентов SAP являются:

• сквозная автоматизация между решениями SAP и другими системами компании (58%),

• стандартизация процессов в рамках миграции SAP S/4HANA (40%),

• настройка и выполнение программных роботов для автоматизации процессов (RPA) (40%).

Барьеры автоматизации

Основные сложности, ограничивающие возможности автоматизации работы с системами SAP это использование предприятием кастомизированных IT-систем и наличие нестандартизированных процессов.

Многие из опрашиваемых SAPinsider используют кастомизированные и изолированные ERP, что затрудняет внедрение и масштабирование решений автоматизации. Корпоративные архитекторы могли бы легче масштабировать системы автоматизации на всю организацию, если бы каждое ее подразделение и каждая используемая ERP-система работали с одними и теми же стандартизованными процессами. Поэтому многие респонденты заявили, что теперь видят в SAP S/4HANA возможность начать все сначала, оптимизировать процессы и внедрить автоматизацию.

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

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

Остановимся подробнее на роботизации SAP. Какой бы путь компания для себя ни выбрала на ближайшее будущее: продолжать работать в SAP ECC или осуществлять миграцию на SAP S/4 HANA роботы могут здесь помочь.

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

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

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

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

Самая популярная область для автоматизации это финансы. Компании автоматизируют:

• обработку дебиторской задолженности (79%),

• обработку кредиторской задолженности (76%),

• управление счетами-фактурами (68%).

Помимо финансов, организации автоматизируют широкий спектр процессов:

• тестирование SAP S/4HANA (43,5%),

• миграцию данных для SAP S/4HANA (42%),

• онбординг новых сотрудников (40%),

• ERP-риски и контроль (36%),

• обработку заработной платы (34%),

• обработку производственных заказов (30%),

• складские операции (30%).

Автоматизация с помощью UiPath

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

UiPath является официальным партнером SAP, у компании есть все необходимые сертификаты. Решения UiPath работают почти со всеми интерфейсами и облачными приложениями SAP:

• SAP WinGUI

• SAP S4/HANA

• SAP SuccessFactors

• SAP BAPI

• SAP WebGUI

• SAP S4/HANA Cloud

• SAP Ariba

• SAP RFC

• SAP Fiori

• SAP C4/HANA

• SAP Concur

• SAP OData

• SAB Business Client

• SAP Hybris

• SAP Fieldglass

SAP WinGUI-это наиболее часто используемый интерфейс для доступа к функциям SAP в приложениях SAP, таких как SAP ERP, SAP ECC, SAP S/4 HANA, а также в семействе приложений SAP Business Suite, таких как SAP BI/BW, SAP CRM, SAP SCM, SAP PLM и других. При работе с SAP WinGUI в UiPath Studio можно использовать любые темы (Belize, Blue Crystal, Corbu), для работы робота обязательно должен быть включен SAP WinGUI scripting.

Кроме того, с помощью UiPath можно комфортно поддерживать очень актуальную сегодня миграцию на SAP S/4 HANA на всех ее стадиях от проектирования до разработки:

• Подготовка данных;

• Мэппинг и кастомизация;

• Миграция данных;

• Тестирование;

• Постмиграция.

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

Акселераторы UiPath можно загрузить непосредственно с UiPath Marketplace, они содержат готовые рабочие процессы для наиболее часто используемых транзакций и приложений в SAP ECC и SAP S/4HANA. Их можно использовать как для автоматизации роботизированных процессов SAP, так и в качестве тестовых примеров. Время на внедрение робота с помощью акселераторов сокращается на 30%.

Гайд: с чего начинается работа по роботизации SAP в UiPath Studio

Для автоматизации SAP можно использовать стандартные активности UiPath, такие как Click или Type into. Но мы сегодня остановимся подробнее на тех активностях, которые были специально разработаны для взаимодействия с SAP.

SAP Logon активность для подключения к системе SAP через окно SAP Logon.

Необходимо прописать в соответствующих полях SAP Logon Path и Connection Name

C помощью SAP Logon мы выбираем то подключение, с которым хотим работать.

SAP Login используется для входа конкретного пользователя.

Нужно заполнить поля: клиент, пользователь, пароль, язык.

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

Call Transaction вызов транзакции. В параметрах указываем код транзакции.

Click Toolbar Button нажатие на действие, доступное в Toolbar.

Select Menu Item выбор элемента меню, по аналогии с активностью Click Toolbar Button в списке для выбора отобразятся даже вложенные элементы.

Для того, чтобы понять как с ними работать, посмотрим пример. На скриншоте отображена транзакция создания нового заказа (ME21N).

Используя активность Click Toolbar Button, мы получаем доступ к тем элементам, которые могут быть доступны с использованием горячих клавиш:

Несмотря на то, что на экране мы не видим элемент подменю Other Purchase Order, робот может вызвать его напрямую без совершения нескольких кликов по различных подменю. Активность Select Menu Item нам даст возможность выбрать любой из элементов меню и подменю.

Активность Read Status Bar позволяет прочитать сообщения из статус-бара. На основе полученных сообщений, робот может принимать решение о дальнейших действиях. Например, если мы ввели в поиске некорректный номер заказа, появится сообщение об ошибке. У этой активности есть 3 выходных параметра:

Message Type стандартные типы статусов SAP: success, error и др.

Message Text сообщение в строке статуса

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

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

Expand Tree активность, позволяющая выбрать любой элемент в дереве SAP.

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

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

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

В очень упрощенном варианте процесс может выглядеть так:

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

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

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

В нашем случае робот извлекает данные заказа из SAP и проверяет сумму к оплате. Она не совпадает, и робот создает пользователю задачу в Action Center на проверку счета-фактуры.

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

В нашем примере задача проверки выглядит так:

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

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

Посмотреть видео этого процесса с взаимодействием в SAP можно на YouTube-канале UiPath.

Что в итоге

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

Автоматизация работы в SAP маленький кирпичик в задаче полной автоматизации предприятия. С помощью UiPath можно закрыть все сложности, связанные с этой задачей. Роботы могут автоматизировать работу как в SAP, так и в других приложениях, включая legacy-системы. Интеграция между системами становится как никогда простой, позволяя быстро разрабатывать и внедрять автоматизацию в эксплуатацию.

Современные компании активно используют 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 значительно упрощают работу с фрагментарными процессами и делают ее доступной обычным пользователям без специализированных знаний.

В последнее время все чаще слышно про 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 в других рутинных процессах.

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

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

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

При написании этой статьи мы пообщались со специалистом финансового отдела одного из Российских провайдеров цифровых услуг и решений, использующей в своей работе Studio X. Светлана не имела опыта разработки до знакомства с сервисами UiPath. С помощью Studio X она менее чем за полгода научилась роботизировать RPA-процессы.

Светлана рассказала нам немного о своём опыте:

Сложности конечно были. По указанной ссылке я установила программу (UiPath Studio X), больше 4 месяцев смотрела презентации, видео, читала материалы на сайте, но ничего не получалось повторить. Потом я прошла видеообучение со специалистом UiPath, Ильей и на практике освоила азы роботизации.

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

Комментарий от автора: Светлана автоматизировала удалённый рабочий стол через картинки это значит, что использовались не классические селекторы, а технология Computer Vision (компьютерное зрение), о которой мы рассказали здесь. Нужные области это селекторы, на примере ниже станет более понятно о выделении каких областей идёт речь.

Далее состоялась встреча с Ильёй, на которой я смогла показать своего первого робота. Оказалось, что для Oracle нужно было установить еще донастройку Java.

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

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

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

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

Знаю, что можно создавать и сложных многозадачных роботов, поэтому очень хочу изучить UiPath досконально!.

Темпы оцифровывания бизнеса все время растут, а после пандемии COVID-19 они совершили качественный скачок. В исследовании компании KMDA говорится, что в 2020 году на 20% (по сравнению с 2018 годом) выросло количество российских компаний, приступивших к реализации цифровой трансформации. Соответственно, увеличилась и потребность в компетенциях IT-специалистов, компаниям стало значительно не хватать разработчиков и айтишников других профилей.

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

Раньше citizen developers обычно создавали простые однопользовательские решения на основе Microsoft Excel и Access. Сегодня low-code инструменты не требуют от пользователя особых технических знаний и навыков, и они могут без труда разрабатывать ведомственные, корпоративные и даже общедоступные приложения.

Зачем нужны citizen developers?

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

Для наглядности можно посмотреть на график, на котором по оси ординат мы измеряем выгоду от роботизации процесса, а по оси абсцисс количество задач. Самую большую выгоду (на один процесс) мы получаем при роботизации процессов с большим числом транзакций, например, акты сверок. Роботизировали один раз автоматизировали сразу сотни тысяч транзакций. Число таких процессов у компании конечно. Количество задач, которые могут автоматизировать citizen developers, наоборот, неограниченно. Но каждая такая задача приносит несоразмерную с затратами на разработку в центре компетенций или силами подрядчика прибыль. Однако, если посчитать площадь под графиком, то мы увидим, что выгода от citizen development сопоставима с роботизацией крупных процессов с большим числом транзакций. Именно поэтому имеет смысл подключать бизнес-пользователей к разработке RPA-процессов для себя. Минимальными затратами можно получить серьезную прибыль в масштабах компании.

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

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

Как становятся citizen developers

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

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

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

В отличие от RPA- разработчиков и IТ-команд citizen developers создают новые решения только с использованием предварительно одобренных технологий. Их продукты чаще всего используются на индивидуальном и командном уровне, хотя не исключено, что они могут найти более широкое применение в масштабе всей организации.

Решения UiPath для citizen developers

Одним из решений UiPath для citizen developers является Studio X это среда разработки, которую используют бизнес-пользователи для создания своих проектов по автоматизации. Интерфейс студии очень простой и user friendly:

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

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

Шаг 1

Заходим в браузер на Google.com и гуглим текущее время в Москве. Для этого выбираем ресурс User Application Browser. Studio X говорит, что необходимо указать приложение для автоматизации:

Шаг 2

Для этого достаточно кликнуть по окну браузера, в котором вы работаете. Далее возвращаемся в студию и видим, что там указано, что мы используем Google Chrome. Сюда же можно ввести нужный URL:

Шаг 3

Далее выбираем активность Type Into, чтобы задать роботу текстовое поле для ввода:

Шаг 4

Нужно указать куда вводить текст, для этого надо выделить поисковую строку в Google. После этого нажимаем кнопку Подтвердить.

И указываем, что нужно ввести Текущее время в Москве. После этого нужно дать указание роботу нажать на кнопку Поиск. Для этого используем активность Click:

Шаг 5

И там же указываем объект это кнопка поиска Google:

Шаг 6

После этого роботу нужно получить данные со значением текущего времени используем для этого активность Get Text и выделяем строчку со временем:

Шаг 7

Полученное значение времени сохраним в переменную для дальнейшего использования. Назовем ее Время Москва:

Шаг 8

И в завершении используем активность вывода сообщения Message Box.

Пишем Точное время в городе Москва и дальше добавляем сохраненную переменную:

Вот как выглядит результат работы робота:

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

Такие простые автоматизации без труда могут быть освоены citizen developers и использоваться ими для роботизации рутинных процессов на местах.

У UiPath есть не только продукты, специально разработанные для citizen developers, но и специализированные курсы по автоматизации для бизнес-пользователей.

Как компании используют citizen development

Тренд citizen development набирает обороты в последние полтора года среди клиентов UiPath в Азиатско-Тихоокеанском регионе (APAC).

Австралийский Heritage Bank приступил к автоматизации в начале 2017 года. Теперь у него есть полноценная команда по автоматизации, управляющая 12 unattended и 60 attended роботами.

Для масштабной автоматизации банк привлек сотрудников, у которых была сильная мотивация к обучению навыкам автоматизации. Они стали главными кандидатами на роль citizen developers. Далее планируется отобрать 10-20 человек из их числа, чтобы управлять автоматизацией всей компании. Руководство хочет, чтобы сотрудники могли видеть, как автоматизация, запущенная с их помощью, помогает коллегам высвобождать время на выполнение более стратегических или творческих задач. Это должно мотивировать людей заниматься citizen development на местах.

Еще один пример успешного внедрения citizen development компания VITAL. В конце 2017 года VITAL начала работать с RPA для автоматизации повторяющейся работы с данными, чтобы в итоге стать цифровым сервисным центром.

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

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

Citizen development: факторы успеха

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

• поддержка руководства компании,

• грамотные коммуникации с коллективом,

• поддержание уверенности сотрудников в полезности RPA.

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

Citizen development это в первую очередь инвестиции в людей, а не в технологии. Если компания правильно мотивируют своих сотрудников, то она может добиться потрясающих результатов в масштабировании автоматизации. А бот для автоматизации работы с отчетами, разработанный 65-летней сотрудницей, станет обыденностью, а не чем-то удивительным.

Несмотря на широкую распространенность платформы 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С. Таким образом, когда вашим сотрудникам понадобится роботизация они смогут сделать ее самостоятельно в короткие сроки не ожидая долгих согласований от отдела разработки (или же привлечения сторонних организаций и фрилансеров).

Не существует компаний, в которых не было бы работы с документами. И это кропотливый, рутинный, но очень важный процесс. Люди хотят получать зарплату вовремя, а поставщики и контрагенты своевременную оплату за свои услуги. Бухгалтеру в компании регулярно приходится проводить серии повторяющихся действий и при этом отслеживать их правильность. Вот простейший пример цепочки таких операций: чтобы отправить счет покупателю, менеджер по продажам отправляет бухгалтеру заявку. Затем бухгалтер создает счет в учетной системе, формирует печатную форму и высылает ее менеджеру. Если с покупателем ведется обмен электронными документами, то бухгалтер создает и отправляет ему счет в системе ЭДО.

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

Если какие-то задачи выполняются систематически с неизменной четкой логикой, и они присутствуют в большом количестве бизнес-процессов, то их роботизация становится экономически выгодной. UiPath предлагает использовать программных роботов для автоматизации процесса обработки входящих документов. Использование RPA позволяет для каждого типа документов применять разные подходы к распознаванию и извлечению (например, для одного документа использовать шаблоны Abbyy Flexi Capture, а для другого Microsoft OCR и ML-модели), что делает этот процесс гибким, с точки зрения внедрения.

Сложности распознавания и извлечения данных

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

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

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

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

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

_{Примеры извлечения данных из шаблонов. Источник: https://research.aimultiple.com/wp-content/uploads/2019/03/key-value-pairs.jpg}

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

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

Как роботы извлекают данные?

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

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

Создаем проект по обработке документов в UiPath Studio

1 Запуск менеджера таксономий.

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

Мы можем выбирать категорию и тип распознаваемого документа:

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

2 Оцифровка документа с помощью OCR

В UiPath реализовано полнотекстовое распознавание. Можно настроить мониторинг папки, из которой робот будет переносить документы в OCR-сервис. У UiPath есть встроенные механизмы для работы с распространенными движками, как платными, так и бесплатными (Abbyy, Tesseract OCR, Microsoft OCR и др.). Чтобы выбрать нужный движок, нужно просто перенести его из палитры действий в Digitize Document Scope.

3 Классификация документа по ключевым словам.

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

Классификатор UiPath может обучаться на массиве данных.

4 Экстракция данных.

Экстракция это извлечение текстовых данных из распознаваемого файла.

На этом этапе производится выбор экстрактора, который будет извлекать данные. На текущий момент в UiPath есть 4 основных типа экстрактора: формы, ML, Regex, Abbyy Flexi Capture. Переносим их из палитры действий в Data Extraction Scope.

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

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

_{Так настраиватся извлечение нужных данных в UiPath Studio. Источник: https://www.uipath.com/blog/ai-invoice-receipt-processing}

А вот как в интерфейсе сервиса выглядит распознанный документ с извлеченными данными:

5 Экспорт результатов распознавания.

Первичный экспорт результатов происходит с помощью действия Export Extraction Results в датасет, откуда информация может передаваться в любые сторонние системы, например, SAP, 1C или Госуслуги для бизнеса. При этом нам не нужно реализовывать сложную интеграцию. Робот может ввести данные в абсолютно любую систему через пользовательский интерфейс.

Примеры внедрения RPA для работы с документами

Одно из первых внедрений робота UiPath для работы с документами было проведено в компании СОК Сервисный Центр РУС, которая оказывает сервисные услуги бухгалтерского сопровождения магазинам финской розничной сети PRISMA и отелям Sokos Hotels в России.

Робот-ассистент UiPath освободил сотрудников сервисной компании от выполнения рутинных операций, связанных с документооборотом. Он обращается к ERP-системе компании, находит, распечатывает и рассылает клиентам по e-mail бухгалтерские документы (счета, счета-фактуры, накладные), в соответствии с требуемыми параметрами и условиями формирования печатных форм. Скорость выполнения операций благодаря использованию робота-ассистента выросла, а количество ошибок уменьшилось. Это позволило ускорить обработку и оплату счетов, и разгрузить сотрудников, высвободив до двух часов их рабочего времени для решения более творческих и интересных задач.

Еще один пример внедрение бота в компании QIWI, который проверяет бухгалтерские документы на соответствие стандартам финансовой безопасности. Он выполняет запросы к таблицам баз данных из различных систем (в основном ORACLE). Затем компонует полученные результаты и сохраняет их в отдельный файл. После этого бот создает в 1С: Документооборот документы с файлами отчетов.

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

Выводы и перспективы

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

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

По данным Aimultiple.com большинство компаний из списка Fortune 500, использующих технологии, которые разработаны более трех лет назад, имеют уровень автоматизации 10-15%, в то время как решения для извлечения данных счетов на основе машинного обучения могут увеличить этот показатель до 80% и выше.

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