Что нужно знать перед началом роботизации процессов?

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

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

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

 Внедрение роботов облегчает нашу с вами работу, и экономическая выгода от нее не заставит себя ждать. Главное выбрать правильного поставщика услуг и вендора.

Комментарии 2

    +1
    Почему пропустили слабые стороны RPA? Уж их то перед начало точно стоит знать.
    1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).
    2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.

    В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
    Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.
      0
      Почему пропустили слабые стороны RPA? Уж их то перед начало точно стоит знать.
      1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).

      Соглашусь, но частично. Процессы для РПА зачастую берут межплатформенные и системы on-premise, по крайней мере сейчас, и компании не собираются обновлять все и сразу в короткие сроки. Пока пройдет год, два до обновления/смены систем, есть вероятность получить выгоду. Все это надо считать. Но, конечно, если планируется смена систем, обновления, доработки и пр., в очень короткие сроки, то не нужно тратить время на роботизацию.


      2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.

      В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
      Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.

      Верно. РПА очень специфичен и процессы не все под него подойдут, а софты улучшаются с каждым днем. Стараться нужно делать роботизацию на бэке, нежели подвязывать на интерфейсе, так как обновления системы будут ломать робота, и поддержка должна будет его постоянно поправлять. Разработка на бэке также увеличивает скорость обработки. Мы выводили примерную статистику «сколько раз нужно будет подправлять робота по процессам в течение года» чтобы посчитать стоимость поддержки.
      РПА не панацея, увы, но тем не менее, в отдельно взятых случаях стоит считать все риски и ситуацию AS IS чтобы в точности ответить на вопрос «стоит ли идти в роботизацию?».
      Обязательно нужно проводить преданализ и посчитать выгоду.

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

    Самое читаемое