RPA сейчас на волне популярности. Вендоры обещают революцию в производительности. Консультанты рисуют радужные ROI. Истории успеха множатся. И возникает соблазн: давайте автоматизируем всё!
Проблема в том, что RPA – не универсальное лекарство. Это инструмент для определённого класса задач. Применённый не к тому процессу, он создаёт больше проблем, чем решает. Я видел проекты, где робот обходился дороже, чем ручной труд. Где автоматизация сломала процесс, который худо-бедно работал. Где деньги и время ушли в никуда.
В этой статье – честный разбор ситуаций, когда RPA не подходит. Шесть красных флагов, которые должны заставить задуматься: а точно ли это надо роботизировать? И что делать вместо этого.

Процесс слишком часто меняется
RPA любит стабильность. Робот запрограммирован на конкретную последовательность действий в конкретном интерфейсе. Завтра интерфейс изменится – робот сломается. Поменяются правила – робота нужно переделывать.
Когда это проблема? Когда процесс меняется чаще, чем раз в квартал. Когда системы, с которыми работает робот, постоянно обновляются. Когда бизнес-правила нестабильны и «пока не устаканились». Когда регуляторные требования часто пересматриваются.
Каждое изменение – это доработка робота: анализ, разработка, тестирование, деплой. Если изменения частые, вы будете тратить больше времени на поддержку робота, чем экономить на автоматизации.
Что делать вместо этого? Подождать, пока процесс стабилизируется. Или использовать более гибкие инструменты: low-code платформы с визуальными редакторами, которые бизнес может менять сам. Или AI-решения, которые адаптируются автоматически.
Слишком много исключений
Правило 80/20 в RPA работает жёстко: 80% типовых случаев автоматизируются легко, а 20% исключений съедают 80% усилий. Но что если исключений не 20%, а все 50%?
Когда это проблема? Когда больше половины случаев – «нестандартные». Когда для каждого клиента свои правила. Когда данные на входе хаотичны и неструктурированы. Когда нужно принимать решения на основе контекста, который сложно формализовать.
В таких случаях робот будет ловить исключения на каждом шагу. Очередь на ручную обработку будет расти. Люди будут тратить время на разбор того, что не смог робот. Суммарная трудоёмкость может вырасти, а не снизиться.
Что делать вместо этого? Сначала стандартизировать процесс. Уменьшить количество исключений организационными мерами. Или использовать AI-решения, которые умеют принимать решения в неоднозначных ситуациях. Или признать, что этот процесс требует человеческого суждения.
«Мы автоматизировали обработку заявок на возврат. На бумаге выглядело идеально. На практике – 60% заявок уходили в исключения, потому что клиенты писали причины возврата в свободной форме, и робот не понимал. В итоге переделали на AI-классификатор, и только потом подключили RPA для рутины.»
Есть API, но используют RPA
RPA – это автоматизация через интерфейс пользователя. Робот кликает кнопки, заполняет поля, копирует данные – как человек. Это нужно, когда другого способа интегрироваться нет. Но если есть API – зачем эмулировать клики?
Когда это проблема? Когда система имеет API или другие способы программной интеграции, но вместо них используют RPA. Когда можно написать простой скрипт или настроить интеграцию – но выбирают роботов «потому что модно».
Почему это плохо? API-интеграция быстрее, надёжнее, проще в поддержке. Она не зависит от интерфейса – если дизайнер переставит кнопку, интеграция продолжит работать. Она потребляет меньше ресурсов и легче масштабируется.
RPA – это «интеграция последней надежды» для систем без API. Если API есть – используйте его. Если можно настроить штатную интеграцию – настраивайте. RPA оправдан только когда других вариантов нет или они непропорционально дороги.
Объём слишком мал
Автоматизация имеет фиксированные затраты: анализ, разработка, тестирование, инфраструктура, поддержка. Эти затраты должны окупаться за счёт экономии на рутине. Если работы мало – экономия не покроет инвестицию.
Когда это проблема? Когда процесс выполняется несколько раз в день или реже. Когда объём операций – десятки, а не сотни или тысячи. Когда экономия времени на одной операции – минуты, а не часы.
Простой расчёт: если робот экономит 10 минут на операции, и операций 20 в день – это 3-4 часа экономии в день. Звучит неплохо. Но если операций 5 в день – полчаса экономии. А разработка робота стоит, допустим, 500 000 тенге. Окупаемость растянется на годы.
Что делать вместо этого? Посчитать ROI честно. Если не окупается за разумный срок (полгода-год) – не автоматизировать. Или поискать способы объединить несколько мелких процессов в один более объёмный. Или использовать более дешёвые решения: макросы, скрипты, простые инструменты.
Процесс требует творческого решения
RPA хорош для детерминированных задач: «если А, делай Б, иначе В». Робот следует алгоритму. Но есть задачи, где алгоритм не написать – решение зависит от контекста, опыта, интуиции.
Когда это проблема? Когда нужно принять решение на основе неполной информации. Когда требуется оценить «хорошо» или «плохо» – не по формальным критериям, а по ощущению. Когда важны переговоры, убеждение, эмоциональный интеллект. Когда задача – придумать что-то новое.
Примеры: оценка качества текста для маркетинга, принятие решения о кредите в пограничном случае, переговоры с недовольным клиентом, выбор стратегии для сложной сделки. Это не для роботов – здесь нужен человек.
Что делать? Автоматизировать рутинную часть, оставив творческую человеку. Робот может собрать информацию, подготовить черновик, отфильтровать очевидные случаи – а человек принимает решение в сложных.

