что относится к основным подходам роботизации в бизнесе
Что нужно знать перед началом роботизации процессов?
Robotic Process Automation, или сокращенно RPA, набирает все больше оборотов на рынке СНГ и Казахстана, в частности. Участники рынка обеспокоились непрерывностью своей деятельности, эффективностью и, конечно, экономией. Пандемия указала нам на дыры, которые имеются в процессах, на то, как это опасно подвязывать процессы на людях и что полная диджитализация это не будущее, это сейчас.
За последние полгода я провела огромное количество встреч с клиентами, большими и не очень, компаниями и собрала наиболее часто встречающиеся вопросы чтобы написать эту статью. Этакий FAQ от владельцев бизнеса, руководителей и исполнителей, которые каким-либо образом хотят, начали или прошли роботизацию на своих участках.
Почему я могу об этом вещать? И кем выступает моя компания?
Мы телеком оператор, который решил, что имеет право и все шансы, чтобы стать лидером рынка по предоставлению услуг роботизации, так как успешно сделал это у себя и сэкономил на этом много сотен миллионов и рабочих часов. Мы решили не останавливаться только на себе и помочь другим компаниям исправить их процессы, стать эффективнее и гибче.
Для начала давайте поймем, что такое бизнес-процесс
Да да, нужно сначала понять именно это. Так как понимание процессов могут отличаться в умах заказчика и исполнителя, что далее приведет к спорам о том, что роботизация должна дать клиенту.
Если процесс начинается с формирования заявки на закуп в январе, а получаете акт выполненных работ от поставщика, который нужно занести в базу, в декабре этого же года, то это не 1 процесс.
Видимость начала и конца процесса должно быть в рамках 1 дня, даже 1 часа.
Процесс должен быть декомпозирован на несколько подпроцессов, процедур и функций, которые имеют свою логику, но в итоге ведут к достижению единой цели основного процесса.
Каждый такой подпроцесс требует отдельного внимания. Более того, можно начинать роботизировать только отдельные подпроцессы и постепенно налаживая весь процесс целиком. Бывает такое, что процесс начинается со сбора данных, где-то на месторождении, где водитель погрузчика пишет отработанные часы на листке бумаги, подписывает у главного по участку и далее относит этот документ в кадровую службу. Кадровик делает свой расчет и далее передает экономистам и в бухгалтерию. В результате множества таких документов формируется один реестр по количеству отработанных часов поставщика услуг, соответственно зарплаты, и доходная статья бюджета для перевыставления. Вроде бы процесс начался, когда водитель заполнял от руки бумагу, но для роботизации в формате AS IS, она начинается только когда данные попадут в цифровой формат.
Итого, процесс должен быть цифровым, рутинным и повторяющимся.
Сколько мне нужно роботов?
Этот вопрос очень тревожит всех, так как многие именитые вендоры выставляют счет за каждого робота в отдельности. Поэтому любой заказчик будет заинтересован в сокращении их количества.
Робот — это, по сути, виртуальный сотрудник. У него в запасе 24 часа. Все что вы сможете уместить в 24 часа робот исполнит. Если процесс масштабный и в день вы совершаете таких операций 10 тысяч штук, где каждая операция занимает 1 минуту, то арифметика проста и ее поймет первоклассник. 10 тысяч штук делим на 1440 минут (столько минут в сутках) = 6.9.
То есть, для выполнения всех операции в рамках данного процесса, при полной загрузке, вам потребуется 7 роботов.
И так по каждому процессу.
Количество операций по процессу как 10 тысяч штук в день, это конечно очень много. И на нашем рынке может встретиться разве что в Ритейле.
Плюс ко всему, не стоит забывать, что зачастую робот работает с другими системами, соответственно, то, как они быстро будут отвечать на запросы также важно для скорости. Увы, не все зависит от робота.
Сколько будет стоить проект?
Стоимость проекта включает в себя несколько видов затрат: стоимость робота, то есть виртуального сотрудника, стоимость оркестратора, назовем его распределителем задач, либо менеджером роботов и траблшутером, студия (там где разработчик работает), виртуальные машины для каждого робота (он виртуальный, но все же сотрудник), Office, сервера либо облако.
Из опыта могу сказать, что основная статья расходов это конечно же сами роботы (более 75% чека).
Почему так дорого?
Многие клиенты почему-то ожидают что роботизация всего их отдела в 10 человек должна обойтись им примерно в 1000 баксов XD
Основные поставщики роботов приходят к нам из США. Где стоимость человекочасов достаточно высока. Один робот, который стоит примерно 8-10K USD, что ничтожно в сравнении с годовой заработной платой.
Конечно, для рынка, где средняя заработная плата 500 USD в месяц это может показаться крайне нерентабельно. Но, так ли это на самом деле? Стоит ли нам теперь отказывать себе в удовольствии на роботизацию? Нет. И вот почему.
Помимо ФОТ процесс может нести дополнительные расходы в виде штрафов, неисполнения обязательств перед третьей стороной, неправильные расчеты, ошибки и многое другое. Если считать эффективность с учетом всех этих факторов, то возможно вы уже вышли на точку безубыточности.
Также количество вендоров роботов из СНГ начинает расти. Может на сегодняшний день они немного уступают мировым аналогам, но справиться с процессами не сложными они могут и работают при этом стабильно.
Помимо этого, есть вариант облачного размещения роботов, аренды у большого интегратора, чтобы не нести дополнительные расходы.
Расчет эффективности не всегда имеет положительный знак для отдельно взятого процесса
Были и остаются кейсы, когда среди 10 процессов клиента, 1 или 2 могут показать отрицательный знак в расчете эффективности роботизации, но в общей совокупности всех процессов выходить в плюс. С чем это обычно связано? С тем, что происходит реинжиниринг процессов. Люди могут реально делать сверку документа быстрее чем робот, если, к примеру нужно прочесть только 1 строку в документе. А для робота, ее еще нужно отсканировать и внести в папку чтобы он мог ее оттуда брать. Но, возвращаясь к пункту 4 вспомним, что количество таких быстрых операций человеком, это непременно ведет к ошибкам и процесс будет совершаться еще раз, а может не один. То есть, отрицателен он как правило при расчете с учетом только видимых расходов.
Ваш робот ломается, вы плохие ребята…
Процесс работает в продуктивной среде, он уже приносит свои плоды, а владельцы бизнес-процессов могут пойти пить чай. Но не все так просто. В процессе роботизации есть несколько степов. Один из финальных степов — это стабилизация. Это когда начинают всплывать исключения, которые не были учтены в начале роботизации данного процесса. Вы забыли, что из 1000 файлов в формате docx, у вас все-таки бывают иногда и JPEG-ы, но это о как редко. Все это требует проработки со стороны интегратора и относится к данной стадии нужно с пониманием. Это не робот сломался, это обязательная часть процесса роботизации бизнес-процессов.
Конфликт интересов и саботаж
В самом начале роботизации руководство должно понять: кто имеет в роботизации самый главный интерес, чего мы хотим достичь и как всех объединить. Также, нужно дать понять людям, что станет с ними после того, как часть их работы отдадут цифровому сотруднику. Уволят? Или перенаправят на другую позицию? Если диалог ранее не состоялся между сотрудниками, чья позиция уйдет под роботизацию, и теми, кто в ней заинтересован, то ждать саботажа не придется.
Саботаж может быть как на стороне роботизируемого отдела, так и на стороне IT. Имеет место быть синдром “Not invented here”, что означает избегание использования или покупки продуктов, исследований, стандартов или знаний из внешних источников, сильное предубеждение против идей извне.
Поэтому все стороны, которые будут каким-то образом вовлекаться в процесс роботизации должны собраться на берегу и обговорить весь план взаимодействия, интересов и ролей. Даже пилотного проекта.
Я не знаю с чего мне начать, как создать Roadmap?
Начинать надо с того, что даст самые быстрые результаты и что смотивирует команду, компанию и руководство пойти на роботизацию в целом.
В первую очередь это процессы простые в разработке, но имеющиеся большом количестве, то есть, повторяющиеся очень много раз и, как следствие, требующего большого вовлечения сотрудников. Начинать разработку со сложного процесса не желательно. Зачастую это может потребовать полгода разработки, а экономия при этом окажется незначительной.
Сложные процессы — это уже следующий уровень, когда вы хорошо знакомы с RPA, нарастили экспертизу и готовы расширяться.
При неполучении быстрых результатов падает мотивация и продолжить затею вряд ли получится, как минимум, вам не выделят бюджет под инициативу.
Подытожим, в первую очередь работаем над простыми процессами в большом количестве, только затем сложные в малом количестве.
Я найму свою команду, и мы будем делать сами
Каждая компания, на самом то деле, может делать роботизацию самостоятельно. Вопрос только в том, насколько она сможет расширяться и продолжать поддерживать сложные операционные процессы, которые затрагивают целые департаменты.
Компании, которые не содержат штат IT специалистов, у которых есть достаточно времени чтобы уделять его бизнес заказчикам, делать доработки и постоянно обучаться, возможно, но нелегко и долго.
Каждый должен заниматься тем, что у него хорошо получается, прямо как у людей. Если вы транспортная компания, отдайте лучше роботизацию на аутсорс, а сами наслаждайтесь выигранным временем и расширяйтесь.
Я как консультант, почти все решения рассматриваю на цифрах. Если ваша компания не имеет продуктовой культуры, вы не руководили разработчиками, но горите желанием делать роботизацию самостоятельно, просто посчитайте сколько это будет стоить. Помимо найма и обучения сотрудников, учитывайте альтернативные издержки и потери от неэффективных процессов.
Внедрение роботов облегчает нашу с вами работу, и экономическая выгода от нее не заставит себя ждать. Главное выбрать правильного поставщика услуг и вендора.
Роботизация бизнес-процессов
Об основных областях применения, технологиях и плюсах внедрения RPA будет рассказано в представленной статье.
Что такое роботизация бизнес-процессов
Роботизация чаще всего применяется для оптимизации процессов:
Для проведения роботизации бизнес-процессов используются специальные платформы (например, PIX RPA Platform, UiPath, ElectroNeek) или дополняются существующие системы управления бизнесом (такие, как Bitrix24).
Основные технологии robotic process automation
Существует несколько разновидностей программных ботов.
В зависимости от того, для каких задач используются боты, они называются:
про-ботами. Эти боты действуют по простым, повторяемым алгоритмам обработки данных;
ноу-ботами. Они применяются для поиска в интернете информации по критериям, заданным пользователем;
чат-ботами. Эти боты («виртуальные агенты») используются для ответов на запросы клиентов в режиме реального времени.
По уровню автоматизации программные боты подразделяются на:
Attended Robots. Пользователи, которым необходимо автоматизировать свои процессы, запускают эти боты со своих компьютеров;
Hybrid. Эти боты относятся к смешанному типу.
Преимущества внедрения RPA
Роботизация позволяет ускорить и улучшить выполнение процессов, которые являются «бутылочным горлышком» компании. В частности, внедрение RPA позволяет:
повысить производительность труда персонала;
снизить рутинную нагрузку на сотрудников;
снизить число ошибок, связанных с «человеческим фактором»;
оптимизировать использование человеческих и технических ресурсов;
повысить уровень удовлетворенности обслуживаемых клиентов.
Особенно важно и полезно внедрять роботизацию в компаниях, представляющих собой разветвленную схему подразделений, или имеющих сложные производственные системы.
Научиться основам роботизации бизнес-процессов можно, пройдя обучение на курсах, которые проводит ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ. Записаться на данные курсы можно на нашем сайте.
Роботизация бизнес-процессов: что это и где используется?
Согласно отчету Global Market Insights, к 2024 году рынок роботизированных бизнес-процессов достигнет 5 млрд долл. США. Внедрение таких технологий расширяет возможности организаций и увеличивает их производительность. Поэтому сегодня мы поговорим о том, что такое роботизация процессов и где ее эффективно используют.
Что такое роботизация бизнес-процессов?
Роботизация бизнес-процессов (с англ. Robotic Process Automation, RPA) — это использование программного обеспечения с искусственным интеллектом (ИИ) и возможностями машинного обучения для обработки повторяющихся задач большого объема, которые ранее требовались для выполнения людьми. Эти задачи могут включать запросы, расчеты и ведение записей и транзакций.
Приведем простой пример роботизации: работу человека-грузчика может заменить робот, который перемещает больше продукции за меньшее количество времени. Он не будет болеть, брать отгулы и отпуск, совершать ошибки, а также требовать выплату заработной платы. В этом заключается экономия затрат организации и в целом эффективность использования роботизированных систем.
RPA-технология
Роботизация бизнес-процессов состоит из программных роботов (ботов), которые могут имитировать человека-работника. Боты могут входить в приложения, вводить данные, вычислять и выполнять задачи, а затем выходить из системы. В настоящее время практики делят технологии RPA на три обширные категории:
Программное обеспечение RPA не является частью IT-инфраструктуры организации. Вместо этого роботизация находится на вершине, что позволяет компании быстро и продуктивно внедрять эту технологию. Над RPA-технологиями трудится армия специалистов, которые создают эффективные решения для бизнеса.
Что отличает RPA от традиционной IT-автоматизации? Это способность быть в курсе и адаптироваться к изменяющимся обстоятельствам, исключениям и новым ситуациям. После того, как программное обеспечение RPA обучено захватывать и интерпретировать действия определенных процессов в существующих программных приложениях, оно может манипулировать данными, инициировать ответы, новые действия и автономно взаимодействовать с другими системами.
Примеры роботизации
Практически во всех сферах используется роботизация бизнес-процессов. Вот несколько удачных примеров:
Кроме того, RPA широко используется на производственных процессах. Промышленные роботы применяются как для изготовления продукции, так и для ее упаковки и транспортировки.
Роботизация бизнес-процессов призвана улучшить работу десятков тысяч организаций. Особенно она полезна для компаний, имеющих разные и сложные системы, которым необходимо плавно взаимодействовать друг с другом. Помимо повышения продуктивности труда, роботизация обеспечивает экономию затрат для повторяющихся задач, увеличение скорости производственных процессов и улучшение сервиса.
RPA | Роботизация процессов глазами аналитика
Последние полтора года я занимаюсь внедрением и развитием в компании блока RPA на одной из популярных платформ.
Четкого проекта внедрения не было: руководство подсмотрело у дружественных организаций «модную» технологию, дало мне задачу прощупать тему и бросило подразделениям клич по сбору заявок на автоматизацию.
Эта публикация зародилась как план выступления перед коллегами, заинтересованными во внедрении роботизации и знакомыми лишь с рекламными материалами. Признаюсь, что при переносе этих мыслей на публичный ресурс мне было сложно определиться с целевой аудиторией и вырезать только подходящий ей фрагмент. Бизнес-заказчикам, менеджерам проектов и просто интересующимся она должна дать упорядоченное представление о технологии и общих подходах. В остальном это личные впечатления человека, который любит решать процессные задачи и недостаточно усидчив для того, чтобы быть программистом. Технические детали намеренно опущены – разработчикам я здесь ничего интересного не расскажу.
Что такое робот и что он умеет
С точки зрения участия в бизнес-процессах компании робот – это виртуальный сотрудник-оператор. Вот как живой, только:
Уже читали это в презентациях? Ну ок, это правда.
Он оперирует формальной логикой:
Более сложный пример: Сценарий обработки входящих сообщений, в котором для двух типов сообщений реализованы разные алгоритмы обработки. Определение типа сообщения было реализовано по стабильно повторяющейся теме одного из типов. При очередном обновлении сервиса тема изменилась. Робот успешно выполнял сценарий без сбоев, но выбирал при этом неправильную с точки зрения бизнеса обработку.
Важный вывод из этого пункта: в изменяющихся условиях формально успешное выполнение сценария не гарантирует корректный бизнес-результат! Этот результат необходимо своевременно контролировать – хорошо, если это происходит естественным образом при его обработке на последующих этапах процесса.
У сотрудника-оператора есть старший сотрудник или начальник, к которому можно обратиться при возникновении непредвиденных ситуаций. Для робота тоже должны быть такие кураторы по каждому процессу.
Сотрудник работает на своем ПК или в терминальной сессии, каждый робот также работает в своем собственном окружении. Если бы и можно было запустить в одной сессии несколько роботов, это привело бы к печальным последствиям: попробуйте с коллегой подключить к одному компьютеру две клавиатуры и набирать каждый свой текст.
С точки зрения автоматизируемых приложений робот – это обычный пользователь, который нажимает на кнопки, вводит и считывает данные. Если приложение лицензируется по количеству одновременных подключений – робот займет лицензию при работе в нем.
Помимо взаимодействия с экранными формами приложений, роботы на используемой мной платформе умеют:
Существует и альтернативная форма использования – виртуальный помощник: робот запущен в окружении реального пользователя, который при необходимости запускает тот или иной сценарий, или робот сам реагирует на наступление предусмотренного события. Напоминает использование макросов, только для разработки подобных сценариев не требуются специальные навыки (зато требуются лицензии RPA).
Задачи, которые решает робот
Что роботизировать
Итак, мы используем виртуального сотрудника, чтобы он выполнял формализованные сценарии.
С точки зрения эффекта от роботизации приоритет должен быть за несложными, но продолжительными и часто повторяющимися процессами. Тут все просто:
У меня уже год в очереди висит задача, выполнение которой сэкономит одному сотруднику один раз в месяц по часу времени. Я к ней приступлю тогда, когда закончатся задачи с более ощутимым эффектом.
Точки входа и выхода для робота должны быть плавно встроены в общий процесс, чтобы не нужно было прилагать значительных усилий для передачи задания роботу или сбору результатов его работы.
Помимо высвобождения человеко-часов есть и менее очевидный фактор – цена ошибки. В хорошо формализованном процессе вероятность незамеченной ошибки у робота ниже, чем у человека.
В предыдущем разделе я упоминал про возможность некорректного с точки зрения бизнеса результата – обратите внимание на приведенные формулировки и оцените условия выполнения интересующего сценария. Также отлично показывает себя практика, когда робот перепроверяет результат работы человека по заданным правилам и передает на ручной разбор выявленные проблемы.
Плохо подходят под роботизацию процессы:
Но часто и здесь есть выход – комбинировать роботизацию с ручным принятием решений:
Не стоит запускать роботизацию и там, где она попросту не нужна, или заказчик пытается в своем представлении подменить роботом доработку конкретного приложения.
Пример 1:
– Мне нужно, чтобы робот отслеживал получение новых писем на общий почтовый ящик и при поступлении новых пересылал их по списку рассылки.
– Попросите администраторов настроить переадресацию на почтовом сервере.
Пример 2:
– Мы каждое утро печатаем огромное количество документов. Можно сделать так, чтобы мы пришли утром, а робот уже все напечатал, мы подпишем и отправим?
– Технически это возможно, но есть несколько вопросов: Кто будет контролировать ночью наличие бумаги, краски и качество печати? Удобно будет потом фасовать напечатанное по стопкам и подписывать? Удобно будет контролировать и отмечать, что подписали и отправили? С учетом всего этого, много времени сэкономит такая автоматизация?
–…
Тем не менее, использование роботов – отличный выход, если выполнение необходимых операций возможно, а автоматизация средствами самой системы потребует значительных временных и финансовых ресурсов.
Несколько примеров направлений, подходящих под роботизацию:
Управление рисками
Поговорим о том, что может пойти не так:
Риск | Комментарий | Как управлять |
---|---|---|
Ошибки логики сценария | Ошибка разработчика. Ошибаются все – вопрос в том, насколько грубо и насколько сложно исправить ситуацию. | Хорошая читаемость сценария уменьшает вероятность появления ошибок и упрощает их поиск и исправление. По возможности должно быть предусмотрено рецензирование сценариев. Разработчик и заказчик в первое время после внедрения или доработки сценария наблюдают за результатами запусков. |
Ошибки постановки задачи | Во многих случаях на этапе сбора требований описывают только самый простой вариант развития событий. Даже после наводящих вопросов не вспоминают все ситуации, когда что-то идет не по плану, и не упоминают необязательные диалоговые окна и уведомления, которые может выдавать приложение. Это нормально. Мы потому и роботизируем эти операции, что они механические и при их выполнении исполнитель часто действует неосознанно. | По возможности привлекать экспертов к постановке задач. Разработчику придется уточнять последовательность действий когда неописанная ситуация возникнет при разработке или уже в эксплуатации сценария. |
Сбой платформы RPA | Проблемы непосредственно с функционалом роботов: закончился срок действия лицензий, зависло приложение робота, сбой на стороне модуля управления запуском роботов. | Необходимы наблюдение и контроль. |
Сбой окружения | Что-то в окружении робота мешает выполнить сценарий. Например: * cистемные уведомления, которые блокируют доступ к формам приложений: уведомления об обновлениях windows, отчеты об ошибках, уведомления службы предотвращения выполнения и т.п. * нет свободной оперативной памяти * переполнен диск. | Все системные уведомления для робота необходимо отключить. За оперативной памятью и диском необходимо наблюдение. |
Сбой инфраструктуры | Недоступны связанные с выполнением сценария внутренние сервисы. Например, робот не может отправить уведомление из-за сбоя почтового сервера или выложить файл на сетевой диск из-за проблем в дата-центре. | Это аварии в масштабах компании, которые устраняет IT. |
Сбой целевого сервиса | Недоступны целевые для сценария сайты или приложения. | Необходимо обращаться к администраторам и службам поддержки соответствующих ресурсов. |
Обновление автоматизируемого сайта/приложения | При работе с внешними системами это самая острая проблема RPA. Хорошо, если есть тестовая среда и регламентирован порядок обновления. Но это часто не так даже с системами, используемыми внутри компании, не говоря уже про внешние. Просто в один прекрасный момент они начинают вести себя по-другому в части, критичной для сценария. И тут два варианта: 1) при выполнении сценария происходит сбой: робот не находит нужное окно, кнопку, поле в таблице и т.п. 2) Сбоя не происходит, но результат становится некорректным. | В первом случае все просто: разработчик получает уведомление о возникшем сбое, при анализе понимает, что произошло обновление, и выполняет доработку сценария. Иногда требуется незначительная правка, иногда изменение логики сценария. Это будни. Во втором случае помогут своевременный контроль результата и фантазия разработчика, предусматривающего лишние проверки «на всякий случай». |
Некорректные бизнес-настройки | Без предупреждения изменены или не актуализированы нетехнические настройки, за которые отвечает бизнес. Например, бизнес-пользователи по каким-то причинам производят замену сертификата, используемого в сценарии обмена сообщениями, робот продолжает использовать старый – возникает сбой. | Всегда должен быть куратор от бизнеса, который следит за актуальными настройками и своевременно оповещает о внесении изменений. |
Потеря компетенции у бизнес-пользователей | После роботизации процесса у бывших исполнителей появляется соблазн полностью отстраниться от участия в процессе, в том числе в разборе сложных ситуаций и ручном исполнении в случае сбоя. А в случае замены сотрудников может возникнуть ситуация, когда уже никто со стороны бизнеса не знает, как выполнить нужные операции. | Это снова про куратора процесса. Также должен быть определен план действий (или смирение с потерями) в аварийном случае, когда сбой роботизации невозможно оперативно устранить. В некоторых случаях стоит оформить и сохранить инструкции по выполнению операций. |
Безопасность | Робот со временем обрастает связкой «ключей от всех дверей». Взлом сервера скомпрометирует все учетные данные, которые там хранятся. | С осторожностью назначать права доступа. При необходимости изолировать окружение робота от корпоративных ресурсов. Хранить используемые в сценариях пароли только в зашифрованном виде. И вообще, специалисты ИБ могут давать отличные советы, когда не заняты затягиванием согласований. Кстати, некоторые из платформ RPA прошли сертификацию на соответствие стандартам ИБ. |
Всё это либо общие для IT риски, либо следствия неопределенности при работе с неподконтрольными сервисами и приложениями. При «классической автоматизации» работы с внешними веб-сервисами точно так же возникнет сбой при неожиданном изменении последних.
Идеальный пример с точки зрения управления рисками: RPA внедряется в компании с единственной целью – «загнать» десятки роботов в SAP конкретную информационную систему. Экономический эффект просчитан, разработкой сценариев занимаются опытные специалисты, сформулированы детальные ТЗ с привлечением экспертов, все взаимодействие регламентировано, среды контролируются, отлажен порядок тестирования.
Но это лишь один из вариантов использования роботов.
О постановке задач
Условно можно выделить два подхода к постановке задач:
«Сверху» | «Снизу» |
---|---|
Задачу ставит подразделение или лицо, которое управляет бизнес-процессом | Задачу ставит конечный исполнитель операции или его непосредственный руководитель |
Заказчик видит весь процесс и может явно выделить этапы, где необходимо вмешательство ответственных сотрудников, а где механическая работа, которую стоит отдать роботу | Заказчик видит свою ежедневную деятельность и стремится избавиться от рутинной работы |
Заказчик может оценить трудозатраты, эффект от роботизации, критичные сроки и точки соприкосновения этапов | Заказчик оперирует понятиями «долго» и «неудобно», точки входа и выхода робота могут быть выбраны нерационально, задачи разных заказчиков могут пересекаться и даже противоречить друг другу |
На выходе получается роботизированный бизнес-процесс | На выходе получается роботизированная операция |
Первый подход дает более понятный эффект для организации, но требует наличия культуры управления проектами и бизнес-процессами.
При втором подходе нужно более внимательно анализировать запросы заказчиков на целесообразность и непротиворечивость. Но он не так уж и плох, не отменяет положительный, хоть и неопределенный, эффект от внедрения, а из реализованных порознь операций тоже можно впоследствии собрать цельный процесс.
Исходя из обозначенных ранее рисков, при постановке задачи необходимо:
О сроках
Срок разработки и запуска в эксплуатацию сценария не может быть постоянной величиной, он зависит от:
В простом случае со сценарием проверки новостей на сайте можно управиться за пару часов разработки. Самые сложные задачи, которые у меня были, требовали до 2 недель разработки. В качестве «сферической» средней величины можно взять 1-3 дня чистого времени.
Очень часто в процессе разработки сценария выявляются неописанные постановкой ситуации, постановка расширяется, что также влияет на срок запуска.
Есть еще и непрогнозируемые факторы простоя:
Замечу, что RPA хорошо вписывается в гибкие подходы.
Часто можно уже через несколько часов разработки показать заказчику прототип сценария с хотя бы частично реализованной бизнес-логикой, на этом этапе могут быть выявлены дополнительные требования, о которых не вспомнили при постановке задачи. Разумеется, на этом разработка не заканчивается – предстоит проработка деталей и работа над отказоустойчивостью. Последним можно пренебречь разве что в «одноразовых» сценариях, что позволяет очень оперативно прийти на помощь бизнесу.
А иногда заказчики заинтересованы в поэтапном внедрении с оценкой промежуточных результатов.
Архитектура
Минимально необходимых компонента всего два:
Робот, который выполняет один из доступных сценариев по команде
Робот должен быть запущен в интерфейсной сессии, иначе он не сможет взаимодействовать с экранными формами приложений. Есть несколько вариантов в каком окружении запускать робота, это может быть:
Или в этом окружении должны быть установлены и настроены приложения, которые использует робот при выполнении сценариев, или робот может использовать RDP/Citrix подключение к удаленному серверу с необходимыми приложениями.
В такой конфигурации уже можно запускать сценарии вручную, в определенных случаях этого будет достаточно. Напомню, что в этом случае робот может «общаться» с пользователем с помощью диалоговых окон.
В предлагаемый вендорами комплект также входит компонент управления запуском сценариев. Помимо собственно запуска он может:
У меня же управление реализовано на стороне SQL сервера.
Связка RPA с другими сервисами позволяет существенно расширить возможности роботизации:
Выбор платформы
О знакомстве с функционалом
Вендоров RPA несколько десятков. При первичной выборке я обращал внимание прежде всего на наличие открытой документации и пробного периода – и это исключило почти всех.
Как можно получить представление о конкретном решении:
О стоимости
Несмотря на ажиотаж вокруг технологии роботизации, стоимость внедрения и эксплуатации не обязательно высока.
Существуют даже бесплатные версии платформ RPA, имеющие некоторые ограничения (не обязательно функциональные). Отдельные возможности можно реализовать и на решениях, не относящихся к миру RPA: средства автоматизации управления web-браузером, макросы, сценарные языки, системы автоматизации тестирования и т.д.
В качестве примера крайности: в организации малого бизнеса используется бесплатная платформа RPA, разработкой несложных сценариев занимается штатный IT-специалист. Бизнес несет расходы только на инфраструктуру.
Другая крайность: использование десятков и сотен роботов в условиях высокой нагрузки, большие команды разработки из сертифицированных разработчиков. И на лицензии, и на ФОТ порядок затрат будет в десятках миллионов рублей в год. Становятся заметными расходы на инфраструктуру.
Посередине между ними варианты с покупкой минимально необходимого набора лицензий на коммерческие версии платформ с использованием штатного модуля управления запуском (порядок затрат на лицензии в миллионах рублей в год), так и без него (от нескольких сот тысяч рублей в год).
Есть разные варианты привязки лицензии на робота и Студию, но общий подход такой: «один одновременно запущенный экземпляр = одна лицензия».
Чего не хватает в используемой платформе RPA
Платформы RPA регулярно обновляются и приобретают новые возможности.
Но вендоры так сконцентрированы на добавлении функционала, что часто не обращают внимания на удобство использования при разработке сценариев.
Кстати, баги с этими обновлениями тоже появляются.
Все мои пожелания сводятся к процессу разработки сценариев:
По моему мнению, идеологически неправильно представлять операции с экранными формами приложений и сайтов в виде простой последовательности действий. Это выглядит лаконично и легко для восприятия, но не способствует грамотному подходу к отказоустойчивости.
Простой пример: робот нажал на кнопку (а точнее попытался нажать) и 5 минут ждет появления сообщения «ОК». Если сообщение появилось – хорошо, если нет – возникает сбой. А если приложение «вылетело» через 10 секунд после нажатия кнопки? А если через две минуты возникло сообщение об ошибке? Робот все равно будет ждать 5 минут, не сможет выполнить второе действие – чтение сообщения, и только тогда выведет сбой.
Я использую собственные шаблоны и библиотеки, в которых это учтено, но от их использования в сценарии страдает читаемость, гораздо удобнее и нагляднее был бы встроенный контейнер по примеру тест-кейса:
Что сделать | Что должно произойти | Чего точно не должно произойти |
---|---|---|
Нажать кнопку | Появилось сообщение «ОК» | Не должно появиться сообщение об ошибке Приложение не должно пропасть из списка запущенных процессов |
У меня еще есть опция периодически повторять инициирующее действие (а если приложение просто не среагировало на нажатие кнопки?).
Здесь смысл не столько в том, что неудобно и плохо читается, а в том, что это должен быть стандарт работы с экранными формами.
Не хватает многопоточности в рамках сценария.
Даже имеющийся контейнер параллельной работы всего лишь выполняет действия из потоков поочередно, ожидание одного потока тормозит другой.
Хотелось бы иметь возможность в дополнение к основному процессу, например:
Как развитие предыдущего пункта – автоматический выбор настроек мне только мешает, приходится специально каждый раз переоткрывать формы настроек, проверять, перевыбирать, исправлять. Это касается:
Явное указание этих настроек при инициации вместо присвоения значений «по умолчанию» было бы гораздо лучше.
Требования к разработчикам сценариев
Подходы к разработке
Любой сценарий и состоит из действий (Activity). Они выполняют полезные операции: кликнуть мышкой, присвоить переменной значение, объединить файлы pdf в один и т.п. В их свойствах разработчик сценария уточняет, как именно нужно выполнить действие.
Вендоры платформ предлагают большой набор готовых действий, что позволяет «программировать квадратиками» без навыков разработки.
Существуют даже специальные версии Студии, ориентированные на бизнес-пользователей и предельно упрощающей процесс разработки сценариев и скрывающие «лишние» настройки. Впрочем, создать в них получится только простые линейные сценарии.
Некоторые платформы RPA предоставляют возможность использовать только заранее предусмотренные вендором действия.
Некоторые – предусматривают возможность расширения за счет:
Обучение
Технология RPA легка в освоении, общий принцип работы в большинстве случаев интуитивно понятен.
Хорошо, если вендор поддерживает портал с актуальной документацией и форум, где можно найти ответы на многие вопросы.
Для некоторых платформ также есть специальные порталы с обучающими курсами и возможностью получения сертификатов. Там клиенты могут самостоятельно обучать своих сотрудников… вырвав их из рабочего процесса на несколько недель.
Ключевые навыки
Каким же должен быть разработчик сценариев RPA? Не обязательно опытным программистом, это мы уже выяснили.
Работа с заказчиками, обследование процессов, поиск обходных решений, предложение лучшего варианта реализации, анализ возможных точек сбоя, разработка алгоритмов как в части сценария, так и в части формализации бизнес-процесса – для этого нужно быть прежде всего аналитиком. Подход «просто делать что сказали» здесь работает плохо.
Ну что ж, я не все понимаю в этой жизни.
Если сузить вопрос до перечисления навыков и технологий, то это прежде всего:
Следующие навыки менее важны, требуются не всегда и/или придут с опытом:
На старте внедрения о последних трех пунктах я имел лишь приблизительное представление.
Уверенные навыки работы с данными и алгоритмами мне дала работа аналитиком в целом и с базами данных в частности.
Заключение
Я выделяю 3 ключевые особенности технологии RPA, которые отличают роботизацию от «классической» автоматизации и других решений создания сценариев:
Благодаря этому у роботизации широкие возможности применения для бизнеса разных масштабов.
RPA не только дает инструменты решения прикладных задач, но и настраивает на работу прежде всего с процессами, не ограничиваясь автоматизацией конкретных информационных систем. Роботизация способствует постановке правильных вопросов и даже может помочь на пути формализации бизнес-процессов.
Мне же, как аналитику: