Оптимизация бизнес-процесса до разработки экономит больше, чем автоматизация лишних действий

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

Сначала запишите начало и конец процесса. Например: заявка поступила; сотрудник проверил комплектность; ответственный назначен; клиент получил ответ. Владелец процесса отвечает за весь этот путь и вправе менять правила передачи между отделами.

Цифровая зрелость проверяется по владельцу процесса, согласованным данным и способу принять изменение.

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

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

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

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

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

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

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

Возьмём учебный пример: 600 заявок за условный месяц. На каждую уходит 7 минут полезной работы и 5 минут переносов и подтверждений, которые в этом примере признаны ненужными. Исходный маршрут занимает 12 минут труда на заявку, или 120 часов в месяц.

Если ненужные действия автоматизировать до 1 минуты, получится 8 минут на заявку и 80 часов в месяц. Если их удалить, останутся 7 минут и 70 часов. Удаление высвобождает 50 часов против 40 у автоматизации; код для удалённых действий не требуется.

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

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

На vibecoding.ru инженер ведёт машину агентов. Прежде кода записано, какой результат нужен и что проверять. Подробности правил для ИИ-агентов вынесены в отдельную статью; здесь важен выбор самой работы: какой шаг остаётся, а какой повторяет соседний.

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

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

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

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

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

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

1. Назначьте владельца результата и запишите начало и конец выбранного процесса.

2. Пройдите фактическую заявку. Уберите повторный ввод и передачи без решения; необходимые проверки сохраните.

3. Сравните сокращённый маршрут с автоматизацией текущего. Разделяйте время сотрудников, ожидание клиента и денежные расходы.

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