Программные роботы в офисах: ломаем копья при внедрении

Заказчика интересует... всё! Само словосочетание RPA или «роботизированная автоматизация» оказывает волшебный эффект на того, кто его слышит. Мысль о том, что всё можно отдать на откуп роботам - завораживает. Или все-таки не всё роботизируется? Кстати, насколько это вообще сложно и как объяснить заказчику, на что уходят деньги?

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

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

Пару слов о RPA

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

А примеры можно?

Представим два процесса.

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

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

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

Не будем искать виноватых, – что делать?

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

Разберем по пунктам пример самого простого проекта в нашей практике. Заказчик — ТОП30 банк, которому необходима ежедневная выгрузка документов из автоматизированной банковской системы.

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

2. Нам не понадобились алгоритмы машинного обучения, мы просто проверяем, что файл который мы выгружали находится в папке. — 1 балл

3. Мы не работаем напрямую с документами, поэтому их вариативность нерелевантна — 0 баллов

4. Нам не нужно распознавать текст. — 0 баллов

5. Работаем всего с одним приложением. — 0 баллов

6. Глубина интеграции достаточно низкая, да, интерфейс приложения не интегрирован с RPA платформой, но мы используем горячие клавиши с проверкой правильности ввода — 2 баллов.

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

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

Итого проект оценен в 8 баллов из 80 возможных. Роботизация такого процесса с учетом составления документации, тестировании с заказчиком и обучении оператора — составляет 10 рабочих дней. Напоминаем, это самый простой процесс в нашей практике.

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

Ожидание и Реальность

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

А теперь разберемся с тем, что обычно хочет заказчик и какие трудности это за собой влечет. На российском рынке компаниям больше всего хочется автоматизировать документооборот. Оно и понятно, заполнение вручную огромной стопки документов, их сортировка и круглосуточное отражение своих глаз в мониторе на фоне Excel-таблицы или «1С:Предприятие» вряд ли открывают большой простор для роста эффективности компании. Однако тут и начинается самое тяжелое для разработчика RPA.

Первое, что нужно отметить, что подавляющее большинство документов из себя представляют pdf-сканы. Если нам нужно работать с содержимым таких документов, то становится больно, потому что приходится взаимодействовать с технологией OCR. И здесь выбора два: Вы либо покупаете какое-то качественное решение, позволяющее эту технологию максимально эффективно эксплуатировать, либо же довольствуетесь встроенными в софт Вашего вендора методологиями оптического распознавания. И вот с последним все очень неоднозначно. Например, в программе «UiPath Studio» по умолчанию присутствуют два движка OCR: от «Microsoft» и от «Google». Первый хорош, если Вам надо считать, скажем, целиком страницу. Второй удобен, если Вам надо считать маленький кусочек текста (но зато более гибок в настройке).

Как нетрудно догадаться, интеграция с русским языком, хоть и присутствует, но работает далеко не самым лучшим образом. В некоторых случаях и вообще идет полный "расколбас". Значок «№» как только робот не считывал: и «N9», и «jf2», и «Jf9», и море других вариантов. А в наших документах присутствуют не только такие значки. Тут Вам и таблица, на которую заехал кусок печати, и размашистая подпись, гордо занимающая половину пространства и загораживающая кусок текста, и артефакты от скана.

И тут мы приходим ко второй проблеме. Документы далеко не всегда оформляются в едином стиле. Ключевые слова могут то присутствовать, то отсутствовать. Номер акта может быть как со значком, так и без. Все это крайне затрудняет парсинг, не говоря уже о работе с адресами и прочим. Но и это еще не все. Документ может быть многостраничный, при этом некоторые страницы (какой-нибудь счет-фактура или какая-нибудь товарная накладная) могут быть повернуты на произвольный угол. Казалось бы, что стоит их повернуть? Тем более тот же «UiPath» позволяет разрабатывать свои модули посредством C #, импортировать код из Python (пока только 32-битного) или из Visual Basic. Однако и тут проблема. Что бы мы делали, если бы хотели повернуть страницу pdf-файла, используя, скажем, C #? Мы бы взяли любую open-source библиотеку и воспользовались бы готовым решением. И тут стучится в дверь политика лицензирования. И выясняется, что за коммерческое использование все равно придется доплатить. В результате, вам приходится искать методы, как выкрутиться. Потому что написать обработчик pdf с самого нуля — задача, мягко говоря, непростая. Теперь представьте, какие чувства испытывает RPA-разработчик, когда ему заказчик с улыбкой показывает пятистраничный документ с мелким шрифтом, кучей таблиц и несколькими повернутыми страницами.

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

Таким образом и сложные проекты с ощутимым эффектом стоит включать в план роботизации с очень большим вниманием и осторожностью.

И какой вывод?

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

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

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