Инструкция: как внедрить программного робота (и кому это действительно нужно)

Что можно поручить роботу

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

Комплексно оцените целесообразность внедрения. Оценка должна включать четыре параметра:

• FTE – число задействованных в процессе сотрудников (full time employee)
• ST – число сотрудников, поддерживающих RPA-процесс (support team)
• CF – фактор сложности процесса (complexity factor)
• VF – фактор волатильности (изменчивости) процесса (volatility factor)

Измерив каждый показатель, можно разместить любой процесс на системе координат, где по оси ординат будет сложность и волатильность, а по оси абсцисс – число персонала (FTE). Систему координат с проставленными на ней процессами можно разделить на четыре квадранта критериев-рейтингов:

• Р1 – безусловно целесообразно
• Р2 – скорее целесообразно
• Р3 – скорее нецелесообразно
• Р4 – нецелесообразно

Применение RPA практически не зависит от отрасли. Но сегодня мы можем назвать сферы бизнеса, где эта технология наиболее востребована:

• Финансовый сектор и банки
• Фармацевтика
• Складское хозяйство
• Ритейл
• Страхование
• Металлургия
• E-commerce
  

В этих отраслях большой объем задач, часто стабильных и редко изменяемых, что делает их отличной площадкой для автоматизированной роботизации.

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

Как рассчитать затраты по внедрению

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

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

Пример. Расчет эффективности удобнее делать на примере. Возьмем один из типовых процессов – сбор и сверку актов с контрагентами с разнесением в базу данных и систему электронного документооборота в одном крупном холдинге. В компании этим процессом занимаются восемь сотрудников по всей стране. Это обходится организации в 7 648 000 рублей в год (зарплата, рабочие места и прочее). Так называемая рабочая группа людей в течение года с учетом праздников и отпусков отводит приблизительно 5 448 полезных человеко-часов.

Перейдем к расчетам по RPA. Траты на робота делятся на лицензии в год, разработку и поддержку. Под эту задачу нужно приобрести пакет лицензий UiPath стоимостью примерно 280 000 рублей в год. Оценка трудозатрат: 950 000 рублей и четыре месяца по срокам. 

В итоге срок окупаемости за первый год составит 7 месяцев. Следует учесть, что в первые месяцы рабочая группа все так же будет сопровождать процесс вручную пока разрабатывается алгоритм для робота. Поддержка может быть оказана как внутренним центром компетенции, так и внешним по контракту. На этот процесс закладывается 450 000 рублей в год.

Итого за первый год экономия составляет 39,1% (2 993 334 рубля), а за второй, где уже тратиться нужно лишь на лицензии и поддержку , – 90,9% (6 955 000 рублей).

Как внедрить робота

Подход к внедрению стоит делить на 3 главных этапа:



Первый этап – детализация и пилот. В этом процессе главное – правильно определить «подопечного», ведь от успешности внедрения RPA на нем зависит многое. На первом этапе происходит классический ряд действий:

• Анализ процесса «как есть» и «как будет»
• Определение целевой архитектуры
• Концептуальное проектирование, тестирование «хваткости робота»
• Разработка, тестирование и отладка
• Демонстрация
  

После реализации пилота RPA лидер (он же, вероятно, спонсор) принимает решение о масштабируемости, и команда RPA переходит на следующий этап.

Второй этап – оценка влияния на операционную модель:

• Описание процесса «как есть» и «как будет»
• Расчет экономического эффекта
• Анализ текущих и целевых показателей
• Приобретение ПО
• Подготовка к тестовой/промышленной эксплуатации

В результате этапа у вас появится план по роботизации процесса, в результате выполнения которого будут достигнуты зафиксированные показатели по приросту бюджета/скорости/качества, подготовлена почва для непосредственной разработки.

Третий этап – внедрение и/или масштабирование:

• Разработка алгоритма по методу гибких методик
• Настройка робота
• Его интеграция в систему управления
• Внедрение и промышленная эксплуатация
• Донастройка робота по результатам тестирования
• Оценка эффективности его работы
  

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

Тестируем робота на «хваткость»

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

Например, чтобы кликнуть на элемент на сайте мы можем попробовать следующие способы:

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

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

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

Разработка MVP робота: почему заказчику важно участвовать

Аббревиатуру MVP ввел Фрэнк Робинсон еще в 2001 году, но популярность она получила благодаря гибким методологиям, где продукт разрабатывается инкрементально и итеративно. MVP – это минимально жизнеспособный продукт, он же – прототип RPA. Прототип содержит в себе самые основные функции, которые мог бы выполнять робот, для того, чтобы выполнить задачу по заданному процессу. Он характеризуется:

• Заранее известными входными данными
• Отсутствием ошибок (прототип не подразумевает реагирование на исключения)
• Самым коротким исходом
• Отсутствием цикличности или работы с массивами/списками (опционально)

Почему так? Реализация прототипа показывает две вещи:

• Робот успешно прошел испытание «хваткости», и он способен работать со всеми элементами по своим задачам
• Команда разработки RPA правильно поняла поставленную задачу
  

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

Выбираем стратегию внедрения робота

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

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

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

Остановиться на одном процессе или роботизировать бизнес дальше? 

Увидев прирост по бюджету и скорости, компании редко останавливаются на роботизации одного процесса. Также приняв тот факт, что в основном пилоты загружают робота не более чем на 25%, можно спокойно «вешать» на того же виртуального работника другие процессы, которые он будет выполнять. Следовательно, под них не нужно будет закупать лицензии.

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

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

Источник: RB.RU