О том, как складывается карьера - написано в начале и под конец. Один из них после плотного изучения визуального программирования смог освоить классическую разработку на C# и устроился джуниором в одну из IT-компаний. Двое других пока не выросли дальше визуального программирования, но тем не менее создают свои программки уже и без моей помощи, что я считаю очень хорошим прогрессом (тут даже скорее важно то, что они сами делают это с удовольствием и благодарят меня за то, что сдвинул их с мертвой точки).
Но вообще в целом, что касается карьеры - я себе не ставлю никогда цели "Устроить своего ученика в гугл-яндекс", а цель скорее - развить и дать более глубокое понимание, развить интерес к открытию новых границ. А как человек воспользуется этим для продвижения по карьере это уже его дело.
А можете, пожалуйста, указать, где в статье указано про No-Code? Статья посвящена тому, как через мостик визуального программирования научится именно что писать полноценный "Много-Code".
Возможно, вы где-то в середине решили просто пролистать статью, но в блоке с примерами простых программ на UiPath я написал, что простота визуального программирования побудила в учениках интерес разбираться глубже. И уже благодаря ему в этой же самой среде они начали писать программный код, благо она позволяет это делать. Сначала 1-2 строчки, потом больше-больше, постепенно заменяя визуальные готовые блоки на свой код.
Визуальная среда здесь - не конечная точка "путешествия", а скорее как мостик между визуальным осознанием алгоритмов и сложным программированием. Если бы я, как и другие, пытался бы их научить сразу писать код - с высокой долей вероятности ничего не получилось бы. А здесь у меня все получилось и я делюсь опытом "Как еще можно учить людей". И это не фантазия, а подтвержденный мною факт.
Смысл был не в том, чтобы научить визуальному программированию, а в том, чтобы пробудив более глубокий интерес научить делать правильно. Если бы я начал со скретча - я бы не смог прямо там же показать им как программировать классическим способом. Я не просто так в плюсах UiPath указал возможность полноценно программировать - именно этот мостик и сработал. Сначала ученики научились делать программы не написав ни строчки кода, а потом уже заменяли готовые визуальые блоки на свой код. Не все сразу, постепенно. И это заработало.
Ученики считали себя гуманитариями сами, так как учились в соответствующих учебных заведениях, но по факту имеющихся знаний и навыков их трудно таковыми назвать, поэтому я и делаю такую оговорку в статье
Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд - не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно. Тем более, что если речь идет про клиент-серверную архитектуру, здесь не нужно самому изобретать велосипеды и искать разнообразные движки, так как сам сервер UiPath (оркестратор) дает очень многое.
Даже из моего личного опыта: Когда-то давно мы с моей командой вели разработку одного решения для крупного банка. Решение должно было строить очередь из миллионов транзакций и обрабатывать их на десятке нод. Все это разрабатывалось тогда, когда еще никаких RabbitMQ и подобных решений на рынке не было (а если и были - они являлись не сильно известными).
Так вот такое решение мы разрабатывали несколько месяцев (с учетом отладки и доведения до ума). А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день. И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
С учетом того, что они могут объяснить каждое действие, которое применяют, а сам код роботов разбивают на части (отдельные файлы) с собственными входными и выходными аргументами (считай параметры и возвращаемое значение) - считаю, что удалось
По последней стадии - у меня была примерно такая же история, когда я устраивался на свою вторую работу. Причем концовка похожа, но с интересным нюансом.
Как сейчас помню - мы сидели с друзьями в (тогда еще) Ростиксе на Водном стадионе, потребляли курицу, я морально готовился к тому, что после обеда надо ехать на другой конец Москвы на очередное (тогда казалось сотое) собеседование. И тут буквально когда я уже собирался вставать - мне позвонила девушка с неизвестного номера и предложила приехать "сейчас" на собеседование в компанию, о которой я ничего не слышал, причем находилась она в 20 минутах езды. Я отменил запланированное собеседование и поехал по адресу, который назвала девушка.
Мы пообщались с ней, при этом в комнату еще пришел будущий коллега, который на вопрос девушки "Хочешь что-нибудь ему задать?" ответил "Спасибо, не надо, я все что надо уже услышал". Потом подошел еще будущий начальник, который спросил "Что хочешь знать?", а я уже ни на что не рассчитывая спросил первое, что пришло в голову: "Где вы тут кушаете?". По итогу девушка меня проводила со стандартными словами "Мы вам перезвоним".
Самое веселое то, что через пару дней она мне и правда перезвонила, и сказала, что меня готовы взять, только зарплату могут предложить на 5 тысяч меньше той, о которой просил. Так я и устроился туда, проработав больше трех лет, заведя полезные знакомства, благодаря которым все следующие места работы (кроме текущего) я получал без общения с рекрутерами, а HR-ам только приносил документы.
Желаю тебе успехов на новом месте, и чтобы в будущем новые лучшие места находились тоже по знакомству!
Опрос - это как ЕГЭ, можно тыкнуть в квадратики (кружочки), но это лишь некая уравниловка. Поэтому скорее интересно послушать живые мнения, опыт использования, субъективные ощущения.
Причем, если доверить роботу весь цикл - а значит гарантированная интеграция с источниками данных в виде связей внутри ERP или по API с внешними данными не производится...
Но зачем? Ведь робот может выполнить все действия для связки разных готовых систем, которые уже делают все нужное. Робот не должен сам лезть в источники данных и связи внутри ERP, робот должен нажать кнопку, которая запустит уже 100% отлаженный программный механизм внутри ERP, получить результат с экрана и передать его другому механизму. По сути RPA здесь будет клеем, который позволяет очень быстро объединить системы. Почему не программированием - объяснение ниже.
Зачем нужен робот для сверки Excel-файлов
Сверка сверке рознь. Одно дело, когда контрагент присылает Excel файл и нужно просто взять свой Excel-файл и строчка к строчке сравнить... Но совсем другое дело, когда своего Excel-файла как такового нет, а есть 2-3 системы, где есть информация, которую и надо сверить. Соответственно робот смотрит Excel-файл контрагента строчка за строчкой, и для каждой строчки выполняет проверки в нескольких системах.
Можно такое сделать на VBA? Посидев отлаживая несколько недель вызовы веб-сервисов или COM-объектов... А если у этих систем нет внятного API?
а сделать учет в виде простой базы данных в любой бесплатной СУБД или каких-нибудь гугл-таблицах. Иначе работы для RPA будет всегда очень много.
Легко сказать, да трудно сделать. Как показывает реальная практика, только первый этапы разработки и ввода в эксплуатацию даже самых простых систем в организации такого масштаба - это год (в самом лучшем случае половина года). А чтобы допилить систему до состояния "конфетка" - может потребоваться и 2 и 3 года.
Теперь возьмем весы и сравним два варианта:
Вариант 1 - За 2-3-4 месяца внедрить полноценный процесс, решающий конкретную задачу, которая не может быть решена текущим парком ПО. Результат - старые системы не ломаются, пользователи не тратят время на освоение новых интерфейсов, не испытывают проблем из-за миграции, но при этом получают новый функционал
Вариант 2 - 1 год проходит до того момента, как компания получает первую версию нужной системы, пользователи испытывают проблемы с освоением нового интерфейса, часть данных не перенесена или пересена криво при миграции, всего нужного функционала еще нет...
Даже если представить, что по результатам первого этапа требуемый результат был достигнут - в сравнении с первым компания начинает применять новый функционал на 8 месяцев позже, чем могла бы. А в нашем веке скоростей это может быть очень критичным. Особенно учитывая то, что срок окупаемости RPA-проектов довольно короткий (меньше года, бывает и за 2-3 месяца) - весы все же перевешивают в сторону применения роботов, а не затрат на разработку "нормальной учетной системы".
На самом деле ваши вопросы - довольно частые, и на них уже давно есть ответы. в частности по поводу изменчивости интерфейса можно почитать здесь: https://habr.com/ru/company/uipath/blog/577782/
Разработка новых процессов, доработка существующих, а так же поддержка в целом, как правило, осуществляется центром компетенций, который формируется внутри компании (или привлекается от интегратора). Финансовая сторона вопроса всегда должна быть просчитана еще до того, как вы вошли в эту историю и начали вкладывать средства в роботизацию. Каких-то универсальных цифр я вам не приведу, так как для каждого заказчика они индивидуальны.
Если вам и правда интересно узнать как построить качественный центр компетенций, который будет приносить выгоду компании, а не заниматься бесконечными исправлениями ошибок - стоит связаться с вашим аккаунт-менеджером в UiPath, а если вы еще не установили контакт - всегда можно обратиться через форму обратной связи на https://uipath.marvel.ru/
У перечисленных систем далеко не всегда коробочные решения подходят для всего сразу. Они требуют доработки-донастройки. И не всё они умеют без индивидуальной разработки нового функционала. Тем более когда идет вопрос про взаимодействие с другими системами, сайтами, программами, которые либо являются не очень популярными (и не имеют шаблонных коннекторов), либо являются самописными разработками (далеко не лучшего качества).
Интеграция в таком случае - дорогостоящий долгосрочный проект, а роботизация с использованием таких платформ как UiPath позволяет это сделать в разы быстрее и надежнее.
Отдельно важно отметить, что роботы - это не "еще одна программа" для пользователя, а программа, которая эмулирует действия человека. Максимум, что делает сотрудник - это запускает робота (но обычно это происходит по определенному событию или расписанию без участия человека).
Роботизация - это по своей сути подраздел автоматизации. Главным преимуществом применения роботов является то, что они позволяют автоматизировать взаимодействие с разными системами за очень короткие сроки.
Не у всех систем и программ на свете есть API, а иногда оно на столько неудобное, что требует месяцев разработки и отладки интеграционных модулей, чтобы все работало "как часы". Тут возникает диссонанс - действие, которое нужно автоматизировать кодом через вызов методов API, пользователь делает в два клика (условно). Соответственно, с помощью RPA можно настроить робота, который будет делать эти самые два клика - и это будет очень быстрой разработкой.
А еще почему-то многие ошибочно думают, что "роботы" (RPA) - это только про "квадратики с действиями". На самом деле современные RPA-платформы, в частности UiPath, позволяют вам добавлять целые блоки кода на языках C#, VBNET в своих роботов, а при необходимости - подключать любые доступные .NET Framework и .NET Core библиотеки.
И зачастую наиболее правильным решением будет не "Только писать код" или "Только применять робота", а комбинировать оба подхода. Там где у вас есть компетенции в API и вы уверены, что сделаете интеграцию быстро - пишите код, там где есть понимание, что застрянете в болоте - используйте робота.
Абсолютно согласен, но... Когда вы придете работать в настоящие компании и столкнетесь с реальностью - поймете, что в очень многих компаниях до сих пор ведется бумажный документооборот. Сам по себе за секунду он электронным не станет. Для начала надо перегнать все в цифру + правильно его считать (не просто текст, а данные из полей, таблиц).
Когда я начинал свою карьеру в 2009 году, то точно так же как вы, многие возмущались, что никто не переводит бумажный документооборот в электронный. И тогда уже технологии распознавания и считывания документов существовали и использовались. Но есть большая разница. Тогда нужно было обладать высокой экспертизой в OCR, знать специфичное ПО, очень много работать над настройкой извлечения данных из одного шаблона документас (а шаблонов надо всегда настраивать много).
Сегодня благодаря Document Understanding, о котором написано в этой статье, настройка одного шаблона занимает смешное время для не сильно квалифицированного сотрудника. И это действительно дает гораздо большую возможность для более скорого перехода от безбумажного к электронному документообороту.
Очень хорошая и полезная статья, автору уважение за проделанную работу, хорошее сравнение по конкретным пунктам.
Однако, судя по всему, автор статьи либо пользовался продуктами UiPath давно и не знает про новые возможности, либо не полностью прошел свежие курсы академии вендора. Дополню по пунктам, чтобы материал в сочетании с комментарием мог восприниматься более полным.
Базовый функционал
Довольно условное понимание базового функционала. Внедрения в крупные корпорации показали, что "просто уметь взаимодействовать с интерфейсом" - мало. Есть потребность в организации командной работы над одним проектом (разные части робота могут делать разные люди независимо друг от друга на разных машинах), в обеспечении работы с очередями транзакций для обработки больших массивов данных, в возможности создания и использования тестов... и это лишь верхушка айсберга требований, предъявляемых крупными организациями к современным RPA-платформам. Но, конечно, вопрос о том, что из всего этого относить к базовому, а что нет - вполне открытый.
Интерфейс и возможности разработки
Действительно, оригинальная версия студии разработки UiPath предполагает базовое понимание основ программирования (минимум - переменные, их типы, область видимости). Однако, у UiPath имеется специальная версия студии разработки - StudioX. В этой версии робота можно разрабатывать даже без знания аналогичных основ программирования и без необходимости писать программный код (но если очень нужно, то можно). Даже в России уже есть несколько крупных организаций, где есть сотрудники, успешно создающие своих роботов в этой версии студии. Так что в этом плане можно считать возможности no-code разработки эквивалентными.
Ролевая модель
Относительно недавно у UiPath появились похожие возможности путем настройки правил через Automation Ops, благодаря которым можно запретить определенным разработчикам или группам разработчиков (например, тем самым Citizen Developers) выполнять определенные действия.
Кроссплатформенность
Данный пункт до недавнего времени был абсолютной истиной. Однако, буквально пару недель назад UiPath сделал доступным для предварительного ознакомления роботов для Linux. На данный момент имеется возможность: автоматизации облачных решений через готовые коннекторы, применения всех возможностей .NET Core, которыми можно пользоваться в среде Linux, а так же роботизации браузера. Так что в этом пункте тоже можно выставить паритет
Отладка и обновления
Аналогично пункту выше - буквально с версии 2021.10 в UiPath становится доступной удаленная отладка.
Разница в наших с вами реальностях заключается в том, что в моей реальность есть реальные цифры, данные, я лично вижу и общаюсь с компаниями, где программа роботизации развивается, с каждым годом количество роботов (цифровых сотрудников) и роботизированных процессов увеличивается. Я не знаю в какой реальности живете вы, но предполагаю, что в ней нет реальных цифр.
Конечно, есть компании, где роботизация идет не такими темпами, но это связано в первую очередь с недопониманием концепций и методологий. Узкой и ограниченной область применения может казаться только в том случае, если вы пытаетесь, как говориться, натянуть сову на глобус, а точнее - применить RPA там, где этого делать не нужно, или же у вас просто недостаточно навыков роботизации и вы не умеете правильно настраивать роботов - все это так же поправимо.
С такими упадническими настроениями как у вас можно в конечном итоге прийти к выводу, что компьютеры - это просто костыль для общения между человеком и человеком на расстоянии.
RPA - это методология, набор технологий. Как и в случае с любой технологией - нужно уметь ей пользоваться, понимать зачем она нужна, где ее можно применять и где не стоит. Если вы имели печальный опыт взаимодействия с RPA и пришли к выводу, что это просто "еще одно колесо, не имеющее стандарта" - вынужден заключить, что вы не поняли методологию.
Ничего страшного в этом нет, и учиться никогда не поздно. Вместо того, чтобы проходить курсы от левых контор и полагаться на свой старый опыт - настоятельно советую пройти настоящую академию от лидера рынка, внимательно отнестись не только к стороне разработки, но и к стороне бизнес анализа и понимания процессов в целом. Заметьте, я вам говорю не про 1-2 курса, а про полноценные программы обучения.
Если вас интересует стоимость лицензий и часы работы конкретных специалистов — вам лучше обратиться к официальному дистрибьютору, или же к любому из партнеров UiPath в России.
За рамками цены РПА продуктов вижу цену на отдельный комп, цену на перевод 1С из однопользовательского варианта надомника-тёти-бухгалтера в сетевую двухкомпьютерную
На самом деле такой необходимости нет. В отличие от ряда конкурентов, с которыми вы, возможно, сталкивались, у UiPath имеются «роботы-помощники» (в английском варианте — attended robots) — это специальный вид роботв, который может устанавливаться прямо на компьютер пользователя и вызываться им по требованию (кроме того, его можно научить следить за определенными событиями и он будет предлагать выполнить ту или иную работу самостоятельно).
В данной конфигурации, соответственно, у вас не будет никакой необходимости переводить 1С из однопользовательского режима в сетевой.
Кстати, сама разработчик 1С
Вы можете ознакомиться с перепиской выше, где полностью объяснено когда стоит применять роботов, а когда не стоит. Кратко: Если у вас только 1С и ничего кроме 1С — скорее всего, роботы вам не нужны. Если 1С — одна из нескольких систем, которые не умеют дружить друг с другом (а разработка дружбы стоит дорого и будет идти долго), то роботы избавят вас от этой головной боли быстро, и, вполне возможно, дешевле, чем кастомная разработка интеграции.
А за что вы тогда коллегу по шапке если не за костыль?
Внимательно следим за руками:
Задачу можно решить программированием быстро, API изучен, есть опыт в разработке для данного ПО — нужно писать программу, без альтернатив
Задачу нельзя решить программированием быстро, API не изучен, нет опыта в разработке для данного ПО — лучше использовать робота
Мир не черно-белый. Всегда есть оттенки серого. И профессионализм — это не готовность писать код для всего на свете, а умение выбирать правильный инструмент для конкретной ситуации. И здесь RPA — это не костыль, а полноценный альтернативный вариант решения проблемы.
на пользовательских интерфейсах, которые завтра по желанию разработчика сторонней системы кардинально изменятся? Что, бывают в реальной жизни ситуации когда кто-то гарантирует неизменность пользовательских интерфейсов?
Если мы продолжим следовать вашей логике, то точно так же завтра по желанию разработчика актуальные сегодня методы API могут объявить Deprecated и «приплыли».
Если уж мы говорим про промышленную эксплуатацию, то вам точно должно быть известно, что в любой уважающей себя компании перед тем как устанавливать новую версию ПО — ее проверяют на тестовом стенде. Всегда необходимо проверять корректно ли работает само ПО и все интеграции с ним (в том числе роботов) перед тем как устанавливать обновление на продуктив.
Для этих целей у UiPath есть Test Suite, который позволяет настроить большое количество разнообразных тестов для роботов, нацеленных на разные среды. Вот обновили вы ПО на тестовом контуре — просто запускаете тесты и видите результат: Либо все в порядке, либо вам отображаются сведения где именно что сломалось. С этой информацией можно оперативно исправить конкретные проблемы робота при работе с новой версией. И только после того, как вы убеждены в том, что все роботы работают корректно с новой версией ПО — его можно устанавливать на продуктив.
Ну а если вдруг в компании нет практики «Dev-Test-Prod», то здесь можно только пожать плечами и задаться вопросом — отсутствуют ли вообще проблемы при обновлении продуктива? Как показывает моя практика — такого волшебства не бывает.
Если же речь про публично доступные ресурсы, которые меняются без нашего участия и без нашего тестового контура, то, как правило, дается определенный срок, когда можно нажать кнопку «Перейти на старый дизайн». Роботов так же можно очень быстро научить «перед тем как выполнять работу убеждаться, что мы на старом дизайне, а если это не так — нажимать эту кнопку». Таким образом и роботы продолжают работу, и есть время на перепривязку к новому дизайну.
Не надо быть 1С-программистом, чтобы прочитать вот это. Или у ваших разработчиков XML-файл определенной структуры сгенерировать не получится?
Во-первых об этом надо знать, во-вторых, опять же — вам легко сказать «определенной структуры», а дайте Junior-разработчику разбираться с этой «определенной структурой» и замерьте сколько он будет заниматься этим самым разбором.
И что-то мне подсказывает, что разбираться он будет дольше, чем настраивать робота. И да, разрабатывать роботов могут даже Junior-ы/вчерашние студенты, и эти роботы выполняют свою работу качественно, стабильно и без ошибок (само собой, большой опыт разработки всегда будет в плюс и матерый программист сделает робота лучше, чем вчерашний студент, но это уже другая тема)
Позвольте поинтересоваться, где мною хоть раз было написано про костыли? Костыль — это крайне ненадежное обходное решение, которое позволяет решить одну точечную проблему, но при этом ведет к потенциальному возникновению ряда других проблем в будущем.
Если же мы говорим про полноценную платформу роботизации, такую как UiPath — мы говорим о промышленном решении, которое работает в тысячах компаний по всему миру (и сотнях в России). При чем это не какие-нибудь шаражкины конторы, а очень большие солидные компании, в которых требования к качеству, безопасности на очень высоком уровне (например, NASA). Так что ваши слова про «костыли» — однозначно написаны без погружения в тему.
Моя точка зрения: в 2021...
Осмелюсь предположить, что ваша точка зрения основывается на том, что все программы/системы в мире умеют дружиться друг с другом/имеют внятное апи и готовы к взаимной интеграции. Вот только это совсем не так. Как не стараются разработчики — у них никогда не получится сделать «Одно единое приложение, в котором будет работать сотрудник». Исключение, разве что, какая-нибудь касса или инфо-стенды (киоски).
Когда речь идет о реальной работе с реальными документами, реальными ситуациями — людям так или иначе приходится использовать несколько систем/программ/сайтов для достижения хорошего результата. И, как правило, эти системы либо вообще нельзя подружить, либо можно, но только за очень много денег и времени на разработку.
Так что, как бы вам не хотелось, реальный мир устроен немножко иначе, и пока он устроен так — подобную автоматизацию в короткие сроки можно делать только с помощью RPA. Других альтернатив (по крайней мере пока) лично мне неизвестно.
Вот у вас даже в качестве примера зачем-то выбрана 1С, у которой API (да не один) и открытый и отлично документированный, а вы на нее роботов натравливаете.
Мне придется вас разочаровать. Несмотря на то, что, вроде бы, количество 1С-программистов у нас в стране большое, на самом деле их реальный процент среди всех разработчиков довольно мал. Как я уже писал выше: RPA, UiPath — это не про «Давайте не будем писать код в 1С, а натравим робота», а про «давайте автоматизируем работу пользователя между несколькими разными приложениями, системами и сайтами».
А так как мы живем в России — среди этих систем очень часто оказывается 1С (и не всегда это основная система, требующая большого количества автоматизации). И проблема здесь в том, что многие RPA-разработчики в принципе не умеют программировать в 1С (а некоторые и вообще не знают как правильно с 1С работать в пользовательском режиме). Благодаря UiPath — им и не надо тратить время на изучение 1С, им надо просто сесть с бухгалтером и записать его действия. Всё. Вот только есть нюансы при роботизации 1С, о которых и рассказано в данной статье.
подход «тяп-ляп и в продакшен»
Если бы вы роботизировали хотя бы один полноценный процесс — вы бы понимали, что «Тяп-ляп» это про что угодно, но только не про UiPath. Рекомендую изучить матчасть, для начала хотя бы почитать другие статьи аккаунта RPAconsultant, а уже потом подумать над тем является ли это «тяп ляп». Иначе ваши слова звучат крайне непрофессионально.
На первых порах. Очень недолго.
Если вы изучите клиентов UiPath — вы увидите, что большие компании пользуются роботизацией годами, при чем число роботизированных процессов в каждой компании неуклонно растет. А это верный показатель того, что выгода сохраняется не «на первых порах», а надолго.
Если же у вас есть в этом сомнения — послезавтра пройдет митап, где будут выступать представители Российских компаний, в которых роботизация идет полным ходом и все ей полностью довольны. Буду рад видеть вас в слушателях: www.meetup.com/UiPath-RPA-Moscow/events/278450076
О том, как складывается карьера - написано в начале и под конец. Один из них после плотного изучения визуального программирования смог освоить классическую разработку на C# и устроился джуниором в одну из IT-компаний. Двое других пока не выросли дальше визуального программирования, но тем не менее создают свои программки уже и без моей помощи, что я считаю очень хорошим прогрессом (тут даже скорее важно то, что они сами делают это с удовольствием и благодарят меня за то, что сдвинул их с мертвой точки).
Но вообще в целом, что касается карьеры - я себе не ставлю никогда цели "Устроить своего ученика в гугл-яндекс", а цель скорее - развить и дать более глубокое понимание, развить интерес к открытию новых границ. А как человек воспользуется этим для продвижения по карьере это уже его дело.
А можете, пожалуйста, указать, где в статье указано про No-Code? Статья посвящена тому, как через мостик визуального программирования научится именно что писать полноценный "Много-Code".
Возможно, вы где-то в середине решили просто пролистать статью, но в блоке с примерами простых программ на UiPath я написал, что простота визуального программирования побудила в учениках интерес разбираться глубже. И уже благодаря ему в этой же самой среде они начали писать программный код, благо она позволяет это делать. Сначала 1-2 строчки, потом больше-больше, постепенно заменяя визуальные готовые блоки на свой код.
Визуальная среда здесь - не конечная точка "путешествия", а скорее как мостик между визуальным осознанием алгоритмов и сложным программированием. Если бы я, как и другие, пытался бы их научить сразу писать код - с высокой долей вероятности ничего не получилось бы. А здесь у меня все получилось и я делюсь опытом "Как еще можно учить людей". И это не фантазия, а подтвержденный мною факт.
Смысл был не в том, чтобы научить визуальному программированию, а в том, чтобы пробудив более глубокий интерес научить делать правильно. Если бы я начал со скретча - я бы не смог прямо там же показать им как программировать классическим способом. Я не просто так в плюсах UiPath указал возможность полноценно программировать - именно этот мостик и сработал. Сначала ученики научились делать программы не написав ни строчки кода, а потом уже заменяли готовые визуальые блоки на свой код. Не все сразу, постепенно. И это заработало.
Ученики считали себя гуманитариями сами, так как учились в соответствующих учебных заведениях, но по факту имеющихся знаний и навыков их трудно таковыми назвать, поэтому я и делаю такую оговорку в статье
Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд - не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно. Тем более, что если речь идет про клиент-серверную архитектуру, здесь не нужно самому изобретать велосипеды и искать разнообразные движки, так как сам сервер UiPath (оркестратор) дает очень многое.
Даже из моего личного опыта: Когда-то давно мы с моей командой вели разработку одного решения для крупного банка. Решение должно было строить очередь из миллионов транзакций и обрабатывать их на десятке нод. Все это разрабатывалось тогда, когда еще никаких RabbitMQ и подобных решений на рынке не было (а если и были - они являлись не сильно известными).
Так вот такое решение мы разрабатывали несколько месяцев (с учетом отладки и доведения до ума). А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день. И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
С учетом того, что они могут объяснить каждое действие, которое применяют, а сам код роботов разбивают на части (отдельные файлы) с собственными входными и выходными аргументами (считай параметры и возвращаемое значение) - считаю, что удалось
По последней стадии - у меня была примерно такая же история, когда я устраивался на свою вторую работу. Причем концовка похожа, но с интересным нюансом.
Как сейчас помню - мы сидели с друзьями в (тогда еще) Ростиксе на Водном стадионе, потребляли курицу, я морально готовился к тому, что после обеда надо ехать на другой конец Москвы на очередное (тогда казалось сотое) собеседование. И тут буквально когда я уже собирался вставать - мне позвонила девушка с неизвестного номера и предложила приехать "сейчас" на собеседование в компанию, о которой я ничего не слышал, причем находилась она в 20 минутах езды. Я отменил запланированное собеседование и поехал по адресу, который назвала девушка.
Мы пообщались с ней, при этом в комнату еще пришел будущий коллега, который на вопрос девушки "Хочешь что-нибудь ему задать?" ответил "Спасибо, не надо, я все что надо уже услышал". Потом подошел еще будущий начальник, который спросил "Что хочешь знать?", а я уже ни на что не рассчитывая спросил первое, что пришло в голову: "Где вы тут кушаете?". По итогу девушка меня проводила со стандартными словами "Мы вам перезвоним".
Самое веселое то, что через пару дней она мне и правда перезвонила, и сказала, что меня готовы взять, только зарплату могут предложить на 5 тысяч меньше той, о которой просил. Так я и устроился туда, проработав больше трех лет, заведя полезные знакомства, благодаря которым все следующие места работы (кроме текущего) я получал без общения с рекрутерами, а HR-ам только приносил документы.
Желаю тебе успехов на новом месте, и чтобы в будущем новые лучшие места находились тоже по знакомству!
Опрос - это как ЕГЭ, можно тыкнуть в квадратики (кружочки), но это лишь некая уравниловка. Поэтому скорее интересно послушать живые мнения, опыт использования, субъективные ощущения.
Но зачем? Ведь робот может выполнить все действия для связки разных готовых систем, которые уже делают все нужное. Робот не должен сам лезть в источники данных и связи внутри ERP, робот должен нажать кнопку, которая запустит уже 100% отлаженный программный механизм внутри ERP, получить результат с экрана и передать его другому механизму. По сути RPA здесь будет клеем, который позволяет очень быстро объединить системы. Почему не программированием - объяснение ниже.
Сверка сверке рознь. Одно дело, когда контрагент присылает Excel файл и нужно просто взять свой Excel-файл и строчка к строчке сравнить... Но совсем другое дело, когда своего Excel-файла как такового нет, а есть 2-3 системы, где есть информация, которую и надо сверить. Соответственно робот смотрит Excel-файл контрагента строчка за строчкой, и для каждой строчки выполняет проверки в нескольких системах.
Можно такое сделать на VBA? Посидев отлаживая несколько недель вызовы веб-сервисов или COM-объектов... А если у этих систем нет внятного API?
Легко сказать, да трудно сделать. Как показывает реальная практика, только первый этапы разработки и ввода в эксплуатацию даже самых простых систем в организации такого масштаба - это год (в самом лучшем случае половина года). А чтобы допилить систему до состояния "конфетка" - может потребоваться и 2 и 3 года.
Теперь возьмем весы и сравним два варианта:
Вариант 1 - За 2-3-4 месяца внедрить полноценный процесс, решающий конкретную задачу, которая не может быть решена текущим парком ПО. Результат - старые системы не ломаются, пользователи не тратят время на освоение новых интерфейсов, не испытывают проблем из-за миграции, но при этом получают новый функционал
Вариант 2 - 1 год проходит до того момента, как компания получает первую версию нужной системы, пользователи испытывают проблемы с освоением нового интерфейса, часть данных не перенесена или пересена криво при миграции, всего нужного функционала еще нет...
Даже если представить, что по результатам первого этапа требуемый результат был достигнут - в сравнении с первым компания начинает применять новый функционал на 8 месяцев позже, чем могла бы. А в нашем веке скоростей это может быть очень критичным. Особенно учитывая то, что срок окупаемости RPA-проектов довольно короткий (меньше года, бывает и за 2-3 месяца) - весы все же перевешивают в сторону применения роботов, а не затрат на разработку "нормальной учетной системы".
На самом деле ваши вопросы - довольно частые, и на них уже давно есть ответы. в частности по поводу изменчивости интерфейса можно почитать здесь: https://habr.com/ru/company/uipath/blog/577782/
Разработка новых процессов, доработка существующих, а так же поддержка в целом, как правило, осуществляется центром компетенций, который формируется внутри компании (или привлекается от интегратора). Финансовая сторона вопроса всегда должна быть просчитана еще до того, как вы вошли в эту историю и начали вкладывать средства в роботизацию. Каких-то универсальных цифр я вам не приведу, так как для каждого заказчика они индивидуальны.
Если вам и правда интересно узнать как построить качественный центр компетенций, который будет приносить выгоду компании, а не заниматься бесконечными исправлениями ошибок - стоит связаться с вашим аккаунт-менеджером в UiPath, а если вы еще не установили контакт - всегда можно обратиться через форму обратной связи на https://uipath.marvel.ru/
У перечисленных систем далеко не всегда коробочные решения подходят для всего сразу. Они требуют доработки-донастройки. И не всё они умеют без индивидуальной разработки нового функционала. Тем более когда идет вопрос про взаимодействие с другими системами, сайтами, программами, которые либо являются не очень популярными (и не имеют шаблонных коннекторов), либо являются самописными разработками (далеко не лучшего качества).
Интеграция в таком случае - дорогостоящий долгосрочный проект, а роботизация с использованием таких платформ как UiPath позволяет это сделать в разы быстрее и надежнее.
Отдельно важно отметить, что роботы - это не "еще одна программа" для пользователя, а программа, которая эмулирует действия человека. Максимум, что делает сотрудник - это запускает робота (но обычно это происходит по определенному событию или расписанию без участия человека).
Роботизация - это по своей сути подраздел автоматизации. Главным преимуществом применения роботов является то, что они позволяют автоматизировать взаимодействие с разными системами за очень короткие сроки.
Не у всех систем и программ на свете есть API, а иногда оно на столько неудобное, что требует месяцев разработки и отладки интеграционных модулей, чтобы все работало "как часы". Тут возникает диссонанс - действие, которое нужно автоматизировать кодом через вызов методов API, пользователь делает в два клика (условно). Соответственно, с помощью RPA можно настроить робота, который будет делать эти самые два клика - и это будет очень быстрой разработкой.
А еще почему-то многие ошибочно думают, что "роботы" (RPA) - это только про "квадратики с действиями". На самом деле современные RPA-платформы, в частности UiPath, позволяют вам добавлять целые блоки кода на языках C#, VBNET в своих роботов, а при необходимости - подключать любые доступные .NET Framework и .NET Core библиотеки.
И зачастую наиболее правильным решением будет не "Только писать код" или "Только применять робота", а комбинировать оба подхода. Там где у вас есть компетенции в API и вы уверены, что сделаете интеграцию быстро - пишите код, там где есть понимание, что застрянете в болоте - используйте робота.
Абсолютно согласен, но... Когда вы придете работать в настоящие компании и столкнетесь с реальностью - поймете, что в очень многих компаниях до сих пор ведется бумажный документооборот. Сам по себе за секунду он электронным не станет. Для начала надо перегнать все в цифру + правильно его считать (не просто текст, а данные из полей, таблиц).
Когда я начинал свою карьеру в 2009 году, то точно так же как вы, многие возмущались, что никто не переводит бумажный документооборот в электронный. И тогда уже технологии распознавания и считывания документов существовали и использовались. Но есть большая разница. Тогда нужно было обладать высокой экспертизой в OCR, знать специфичное ПО, очень много работать над настройкой извлечения данных из одного шаблона документас (а шаблонов надо всегда настраивать много).
Сегодня благодаря Document Understanding, о котором написано в этой статье, настройка одного шаблона занимает смешное время для не сильно квалифицированного сотрудника. И это действительно дает гораздо большую возможность для более скорого перехода от безбумажного к электронному документообороту.
Очень хорошая и полезная статья, автору уважение за проделанную работу, хорошее сравнение по конкретным пунктам.
Однако, судя по всему, автор статьи либо пользовался продуктами UiPath давно и не знает про новые возможности, либо не полностью прошел свежие курсы академии вендора. Дополню по пунктам, чтобы материал в сочетании с комментарием мог восприниматься более полным.
Базовый функционал
Довольно условное понимание базового функционала. Внедрения в крупные корпорации показали, что "просто уметь взаимодействовать с интерфейсом" - мало. Есть потребность в организации командной работы над одним проектом (разные части робота могут делать разные люди независимо друг от друга на разных машинах), в обеспечении работы с очередями транзакций для обработки больших массивов данных, в возможности создания и использования тестов... и это лишь верхушка айсберга требований, предъявляемых крупными организациями к современным RPA-платформам. Но, конечно, вопрос о том, что из всего этого относить к базовому, а что нет - вполне открытый.
Интерфейс и возможности разработки
Действительно, оригинальная версия студии разработки UiPath предполагает базовое понимание основ программирования (минимум - переменные, их типы, область видимости). Однако, у UiPath имеется специальная версия студии разработки - StudioX. В этой версии робота можно разрабатывать даже без знания аналогичных основ программирования и без необходимости писать программный код (но если очень нужно, то можно). Даже в России уже есть несколько крупных организаций, где есть сотрудники, успешно создающие своих роботов в этой версии студии. Так что в этом плане можно считать возможности no-code разработки эквивалентными.
Ролевая модель
Относительно недавно у UiPath появились похожие возможности путем настройки правил через Automation Ops, благодаря которым можно запретить определенным разработчикам или группам разработчиков (например, тем самым Citizen Developers) выполнять определенные действия.
Кроссплатформенность
Данный пункт до недавнего времени был абсолютной истиной. Однако, буквально пару недель назад UiPath сделал доступным для предварительного ознакомления роботов для Linux. На данный момент имеется возможность: автоматизации облачных решений через готовые коннекторы, применения всех возможностей .NET Core, которыми можно пользоваться в среде Linux, а так же роботизации браузера. Так что в этом пункте тоже можно выставить паритет
Отладка и обновления
Аналогично пункту выше - буквально с версии 2021.10 в UiPath становится доступной удаленная отладка.
Разница в наших с вами реальностях заключается в том, что в моей реальность есть реальные цифры, данные, я лично вижу и общаюсь с компаниями, где программа роботизации развивается, с каждым годом количество роботов (цифровых сотрудников) и роботизированных процессов увеличивается. Я не знаю в какой реальности живете вы, но предполагаю, что в ней нет реальных цифр.
Конечно, есть компании, где роботизация идет не такими темпами, но это связано в первую очередь с недопониманием концепций и методологий. Узкой и ограниченной область применения может казаться только в том случае, если вы пытаетесь, как говориться, натянуть сову на глобус, а точнее - применить RPA там, где этого делать не нужно, или же у вас просто недостаточно навыков роботизации и вы не умеете правильно настраивать роботов - все это так же поправимо.
С такими упадническими настроениями как у вас можно в конечном итоге прийти к выводу, что компьютеры - это просто костыль для общения между человеком и человеком на расстоянии.
RPA - это методология, набор технологий. Как и в случае с любой технологией - нужно уметь ей пользоваться, понимать зачем она нужна, где ее можно применять и где не стоит. Если вы имели печальный опыт взаимодействия с RPA и пришли к выводу, что это просто "еще одно колесо, не имеющее стандарта" - вынужден заключить, что вы не поняли методологию.
Ничего страшного в этом нет, и учиться никогда не поздно. Вместо того, чтобы проходить курсы от левых контор и полагаться на свой старый опыт - настоятельно советую пройти настоящую академию от лидера рынка, внимательно отнестись не только к стороне разработки, но и к стороне бизнес анализа и понимания процессов в целом. Заметьте, я вам говорю не про 1-2 курса, а про полноценные программы обучения.
На самом деле такой необходимости нет. В отличие от ряда конкурентов, с которыми вы, возможно, сталкивались, у UiPath имеются «роботы-помощники» (в английском варианте — attended robots) — это специальный вид роботв, который может устанавливаться прямо на компьютер пользователя и вызываться им по требованию (кроме того, его можно научить следить за определенными событиями и он будет предлагать выполнить ту или иную работу самостоятельно).
В данной конфигурации, соответственно, у вас не будет никакой необходимости переводить 1С из однопользовательского режима в сетевой.
Вы можете ознакомиться с перепиской выше, где полностью объяснено когда стоит применять роботов, а когда не стоит. Кратко: Если у вас только 1С и ничего кроме 1С — скорее всего, роботы вам не нужны. Если 1С — одна из нескольких систем, которые не умеют дружить друг с другом (а разработка дружбы стоит дорого и будет идти долго), то роботы избавят вас от этой головной боли быстро, и, вполне возможно, дешевле, чем кастомная разработка интеграции.
Мир не черно-белый. Всегда есть оттенки серого. И профессионализм — это не готовность писать код для всего на свете, а умение выбирать правильный инструмент для конкретной ситуации. И здесь RPA — это не костыль, а полноценный альтернативный вариант решения проблемы.
Если мы продолжим следовать вашей логике, то точно так же завтра по желанию разработчика актуальные сегодня методы API могут объявить Deprecated и «приплыли».
Если уж мы говорим про промышленную эксплуатацию, то вам точно должно быть известно, что в любой уважающей себя компании перед тем как устанавливать новую версию ПО — ее проверяют на тестовом стенде. Всегда необходимо проверять корректно ли работает само ПО и все интеграции с ним (в том числе роботов) перед тем как устанавливать обновление на продуктив.
Для этих целей у UiPath есть Test Suite, который позволяет настроить большое количество разнообразных тестов для роботов, нацеленных на разные среды. Вот обновили вы ПО на тестовом контуре — просто запускаете тесты и видите результат: Либо все в порядке, либо вам отображаются сведения где именно что сломалось. С этой информацией можно оперативно исправить конкретные проблемы робота при работе с новой версией. И только после того, как вы убеждены в том, что все роботы работают корректно с новой версией ПО — его можно устанавливать на продуктив.
Ну а если вдруг в компании нет практики «Dev-Test-Prod», то здесь можно только пожать плечами и задаться вопросом — отсутствуют ли вообще проблемы при обновлении продуктива? Как показывает моя практика — такого волшебства не бывает.
Если же речь про публично доступные ресурсы, которые меняются без нашего участия и без нашего тестового контура, то, как правило, дается определенный срок, когда можно нажать кнопку «Перейти на старый дизайн». Роботов так же можно очень быстро научить «перед тем как выполнять работу убеждаться, что мы на старом дизайне, а если это не так — нажимать эту кнопку». Таким образом и роботы продолжают работу, и есть время на перепривязку к новому дизайну.
Во-первых об этом надо знать, во-вторых, опять же — вам легко сказать «определенной структуры», а дайте Junior-разработчику разбираться с этой «определенной структурой» и замерьте сколько он будет заниматься этим самым разбором.
И что-то мне подсказывает, что разбираться он будет дольше, чем настраивать робота. И да, разрабатывать роботов могут даже Junior-ы/вчерашние студенты, и эти роботы выполняют свою работу качественно, стабильно и без ошибок (само собой, большой опыт разработки всегда будет в плюс и матерый программист сделает робота лучше, чем вчерашний студент, но это уже другая тема)
Позвольте поинтересоваться, где мною хоть раз было написано про костыли? Костыль — это крайне ненадежное обходное решение, которое позволяет решить одну точечную проблему, но при этом ведет к потенциальному возникновению ряда других проблем в будущем.
Если же мы говорим про полноценную платформу роботизации, такую как UiPath — мы говорим о промышленном решении, которое работает в тысячах компаний по всему миру (и сотнях в России). При чем это не какие-нибудь шаражкины конторы, а очень большие солидные компании, в которых требования к качеству, безопасности на очень высоком уровне (например, NASA). Так что ваши слова про «костыли» — однозначно написаны без погружения в тему.
Осмелюсь предположить, что ваша точка зрения основывается на том, что все программы/системы в мире умеют дружиться друг с другом/имеют внятное апи и готовы к взаимной интеграции. Вот только это совсем не так. Как не стараются разработчики — у них никогда не получится сделать «Одно единое приложение, в котором будет работать сотрудник». Исключение, разве что, какая-нибудь касса или инфо-стенды (киоски).
Когда речь идет о реальной работе с реальными документами, реальными ситуациями — людям так или иначе приходится использовать несколько систем/программ/сайтов для достижения хорошего результата. И, как правило, эти системы либо вообще нельзя подружить, либо можно, но только за очень много денег и времени на разработку.
Так что, как бы вам не хотелось, реальный мир устроен немножко иначе, и пока он устроен так — подобную автоматизацию в короткие сроки можно делать только с помощью RPA. Других альтернатив (по крайней мере пока) лично мне неизвестно.
Мне придется вас разочаровать. Несмотря на то, что, вроде бы, количество 1С-программистов у нас в стране большое, на самом деле их реальный процент среди всех разработчиков довольно мал. Как я уже писал выше: RPA, UiPath — это не про «Давайте не будем писать код в 1С, а натравим робота», а про «давайте автоматизируем работу пользователя между несколькими разными приложениями, системами и сайтами».
А так как мы живем в России — среди этих систем очень часто оказывается 1С (и не всегда это основная система, требующая большого количества автоматизации). И проблема здесь в том, что многие RPA-разработчики в принципе не умеют программировать в 1С (а некоторые и вообще не знают как правильно с 1С работать в пользовательском режиме). Благодаря UiPath — им и не надо тратить время на изучение 1С, им надо просто сесть с бухгалтером и записать его действия. Всё. Вот только есть нюансы при роботизации 1С, о которых и рассказано в данной статье.
Если бы вы роботизировали хотя бы один полноценный процесс — вы бы понимали, что «Тяп-ляп» это про что угодно, но только не про UiPath. Рекомендую изучить матчасть, для начала хотя бы почитать другие статьи аккаунта RPAconsultant, а уже потом подумать над тем является ли это «тяп ляп». Иначе ваши слова звучат крайне непрофессионально.
Если вы изучите клиентов UiPath — вы увидите, что большие компании пользуются роботизацией годами, при чем число роботизированных процессов в каждой компании неуклонно растет. А это верный показатель того, что выгода сохраняется не «на первых порах», а надолго.
Если же у вас есть в этом сомнения — послезавтра пройдет митап, где будут выступать представители Российских компаний, в которых роботизация идет полным ходом и все ей полностью довольны. Буду рад видеть вас в слушателях: www.meetup.com/UiPath-RPA-Moscow/events/278450076