"Идеи о разработке бизнес-пользователями ходят уже давно, и многие вендора стараются предложить свои решения именно для бизнес-пользователей" - многие вендоры сейчас предлагают low-code и no-code платформы для внедрения автоматизации бизнес-пользователями. Я согласен с тем, что RPA разработка - это инструмент для лёгкой и быстрой автоматизации, который даёт хороший результат, но к нему надо относиться аккуратно и разграничивать доступ к этому инструменту для рядовых пользователей.
Действительно, научиться разрабатывать роботов может каждый, но не все могут делать это хорошо. Далее я расскажу, почему я, как технический разработчик RPA, пришел к такому выводу.
Начиная свой путь в RPA у меня уже были некоторые базовые понимания таких вещей как:
Концепция ООП
Regex
Масштабируемость
Отказоустойчивость
Чистый код
Оптимизация алгоритмов
Форматы обмена данных JSON, XML
Работа с различными структурами данных
Всё это дало мне хороший старт в RPA, где помимо разработки и поддержки мне доводилось заниматься администрированием терминальных серверов и спасать пользователей от самих себя.
RPA разработка это не Rocket science, но некоторый набор знаний и компетенций всё же обязателен. Всё это можно изучить попутно, однако, в таком случае, потребуется гораздо больше времени, усилий и ошибок, которые лягут на плечи коллег и работодателя.
Что, если сравнить решения автоматизации работы с Excel-файлом технического специалиста и бизнес-разработчика без опыта разработки?
Если брать базовую задачу по автоматизации Excel файлов, то решение для бизнес-разработчика и технического специалиста будет сильно отличаться. Решение бизнес-разработчика, вероятно, будет хорошо работать с файлами небольшого размера, это даст быстрый profit, но что произойдёт, если файл увеличится с нескольких десятков строк до нескольких тысяч, либо изменится формат файлов, их количество или необходимо будет изменить логику работы? Если потребуется запускать бота сотни или тысячи раз в месяц?
В данной ситуации во главе угла будет стоять опыт разработчика.
Основным преимуществом технического специалиста будет являться его способность видеть более масштабную картину происходящего, а также видеть и прогнозировать узкие места текущего решения, так называемые bottle necks. Несомненно, этому можно научиться, но это займёт у бизнес-разработчика гораздо больше времени, к тому же этот опыт будет нарабатываться только на реальных проектах, с реальными задачами, которые почти всегда уникальны.
Всё это сильно усугубляется тем, что организации, не являющиеся специализированными на IT, зачастую, не обладают чётко отлаженной работой в области системного администрирования и склонны к постоянным изменениям архитектуры, которые часто могут приводить к сбоям и нестабильной работе в самих используемых в роботах системах, таких как SAP, 1C, CRM, ERP, почтовых серверов, внутренних системах и прочих.
Работа в нестабильно работающих и часто изменяющихся системах тоже является вызовом для разработчика RPA - здесь потребуется способность правильно выстраивать процесс работы в случае любых непредвиденных ситуаций на любом этапе и настройка роботов на перезапуск без потери проделанной роботом работы. Если при проводке документа система даст сбой, робот обязан должен будет правильно проанализировать этап ошибки и не сделать проводку по второму разу.
Всё перечисленное требует от разработчика глубоких знаний и специфического опыта.
Оптимальным решением для роботизации процессов в компании будет хранение всех наработанных практик в рамках одного централизованного подразделения и установление в подразделении жёстких рамок и единого взгляда в подходе к архитектуре роботов, в том числе и с точки зрения информационной безопасности(!). Также централизованная работа подразделения даёт такие бонусы, как единая база переиспользуемых компонентов, скриптов, лучших практик, что при должном уровне взаимодействия и коммуникации между членами команды даст огромную экономию времени в перспективе. При наличии децентрализованной разработки, когда в разных подразделениях присутствует свой бизнес‑разработчик, оторванный от единой практики, теряет эти преимущества.
Таким образом, стандартизация, контроль качества и налаженная коммуникация являются залогом стабильно работающего ПО не только в классической разработке, но и обязательно в RPA.
Также одной из наиболее неочевидных проблем для руководства, которое занимается внедрением citizen-RPA разработки, является необходимость в поддержке и обслуживании роботов, ведь написать своего робота на самом деле несложно, но из виду упускается то, что роботы, как и любая сложная система, могут требовать донастройки, оптимизации и внесению изменений. Неопытные разработчики склонны чрезмерно усложнять логику работы робота, что может привести к тому, что другие разработчики не смогут разобраться в сложной реализации и, в случае, если сотрудник покинет компанию - это может потребовать больших средств, чтобы поддерживать робота, либо переписать его заново (!).
Еще одной неочевидной проблемой может являться то, что при наличии текучки кадров, при увольнении бизнес-разработчика можно просто потерять сведения о том, как тот или иной процесс выглядел до роботизации, хотя это справедливо не только для бизнес-разработчиков.
Подводя итог, хочется подчеркнуть, что при внедрении RPA самым правильным решением будет создание единого подразделения и, в случае наличия талантливых сотрудников, которые хотят попробовать себя в разработке, делать их полноценными участниками практики, развивая их как полноценных, технических специалистов, не делая из них универсальных бизнес-разработчиков, снабжая их инструментами разработки в отрыве от основной практики.
