Я останавливаю автоматизацию там, где решение ещё нельзя безопасно отдать правилам

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

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

Не всё ручное — лишнее

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

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

Полезная граница проходит иначе: типовой случай идёт быстро и прозрачно, а нетиповой попадает к конкретному человеку с понятным вопросом. Не «разберитесь», а «сумма выше лимита на 18%, можно ли продолжать?» или «у контрагента изменились реквизиты, подтвердите источник». Тогда ручная проверка остаётся решением, а не ремонтом плохо настроенной системы.

Три вопроса перед автоматизацией

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

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

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

Начинать стоит не с самого заметного процесса

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

Я обычно ищу участок, где действие повторяется, результат можно проверить, а ошибка не становится катастрофой. Например, собрать документы по закрытому шаблону, разложить обращения по известным темам или напомнить о пропущенном поле. Такой участок даёт команде опыт: как описывать правила, куда смотреть при сбое и кто поддерживает маршрут после запуска.

О выборе первого процесса я уже подробно писал в статье «Как выбрать первый процесс для автоматизации бизнеса?». Важно не пытаться доказать ценность автоматизации красивой схемой. Её ценность проявляется в рабочий понедельник, когда процесс проходит без ручного переписывания, а проблема не прячется между двумя отделами.

Что делать с исключениями

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

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

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

Признак здоровой границы

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

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

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

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