"Идеи о разработке бизнес-пользователями ходят уже давно, и многие вендора стараются предложить свои решения именно для бизнес-пользователей" - многие вендоры сейчас предлагают 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 самым правильным решением будет создание единого подразделения и, в случае наличия талантливых сотрудников, которые хотят попробовать себя в разработке, делать их полноценными участниками практики, развивая их как полноценных, технических специалистов, не делая из них универсальных бизнес-разработчиков, снабжая их инструментами разработки в отрыве от основной практики.
Комментарии (8)
c_kotik
22.10.2023 21:07+2Побуду занудой, но слоган "просто добавь воды" был популярен в 90х и то у напитков. Так что ваш поезд о сферических бизнесах в вакууме не то что ушёл, вы ещё и не на тот маршрут сели.
GospodinKolhoznik
22.10.2023 21:07+1Обычно в бизнесе проблема не в том, что эксель файл размером в сотни тысяч строк, и не в том, что макрос надо запускать сотни раз на дню, а в том, а в том, что эксельки приходят извне, и раз в какой то период их формат и логика наполнения немножко меняется.
Как правило менять код макроса надо не сильно, но быстро, т.к. данные нужны обработать "уже вчера". А проходить всю процедуру обращения в IT департамент, написания ТЗ и согласования работ просто некогда. Поэтому программирование - вторая грамотность.
MindHunter11993
22.10.2023 21:07+1Если честно, то автор приводит ряд доводов, которые не выдерживают никакой критики.
Централизованное IT-подразделение необходимо, по большому счету в любой организации, вне зависимости от того, какие технологии используются в ней. И любой, даже гениальный разработчик натворит делов в ситуации, когда все работает как попало на костылях и заплатках. Точнее, до него-то мысль о централизации и приведении всего в порядок дойдет достаточно быстро.
Как правильно заметили в комментариях, Excel на несколько десятков строк никакой автоматизации не требует. А рост объемов данных - вещь неизбежная, если бизнес работает хорошо.
И тут встают два вопроса: правильный подбор решения для автоматизации и правильный подбор тех самых бизнес-разработчиков. Такой разработчик - это не левый человек с улицы, который только в ворде форматирование менять умеет. Таких людей пытаться обучать бизнес-разработке - идея заранее дохлая. Это должен быть человек, который понимает, как система работает, в идеале, выпускник/старшекурсник технического ВУЗа, возможно без реального опыта работы. Идея low-code не в том, чтобы посадить первого встречного, а чтобы снизить порог входа. Условно, помочь джунам, которых огромная куча на рынке, найти свое место, и, возможно, пойти дальше, или остаться на этой технологии, если ему будет интересно
dyshess Автор
22.10.2023 21:07Согласен со всем перечисленным, однако, реклама и подход рекламируется именно такой, что можно посадить любого сотрудника, у которого просто есть желание, что у владельцев бизнеса создаёт неверное представление о технологии
MindHunter11993
22.10.2023 21:07Ну, тут важно отделить зерна от плевел. Чаще всего такой маркетинговый подход направлен именно на привлечение внимания, как один из инструментов лидогенерации. Правда, это уже несколько лет как не работает. Все, кто мог, уже обожглись.
Самое важное - насколько честно и на каком этапе вендор скажет, кто именно нужен в качестве бизнес-разработчиков. И здесь есть две крайности:
1. Можно попытаться дать low-code или no-code реальным разрабам. В этом случае крайне высока вероятность отторжения в дуже "нафига мне эти игрушки, я кодом в сто раз быстрее и понятнее запилю"
2. Взять реально людей с улицы, не проверив их скилл (особенно, если вендор не готов помогать в подборе) и облажаться тогда, когда будет слишком поздно.
Чтобы всего этого избежать нужно пощупать систему самостоятельно или запросить настройку какого-то небольшого кейса. Там будет понятно, что внутри, как это работает, какие навыки нужны.
Batalmv
22.10.2023 21:07Мне кажется, что ошибка сразу в начале, прмя в заголовке. "Почему вам не нужны Citizen-Developers". А именно в слове "вам".
Citizen-девелоперы - это по сути сам бизнес. Т.е. я "бизнес" - делаю деньги и нуждаюсь в технической поддержке этого замечательного со всех сторон процесса. Это важная исходная точка. Бизнес первичен, деньги у него. решаея задачу технической поддержки, бизнес может прийти к:
своему "квалифицированному" ИТ
внешнему ИТ
своим ресурсам
Это очень в общем конечно, но надо понимать, что это тоже важно. Бизнес заказчик и он имеет важное право голоса, так как в конечном итоге - ему платить. Конечно в больших организациях есть "законы", которые не позволяют иметь такую свободу, граничащую с анархией, но все ж базовой сути причинно-следственных связей это не отменяет.
Почему бизнес не всегда идет к своему ИТ. Да просто. Оно имеет ограниченный ресурс, он о часто не эффективно, и это еще мягко сказано. А деньги плати. Получается такой себе "монополист" локального масштаба.
Почему бизнес не идет к внешнему подрядчику? Часто это дорого и сложно, да и там нарваться на плохое качество можно. В больших организациях еще всплывет задача интеграций, поддержки этого всего ... короче, тоже не "silver bullet".
Low-code выглядит соблазнительно, так как могу делать сам, когда захочу, что захочу.
-----------
В реальной жизни любой кейс уникален. Где-то может быть "сильный" бизнес, способный реально решать часть своих технических вопросов, где-то вменяемое свое ИТ. А где-то вообще ИТ на аутсорсе. Но нельзя говорить, что один подход лучше другого в общем. В частности да, но надо знать все эти частности.
saboteur_kiev
а у среднестатистического пользователя excel в бизнесе, и так в эфеселе обычно несколько тысяч строк. Как минимум в тех файлах, где интересна какая-то автоматизация.
И что такое "небольшой размер"? файл в 15 мегабайт это много или мало? а я такие встречал еще лет 20 назад.
Опять таки, "быстрый профит" это наверное как раз то, что нужно в бизнесе. Потому что пока будут писать автоматизацию, поезд уйдет и бизнес поменяется.
А, недочитал конец вашей фразы. Каким образом бизнес превратился в запуск бота сотни или тысяч раз в месяц...
Статья ни о чем..
dyshess Автор
Хочу подчеркнуть, что данная статья применима к RPA разработке, сравнения с автоматизацией в широком понимании здесь нет. По сути, rpa - это уже компромиссное решение в плане скорости разработки