Comments 2
Почему пропустили слабые стороны RPA? Уж их то перед начало точно стоит знать.
1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).
2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.
В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.
1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).
2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.
В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.
Почему пропустили слабые стороны RPA? Уж их то перед начало точно стоит знать.
1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).
Соглашусь, но частично. Процессы для РПА зачастую берут межплатформенные и системы on-premise, по крайней мере сейчас, и компании не собираются обновлять все и сразу в короткие сроки. Пока пройдет год, два до обновления/смены систем, есть вероятность получить выгоду. Все это надо считать. Но, конечно, если планируется смена систем, обновления, доработки и пр., в очень короткие сроки, то не нужно тратить время на роботизацию.
2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.
В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.
Верно. РПА очень специфичен и процессы не все под него подойдут, а софты улучшаются с каждым днем. Стараться нужно делать роботизацию на бэке, нежели подвязывать на интерфейсе, так как обновления системы будут ломать робота, и поддержка должна будет его постоянно поправлять. Разработка на бэке также увеличивает скорость обработки. Мы выводили примерную статистику «сколько раз нужно будет подправлять робота по процессам в течение года» чтобы посчитать стоимость поддержки.
РПА не панацея, увы, но тем не менее, в отдельно взятых случаях стоит считать все риски и ситуацию AS IS чтобы в точности ответить на вопрос «стоит ли идти в роботизацию?».
Обязательно нужно проводить преданализ и посчитать выгоду.
1) если есть АПИ для интеграции (или его можно дописать. или оно планируется в ближайшее время), то в RPA лезть дорого (в основном потому, что RPA пытается функционировать с форматами обмена для человека, а не для машины).
Соглашусь, но частично. Процессы для РПА зачастую берут межплатформенные и системы on-premise, по крайней мере сейчас, и компании не собираются обновлять все и сразу в короткие сроки. Пока пройдет год, два до обновления/смены систем, есть вероятность получить выгоду. Все это надо считать. Но, конечно, если планируется смена систем, обновления, доработки и пр., в очень короткие сроки, то не нужно тратить время на роботизацию.
2) RPA ломаются от любого чиха дизайнера внешнего сервиса. Поэтому затраты на RPA — не одномоментные, там нужно закладывать суммы в обслуживание.
В итоге RPA получается очень узкоспецифичным продуктом. Современный софт сдвигается в сторону все большего числа интеграций — и это сужает поле RPA с одной стороны, довольно высокие затраты сужают с другой, сильная изменчивость софта и любовь перекраивать интерфейсы — сужает с третьей стороны.
Подозреваю, что он хорошо заходит для legacy, где ну никак интеграцию не прикрутить, софт почти не развивается и поэтому почти не меняется. А вот, где еще он хорошо зайдет — это хороший вопрос.
Верно. РПА очень специфичен и процессы не все под него подойдут, а софты улучшаются с каждым днем. Стараться нужно делать роботизацию на бэке, нежели подвязывать на интерфейсе, так как обновления системы будут ломать робота, и поддержка должна будет его постоянно поправлять. Разработка на бэке также увеличивает скорость обработки. Мы выводили примерную статистику «сколько раз нужно будет подправлять робота по процессам в течение года» чтобы посчитать стоимость поддержки.
РПА не панацея, увы, но тем не менее, в отдельно взятых случаях стоит считать все риски и ситуацию AS IS чтобы в точности ответить на вопрос «стоит ли идти в роботизацию?».
Обязательно нужно проводить преданализ и посчитать выгоду.
Sign up to leave a comment.
Что нужно знать перед началом роботизации процессов?