Last Updated on 2019-10-01 by admin
Основываясь на своем опыте работы с крупными финансовыми и страховыми компаниями, мы решили рассказать вам о том, по каким же критерия следует определять применимость RPA, как избежать отсутствия планируемого от внедрения результата и, конечно, как посчитать финансовую выгоду от внедрения.
Начнем с нескольких «должно»:
– бизнес-процесс должен иметь чёткий и однозначный алгоритм работы;
– количество развилок должно быть конечно;
– все принимаемые решения должны иметь возможность быть описанными чёткими условиями. Без этого полностью автоматизировать бизнес-процесс просто невозможно;
– бизнес-процесс должен взаимодействовать исключительно с цифровыми объектами. Никакого распознание рукописного текста или голоса. Да, сейчас появляются технологии, которые позволяют решать и эти задачи, однако процент корректного распознания не велик. Роботизация таких процессов, как правило, не несёт ощутимой выгоды, т.к. все равно требует дополнительной проверки человеком.
Именно соблюдение всех этих пунктов даёт возможность применение RPA для автоматизации бизнес-процесса.
Однако применимость роботизации ещё не даёт гарантий выгоды от её внедрения. Для определения наиболее подходящих процессов мы рекомендуем основываться на следующих постулатах:
– данный процесс в промышленной среде выполняется большим числом сотрудников. Чем больше сотрудников можно освободить от выполнения рутинных задач, тем больше выгода для фирмы;
– процесс включает в себя работу с большим количеством подсистем иили системы написаны давно, с применением непопулярных на текущий момент языков программирования, и не имеют API. Этот пункт не столь очевиден, как предыдущий, однако важен с точки зрения повышения эффективности бизнес-процессов. Дело в том, что одним из особенностей RPA-технологий является единый принцип работы с графическим интерфейсом приложений. Роботу всё равно, работает он на сайте или в 1С, занимается отправкой писем или СМС. С точки зрения разработки и поддержки подход один, селекторы (идентификаторы элементов) имеют однотипную структуру. Однако есть у этого подхода и недостатки. Скорость роботизированных процессов хоть и превосходит скорость человека, однако всё равно существенно ниже, чем при автоматизации. Это обусловлено необходимостью открытия приложений и работой через графический интерфейс. Автоматизация же позволяет использовать программные интерфейсы и выполнять процесс без запуска приложений. Резюмируя, можно заключить: если приложение одно и имеет описанный программный интерфейс – стоит выбирать автоматизацию. Если процесс включает работу с несколькими приложениями, и автоматизация по программным интерфейсам затруднена – выбор роботизации наиболее целесообразен.
Кирилл Филенков, руководитель направления роботизации
компании Bell Integrator
Если говорить в разрезе работы банковских организаций, то наиболее успешное применение роботов отмечается в следующих областях деятельности: открытие счета физического или юридического лица, выгрузка выписок из АБС; обработка аудиторских запросов по сделкам; выгрузка данных по счетам клиента из АБС; проверка юрлиц на банкротство и выгрузка данных по ИНН клиента из АБС.
После того как мы убедились, что процесс можно роботизировать, необходимо посчитать финансовую выгоду. Здесь всё довольно просто. Считается фонд оплаты труда работников, которых планируется освободить от монотонного труда и затраты на роботов (лицензии и технические специалисты). Получившееся число и есть ожидаемая выгода от внедрения RPA-решений.
Например, посчитаем прямые затраты на среднестатистического сотрудника, с ФЗП в месяц (до вычета НДС) в 35 000 руб. В год ФЗП составит 420 000 руб. Приплюсуем к этим расходам страховые взносы, которые в среднем составляют 30% от ФЗП, а также полис ДМС – примерно 60 000 руб. в год, социальный пакет (премии, льготы) – 20% от ФЗП, а также расходы на обучение, подготовку, повышение квалификации – 20 000 руб. В итоге получаем прямые затраты на сотрудника – 710 000 руб. в год. В то время как ориентировочная стоимость платформы RPA составляет 600 000 руб. в год. Вроде бы разница не колоссальна, однако сотрудник будет работать только в будние дни, по 8 часов, итого 1752 рабочих часа в год. И это при условии идеального работника, который не болеет, не берет отгулы и вовремя приходит/уходит из офиса. Робот же способен работать «24×7» и в режиме максимальной эффективности нарабатывает по 8760 часов ежегодно!
Исходя из всего вышеперечисленного, 1 час работы нашего гипотетического сотрудника составит в среднем 405 рублей. Стоимость часа работы робота – 68 рублей. Прямая экономическая выгода очевидна.
Не забудьте прибавить к этому еще один аргумент – помимо финансовой выгоды, внедрение данной технологии позволяет увеличить качество процесса за счёт снижения числа ошибок, связанных с человеческим фактором, а также повысить скорость работы отдела.
Одной часто встречающейся в нашей практике типичной ошибкой при внедрении RPA является неверный расчёт необходимого количества роботов. Это ведёт к тому, что робот не справляется с большим числом заявок на работу, ожидания растут, эффективность бизнес-процесса падает. Чтобы избежать этого, перед внедрением необходимо провести исследовательскую работу, сравнив скорость выполнения процесса человеком и роботом.
Например, если человек выполняет операцию за 10 минут, а робот за 2 минуты, то 1 робот может заменить не более 5 человек. И для замены отдела в 1000 человек необходим параллельный запуск 200 роботов.
Довольно часто встречается ситуация, при которой процесс роботизируют «как есть». Выполняя точные действия пользователей, не производя аналитику и оптимизацию. Эта ошибка очень распространена, и ведёт как к увеличению затрат на разработку и поддержку, так и к снижению скорости выполнения процесса.
При запуске любого RPA-проекта необходимо проведение аналитики бизнес-процесса с целью его оптимизации под особенности RPA. Нужно создание алгоритма, который включает все возможные ветки и исключения. Также требуется описание всех входных и выходных данных процесса, чтобы предусмотреть алгоритмы при нештатных ситуациях на всех этапах процесса. Так, если в процессе работы приложение неожиданно закрывается или падает с ошибкой, необходимо повторно запустить данный процесс. Если ошибка повторяется – информировать сотрудника по почте, смс или сообщением в средство оркестрации, а параллельно создать алгоритмы на известные случаи ошибок.
К примеру, если мы знаем, что при работе с сайтом возможно появление всплывающих баннеров, мешающих работе робота, нужно научиться их закрывать и продолжать работу. Более типичные случаи, такие как – срок пароля истёк, приложение подвисло на пару секунд и др., также необходимо описывать и создавать алгоритмы работы с ними. Потому что все вышеперечисленные ситуации не должны влиять на работу робота. Иначе невозможно добиться стабильной работы и достичь максимальной эффективности бизнес-процесса.
Особое внимание при создании роботов необходимо уделить и описанию их структуры. Начиная с общего разбиения функций по классам и методам и заканчивая соглашениями в области видимости переменных и их наименований. Данный пункт особенно важен при разработке роботов командой из нескольких человек. Ведь поддержка таких машин без разработки их архитектуры подчас является довольно трудозатратной.
Итак, ваши роботы готовы, и планируете их запуск в работу. Не стоит забывать о том, что перед внедрением в промышленную среду очень важно протестировать разработанный продукт на наборе реальных данных. Это позволит избежать неприятных сюрпризов, связанных с особенностями промышленной среды и реальными данными.
Например, может оказаться, что какие-то данные приходят не в том формате, или боевая система имеет большую задержку выполнения операций, чем тестовая. Набор возможных ситуаций сложно прогнозируем. И без предварительного теста вы, скорее всего, столкнётесь с ошибками и получите сбой в продуктивной среде.
Ну и напоследок еще одна рекомендация.
Не стоит одномоментно замещать весь отдел роботами, даже если на первый взгляд робот выполняет свою работу без ошибок. При любом, даже самом простом бизнес-процессе, существуют подводные камни и скрытые алгоритмы, которые аналитики могли упустить при оптимизации. И даже если вы уже уверены в том, что всё работает, как надо, все равно заменять людей полностью не стоит. Всегда помните о том, что роботы – это такое же ПО, как и программы, с которыми они работают. А у любой программы возможны сбои и баги. Не стоит перекладывать всё на плечи роботов, надеясь, что ничего не случится. Лучше проводить замену людей постепенно, апробируя эффективность и пропускную способность. А если процесс подразумевает параллельную работу большого числа роботов, то не стоит скупиться на покупку программ оркестраторов. Это упрощает контроль и избавляет от необходимости ручного запуска.
