Программная роботизация: без иллюзий

Популярность Robotic Process Automation (RPA) – автоматизации роботизированного процесса – стремительно увеличивается. Показательно, что за последние пару лет многие российские ИТ-компании выделили это направление организационно, а программные инструменты быстро создают и российские, и мировые вендоры, и сообщества открытого кода. Прогнозы развития мирового рынка продуктов и услуг RPA очень оптимистичные: предполагается многократный рост на период до 2025 года от уровня 2018-го.

Показатели экономической эффективности проектов с RPA впечатляющие. По данным, представленным компаниями Deloitte, Robotic process automation (RPA) trends and to-do list for scaling across the enterprise, The 3rd Annual Global RPA Survey Report», за 2018 год, сокращение затрат составляет 59%, повышение производительности – 86%, улучшение качества – 90% и окупаемость проектов за срок менее года. Более того, среди четырехсот участников исследования 53% компаний уже используют RPA, в течение следующих двух лет таких окажется 72%. Из тех, кто уже вложился в RPA, серьезно увеличить затраты на это направление в течение следующих трех лет планируют 78%. Типичные сроки проектов – недели.

Российские компании сообщают в основном о результатах небольших пилотных проектов: раньше в крупном добывающем холдинге получение справки 2-НДФЛ занимало 5 дней, в процесс были вовлечены несколько человек, а теперь это занимает 10 минут без участия людей. В январе 2018 года Российский центр роботизации и искусственного интеллекта (RPA Russia) выпустил отчет «Роботизированная автоматизация», где упомянуты публичные конкурсы по этому направлению «Сбербанка», «Альфа-банка», «Сибура», МТС, «Ростелекома». В этом направлении работают и «Уралхим», и «Лукойл», а также многие другие компании.

У RPA есть и противники, их основной тезис – только отсутствие нормальной интеграции приложений и плохая архитектура систем в целом порождает такие «костыли», как RPA. 

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

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

Где есть смысл в RPA и где его нет

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

Самая частая ошибка, по мнению Ernst & Young (отчет «Get ready for robots. Why planning makes the difference between success and disappointment») – выбор «не того» процесса для роботизации. По данным этого исследования, 30–50% всех RPA-проектов заканчиваются неудачно.

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

Таких процессов в крупной компании, скорее всего, обнаружится довольно много, обычно счет идет на сотни. Как выбрать среди них наиболее приоритетные? Самая общая рекомендация, и Ernst & Young поддерживает ее, заключается в том, чтобы спросить бизнес. RPA – это не ИТ-проект, снова и снова повторяют аналитики. Считать его таковым очень распространенная ошибка. В «Лукойле», например, планируют использовать роботизацию для обработки бухгалтерских документов и специально выделяют время на тщательный анализ деятельности сотрудников ОЦО, чтобы выявить операции, чья автоматизация даст наибольший эффект.

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

Области применения программной роботизации обширны. Подготовка ответов в госорганы по стандартным запросам, подбор персонала на уровне поиска подходящих резюме, онлайн-торговля, бухгалтерия и финансы, в частности автоматизация работы ОЦО, бюджетирование и управленческий учет, ремонты, логистика и отслеживание движения транспорта и груза, сервис- и кол-центры. Речь в данном случае не идет о чат-ботах, хотя и их часто причисляют к программным роботам. «Говорящие помощники» – отдельная тема, и не всегда они применимы для общения с конечными покупателями, клиентами. Но они могут быть очень полезны оператору для подбора необходимой информации в корпоративных системах. Не менее интересная область – контроль состояния оборудования, в том числе ИТ-инфраструктуры.

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

