Роботизация процессов: технология работает, но что дальше?

0 38

Ажиотаж вокруг темы 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;
  • тонкости работы с персональными данными (особенно если облако находится за границей и т.п. 

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

Что дальше? 

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

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

Источник: bankir.ru

Оставьте ответ

Ваш электронный адрес не будет опубликован.