+7 495 204-23-04
#kitbot story
RPA vs классическая автоматизация
В большинстве компаний автоматизация уже частично выстроена или внутри систем или закрыта интеграциями. Но если смотреть на ежедневную работу, картина уже не такая позитивная. Сотрудникам по-прежнему приходится переносить данные между системами, сверять информацию и повторять одни и те же шаги в разных интерфейсах. Каждое действие само по себе простое, но вместе это занимает большую часть рабочего дня.
Здесь появляется RPA — как отдельный слой роботизации бизнес-процессов. Он забирает на себя повторяющиеся действия между системами, где нет смысла делать полноценную интеграцию, работает поверх существующих систем и не требует их изменения.
Здесь появляется RPA — как отдельный слой роботизации бизнес-процессов. Он забирает на себя повторяющиеся действия между системами, где нет смысла делать полноценную интеграцию, работает поверх существующих систем и не требует их изменения.
Где заканчивается классическая автоматизация
Если смотреть на автоматизацию с точки зрения бизнеса, задачи довольно быстро раскладываются на два типа.
Есть процессы, которые хорошо формализуются и почти не меняются. В таких случаях классическая автоматизация закрывает задачу лучше всего. Это могут быть, например, сложные цепочки согласований или обмен данными с 1С — такие сценарии один раз реализуются в системе и дальше становятся частью стандартной логики.
Но как только мы выходим за пределы такой логики, начинаются нюансы. Например, крупный ритейлер получает счета от поставщиков. Данные по ним уже есть в системе, но их нужно проверить, сопоставить с договором, занести в другую систему и передать дальше. Формально это не сложная задача, но таких счетов может быть сотни или тысячи в месяц.
С точки зрения бизнеса это не выглядит как проект для автоматизации, скорее как обычная операционная работа. Но по факту это регулярные затраты, например 500-800 человеко-часов в месяц или 1-2 сотрудника, которые постоянно заняты только этим.
Логичный вопрос, который обычно возникает у бизнеса: почему это не закрыть через доработки или API?
Чтобы пойти классическим путем, нужно описать логику процесса, вовлечь разработку, встроить изменения в систему, пройти тестирование и согласование. Таким образом, мы начинаем тратить на автоматизацию больше ресурсов, чем экономим.
Есть процессы, которые хорошо формализуются и почти не меняются. В таких случаях классическая автоматизация закрывает задачу лучше всего. Это могут быть, например, сложные цепочки согласований или обмен данными с 1С — такие сценарии один раз реализуются в системе и дальше становятся частью стандартной логики.
Но как только мы выходим за пределы такой логики, начинаются нюансы. Например, крупный ритейлер получает счета от поставщиков. Данные по ним уже есть в системе, но их нужно проверить, сопоставить с договором, занести в другую систему и передать дальше. Формально это не сложная задача, но таких счетов может быть сотни или тысячи в месяц.
С точки зрения бизнеса это не выглядит как проект для автоматизации, скорее как обычная операционная работа. Но по факту это регулярные затраты, например 500-800 человеко-часов в месяц или 1-2 сотрудника, которые постоянно заняты только этим.
Логичный вопрос, который обычно возникает у бизнеса: почему это не закрыть через доработки или API?
Чтобы пойти классическим путем, нужно описать логику процесса, вовлечь разработку, встроить изменения в систему, пройти тестирование и согласование. Таким образом, мы начинаем тратить на автоматизацию больше ресурсов, чем экономим.
Где появляется роботизация бизнес процессов (RPA) и как она работает
RPA — это способ снять с людей повторяющиеся действия, которые они выполняют между системами. Берётся конкретный сценарий работы и воспроизводится программным роботом. Например, в работе со счетами робот может:
При этом важно, что в существующих системах ничего менять не нужно. Робот копирует действия пользователей через интерфейс: открывает экраны, нажимает кнопки, заполняет поля. Поэтому роботизация процессов спокойно применяется и в старых системах с legacy-кодом, и в сложных IT-ландшафтах, где нет API или доступ к интеграциям ограничен.
- сам открыть письмо или документ,
- считать данные,
- сверить их с системой,
- занести информацию и передать дальше.
При этом важно, что в существующих системах ничего менять не нужно. Робот копирует действия пользователей через интерфейс: открывает экраны, нажимает кнопки, заполняет поля. Поэтому роботизация процессов спокойно применяется и в старых системах с legacy-кодом, и в сложных IT-ландшафтах, где нет API или доступ к интеграциям ограничен.
Ключевые отличия RPA и классической автоматизации
Чтобы понять, где заканчивается роботизация бизнес-процессов и начинается классическая автоматизация, удобно разложить подходы по ключевым параметрам:
Когда выбирать RPA, а когда — классический подход
RPA технологии хорошо подходят для процессов, которые можно воспроизвести один в один. В таких сценариях не требуется принимать решения — есть понятная последовательность шагов. Именно поэтому обработка стандартных счетов или заявок с фиксированным форматом хорошо ложится на RPA, особенно при больших объемах.
“
Например, в одном из проектов для департамента образования мы внедрили RPA для обработки платежных заявок. Робот выполняет ту же цепочку действий, что и сотрудник: открывает Excel-файл, находит нужные строки, сопоставляет данные с полями в системе, переносит их, проверяет заполнение и сохраняет запись. В результате обработка ускорилась примерно в пять раз, около 80% операций стало выполняться без участия человека, а трудозатраты на процесс сократились почти вдвое.
Но как только процесс выходит за пределы строгой повторяемости, картина меняется.
Возьмём, к примеру, ритейл. На электронную почту компании могут приходить спецификации от поставщиков. Формально это всё ещё одна и та же задача — обработка документа и занесение данных в систему. Но внутри появляются различия: у разных поставщиков может отличаться расчёт НДС, условия скидок зависят от объёмов, где-то действуют лимиты по суммам договора, а где-то требуется дополнительная проверка бюджета, который хранится в другой системе. В итоге одна и та же операция начинает выполняться по разным сценариям в зависимости от каких-то условий.
В таких случаях цепочка шагов начинает усложняться: появляются исключения, дополнительные проверки, новые ветки логики. Со временем это превращает линейный сценарий в систему, которую сложно поддерживать.
Граница между подходами здесь довольно простая. Если процесс в основном повторяется и выглядит как набор действий в интерфейсе: открыть, считать, перенести, проверить, сохранить, и при этом логика почти не меняется, это зона RPA. Его задача — убрать ручную работу, не затрагивая сами системы.
Если же в процессе много условий, влияющих на результат, и требуется, чтобы система сама определяла, как обработать каждый случай, — это уже зона классической автоматизации. Здесь важна не последовательность действий, а правила принятия решений.
В реальной работе эти подходы не конкурируют. Они закрывают разные уровни одного и того же процесса и вместе дают более цельную автоматизацию бизнес-процессов внутри компании. Такой же подход отмечается и в отраслевых обзорах, включая материалы TAdviser: наибольший эффект достигается не за счёт одной технологии, а за счет их сочетания.
Следующий шаг развития таких систем — переход к интеллектуальной автоматизации. В отраслевых обзорах, включая материалы TAdviser, этот этап связывают с подключением ИИ-моделей к процессам. Они расширяют автоматизацию: позволяют не только выполнять заданные сценарии, но и обрабатывать более сложные, вариативные ситуации.
Возьмём, к примеру, ритейл. На электронную почту компании могут приходить спецификации от поставщиков. Формально это всё ещё одна и та же задача — обработка документа и занесение данных в систему. Но внутри появляются различия: у разных поставщиков может отличаться расчёт НДС, условия скидок зависят от объёмов, где-то действуют лимиты по суммам договора, а где-то требуется дополнительная проверка бюджета, который хранится в другой системе. В итоге одна и та же операция начинает выполняться по разным сценариям в зависимости от каких-то условий.
В таких случаях цепочка шагов начинает усложняться: появляются исключения, дополнительные проверки, новые ветки логики. Со временем это превращает линейный сценарий в систему, которую сложно поддерживать.
Граница между подходами здесь довольно простая. Если процесс в основном повторяется и выглядит как набор действий в интерфейсе: открыть, считать, перенести, проверить, сохранить, и при этом логика почти не меняется, это зона RPA. Его задача — убрать ручную работу, не затрагивая сами системы.
Если же в процессе много условий, влияющих на результат, и требуется, чтобы система сама определяла, как обработать каждый случай, — это уже зона классической автоматизации. Здесь важна не последовательность действий, а правила принятия решений.
В реальной работе эти подходы не конкурируют. Они закрывают разные уровни одного и того же процесса и вместе дают более цельную автоматизацию бизнес-процессов внутри компании. Такой же подход отмечается и в отраслевых обзорах, включая материалы TAdviser: наибольший эффект достигается не за счёт одной технологии, а за счет их сочетания.
Следующий шаг развития таких систем — переход к интеллектуальной автоматизации. В отраслевых обзорах, включая материалы TAdviser, этот этап связывают с подключением ИИ-моделей к процессам. Они расширяют автоматизацию: позволяют не только выполнять заданные сценарии, но и обрабатывать более сложные, вариативные ситуации.