Рукотворная пропасть или путь от пилота RPA к внедрению в масштабах компании

[@zxweed]

софт, записывающий действия пользователя в макросы — известен уже много десятилетий, с чего вы решили, что это — новая революция?

[@ilya_kochetov]

TL;DR версия: целое всегда есть нечто большее, чем простая сумма его частей, RPA это подрывная инновация

Все так, макросы начали использовать в 80ых. И BPM системы, которым RPA обязано многим, с 90ых годов начинают отсчет. Автоматизированное тестирование, технология, которая с RPA имеет очень много общего, начали серьезно использовать примерно 20 лет назад.

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

В жизненном цикле инновации

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

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

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

[@WizardryIB]

Моё отношение к RPA неоднозначно. С одной стороны быстрое получение эффекта для владельца бизнеса, сокращение FTE, освобождение от операций и сотрудников в бизнес процессах, предоставление легкого пути в достижении краткосрочных результатов… С другой — моральное право и ответственность за обеспечение новых рабочих мест, создание новой прослойки жестко связанного проприетарного программного обеспечения, цементирование и потеря гибкости внедрения новых систем…

[@ilya_kochetov]

моральное право и ответственность за обеспечение новых рабочих мест

.
Если у вас есть реальные кейсы про сокращения — поделитесь плиз, очень интересно!
В тех случаях, с которыми знаком я, внедрение RPA не приводило к сокращению штатных единиц. Один раз, на моей практике, роботы заменили кучу фрилансеров, выполнявших работу аля Yandex.Toloka или Amazon Turk, вот тут да, от их услуг отказались.
В остальных ситуациях, обычно, происходит совсем другое — у компаний есть проблема перегруженности сотрудников, отсутствия возможности развивать то ли иное направление из-за дефицита кадров, то, что умные люди большую часть времени «перекладывают бумажки». Внедрение RPA приводило к тому, что «процессы раскатывались», люди переставали работать сверхурочно и начинали приносить реальную пользу, работая головой.
Наверное особенно «жесткое» руководство в период кризиса будет пытаться сокращать штаты с помощью роботов, но в большинстве случаев это даже наоборот, повышает качество жизни.

создание новой прослойки жестко связанного проприетарного программного обеспечения

Сейчас у большинства компаний продающих роботов модель лицензирования — ежегодная подписка, аля Office 365. И есть у меня кейс, когда люди решили уйти от текущей платформы к нам. Причем за буквально месяц до окончания срока подписки, когда их роботы перестали бы работать. Я был уверен, что это будет ситуация «ужаса без конца», потому что разработчики видели нашу платформу впервые, но по итогам все прошло быстро и четко (мы помогали, но чисто техническими консультациями).
Как показал опыт, 80% трудозатрат на роботизацию — это формализация бизнес-процесса (или его роботизируемых кусков). В самом роботе, код процесса, сам по себе, служит некой «документацией». При переходе на другую платформу, на уже отлаженном и отработанном процессе, это чисто техническая, не очень сложная задача.
Сами роботы или процессы — намного легче и проще, чем «правильная» интеграция, они обычно пишутся очень быстро и сильно меньше по размерам, чем код полноценных систем.

цементирование и потеря гибкости внедрения новых систем

вот здесь не соглашусь категорически. Как раз это — супер-преимущество роботов, если что-то поменялось, робота можно без особых потерь переписать, за то же, или меньшее время, чем потребовалось бы на переобучение сотрудников и уж точно за много меньше время и деньги, чем потребовалось бы на переделку интеграционного слоя (если мы не говорим про хорошо сделанные микросервисы, конечно, но где они есть :)