Автоматизация бизнес-процессов: что стоит автоматизировать первым

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

Для первого внедрения лучше подходит процесс, в котором одновременно выполняются пять условий:

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

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

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

Неподходящий первый участок — «автоматизировать продажи целиком». В такую формулировку входят поиск клиентов, квалификация, переписка, расчёт цены, подготовка предложения, согласование условий и прогнозирование сделки. Это несколько процессов с разными владельцами, данными и рисками.

До расчёта приоритета полезно применить фильтр. Процесс не стоит брать первым, если хотя бы одно из условий критично:

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

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

Чтобы внедрение автоматизации бизнес процессов не зависело от мнения самого настойчивого руководителя, процессы можно оценить по единой шкале. Ниже — рабочая матрица для предварительного отбора. Это инструмент внутренней приоритизации, а не универсальный отраслевой стандарт.

Оцените каждый критерий от 0 до 3:

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

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

Рассмотрим условный пример. Компания сравнивает три процесса:

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

Первый процесс выполняется часто, использует повторяемые данные, допускает проверку и имеет понятное действие после обработки. Он может стать первым пилотом.

Подготовка презентации занимает заметное время, но выполняется редко. Сначала стоит автоматизировать сбор показателей и формирование черновика отчёта, а не весь процесс.

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

Входящие заявки и обращения

Хороший кандидат, если обращения приходят из форм, почты, мессенджеров или документов и сотрудники вручную переносят данные в CRM.

Процесс можно построить так:

форма или письмо → получение → проверка вложений → извлечение полей → проверка обязательных данных → поиск дубля → выбор маршрута → черновик карточки → проверка менеджером → создание задачи

Обычная интеграция передаёт структурированные поля. Бизнес-правила выбирают ответственного и срок. OCR распознаёт скан. AI нужен только там, где содержание письма или документа нельзя надёжно разобрать шаблоном.

Документы и согласования

Счета, акты, заявки на оплату, договоры и внутренние запросы подходят для автоматизации, когда маршрут зависит от понятных параметров: суммы, подразделения, типа документа, проекта или статуса контрагента.

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

Регулярная отчётность

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

Первый контур обычно включает получение данных, проверки формата, расчёты по утверждённым формулам и формирование отчёта. AI здесь часто не требуется. Он может пригодиться для текстового черновика комментария, но значения и выводы должны быть связаны с проверяемыми источниками.

Контроль статусов и сроков

Если руководитель узнаёт о задержке только на совещании, стоит автоматизировать не само решение, а наблюдаемость процесса: статусы, контрольные точки, уведомления, очереди и причины остановки.

Такой проект часто проще, чем полная перестройка процесса, и даёт данные для следующего этапа: становится видно, где действительно образуется ограничение.

Обработка типовых документов

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

Здесь важно разделить компоненты:

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

В кейсе AI-системы для тендерного отдела опубликован пример более сложного контура: документы приводятся к единой структуре, требования и риски собираются для проверки, а решение об участии остаётся за командой.

Система автоматизации бизнес процессов выбирается после описания задачи. Один и тот же процесс может быть решён разными способами.

Не стоит выбирать BPM, RPA или AI только потому, что технология уже куплена. Например, передача поля из формы в CRM — интеграционная задача. Расчёт скидки по утверждённой формуле — обычный код. Распознавание печатного скана — OCR. Языковая модель нужна, когда результат зависит от смысла неструктурированного содержания и допускает проверку.

Более подробно граница между обычной автоматизацией и AI разобрана в статье «ИИ для бизнеса: где он реально окупается, а где не нужен».

До выбора подрядчика или платформы подготовьте краткий паспорт процесса. Он позволяет сравнить ожидания бизнеса с реальной архитектурой.

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

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

Типовая схема:

источник → приём данных → нормализация → проверки → правила → AI при необходимости → черновик результата → ручное подтверждение → запись в систему → журнал действий

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

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

Перед запуском фиксируют:

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

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

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

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

Обычно не подходят для старта:

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

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

Цена определяется не названием технологии, а объёмом рабочего контура. На оценку влияют:

• количество каналов и форматов входящих данных;
• число интеграций и качество API;
• количество ролей и маршрутов;
• объём справочников и правила их обновления;
• требования к интерфейсу;
• права доступа и аудит действий;
• работа с персональными или конфиденциальными данными;
• необходимость OCR, поиска или AI;
• объём ручной проверки;
• мониторинг, инфраструктура и сопровождение.

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

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

Цель автоматизации — не убрать человека из схемы любой ценой, а изменить характер его участия.

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

Человек обязательно подтверждает:

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

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