Почему первый проект гиперавтоматизации часто становится последним

О гиперавтоматизации обычно говорят как о способе быстро сократить издержки и избавиться от рутины. Это подход к автоматизации, сочетающий в себе набор технологий, включая RPA и AI. На презентациях все выглядит просто: выбрали процесс, настроили робота c ИИ, получили экономический эффект.

На практике все оказывается сложнее — многие проекты заканчиваются успешным пилотом, но дальше автоматизация не масштабируется. Меня зовут Мирза, я руководитель проектов ROBIN компании SL Soft и за время работы я сопровождал десятки инициатив, в которых RPA использовалась вместе с ИИ, поэтому сегодня я поделюсь с вами самыми распространенными ошибками внедрения, из‑за которых гиперавтоматизация не оправдывает ожиданий.

Первый проект как первое свидание, ошибиться на этом этапе — значит испортить все впечатление о технологии. Для первого касания с гиперавтоматизацией очень важно выбрать правильную задачу.

Идеальный кандидат для пилота — скучный, рутинный, предсказуемый процесс, от которого у сотрудников уже глаз дергается. Хорошие примеры: обработка входящих счетов, выгрузка отчетов из нескольких систем, онбординг сотрудников, формирование типовых документов. Общее правило — для первого проекта гиперавтоматизации выбирайте процесс, в котором основная логика предсказуема и хорошо описана.

У таких процессов 4 основных признака:

• Высокая регламентированность. Правила известны и не меняются каждый день.
• Повторяемость. Процесс запускается десятки и сотни раз за день.
• Много ручного труда. Люди занимаются откровенной рутиной: переносят данные, сверяют таблицы, копипастят.
• Измеримая бизнес‑выгода. Эффект можно «пощупать» в деньгах, часах или снижении ошибок.

Если хотя бы два‑три пункта не выполняются, это повод задуматься, стоит ли брать процесс в первый пилот. Одна из типичных ситуаций — желание сразу автоматизировать самый сложный процесс в компании. Логика понятна: если получится здесь, получится везде. На практике вследствие разных причин проект затягивается, растет количество вводных, сроки сдвигаются, и бизнес делает вывод, что технология не работает. Цель первого проекта — не доказать, что команда способна решить самую сложную задачу, а быстро показать измеримый результат. 

На этом часто спотыкаются и берут:

• Процессы с большим числом исключений, где каждый шаг требует вмешательства человека, автоматизация не снижает нагрузку, а создает дополнительный уровень взаимодействия между сотрудником и системой. Например, обработка нестандартных запросов в тех. поддержку, где на каждом из этапов (классификация запроса, запрос данных, сбор логов и др.) может потребоваться эскалация на сотрудника. 
• Задачи, в которых результат полностью зависит от экспертного решения. Генеративный ИИ способен упростить работу специалиста, но для пилота безопаснее сценарии, где модель решает локальную задачу: извлекает данные, классифицирует документы, анализирует текст.
• Редкие операции. Если автоматизация выполняется несколько раз в месяц или реже, то это дорогая игрушка, о которой все забудут раньше, чем она понадобится снова. То же относится к процессам, выполняемым несколько минут в неделю. На них банально сложнее быстро показать заметный экономический эффект. Типичный пример — выгрузка ежеквартальной отчетности для регулятора — может занимать пару часов раз в 3 месяца, но эффект будет практически незаметен.
• Нестабильные процессы. Если регламенты, маршруты согласования и другие правила часто меняются, решение потребует регулярных доработок. Для пилота это означает рост стоимости владения и риск того, что робот устареет быстрее, чем окупится. Такие процессы лучше автоматизировать позже, когда команда наберется опыта и появится база для быстрой адаптации.
• Сложные сквозные процессы — процессы, охватывающие множество подразделений, информационных систем и участников, содержат больше рисков и исключений. Лучше начать с локального процесса внутри одного подразделения, получить быстрый результат, а уже затем переходить к более сложным сценариям. Пример — процесс обработки заказа от витрины до отгрузки, он может затрагивать много подразделений и систем, и разумнее будет начать с одного звена, допустим, с автоматической проверки остатков перед подтверждением заказа.

