Роботизация процессов: технология работает, но что дальше? - «Финансы»
Ажиотаж вокруг темы 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;
- тонкости работы с персональными данными (особенно если облако находится за границей и т.п.
Очевидным преимуществом облака является возможность быстрого наращивания мощностей роботов – это хорошо для сценариев, где есть пиковые нагрузки. Кроме этого, поставщик облачных услуг часто может предоставить те самые сервисы ботов, искусственного интеллекта и продвинутой аналитики, с которыми робот может взаимодействовать. И это может значительно сократить время на разработку общего решения.
Что дальше?
По нашему мнению, трендами ближайших несколько лет станут:
- переход от примитивной (пусть и масштабной) роботизации к интеллектуальным роботам, интегрированным с чат-ботами и системами распознавания;
- обладающим легко наращиваемой мощностью за счет размещения в облаке;
- и оплачиваемым, как сервис, за трансакцию.