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

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



Ажиотаж вокруг темы 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;

  • тонкости работы с персональными данными (особенно если облако находится за границей и т.п.

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


Что дальше?


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


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

  • обладающим легко наращиваемой мощностью за счет размещения в облаке;

  • и оплачиваемым, как сервис, за трансакцию.

ДОБАВИТЬ БАННЕР