На одной из демонстраций я услышал от заказчика фразу, которую потом еще не раз вспоминал: «Робот работает именно так, как мы просили. Правда, это не совсем то, что нам было нужно».

На первый взгляд звучит как парадокс. Но на самом деле подобные ситуации встречаются гораздо чаще, чем кажется. Разработчики на самом деле сделали все правильно. Ошибка была не в коде и не в платформе автоматизации. Проблема возникла значительно раньше — на этапе, когда команда пыталась понять, что именно нужно автоматизировать.

Во многих компаниях участники одного и того же процесса по‑разному представляют, как выполняется работа. Руководитель описывает идеальную схему, сотрудники — привычную практику, а внутренние регламенты зачастую давно расходятся с реальностью. Если начать разработку на основе таких вводных, велика вероятность получить решение, которое формально соответствует требованиям, но не решает задачу бизнеса.

Именно поэтому обследование процесса — это не формальность и не лишний этап, а одна из ключевых составляющих успешного проекта.

Особенно хорошо это видно там, где знания годами передаются «из рук в руки». Представьте, вам нужно автоматизировать обработку входящих документов по электронной почте. На первый взгляд все просто: получить документ, проверить его, зарегистрировать и передать дальше. Но во время обследования выясняется, что один сотрудник всегда проверяет наличие приложения, второй делает это только для определенных типов документов, а третий вообще ориентируется на собственный опыт и принимает решение по ситуации. При этом каждый уверен, что действует правильно, потому что именно так его когда‑то научили.

В результате выясняется, что единого процесса фактически не существует. Есть несколько вариантов его исполнения, сложившихся исторически. Если эти различия не выявить заранее, робот будет воспроизводить лишь один из вариантов. Для части сотрудников он окажется удобным, а для остальных станет источником новых проблем.

После обследования кажется, что самое сложное позади и осталось только написать ТЗ. Но на этом этапе многие начинают описывать не бизнес‑процесс, а будущего робота. Хорошее ТЗ — это не просто описание того, какие кнопки должен нажимать робот или какие атрибуты должен извлекать IDP. Это описание бизнес‑логики процесса.

В нем должны быть четко определены:

• цель автоматизации;
• критерии успешного результата;
• последовательность действий;
• возможные исключения;
• правила принятия решений;
• требования к обработке ошибок;
• инфраструктурные и другие требования имеющие значение.

Если этих договоренностей нет, даже идеально реализованный проект может оказаться бесполезным.

Три вопроса, на которые стоит ответить до начала разработки

На практике перед стартом проекта достаточно убедиться, что команда одинаково отвечает на три простых вопроса.

Первый — что считаем успехом?

Ответы могут звучать правильно, но бесполезно: «сократить ручной труд», «ускорить процесс», «повысить эффективность». Проблема в том, что проверить такие цели невозможно. Они как гороскоп — каждый понимает по‑своему.

Недостаточно сказать: «хотим ускорить процесс». Нужно определить измеримые критерии: сократить время обработки заявки с 30 до 15 минут, снизить число ошибок до 3% или добиться другого конкретного результата.

Второй — как процесс работает сегодня?

Ответ на этот вопрос требует не предположений, а обследования: интервью с исполнителями, анализа документов, наблюдения за выполнением операций. Без исходных данных вы не докажете, что автоматизация что‑то изменила. Зафиксируйте текущие трудозатраты, время выполнения процесса, количество ошибок — иначе ROI останется гипотезой, а решение о масштабировании будет нечем обосновать.

Третий — как должна работать автоматизация?

Только после ответа на первые два вопроса можно формировать требования к будущему решению. Это то самое ТЗ. В противном случае разработчики будут вынуждены принимать решения самостоятельно, а это почти всегда приводит к расхождению ожиданий бизнеса и результата проекта.

