Comments 6
И в чём смысл подобного костыля? У СПАРКа есть API, который будет как минимум работать на порядок быстрее, чем RPA, заполняющий поля и кликающий кнопки. Не говоря уже о том, как отнесётся Интерфакс к такому способу использования их продукта (коллег один аналогичный сервис забанил, когда они с обычной подпиской начали автоматизированно данные сливать). Способов распарсить Excel тоже, мягко говоря, немало (даже если мы не можем повлиять на источник информации, чтобы от него приходило что-нибудь более подходящее).
Т.е. даже если последний этап (внести в учётную систему) нормально автоматизировать по каким-то причинам проблематично (и то причины тут могут быть в 90% случаев только бюрократическими) — то первые два гораздо эффективнее и, подозреваю, сильно дешевле решаются простым скриптом, который выдаст на выходе уже обогащённый данными СПАРКа JSON, XML или что там в эту учётную систему проще всего импортировать окажется.
Т.е. даже если последний этап (внести в учётную систему) нормально автоматизировать по каким-то причинам проблематично (и то причины тут могут быть в 90% случаев только бюрократическими) — то первые два гораздо эффективнее и, подозреваю, сильно дешевле решаются простым скриптом, который выдаст на выходе уже обогащённый данными СПАРКа JSON, XML или что там в эту учётную систему проще всего импортировать окажется.
Добрый день!
В тех случаях, когда у системы нет открытого API, времени или возможности разработки, простой альтернативой интеграции может выступать RPA-бот. Его разработка может занять (как в данном случае) лишь несколько дней. Кроме того, можно работать с несколькими сервисами, в том числе внешними, в рамках одного процесса. Например, проверка клиента при открытии счета в банке. В этом случае время, требуемое на интеграцию, также существенно возрастает, и могут возникнуть сложности, обозначенные выше. Это связано с отсутствием возможности забрать данные через API.
В данном случае работа с сайтом СПАРК была выбрана для создания примера на базе известной многим системы, с понятным и крайне востребованным процессом в закупках.
В тех случаях, когда у системы нет открытого API, времени или возможности разработки, простой альтернативой интеграции может выступать RPA-бот. Его разработка может занять (как в данном случае) лишь несколько дней. Кроме того, можно работать с несколькими сервисами, в том числе внешними, в рамках одного процесса. Например, проверка клиента при открытии счета в банке. В этом случае время, требуемое на интеграцию, также существенно возрастает, и могут возникнуть сложности, обозначенные выше. Это связано с отсутствием возможности забрать данные через API.
В данном случае работа с сайтом СПАРК была выбрана для создания примера на базе известной многим системы, с понятным и крайне востребованным процессом в закупках.
При отсутствии API, опять же, в 90% случаев быстрее спарсить сайт внешнего сервера каким-нибудь Python+beautifulsoup или Java+JSoup или что там лучше знакомо первому пойманному для этой задачи разработчику. В редких случаях, когда на сайте особо хитрый JS, может понадобиться Selenium.
И задачка, описанная в статье, за те же несколько дней точно решится силами одного Junior'а или (при отсутствии своих разработчиков) фрилансера. Что будет не только быстрее работать, но и как минимум в разы, а то и на порядки дешевле обойдётся. Не знаю цен на RPA-решения SAP (впрочем, слова «SAP» и «дёшево» никогда не сочетались), но ценник на UIPath меня в своё время впечатлил.
И задачка, описанная в статье, за те же несколько дней точно решится силами одного Junior'а или (при отсутствии своих разработчиков) фрилансера. Что будет не только быстрее работать, но и как минимум в разы, а то и на порядки дешевле обойдётся. Не знаю цен на RPA-решения SAP (впрочем, слова «SAP» и «дёшево» никогда не сочетались), но ценник на UIPath меня в своё время впечатлил.
Как вы верно заметили, эту задачу возможно решить по-другому, например, силами (одного) разработчика. Но важно принимать во внимание факт, что программист может покинуть компанию и забрать с собой знание о том, как работает скрипт. А также в организациях, как правило, существует более, чем один процесс подходящий под RPA. Представьте, что таких скриптов сотни. Каждый из них нужно поддерживать. И в данном случае специализированное RPA решение даёт возможность оркестрации ботов, показывает аналитику по отработке различных сценариев, позволяет определять на каких машинах тот или иной робот должен запускаться, грубо говоря, управлять этими процессами на корпоративном уровне.
Также с точки зрения лицензирования у нас применен подход, основанный на количестве запусков робота, либо роботов. Вы можете оценить стоимость использования сервиса SAP Intelligent Robotic Automation здесь: www.sap.com/products/cloud-platform/pricing/estimator-tool.html
Также с точки зрения лицензирования у нас применен подход, основанный на количестве запусков робота, либо роботов. Вы можете оценить стоимость использования сервиса SAP Intelligent Robotic Automation здесь: www.sap.com/products/cloud-platform/pricing/estimator-tool.html
Спасибо за комментарий и ссылку на калькулятор.
Т.е. если я правильно понял, то в Вашем примере, если сотруднику приходит, скажем, в среднем 100 строк в этой таблице каждый рабочий день, то в месяц получится (2 * 1 + 2 * 100) * 20 дней = 4040 транзакций (открыть почту и прочитать файл — одна транзакция на шаг, считать данные в СПАРКе и внести в учётную систему — по транзакции на каждую строку).
Т.е. 2000 евро в месяц. Т.е. ФОТ минимум на двух сотрудников минимальной квалификации, которые могли бы выполнять эту работу вручную. При том, что вручную разобрать эти 100 записей даже у самого медлительного сотрудника займёт не больше полдня.
ОК, перед ручным трудом у нас есть преимущество в точности — не будет ошибок, опечаток, пропусков и пр. Но за эти же деньги условный скрипт силами привлечённых, а тем более своих разработчиков можно переписывать хоть каждый месяц заново.
Что касается оркестрации, аналитики и пр. — честно говоря, меня несколько пугает мысль о подобных масштабах внедрения RPA. Если у нас настолько всё плохо с интеграцией разных информационных систем — надо, наверное, посмотреть вообще на корпоративную архитектуру, master data management и пр. Чтобы решить проблему системно, а не согласованно и роботизированно копипастить гигабайты данных в день из табличек в окошечки и из окошечек в таблички. Тем более, что бюджет на сотни роботов будет сопоставим со стоимостью идеологически правильного и красивого решения.
Я не придираюсь, просто меня давненько удивляет такой рост популярности RPA. Пока что могу объяснить это только инертностью и забюрократизированностью крупных корпораций, где внедрить полноценную интеграцию — это месяцы и годы согласований, закупок, километры нервов, потраченных в баталиях с безопасниками, и пр. А RPA, вроде как, в давно согласованных и введённых в эксплуатацию системах ничего не меняет, разработкой само по себе тоже не является — можно сделать быстро. Пусть медленно, пусть некрасиво — но всё лучше, чем руками.
Т.е. если я правильно понял, то в Вашем примере, если сотруднику приходит, скажем, в среднем 100 строк в этой таблице каждый рабочий день, то в месяц получится (2 * 1 + 2 * 100) * 20 дней = 4040 транзакций (открыть почту и прочитать файл — одна транзакция на шаг, считать данные в СПАРКе и внести в учётную систему — по транзакции на каждую строку).
Т.е. 2000 евро в месяц. Т.е. ФОТ минимум на двух сотрудников минимальной квалификации, которые могли бы выполнять эту работу вручную. При том, что вручную разобрать эти 100 записей даже у самого медлительного сотрудника займёт не больше полдня.
ОК, перед ручным трудом у нас есть преимущество в точности — не будет ошибок, опечаток, пропусков и пр. Но за эти же деньги условный скрипт силами привлечённых, а тем более своих разработчиков можно переписывать хоть каждый месяц заново.
Что касается оркестрации, аналитики и пр. — честно говоря, меня несколько пугает мысль о подобных масштабах внедрения RPA. Если у нас настолько всё плохо с интеграцией разных информационных систем — надо, наверное, посмотреть вообще на корпоративную архитектуру, master data management и пр. Чтобы решить проблему системно, а не согласованно и роботизированно копипастить гигабайты данных в день из табличек в окошечки и из окошечек в таблички. Тем более, что бюджет на сотни роботов будет сопоставим со стоимостью идеологически правильного и красивого решения.
Я не придираюсь, просто меня давненько удивляет такой рост популярности RPA. Пока что могу объяснить это только инертностью и забюрократизированностью крупных корпораций, где внедрить полноценную интеграцию — это месяцы и годы согласований, закупок, километры нервов, потраченных в баталиях с безопасниками, и пр. А RPA, вроде как, в давно согласованных и введённых в эксплуатацию системах ничего не меняет, разработкой само по себе тоже не является — можно сделать быстро. Пусть медленно, пусть некрасиво — но всё лучше, чем руками.
Нет, вы посчитали не совсем правильно.
Все строки будут обработаны в цикле, и это не 100 транзакций (на каждую), а одна. То есть по вашему сценарию получается 500 евро в месяц, а не 2000.
На наш взгляд, рынок RPA сейчас действительно переживает подъем, связанный с удобством массового применения данной технологии. Конечно же, в некоторых случаях интеграция является правильным решением, но RPA может ее заменять при необходимости быстрого и недорогого решения задачи.
Все строки будут обработаны в цикле, и это не 100 транзакций (на каждую), а одна. То есть по вашему сценарию получается 500 евро в месяц, а не 2000.
На наш взгляд, рынок RPA сейчас действительно переживает подъем, связанный с удобством массового применения данной технологии. Конечно же, в некоторых случаях интеграция является правильным решением, но RPA может ее заменять при необходимости быстрого и недорогого решения задачи.
Sign up to leave a comment.
Как создать виртуального робота?