Проблема в самом процессе
Иногда RPA используют, чтобы автоматизировать плохой процесс. Логика такая: «Процесс неэффективный, давайте хотя бы робота поставим». Но автоматизация плохого процесса – это ускорение производства брака.
Когда это проблема? Когда процесс избыточен – содержит лишние шаги, которые можно просто убрать. Когда есть ненужные согласования и бюрократия. Когда данные переносятся между системами только потому, что так исторически сложилось. Когда никто не помнит, зачем вообще это делается.
Пример: сотрудник выгружает отчёт из системы A, переформатирует в Excel, загружает в систему B. Можно автоматизировать RPA. А можно – настроить прямую интеграцию между A и B. Или понять, что система B вообще не нужна.
Что делать? Прежде чем автоматизировать – оптимизировать. Убрать лишние шаги. Упростить согласования. Может быть, после оптимизации и автоматизировать не понадобится. Или понадобится, но гораздо меньше.
Как понять, подходит ли RPA: чек-лист
Используйте этот список вопросов для оценки кандидата на автоматизацию.
Стабильность: Процесс и системы стабильны? Изменения реже раза в квартал? Правила устоялись?
Стандартизация: Более 80% случаев – типовые? Исключений меньше 20%? Данные на входе структурированы?
Интеграция: API недоступен или непропорционально дорог? Нет штатных механизмов интеграции?
Объём: Достаточный объём операций? ROI положительный в разумный срок?
Детерминированность: Правила можно формализовать? Не требуется творческое решение?
Качество процесса: Процесс оптимален? Нет лишних шагов, которые можно убрать?
Если на большинство вопросов ответ «да» – RPA подходит. Если много «нет» – ищите альтернативы.
Альтернативы RPA: что использовать вместо
Если RPA не подходит – это не значит, что автоматизация невозможна. Есть другие инструменты.
API-интеграции. Для связи систем, у которых есть API. Надёжнее и быстрее RPA. Требуют разработки, но результат стабильнее.
Low-code / no-code платформы. Для процессов с частыми изменениями. Бизнес может менять логику сам, без разработчиков. Примеры: n8n, Make, Power Automate.
AI-решения. Для задач с неструктурированными данными и нечёткими правилами. Классификация, извлечение информации, принятие решений в неоднозначных случаях.
BPM-системы. Для управления сложными процессами с множеством участников. Оркестрация, маршрутизация, контроль сроков.
Простые скрипты. Для небольших объёмов. Python-скрипт может решить задачу за несколько часов разработки – дешевле, чем полноценный RPA-проект.
Оптимизация процесса. Иногда лучшая автоматизация – убрать лишние шаги. Не автоматизировать, а упразднить.
Не уверены, подходит ли RPA?
Проведём анализ ваших процессов и честно скажем, что автоматизировать RPA, что – другими инструментами, а что лучше оставить как есть. Без навязывания решений – только то, что реально принесёт пользу.
RPA – мощный инструмент, но не панацея. На правильных задачах он даёт впечатляющие результаты. На неправильных – создаёт разочарование и дыру в бюджете.
Шесть признаков, которые мы разобрали – это красные флаги. Не приговор, но сигнал: возможно, RPA – неправильный выбор, и стоит посмотреть на альтернативы.
Не автоматизируйте ради автоматизации. Не следуйте моде. Смотрите на каждый кейс трезво. Иногда лучшее решение – не делать ничего. Или сделать что-то совсем другое.
Полезные материалы
- Какие процессы автоматизировать первыми – методика выбора
- ROI автоматизации – как считать честно
- RPA vs API интеграции – когда что выбрать
- Как не купить «игрушку» – критерии выбора решений