Итак, процесс выбран, ТЗ подготовлено, метрики определены. На этом этапе возникает следующее искушение — как можно быстрее собрать работающее решение. Тем более что сегодня на рынке доступно множество no‑code‑ и low‑code‑платформ, обещающих быстрый старт и минимальные затраты на разработку.

No‑code позволяет снизить порог входа, ускорить разработку, дает собрать прототип за часы на голом энтузиазме и виртуозном перетаскивании кубиков. Такая доступность подкупает. Но здесь кроется опасная иллюзия: отсутствие кода часто приравнивают к отсутствию потребности в квалификации и обучении инструменту. И такое заблуждение может сильно повлиять на результат проекта.

Робот, собранный на скорую руку без понимания технологии и подходов к разработке, знаний инструмента, начинает сыпаться на первом же исключении, которое не предусмотрели. Ведь визуальный конструктор позволяет быстро накидать логику, но он не проверяет ее на прочность в реальных сценариях. 

Обработка ошибок, таймауты, повторные попытки, параллельные запуски — все это остается за кадром, пока кто‑то не подумает об этом заранее. А джун, которого без обучения бросили в сложный процесс со словами «там же конструктор, разберешься», будет думать о перечисленном в самую последнюю очередь. 

No‑code ускоряет проверку гипотез, но не отменяет инженерную культуру. Проектирование архитектуры, продумывание обработки ошибок, мониторинг — эти задачи никуда не исчезают. Именно поэтому в успешных компаниях гиперавтоматизация развивается через обучение работе с инструментами, создание центров компетенций, формирование практик разработки и стандартов проектирования.

Давайте представим идеальный сценарий: процесс выбран, ТЗ написано, в команде — опытные инженеры. Можно считать, что самое сложное позади? К сожалению, нет. Дальше начинается работа с реальной ИТ‑средой, которая редко соответствует ожиданиям, сформированным на этапе проектирования.

Любая автоматизация работает в реальной ИТ‑инфраструктуре, которая постоянно меняется. Поэтому часть рисков связана не с организацией проекта, а с особенностями самих технологий. Подход гиперавтоматизации предполагает применений различных технологий, но на практике чаще всего встречаются две группы технических проблем: изменения интерфейсов информационных систем (это в большей степени влияет на RPA) и ошибки генеративных моделей.

Изменения интерфейсов и внешних систем

Классический RPA‑робот взаимодействует с приложениями так же, как человек: открывает окна, нажимает кнопки, заполняет формы, считывает данные с экрана. Это позволяет автоматизировать системы без API, но делает робота зависимым от изменений интерфейса. Для человека обновление системы может пройти незаметно, для робота — стать критичным: переименованная кнопка, новая форма авторизации, измененная структура страницы или лишнее всплывающее окно могут привести к сбою.

Полностью исключить риск нельзя, но можно снизить его влияние. Используйте надежные механизмы идентификации элементов интерфейса. Для корпоративных систем после каждого крупного обновления проводите smoke‑тестирование критичных роботов. Настройте мониторинг и автоматические уведомления о сбоях, чтобы обнаружить проблему до того, как она повлияет на бизнес‑процесс. Если система предоставляет полноценный API, предпочтение стоит отдавать интеграции через программные интерфейсы — такой подход менее чувствителен к визуальным изменениям.

Галлюцинации и ошибки генеративного ИИ

С генеративным ИИ сложнее. Его появление расширило возможности автоматизации, но природа рисков здесь иная, чем в RPA. Если робот ломается из‑за съехавшей кнопки (это неприятно, но хотя бы ожидаемо), то генеративные модели иногда действуют менее предсказуемо, чем хотелось бы. 

Да, они прогнозируют наиболее вероятный ответ на основе имеющихся данных, но даже современная нейросеть может уверенно выдать ложную информацию, исказить факты или сделать неверный вывод при недостатке контекста. В бытовых сценариях такая ошибка может выглядеть забавно или остаться незамеченной. В корпоративной среде последствия могут быть гораздо серьезнее: ошибка в документе, из‑за которой предприятие получит штраф, заявка, отправленная не туда, некорректный ответ клиенту со срывом SLA.

