RPA не хватает антихрупкости
Роботизация процессов (Robotic Process Automation, RPA) в последние пару лет была на волне хайпа, который и не собирается угасать. Но при всей очевидности пользы для бизнеса массовые внедрения RPA забуксовали. Даже у RPA-единорогов – UiPath, Automation Anywhere и Blue Prism количество клиентов находится на отметке около трех тысяч на каждого, несмотря на многомиллионные вливания (по данным за 2019 год).
Более половины организаций, внедривших RPA, используют меньше 10 ботов; а у 70% – менее чем 50 ботов в эксплуатации (Forrester). Потому что далеко не всякий заказчик готов выращивать компетенцию по такой узкой теме ради автоматизации десятка рутинных операций, а с наскоку все настроить не получается. Кроме того, несмотря на уверения поставщиков, что можно обойтись вовсе без программирования, кодить все-таки приходится – и эти куски кода разбросаны по множеству мест, что затрудняет поддержку. В общем, все сложно. По крайней мере, гораздо сложнее, чем это рисуют маркетологи.
Всему виной хрупкость
Развертывание армии ботов – сложная задача, и слишком часто отрасль не признает серьезность этой проблемы. Столкновение с реальностью показало, что RPA-боты слишком хрупки и поэтому проекты испытывают трудности с масштабированием.
Хрупкость заложена в самой идее RPA – обеспечить интеграцию, имитируя действия пользователя. Боты полагаются на такие зыбкие методы, как перехват и распознавание изображения с экрана или парсинг HTML для веб сайтов и приложений. Естественно, что пользовательские интерфейсы часто меняются, а это значит, что ваш робот не узнает форму, с которой работал еще вчера и его придется перенастраивать.
Да чего далеко ходить – мне недавно понадобилось собрать данные о мобильных банках из Google Play. Чтобы не заниматься копипастом, беру RPA, настраиваю робота, запускаю – упс! – процентов 30 страниц не прочитались. Казалось бы, что может быть стандартнее, чем страница приложения в магазине Google! Ан нет. Видимо, есть особенности HTML-верстки, которые влияют на работу робота, и это потребовало бы более тонкой настройки. Я справился с проблемой, сделав второго робота для нераспознанных страниц, благо мне данные нужны были однократно. А в режиме постоянной интеграции пришлось бы повозиться.
Все это негативно сказывается на успехе проектов. Опрос Deloitte, проведенный в 2017 году среди 400 глобальных компаний, показал, что 63 процента организаций не выполнили в срок проекты RPA. Для тех, кому это удалось, возврат инвестиций (ROI) оказался более длительным, чем ожидалось. В исследовании EY говорится, что 30 – 50% проектов RPA терпят неудачу. Едва ли в 2020 ситуация кардинально улучшилась.
Нассим Талеб рекомендует
Для описания подобных проблем Нассим Талеб изобрел понятие «антихрупкость». Оно обозначает способность к извлечению выгоды из неудач, потерь, ошибок; умение закаляться, развиваться и становиться сильнее при столкновении с хаосом. Вот уж чего, а хаоса в корпоративной автоматизации хватает!
Чтобы выжить в динамичной бизнес-среде и оправдать доверие инвесторов, разработчикам RPA нужно снабдить свои продукты свойством антихрупкости – научить роботов по-умному реагировать на изменения и приспосабливаться к ним, как это делают люди. Возможно, это хороший стратегический совет, но как его реализовать?
Если вернуться к моему примеру со сбором данных про мобильные банки, то меня бы вполне устроил вариант меньшей автоматизации – пусть бы робот спрашивал, что делать, когда не обнаружил данные в ожидаемом месте страницы. Но программисты привыкли делать так, чтобы действие выполнялось по одной кнопке, и готовы до полного изнеможения совершенствовать свой продукт, чтобы он исправно отрабатывал все exception’ы (исключительные ситуации).
В мире настоящих железных роботов такой подход практикуется давно – есть так называемые «коботы» – collaborative robots, которые предназначены для работы в одном пространстве с человеком и не программируются жестко, а обучаются своим белковым напарником. Кстати, в RPA тоже есть понятие и «attended robots» в сценариях контролируемой автоматизации, когда люди и роботы работают вместе друг с другом, и это вполне себе антихрупко.
ИИ спешит на помощь
Как известно, самое трудное в деле автоматизации - это правильно поставить задачу. Применительно к RPA-проектам это значит найти повторяемый и стабильный процесс, который можно будет перепоручить программному боту. Например, копировать данные из счетов-фактур в таблицу Excel для управленческого учета. И это может обойтись вам на порядок дешевле, чем разработка специального решения.
Но это примитивный пример, а в более сложных случаях далеко не так очевидно, какие данные куда нужно переместить. Для этого в RPA стали применять средства обнаружения процессов (process mining). То есть на основе анализа логов (журналов событий) ИИ создает новые модели процессов, которые имеет смысл роботизировать, повышая таким образом антихрупкость системы. (Именно поэтому UiPath купила недавно голландскую компанию ProcessGold.)
Таким образом, стоит говорить о переходе от RPA к IPA – Intelligent Process Automation. Или еще их называют CRPA – Cognitive RPA.
Закон Паркинсона никто не отменял
В больших организациях служащие часто заняты абсолютно бессмысленной работой по перекладыванию бумаг или, в более современном варианте, по внесению ненужных данных во множество различных форм. Бюрократические системы живут по своим правилам, и никакая автоматизация не может сделать их эффективными.
RPA не может исправить плохие процессы – она просто ускоряет их. Когда предприятия пытаются использовать RPA без реинжиниринга, процесс не только не улучшается, но и возникающие ошибки и узкие места, как правило, создают новые проблемы, которые дискредитируют реальные преобразования и уменьшают рентабельность инвестиций.
Пожалуй, это и есть главный тормоз на пути автоматизации офисной рутины. И вряд ли стоит опасаться того, что роботы отнимут работу у людей. Закон Паркинсона неумолим – численность аппарата может только расти, вне зависимости от объема выполняемой работы.
После внедрения RPA клерки станут контролировать работу ботов и писать отчеты – это взгляд пессимиста или оптимиста, решайте сами.
Кстати, как поживают ваши RPA-проекты?
