Комментарии 12
С помощью UiPath мы сделали это бесплатно за 3 недели.
Когда появляются бесплатные рабы, окупаемость любой автоматизации становится божественной. Но, собственно, можно было ничего не автоматизировать, а на полфирмы поставить работать бесплатных рабов.
Если без сарказма, то надо сравнивать затраты с одной и другой стороны.
Если вы не сокращаете, а переобучаете людей, то выходит, что вы начинаете а) платить больше ФОТа более квалифицированным сотрудникам б) добавляете ФОТ тех, кто настраивает роботов и в принципе участвовал в процессах - например, отвлекаясь от основной работы в) платите за лицензии владельцу RPA ПО, правильно я понял?
То есть внедрение RPA не уменьшает ФОТ, а увеличивает?
Можете рассказать, какие количественные показатели были поставлены по целям до запуска внедрения RPA?
Спасибо за статью!
Почему была выбрана роботизация вместо автоматизации (и реализации на ЯП: Java, Python и т.д.)?
Кто занимается сопровождением роботизированных процессов?
Роботизация - это по своей сути подраздел автоматизации. Главным преимуществом применения роботов является то, что они позволяют автоматизировать взаимодействие с разными системами за очень короткие сроки.
Не у всех систем и программ на свете есть API, а иногда оно на столько неудобное, что требует месяцев разработки и отладки интеграционных модулей, чтобы все работало "как часы". Тут возникает диссонанс - действие, которое нужно автоматизировать кодом через вызов методов API, пользователь делает в два клика (условно). Соответственно, с помощью RPA можно настроить робота, который будет делать эти самые два клика - и это будет очень быстрой разработкой.
А еще почему-то многие ошибочно думают, что "роботы" (RPA) - это только про "квадратики с действиями". На самом деле современные RPA-платформы, в частности UiPath, позволяют вам добавлять целые блоки кода на языках C#, VBNET в своих роботов, а при необходимости - подключать любые доступные .NET Framework и .NET Core библиотеки.
И зачастую наиболее правильным решением будет не "Только писать код" или "Только применять робота", а комбинировать оба подхода. Там где у вас есть компетенции в API и вы уверены, что сделаете интеграцию быстро - пишите код, там где есть понимание, что застрянете в болоте - используйте робота.
Спасибо за ответ.
Скорость разработки - это преимущество, но как боретесь с изменением интерфейса систем и изменением функциональности? Ведь API - это всё-таки некий легальный контракт взаимодействия, который система предоставляет для других систем. И молча API, даже самописный, просто так не изменить - как правило API версионируется, остаётся (какое-то время) обратная совместимость со старыми версиями, и процесс не упадёт при добавлении новой версии и изменении какой-то сигнатуры методов.
В тоже время робот запрограммирован на выполнение кликов по определённым контролам. Меняется разметка веб страницы, меняется функциональность кнопки - и робот падает, процесс встаёт.
И встаёт вопрос о затратах на переделку робота + траты от простоя по процессу.
Это сообщение коррелирует с моим вторым вопросом про поддержку решений - на него ответ не получил. Кто поддерживает разработанные решения? Кто контролирует доработку решений? И ещё вопрос: есть ли процедуры ревьюирования решений с целью предотвратить изобретение велосипедов и использования роботов только ради использования роботов и с целью быстрой реализации? Как это происходит при таком большом количестве роботизируемых процессов?
На самом деле ваши вопросы - довольно частые, и на них уже давно есть ответы. в частности по поводу изменчивости интерфейса можно почитать здесь: https://habr.com/ru/company/uipath/blog/577782/
Разработка новых процессов, доработка существующих, а так же поддержка в целом, как правило, осуществляется центром компетенций, который формируется внутри компании (или привлекается от интегратора). Финансовая сторона вопроса всегда должна быть просчитана еще до того, как вы вошли в эту историю и начали вкладывать средства в роботизацию. Каких-то универсальных цифр я вам не приведу, так как для каждого заказчика они индивидуальны.
Если вам и правда интересно узнать как построить качественный центр компетенций, который будет приносить выгоду компании, а не заниматься бесконечными исправлениями ошибок - стоит связаться с вашим аккаунт-менеджером в UiPath, а если вы еще не установили контакт - всегда можно обратиться через форму обратной связи на https://uipath.marvel.ru/
Если в установленные сроки рассылка не проводится — оператор может получить штрафы со стороны контролирующих органов.
ещё бы штрафовать за ночные рассылки
Спасибо за статью и за подсказку с Uipath.
Но разве базовые программы учета не должны брать на себя заботы с работизацией/автоматизацией? ERP, 1C, SAP у них же есть доступные сервисы. Я веду к тому что не сложно будет сотрудникам работать в нескольких программах?
У перечисленных систем далеко не всегда коробочные решения подходят для всего сразу. Они требуют доработки-донастройки. И не всё они умеют без индивидуальной разработки нового функционала. Тем более когда идет вопрос про взаимодействие с другими системами, сайтами, программами, которые либо являются не очень популярными (и не имеют шаблонных коннекторов), либо являются самописными разработками (далеко не лучшего качества).
Интеграция в таком случае - дорогостоящий долгосрочный проект, а роботизация с использованием таких платформ как UiPath позволяет это сделать в разы быстрее и надежнее.
Отдельно важно отметить, что роботы - это не "еще одна программа" для пользователя, а программа, которая эмулирует действия человека. Максимум, что делает сотрудник - это запускает робота (но обычно это происходит по определенному событию или расписанию без участия человека).
закупочный, потому что он очень простой. Его полную автоматизацию удалось провести всего за 3 недели
Полную - вряд ли. Процесс формирования заказа на основе заявок - может быть, но весь процесс закупки совсем не простой и требует участия данных из десятка регистров информации, начиная с рабочего места инициатора при создании требования закупки, которое летит в подразделение закупок. Причем, если доверить роботу весь цикл - а значит гарантированная интеграция с источниками данных в виде связей внутри ERP или по API с внешними данными не производится - то риск ошибки велик (RPA выбирают, когда другой метод недоступен и данные захватывают из изображений в UI), а это риск потерь куда больший, чем затраты на традиционный код. Робот может просто отправить заказ с избыточным или недостаточным количеством, не теми ценами или номенклатурами, или не отправить заказ вовремя.
На роботизацию следующего более сложного процесса — сверку excel-файлов — потребовалось уже 2 месяца.
Зачем нужен робот для сверки Excel-файлов, когда есть нативный VBA и другие доступные бесплатные инструменты для гарантированной и молниеносной обработки массивов из Excel. 2 месяца - это огромный срок для такой задачи, значит дело не в технике сверки между файлами, а в логике и источниках дополнительных данных систем. Можете подробнее описать? Просто интересно, где конкретно RPA выигрывает у обычного кода. Тем более, вы пишите, что поддерживаете многообразие инструментов для различных задач и нет стратегии "RPA only" в архитектуре
Обходной лист при увольнении, в котором фиксируется, что за сотрудником нет никакого оборудования. Робот проверяет архив Excel-файлов и дает информацию по числящемуся оборудованию.
Реестр ОС в "архиве Excel-файлов". Если это правда, то в компании нужно не RPA внедрять, который судя по всему используется как инструмент борьбы с последствиями отсутствия системы учета, а сделать учет в виде простой базы данных в любой бесплатной СУБД или каких-нибудь гугл-таблицах. Иначе работы для RPA будет всегда очень много.
Причем, если доверить роботу весь цикл - а значит гарантированная интеграция с источниками данных в виде связей внутри 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 месяца) - весы все же перевешивают в сторону применения роботов, а не затрат на разработку "нормальной учетной системы".
Про сверку понял, что это не про между Excel-файлами, потому и задал вопрос. Если у систем нет API - наверное, его лучше сделать. Сделав один раз API вы решаете сразу же все текущие и будущие задачи на чтение и запись данных.
Легко сказать, да трудно сделать.
Я так написал именно потому, что сам реализовал не один десяток подобных инструментов для таких простых задач. Причем в компаниях, которые по масштабу сопоставимы с той, что указана в статье. 1 день - БД, 2 недели вечеров после основной работы или две пары выходных - приложение для пользователей: регистрация движений ОС, инвентаризация, ведение справочников. Цель - замена экселя на БД, а не космос с виртуальным ассистентом, 2 недели достаточно.
а не затрат на разработку "нормальной учетной системы".
По тону видно, что вы не беспристрастны и просто в обороне инструмента, который рекламируете, не приводя конкретного примера с оправданным использованием RPA, ещё и заявляя, что он автоматизирует полностью процесс закупки. Для разных задач - разные инструменты. RPA, наверное, хороший оркестратор + он умеет извлекать данные из графического интерфейса и возвращать в него результат - почему бы сразу не выделить эти его стороны. Правда, по моему опыту, с интерфейсом 1С он работает ненадежно, а в СНГ 1С очень популярен. Для SAP RPA вообще бессмысленный, с помощью записи макроса по действиям и расшифровки из них имен объектов форм, можно написать скрипт на VBS, который будет выполнять любой алгоритм с последовательным запуском транзакций, кликами, вставками данных. Это тоже занимает максимум пару недель; и да, я это делал сам ещё 10 лет назад.
Ведь робот может выполнить все действия для связки разных готовых систем, которые уже делают все нужное
Согласен. Сначала архитектура штатных ИС заставляет собственника реализовывать API в формате людей, затем формат API с людей меняют на RPA. Но это далеко не все задачи (взять из одной системы, вставить в другую). Когда речь зайдет о многоэтапной обработке сотни источников (таблиц с операциями, справочниками и прочим) для получения краткого BI-вывода и его возврата в ERP, интересно будет узнать как RPA это решит.
В целом вы описали интересный опыт, но интересны подробности, например участок кода решения конкретной задачи или скриншоты маршрута действий UiPath.
Beeline Казахстан: как за два года роботизировать почти 300 бизнес-процессов и сформировать свой отдел RPA-разработки