Ажиотаж вокруг темы Robotics Process Automation (RPA) постепенно стихает. Сегодня RPA– это уже хорошо известная российским компаниям технология автоматизации. Многие уже сделали первые пилотные проекты, просчитали бизнес-кейсы – и набили первые «шишки». Эксперты российского Accenture анализируют опыт своей компании, подводят промежуточные итоги и размышляют о дальнейшем развитии этой технологии.

Несмотря на то, что тема RPA сейчас очень «раскручена» на рынке, по нашим впечатлениям, еще не у всех ее потенциальных пользователей есть понимание:

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

Обобщая полученный нами опыт, хотелось бы обратить внимание читателей Банкир.Ру на некоторые аспекты применения RPA:

• выбор платформы для роботизации;
  
• факторы, влияющие на бизнес-кейс (обоснование проекта внедрения роботизации);
  
• выбор операционной модели;
  
• особенности процесса разработки.
  

Что выбрать: платформа

RPA- платформ немало, и многие из них так или иначе сегодня представлены в России. BluePrism, UIPath, NICE, Automation Anywhere, Open Span - вот далеко не полный перечень доступных платформ для роботизации.

Какую же из них выбрать?

Часто клиенты просто сравнивают цены на программных роботов и на основании этого делают выбор.

Скорость выполнения одного и того же роботизированного процесса может значительно варьироваться от платформы к платформе, а значит – требуемое количество роботов (как и архитектура решения) может сильно отличаться

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

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

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

Как обосновать: бизнес-кейс

Несмотря на кажущуюся простоту, и с расчетом, и с реализацией бизнес-кейса случаются проблемы.

Выгода для компании рассчитывается, как правило, путем сравнения стоимости часа работы робота и человека. Основная проблема заключается в том, что время, высвобождаемое за счет роботизации, может быть весьма распределенным: 10% у одного сотрудника, 20% у другого сотрудника и т.д. И если таких сотрудников единицы (а не десятки и не сотни), то реального сокращения затрат не происходит. Такая ситуация встречается довольно часто. А роботы при этом обходятся недешево.

Но это – совсем не «смертный приговор» для роботизации.

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

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

По нашему опыту, максимальный эффект достигается при правильном выборе процессов и осуществлении внедрения небольшими порциями (по 2-3 процесса) в небольшой промежуток времени (1-2 месяца).

Кто сделает: RPA разработчики

На первых порах кажется, что RPA – это настолько просто, что сделать разработку может любой.

Это не совсем так. Конечно, разработка RPA на современных платформах несколько ближе к бизнес-пользователю, чем к серьезному софтверному разработчику.

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

Скорость разработки и производительность робота

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

Работа с отсканированными документами тоже не проста. А зачастую клиенты очень хотят возложить на роботов задачи по вводу данных из первичных документов в системы. Помимо качества самого отсканированного документа, нужно учитывать его «подвижность» – алгоритм должен отыскивать нужные параметры на бумаге, даже если тот не идеально точно расположен относительно шаблона.

Желательно, чтобы робот был как можно «ближе» к роботизируемой системе. В противном случае, скорость исполнения задач роботом падает

Еще одна популярная проблема – низкая производительность робота при работе через удаленный рабочий стол. Желательно, чтобы робот был как можно «ближе» к роботизируемой системе. В противном случае, скорость исполнения задач роботом падает и меняется характер разработки такого робота.

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

От пилота к промышленной эксплуатации

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

Развитие и поддержка: операционная модель

Хорошо. Выбрали, разработали, внедрили, уже в режиме промышленной эксплуатации.

А как теперь все это развивать и поддерживать? Далеко не праздный вопрос.

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

Важно понять, как собираются и анализируются запросы на роботизацию, как осуществляется сорсинг (sourcing, выбор исполнителя) разработки, кто отвечает за функционирование роботов в промышленной среде и за работу с инцидентами. Где-то эти функции централизованы, где-то – наоборот. Есть и опыт работы по смешанной модели.

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

Один в поле не воин: дополняем робота

Даже ни с чем не интегрированный робот может, в принципе, стать неплохим подспорьем бизнесу

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

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

Именно в этом мы видим направление развития роботизации. Мы уделяем этому большое внимание в нашем московском инновационном центре - Future Camp.

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

• блокировка банковской карты в чате или посредством письма от клиента;
  
• подбор и заказ авиабилета;
  
• назначение ролей пользователей в SAP;
  
• заполнение форм по отсканированному документу;
  
• проведение платежа по фотографии квитанции и т. п.
  

Интересные возможности предоставляет также «связка» из роботов, работающих на сервере, и роботов, установленных на настольном компьютере пользователя. Грамотно настроенный процесс их взаимодействия позволяет перебросить часть задачи на робота у пользователя в режиме реального времени, если серверный робот не может самостоятельно выполнить какой-либо шаг процесса. Эта же «связка» может позволить клиентам самостоятельно получить сервис, возложенный на робота, который по какой-либо причине не может выполнить один или несколько шагов процесса online- обслуживания клиента (например, какие-то данные с загруженного скана документа не распознались и пользователя просят ввести их вручную).

«Облака» и RaaS (Robotics-as-a-Service)

Как же сегодня без «облаков»?

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

И влияющих факторов здесь тоже будет немало:

• поддерживает ли RPA платформа режим multi-tenancy;
  
• находятся ли роботизируемые системы уже в облаке;
  
• каковы особенности лицензирования данной платформы в режиме as-a-service;
  
• тонкости работы с персональными данными (особенно если облако находится за границей и т.п.
  

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

Что дальше?

По нашему мнению, трендами ближайших несколько лет станут:

• переход от примитивной (пусть и масштабной) роботизации к интеллектуальным роботам, интегрированным с чат-ботами и системами распознавания;
  
• обладающим легко наращиваемой мощностью за счет размещения в облаке;
  
• и оплачиваемым, как сервис, за трансакцию.