Еще один метод выявлять потенциально интересные для роботизации процессы – применение инструментов Process Mining. Метод основывается на анализе цифровых следов в различных информационных системах и на этой основе – реконструкций действий пользователей. Безусловно, он интересен и сам по себе, и в связке с BPM, но его уже используют в российских компаниях именно для первичной диагностики, выбора потенциально заслуживающих роботизации процессов, оценки возможного эффекта. Компания «Инфомаксимум» приводит пример кейса в телеком-операторе, где обследование инструментом Process Mining выявило довольно много любопытных проблем, в том числе сознательное мошенничество персонала для выполнения KPI. Но самое примечательное, что было рекомендовано роботизировать операцию прикрепления файла к документам. За счет этого сэкономлено 5 млн рублей в год на пилотной фокус-группе в 130 сотрудников. Так что в оценке приоритетов роботизации есть смысл опираться на счетные результаты, на точные метрики.

Роботизация и BPM

Казалось бы, и то и другое автоматизирует процесс. Но разница есть, и она принципиальная. BPM применяется в процессах, предполагающих выбор последовательности действий. RPA реализуют однозначно заданную последовательность шагов. Они вполне могут использоваться вместе, дополняя друг друга. Эксперты в BPM считают, что без общего понимания бизнес-процессов компании успехи роботизации будут эпизодическими и кратковременными. В исследовании «BPTrends State of Business Process Management – 2018 report», его проводит ассоциация профессионалов BPM, был вопрос о том, какие технологии респонденты собираются начать использовать в ближайшее время, и 37% анкетированных указали программную роботизацию.

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

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

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

В целом RPA ближе к системам класса ETL (Extract, Transform, Loading – извлечение, преобразование, загрузка), чем к BPM. Блоки RPA вполне могут быть отдельными задачами BPM-систем. Например, автоматизация банковской сверки. Чтобы робот научился достаточно правильно сопоставлять контрагентов (для этого используется машинное обучение), нужно время, и в любом случае всегда останется некий процент ситуаций, где он не сможет выполнить задачу. Поэтому в BPM-решении, автоматизирующем процесс целиком, задача робота имеет ограничения по времени: если оно превышено, задача эскалируется человеку.

Ошибки внедрения

Аналитики Ernst & Young в уже упоминавшемся исследовании «Get ready for robots» выявили несколько самых распространенных ошибок внедрения программной роботизации. Одна из них – попытка внедрить RPA на сложном процессе. Это может только увеличить цену, время и сложность, а эффекта не дать. Гибридные схемы, когда часть работы выполняет человек, а в некоторых, особо нудных местах он запускает робота, возможно комбинацией клавиш, уже доказали свою эффективность. Сделать их проще и быстрей, чем полностью роботизировать процесс, а результат достигается заметный.

Другая ошибка – неумение ответить на вопросы «на что нацелена наша программная роботизация, сколько она будет стоить и что мы получим в результате?», но трудно найти ИТ-проект, где такое незнание не создавало бы проблем.

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

В некоторых компаниях, отмечают в Ernst & Young, проекты RPA ведут по традиционной методологии, как «большие» проекты. Это тоже приводит только к избыточным затратам, затягиванию сроков и груде излишней документации.

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

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

Одно из серьезных заблуждений состоит в том, что достаточно поучить бизнес-пользователей пару дней тому, как настраивать RPA, и они прекрасно будут с этим справляться, смогут автоматизировать простые процессы. На самом деле как только процессов становится хотя бы несколько, возникает задача масштабирования, требуются средства оркестровки, всем этим разнообразием нужно управлять целенаправленно, что предполагает совершенно другие навыки. Кроме того, тестирование RPA-решений – вопрос крайне ответственный, потому что вернуться к начальному положению во многих задействованных системах, «откатить назад» может быть очень сложно и хлопотно. Хаотичная разработка роботов не только затруднит тестирование, но и потребует полного переписывания всего сделанного. Чтобы избежать этого, в Ernst & Young считают минимально необходимым по крайней мере две недели обучения в классе, затем два-три месяца практики под наблюдением и с обучением преподавателем, и только после этого можно говорить о какой-то квалифицированной роботизации. В данном случает экономить на обучении не стоит.

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

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