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