Pull to refresh
12
0
Илья Кочетов @ilya_kochetov

Консультант RPA

Send message

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

  1. Версионирование - git + nuget server

  2. Взять пакет с тестами и запустить тест, правда что такое "конкретный тест" и будет ли он работать вне контекста, будет вопросом к авторам теста и к тому, что и как мы тестируем. В целом есть моем и др. механизмы для воспроизводимости

Лучше чем у Selenium за счёт более высокого уровня абстракции. Те, грубо говоря, хорошо написанный (или даже банально простой) тест падать не будет

Стоимость автотестов надо считать как TCO и они окупаются не за 5 минут. Соответственно да, сначала вы будете инвестировать, а ROI будет совсем не сразу

Работаю вместе с автором, статья не закащная (потому что мы ее не заказывали, у мы нас есть отдельное PR агентство), но правдивая.

Не очень понятно, почему мы не можем использовать тот инструмент, который наша компания разрабатывает и рассказать об опыте его применения? Или вы считаете, что человек, использующий в работе платное ПО автоматически пишет заказу? Я например, обожаю продукты JetBrains, активно их использую, при этом никак с ними не аффилирован. Моя статья о том, что бесплатный Codelite мешает, а PhpStorm помогает разрабатывать, тоже вызовет ваш гнев?

Код это интересно, но я думаю, что статья выглядит неполной без рассказа о том, как в CI/CD у вас настроена работа с артефактами - ассеты, очереди.

Вы изобрели lazy refactoring

AI идет в комодитизацию стремительным паравозом. Не весь и не везде, то тренд однозначно такой.
«Мерчи дешевле» — это если смотреть здесь и сейчас. А большая компания себе этого позволить не может, ей надо смотреть на то, как это будет через 5-10 лет. Естественно используется опыт США и т.д. чтобы попытаться заглянуть в будущее, но у нас все будет (ну, без глобальных катаклизмов) так же, просто с некоторым лагом.
Про RPA и «нормальную автоматизацию» вопрос тролля :) RPA это и есть нормальная автоматизация, и необходимость вписывать в бюджет что-то более дорогое, если что-то более дешевое прекрасно справится — не очень понятно
Как раз наоборот, ML можно натренировать определять «видное место» и прочие метрики, которые нам надо. Ему все равно, реально, главное — чтобы было на чем учиться.
И как только стоимость камер + централизованого решения становится меньше стоимости мерч(ей) с планшетом, софтом и т.д. — опа, никто никуда не ездит.
К замене людей на рутинных задачах на технические решения. В любых видах и формах. Люди болеют, организуют профсоюзы, уходят к другим работодателям и т.д. и т.п. Там где это ценные, интеллектуальные ресурсы, вопрос понятен — надо удерживать. Там где это «monkey job» — если можно дешево автоматизировать, будут дешево автоматизировать.
Был момент, когда автоматизация была дорогая в создании и в поддержке. Сейчас ML коммодитизируется, роботы коммодитизируются, получается очень интересная всем картинка.
AI делает то, что всегда делает — на основании данных делает выводы — правильная ли раскладка? Полна ли полка? Стоит ли вызывать полицию если прозошла кража? Куда надо завести какие товары? Что написано в этой счет-фактуре? Что от нас хотят госорганы в этом запросе? И т.д.
То, что у кого-то, например Walmart, не пошла та ли иная тема, для ИТ очень нормально. Это не значит, что они больше ее двигать не будут. Сменится бизнес климат, команда, CTO, будет задача на сокращение издержек — побегут к роботам, других вариантов пока на горизонте нет. И, кстати, RPA они очень круто используют, угадайте какой :)
Тут есть интересный момент — теоретически да, можно. На практике — у всех ретейлеров есть к теме сильный интерес, именно потому, что теория и практика не сильно пересекаются
На самом деле, тема со стейками более богатая — например мираторговские стейки не должны лежать с черкизовскими, или премиум стейки должны быть на видном месте. Сейчас это контролируют специально обученные люди, а в принципе, задача поддается ML
Поддержу Furriest — писать свой RPA без целей его массового применения это, к сожалению, как показывает практика, тупиковый путь.
RPA дает скорость внедрения, небольшой TOC автоматизации процесса и возможность решать нестандартные задачи.

Оставим за кадром скорость внедрения, предположим что платформа идеально подходит под задачи нашего бизнеса (ха-ха, конечно, но допустим).

А вот с точки зрения TOC и ROI, на мой взгляд, все грустно.
По опыту, для того, чтобы сделать на кастомной разработке автоматизацию, нужен автор этой автоматизации == автору платформы, или существенные усилия со стороны этого автора по документированию, отладке и поддержке платформы.

Если идем по первому сценарию, то про масштабирование можно забыть, силы у человека не бесконечны, плюс все умрет с его уходом на другую должность/работу (или еще хуже, будет на него завязано). Можно сделать несколько процессов, но их поддержка и развитие съедят весь ресурс.

Если по второму, то нужны люди, людям нужны зарплаты, и не очень понятно, как можно получить хоть какую-то экономическую эффективность автоматизации, без продажи самой платформы. Стоимость одного хорошего разработчика в Москве существенно выше чем стоимость лицензий на нескольких готовых роботов, которые поддерживаются, улучшаются и т.д. вендором. А нам еще нужен тестировщик, аналитик, тех писатель, в какой-то момент PM, следить за всем этим безобразием.
И это мы еще на нашей платформе даже процессы не пишем, а только платформу разрабатываем (опять же предположим, что разрабатываем идеально, без багов, проблем и опозданий).

Отсюда же проблема с нестандартными задачами — как только мы выходим за рамки комфорта нашей разработки (любимые всеми нами VDI, ML, CV и OCR требуют отдельных усилий) — у нас не будет ни ресурсов, ни времени, ни сил на то, чтобы это реализовать.

Когда-то, много лет назад, я делал кастомные CMS, а потом мне пришлось поддерживать сайт сделаный на чужой кастомной CMS. Это был очень полезный опыт, меня он многому научил и сэкономил много нервов и времени моим клиентам. Уверен, что опыт разработки своего RPA-решения очень поможет его автору и желаю успехов во всех его начинаниях!

Спасибо большое за статью!
Интересно, но вывод напоминает давние утверждения о том, что для базы данных ничего не надо ui, кроме админской консоли.
То что вы смогли на питоне реализовать некую задачу поиска некоего отклонения на графе и визуализировать результат никак не даёт в результате майнер, это просто демонстрация алгоритма, который может лежать в его основе

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

"Интересно" читать комментарии одного, плохо понимающего о чем говорит, человека, на фантазии другого

youtu.be/trBAs2qTLbw вот здесь более новая информация и видео по UiPath Activity Creator

Отличная статья, видно, что автор серьезно занимается темой

Добрый день! Очень полезная и интересная статья.
Но, боюсь, с цифрами у вас что-то не то, особенно в части с Excel.
Во первых путь миграции по одной записи категорически неверный, нужно делать через datatable. Аргумент что так проще странный, через datatable проще намного.
Во вторых, даже вашим способом так долго работать не должно. Может быть вы поделитесь кодом, чтобы было понятно, о чем речь?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity