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

Финансы

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


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



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

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


Что дальше?


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


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

Ажиотаж вокруг темы 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) Как же сегодня без «облаков»? При рассмотрении темы роботизации часто появляется естественный вопрос: можно
0
Комментарии для сайта Cackle
Другие новости

Это может то, что вы искали