Robotic process automation

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

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

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

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

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

Почему я могу об этом вещать? И кем выступает моя компания?

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

Для начала давайте поймем, что такое бизнес-процесс

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

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

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

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

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

Итого, процесс должен быть цифровым, рутинным и повторяющимся.

Сколько мне нужно роботов?

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

Робот это, по сути, виртуальный сотрудник. У него в запасе 24 часа. Все что вы сможете уместить в 24 часа робот исполнит. Если процесс масштабный и в день вы совершаете таких операций 10 тысяч штук, где каждая операция занимает 1 минуту, то арифметика проста и ее поймет первоклассник. 10 тысяч штук делим на 1440 минут (столько минут в сутках) = 6.9.

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

И так по каждому процессу.

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

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

Сколько будет стоить проект?

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

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

Почему так дорого?

Многие клиенты почему-то ожидают что роботизация всего их отдела в 10 человек должна обойтись им примерно в 1000 баксов XD

Основные поставщики роботов приходят к нам из США. Где стоимость человекочасов достаточно высока. Один робот, который стоит примерно 8-10K USD, что ничтожно в сравнении с годовой заработной платой.

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

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

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

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

Расчет эффективности не всегда имеет положительный знак для отдельно взятого процесса

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

Ваш робот ломается, вы плохие ребята

Процесс работает в продуктовой среде, он уже приносит свои плоды, а владельцы бизнес-процессов могут пойти пить чай. Но не все так просто. В процессе роботизации есть несколько степов. Один из финальных степов это стабилизация. Это когда начинают всплывать исключения, которые не были учтены в начале роботизации данного процесса. Вы забыли, что из 1000 файлов в формате docx, у вас все-таки бывают иногда и GPEG-ы, но это о как редко. Все это требует проработки со стороны интегратора и относится к данной стадии нужно с пониманием. Это не робот сломался, это обязательная часть процесса роботизации бизнес-процессов.

Конфликт интересов и саботаж

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

Саботаж может быть как на стороне роботизируемого отдела, так и на стороне IT. Имеет место быть синдром Not invented here, что означает избегание использования или покупки продуктов, исследований, стандартов или знаний из внешних источников, сильное предубеждение против идей извне.

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

Я не знаю с чего мне начать, как создать Roadmap?

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

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

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

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

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

Я найму свою команду, и мы будем делать сами

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

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

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

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

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