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

авторТ.ч. овчинка автоматизация, да еще сделаная непрофиссионалом, выделки не стоит.
Тут не совсем. Если официальные разработчики официально отказывают в разработке нормального инструмента массового ввода по формальным причинам, либо если ЖЦ такой разработки организационно длится невообразимо долго (месяцы), а решить надо ситуативную задачу здесь и сейчас "вдолбите 100500 однотипных документов в ERP в срок до вчера", - то RPA-инструмент с макрорекордером очень даже оказывается "стоит выделки".

авторПри условии, что исполнитель хорошо владеет RPA-инструментом, своей ERP-ситемой и что RPA успешно сработает.
На практике достаточно 1го и 3го пунктов. Причём если RPA-инструментарий содержит встроенный макрорекордер, и скрипты которые он формирует на какомто достаточно распространённом языке (ну например тотже VBA как дефакто-стандарт всякой наколенной лоскутной автоматизации), - то порог входа в такое RPA заметно снижается.
Разумеется продвинутый пользователь такого RPA должен обладать задатками программиста (а лучше быть бывшим программистом, что в офисах не редкость).

автор я выше описывал вполне жизненный пример - повторю "нам будет интересно для вас сделать api если вы нам обеспечите оборот 5 000 000 руб/мес - мы вам дадим статус любимого клиента и будем обсуждать ваши хотелки. иначе пройдити нафих"
Или другой банальный пример: SAP-коробка отдана на внутренний оутсорс, заказ реализации массового ввода под конкретную бизнес-транзакцию может организационно длиться месяцами (от написания ТЗ, до его реализации и сдачи в ПЭ);
- плюс у оутсорсера могут быть масса более критичных проектов, ссылаясь на которые он может либо отказать, либо донельзя затянуть сроки;
- плюс (применительно к SAP-коробкам) в ТЗ базового проекта среди целей и задач может значиться чтото вроде "максимальное использование базовой коробочной функциональности SAP", что даёт повод отказать в реализации ТЗ по формальному признаку "это не стандарт, а допразработка => противоречит концепции проекта => индейская изба => продолжайте долбить вручную".

В таких условиях RPA-инструмент хоть и костыль, но позволяющий пользователям без привлечения оутсорсера решать ситуативные бизнес-задачи. Т.е. вчера долбили по 3 документа в день, а сегодня дали приказ вдолбить 100503 со сроком завтра. Вот для такого какраз RPA вполне себе инструмент.