Comments 13
А как по мне это даже не обезболивающее. Это очередная сладкая пилюля, Которую пытаются продать.
Проблема загрузки Excel решается на ура и за короткие сроки в любой классической парадигме разработки, но бизнес может ждать решения этой проблемы месяцами не потому что это сложно а потому что ЗАДАЧА НЕ ПРИОРИТЕТНА!
Всем плевать что есть где-то Марья Ивановна, которая тратит 2 часа в день на перебивание из экселя в программу когда есть задача сделать сложную бонусную программу для клиентов, которая принесет бизнесу миллионую прибиль.
А эти робототехники говорят немного о другом. НАПИСАНИЕ КОДА ЭТО НЕ ПРОБЛЕМА!!! И красивые дорогие роботы не решают ровным счетом ничего. Время разработки на автоматизацию действительно сокращаются навязыванием абсолютно наплевательским подходом, который призывает отказаться от действительно проблемного участка разработки — ИНТЕГРАЦИЯ! Интеграция кода в жизненный цикл приложения вот это вот проблема. А будет ли жить Ваш робот если разработчик переименует ID какого-то дива и про Вас не вспомнит (а он не вспомнит потому что не будет о Вас знать)? Просите доступ к БД — поверьте разработка максимально защитится от Ваших глючных роботов предоставив доступ к витрине данных вместо реальной БД (это к стати бизнесу влетит в копеечку) но что вы будете делать когда разработчик неожиданно поменяет структуру БД и ничего Вам не скажет?
Раньше были такие вещи как Visual Basic, Access где бизнес пользователи за недорого и без пафоса действительно решали свои рутинные задачи (некоторые вещи к стати перерастали во взрослое ИТ и ставали головной болью) и в этом был смысл. Здесь же я смысла не вижу
Проблема загрузки Excel решается на ура и за короткие сроки в любой классической парадигме разработки, но бизнес может ждать решения этой проблемы месяцами не потому что это сложно а потому что ЗАДАЧА НЕ ПРИОРИТЕТНА!
Всем плевать что есть где-то Марья Ивановна, которая тратит 2 часа в день на перебивание из экселя в программу когда есть задача сделать сложную бонусную программу для клиентов, которая принесет бизнесу миллионую прибиль.
А эти робототехники говорят немного о другом. НАПИСАНИЕ КОДА ЭТО НЕ ПРОБЛЕМА!!! И красивые дорогие роботы не решают ровным счетом ничего. Время разработки на автоматизацию действительно сокращаются навязыванием абсолютно наплевательским подходом, который призывает отказаться от действительно проблемного участка разработки — ИНТЕГРАЦИЯ! Интеграция кода в жизненный цикл приложения вот это вот проблема. А будет ли жить Ваш робот если разработчик переименует ID какого-то дива и про Вас не вспомнит (а он не вспомнит потому что не будет о Вас знать)? Просите доступ к БД — поверьте разработка максимально защитится от Ваших глючных роботов предоставив доступ к витрине данных вместо реальной БД (это к стати бизнесу влетит в копеечку) но что вы будете делать когда разработчик неожиданно поменяет структуру БД и ничего Вам не скажет?
Раньше были такие вещи как Visual Basic, Access где бизнес пользователи за недорого и без пафоса действительно решали свои рутинные задачи (некоторые вещи к стати перерастали во взрослое ИТ и ставали головной болью) и в этом был смысл. Здесь же я смысла не вижу
Именно об этом я и говорил, когда говорил что грань разумности использования надо найти самостоятельно. А не слушать, что рассказывают рекламщики :) В примере, который я привел в статье, действительно многое решается путем внесение изменений в платформу — но суровый мир энтепрайза, к сожалению, говорит что эти изменения (а их порядочно — добавление новых сущностей, изменение кучи окон и так далее) — тянет за собой необходимость согласование с кучей стейкхолдеров и все такого. А проблема есть прямо тут и сейчас.
Поэтому, в некоторых случаях, может оказаться удобно сделать это с помощью [тут подставить технологию, куда входит и RPA]. И написать скоп изменений в долгую, чтобы проблема исчезла сама собой и этот костыль можно было убрать.
Поэтому, в некоторых случаях, может оказаться удобно сделать это с помощью [тут подставить технологию, куда входит и RPA]. И написать скоп изменений в долгую, чтобы проблема исчезла сама собой и этот костыль можно было убрать.
Все хуже, я думаю. Если раскручивать эти примеры дальше, то мы придем к проблемам в процессах.
Вот коротко мысль geber: процесс добавления фич столь сложный (и дорогой?), что пользователь решил его обойти.
У valis: бизнес считает, что задачу Марьи Ивановны стоит делать вручную, но требует от нее скорости работы как в автоматизированном варианте.
В обоих вариантах что-то не так пошло в головах руководителей, т.к. оба варианта легко сводятся к противоречию. Можно какие угодно вставлять новые технологии: RPA, CRM, ERP, но пока это противоречие не решено — системно ничего не изменится.
Вот коротко мысль geber: процесс добавления фич столь сложный (и дорогой?), что пользователь решил его обойти.
У valis: бизнес считает, что задачу Марьи Ивановны стоит делать вручную, но требует от нее скорости работы как в автоматизированном варианте.
В обоих вариантах что-то не так пошло в головах руководителей, т.к. оба варианта легко сводятся к противоречию. Можно какие угодно вставлять новые технологии: RPA, CRM, ERP, но пока это противоречие не решено — системно ничего не изменится.
Ну не совсем так. У меня от Марьи Ивановны требуют ровно то, что она умеет и ее руководитель знает что делать это вручную не правильно и уже даже подал заявку на автоматизацию данного процесса в ИТ.
Но как в хорошем зрелом бизнесе сначала задача попадет на бизнес аналитика, который сначала действительно попробует выяснить а нужна ли эта задача бизнесу (как и в любом крупном энтерпрайзе у нас случались курьезы когда человечья делал что-то, чего уже по определению делать не нужно).
После действительно идет муторный круг исследований, согласований, планирований. Потом наконец таска падает разработчику. После процесс тестирования, внедрения… Все это сопровождается горой отчетности и бесконечных совещаний. Но я не представляю другого пути.
Все это можно оптимизировать, продавливать, ускорять, иногда подпирать костылями. Но ни в коем случае нельзя избегать! Даже идиотские с одной стороны телодвижения нужны
Но как в хорошем зрелом бизнесе сначала задача попадет на бизнес аналитика, который сначала действительно попробует выяснить а нужна ли эта задача бизнесу (как и в любом крупном энтерпрайзе у нас случались курьезы когда человечья делал что-то, чего уже по определению делать не нужно).
После действительно идет муторный круг исследований, согласований, планирований. Потом наконец таска падает разработчику. После процесс тестирования, внедрения… Все это сопровождается горой отчетности и бесконечных совещаний. Но я не представляю другого пути.
Все это можно оптимизировать, продавливать, ускорять, иногда подпирать костылями. Но ни в коем случае нельзя избегать! Даже идиотские с одной стороны телодвижения нужны
наверное стоит учитывать что предлагаемое решение просто удивительно хорошо вписываться в модель MVP — оно позволяет решать ОПЕРАТИВНЫЕ задачи бизнеса — не правильно с ТЗ единой идеологии и Любого Централизованного подхода, но по сути чем оно отличается от микросервисов? это они же вид сбоку только без потребности заменять собой всю инфраструктуру — те это «ОПЕРАТИВНЫЙ КОСТЫЛЬ» который можно Быстро внедрить в работу… Хорошо это или плохо? ну вот по мне так Это просто очередной этап развития информационных систем бизнеса…
Какое же дно!
Обычное. С тех пор как все увидели какие же бабки способен приносить ИТ началось — ERP, CRM, Диджитализация, RPA, ЭДО, BI и еще десяток модных словечек которыми топ менеджеров компаний ЕЖЕДНЕВНО атакуют десятки продажников.
Все показывают красивые графики, которые сулят Вам светлое будущее с копеечной стоимостью владения при внушительных капитальных затратах. Куда уж с ними тягаться хмурым айтишникам из собственных подразделений.
Все показывают красивые графики, которые сулят Вам светлое будущее с копеечной стоимостью владения при внушительных капитальных затратах. Куда уж с ними тягаться хмурым айтишникам из собственных подразделений.
Уже 3 пост про этих роботов на Хабре и в каждом авторы показывают фантастическое непонимание проблемы. Или делают вид
Т.е. на разработку мы ресурсов не даем, а на RPA пожалуйста горстью?
Возможно в области парсинга GUI компонентов RPA и сложно переплюнуть, но во всем остальном то, может логичнее какой-нибудь VBA,python,powerBI?
Честно говоря, я в первый раз в жизни понял, что такое «подгорает» когда прочитал предыдущую статью про волшебную таблетку RPA( habr.com/ru/post/551318 ).
Очень хотелось ее прокомментировать, но комментировать было особенно нечего, одни эмоции, то что написал автор той статьи больше всего мне напомнило класс программ «бредогенератор». Вольное жонглирование терминами, ноль обоснований, бравада кривыми решениями кривость которых понятна, во всяком случае мне, с первого взгляда и никакого погружения в проблематику, в вопросы а почему вот так все не идеально и какую именно проблему мы решаем.
Но почему же тогда подгорело? А потом, что это маркетинг, попытка продажи волшебной таблетки последствия применения которой разгребать потом как раз «принижаемым» в этой статье ИТ специалистам.
Да есть класс задач которые вероятно удобнее решить с использование RPA, вероятно это в основном системы доступа к коду которых нет и они не имеют необходимых интерфейсов. И да, здесь я даже поддержку подобное решение. Но это не волшебная таблетка и даже не обезболивающее решающее проблемы сроков и стоимости разработки, это костыль в самом неприятно смысле этого слова.
Возможно в области парсинга GUI компонентов RPA и сложно переплюнуть, но во всем остальном то, может логичнее какой-нибудь VBA,python,powerBI?
Честно говоря, я в первый раз в жизни понял, что такое «подгорает» когда прочитал предыдущую статью про волшебную таблетку RPA( habr.com/ru/post/551318 ).
Очень хотелось ее прокомментировать, но комментировать было особенно нечего, одни эмоции, то что написал автор той статьи больше всего мне напомнило класс программ «бредогенератор». Вольное жонглирование терминами, ноль обоснований, бравада кривыми решениями кривость которых понятна, во всяком случае мне, с первого взгляда и никакого погружения в проблематику, в вопросы а почему вот так все не идеально и какую именно проблему мы решаем.
Но почему же тогда подгорело? А потом, что это маркетинг, попытка продажи волшебной таблетки последствия применения которой разгребать потом как раз «принижаемым» в этой статье ИТ специалистам.
Да есть класс задач которые вероятно удобнее решить с использование RPA, вероятно это в основном системы доступа к коду которых нет и они не имеют необходимых интерфейсов. И да, здесь я даже поддержку подобное решение. Но это не волшебная таблетка и даже не обезболивающее решающее проблемы сроков и стоимости разработки, это костыль в самом неприятно смысле этого слова.
Люди придумали на питоне как автоматизировать ctrl+c и ctrl+v и преподносят нам как замену микросервисам
Sign up to leave a comment.
RPA — обезболивающее или серебряная пуля?