Автоматизация бизнес-процессов: как выбрать первый проект
Самая раздражающая задача не всегда лучшая для первого внедрения. Сравниваем повторяемость, исключения, доступность данных и измеримый результат на примере согласования закупок.
Руководитель предлагает автоматизировать согласование закупок: документы ходят долго, сотрудники постоянно напоминают друг другу об оплате. На встрече выясняется, что под одной жалобой скрываются разные причины. В одной заявке нет центра затрат, в другой не назначен заместитель согласующего, в третьей поставщик ещё не подтвердил условия. Робот, который чаще отправляет напоминания, не устранит все три задержки.
Первый проект стоит выбирать по наблюдаемому процессу. Нужно увидеть повторяющуюся операцию, отделить работу от ожидания и понять, каким данным можно доверять. Ниже — способ подготовить пилот без обещаний универсальной окупаемости и без обязательной покупки платформы для анализа процессов.
«Автоматизировать снабжение» слишком широко для приёмки. «Передать на оплату заявку с подтверждёнными реквизитами, суммой и согласованиями» — уже результат, для которого можно определить начало, завершение и исключения. Граница процесса помогает не включить в пилот одновременно склад, договоры и планирование производства.
Запишите, что запускает работу, какие сведения обязательны, кто принимает решение и что подтверждает завершение. Укажите владельца правила: кто решает спор об очередности согласующих или лимите суммы. Если правило каждый раз изобретают заново, сначала придётся согласовать порядок работы; интерфейс не заменит это решение.
Возьмите завершённые заявки и пройдите их по истории изменений. Дополните выборку возвратами, отменами и случаями с пропущенными данными. Одни удачные операции покажут идеальный процесс, а автоматизации придётся работать с остальными.
Для простого журнала достаточно устойчивого идентификатора заявки, названия события и времени. Эти базовые поля используются и в журналах process mining . Но до загрузки нужно проверить смысл событий: статус «согласовано» мог быть выставлен задним числом, а перенос карточки — не означать фактическую передачу документа.
Ниже учебный CSV, не выгрузка из проекта. Часовой пояс указан явно; в реальной схеме храните также идентификатор события для удаления технических дублей.
По этому журналу видно ожидание между возвратом и повторной подачей. Но неизвестно, сколько минут сотрудник действительно работал с заявкой. Не превращайте всё календарное время в трудозатраты. Для ручной работы нужна отдельная оценка: наблюдение, выборочный замер или согласованный учёт операций.
Приоритет нельзя свести к числу запусков. Операция на десять секунд может быть массовой, но интеграция с закрытой системой окажется дорогой. Редкая операция может быть критичной из-за потери документов. Сначала исключите кандидатов без владельца и проверяемого результата, затем сравните оставшиеся.
Критерий
Хороший признак для пилота
Что требует подготовки
Входные данные
Есть устойчивый формат и идентификатор
Данные собираются из случайных писем
Правило решения
Условия можно объяснить и проверить
Решение зависит от неописанных договорённостей
Доступ к системе
Есть разрешённый API или импорт
Работает только ручной интерфейс без устойчивой схемы
Исключения
Их можно распознать и передать человеку
Неизвестно, где заканчивается обычный случай
Результат
Есть документ или подтверждённое событие
Успех описывают как «должно стать удобнее»
Для закупок хорошим первым шагом может оказаться проверка полноты заявки и выбор согласующего по действующему справочнику. Автоматическое одобрение всех расходов — существенно другая задача. Малый пилот должен приносить законченный результат, а не просто демонстрировать красивую схему переходов.
Посчитайте полезный объём, а не обещанную экономию #
Предположим, компания обрабатывает 400 заявок в месяц. Из них 250 соответствуют правилам пилота. На каждую типовую проверку уходит четыре минуты, после автоматизации сотрудник тратит одну минуту на результат. Предварительное высвобождение — 750 минут, или 12,5 часа в месяц. Все числа здесь условные; они показывают устройство расчёта.
Из этих часов ещё нужно вычесть разбор ошибок, сопровождение справочника и контроль исключений. Если сотрудники используют время для других задач, это высвобождённая ёмкость, а не автоматически сократившийся фонд оплаты труда. Стоимость лицензий, интеграции и поддержки считают отдельно. Такая арифметика помогает сравнить варианты, но не доказывает эффект до измерения пилота.
Если данные уже находятся в CRM, может хватить полей, прав и штатных правил процесса. Если требуется обмен между учётом, почтой и CRM, оценивают оркестратор вроде n8n или Make и прямые API. Для нестандартных расчётов может понадобиться отдельный сервис. Название платформы не определяет правильность маршрута согласования.
AI полезен, когда вход действительно неструктурирован: например, требуется выделить предмет закупки из письма. Проверку обязательных реквизитов и сравнение суммы с лимитом обычно лучше выполнять явным правилом. Для модельного шага заранее задают, какие ошибки допускаются и когда результат возвращается человеку.
До запуска зафиксируйте исходный период и одинаковые определения метрик. Доля возвратов считается от всех подходящих заявок, а не только от успешно обработанных роботом. Продолжительность показывают вместе с количеством исключений; ускорение за счёт исключения сложных случаев из отчёта не является улучшением процесса.
— Проверьте обычную заявку с полными данными.
— Уберите обязательный реквизит: система должна объяснить, чего не хватает.
— Исключите согласующего из рабочего справочника: заявка не должна зависнуть без владельца.
— Повторно доставьте событие подачи: новая заявка не должна появиться второй раз.
— Верните документ на исправление после согласования: должно сохраниться различие редакций.
После пилота соберите причины ручной обработки. Они становятся материалом для следующего этапа, но не каждая причина требует новой автоматизации. Иногда достаточно изменить форму или устранить противоречие в справочнике.
Не обязательно. Для одного ограниченного процесса часто достаточно качественной выгрузки событий и выборочного разбора заявок. Специализированный инструмент имеет смысл, когда нужно регулярно исследовать много вариантов и систем, а данные позволяют их связать.
Можно начать с обследования. До автоматического исполнения нужно согласовать хотя бы границы пилота, владельца решений и обработку исключений. Иначе команда автоматизирует одну из противоречащих друг другу версий процесса.
NetLab поможет разобрать фактический путь заявки, сравнить кандидатов и подготовить автоматизацию бизнес-процессов с понятными критериями приёмки. Опишите повторяющуюся задачу , системы и основные задержки — определим, где достаточно настройки, а где требуется интеграция или изменение процесса.