Поэтому при внедрении ИИ не стоит рассматривать модель как полностью автономного исполнителя. Надежный подход — Human‑in‑the‑Loop: человек сохраняет контроль над решениями в критически важных точках процесса. По мере накопления статистики и подтверждения качества уровень контроля можно постепенно снижать.

Кроме того, рекомендую максимально ограничивать область ответственности модели. Чем уже задача и чем строже формат ожидаемого результата, тем ниже вероятность ошибок. ИИ, который классифицирует входящие письма по темам «жалоба», «запрос документов», «техподдержка» и обучен отвечать в зависимости от контекста, будет ошибаться в разы реже, чем модель с полной самостоятельностью без инструкций.

Мне сложно себе представить проект, в котором никогда ничего не ломается. Гораздо важнее, чтобы команда заранее спросила себя: «Что будет, когда робот или LLM ошибутся?» и была готова к внештатным ситуациям.

Оглянитесь на предыдущие четыре ошибки. За каждой из них стоят не технологии, а люди. И это нормальный ход вещей, на всех этапах люди — неотъемлемая часть процесса автоматизации. Особенно, когда внедряемая технология новая, а опыт ее внедрения только нарабатывается.

И на практике успех внедрения зависит не только от разработчиков и ЛПРов, но и от тех, кому предстоит работать с системой — от пользователей.

Для пользователя автоматизация с одной стороны — это благо, которое увеличивает его эффективность, снимает рутину и дает много других «плюшек», но с другой — вызывает у него некоторую настороженность. Одни сотрудники опасаются, что роботы или ИИ со временем заменят их на рабочем месте, другие не доверяют новой технологии и предпочитают привычные способы работы, третьи видят в проекте дополнительную нагрузку, поскольку приходится участвовать в интервью, тестировании и обучении.

Из перечисленного видно как минимум две проблемы:

1. Сопротивление сотрудника автоматизации из‑за страха за свое рабочее место и недоверия к технологии.
2. Низкая вовлеченность сотрудника в процесс автоматизации, так как это мешает основной работе, не интересно или требует времени, которого нет.

Как следствие, пользователи неохотно участвуют в обследовании процессов, формально относятся к тестированию, редко используют готовые решения и не сообщают о возникающих проблемах. В результате решение может быть успешно внедрено с технической точки зрения, но так и не стать частью реального бизнес‑процесса.

Поэтому вовлечение бизнеса должно начинаться задолго до внедрения. Проводите интервью с будущими пользователями, организуйте кик‑офф перед началом проекта, показывайте промежуточные результаты, демонстрируйте пилоты. Ну и конечно, когда сотрудники видят, как автоматизация забирает у них рутину, а не работу, отношение меняется быстрее, чем после любых презентаций.

Чтобы снизить сопротивление и страхи насчет возможных сокращений важно сформировать правильные ожидания. Донести, что агенты не заменяют экспертизу человека и не отменяют его роль в процессе. Их задача — взять на себя повторяющиеся операции, освободив время для задач, где действительно требуется человек. Вывод здесь простой: люди не враги автоматизации и не помеха. Они — главное условие ее успеха. Когда ключевые пользователи становятся союзниками на старте, проект получает поддержку, которую не нужно потом догонять.

Хоть в статье и перечислены основные ошибки внедрения, но в заключение хочу добавить важное: даже когда вы героически обошли все барьеры и запустили свой первый проект — праздновать рано. Адаптация и сопровождение только начинаются. Сотрудники должны понимать, как работать с решением, куда обращаться с вопросами и кто их поддержит. Внедренная система ничем не отличается от любой другой в портфеле ИТ‑подразделения и требует постоянного сопровождения.

По моему опыту, самые успешные проекты появляются там, где бизнес и ИТ работают как единая команда. Бизнес помогает определить приоритетные процессы и оценивает результат, ИТ обеспечивает техническую реализацию и поддержку. Только при таком подходе гиперавтоматизация становится не экспериментом, а инструментом, который действительно используется и приносит измеримую пользу компании.