Аудит бизнес-процессов: чеклист до пилота

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

Три формулировки, которые путаю на старте:

На одном разборе у сервиса с выездом заявки жили в Telegram владельца, в комментариях к объявлению и в таблице, которую обновляли «когда вспомнят». Маркетинг считал лиды по рекламе, мастер - по выездам. Цифры не сходились не из-за трафика. Не было одного ответа: что считается принятой заявкой и кто отвечает до выезда. Я не предлагал «цифровую трансформацию». Предложил одну карту контура «заявка → слот → выезд» и критерий: тест-заявка за сутки даёт строку учёта и имя ответственного. Через неделю стало видно, сколько обращений зависает до первого живого ответа.

По теме в блоге я отдельно разбираю карту автоматизации бизнес-процессов и входящие заявки. Эта статья - про аудит процессов как вход: что снять до инструмента.

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

Я не запускаю аудит «всего бизнеса». Беру контур с частым повтором и измеримым сбоем: заявка, запись, согласование счёта, отгрузка мелкой партии. Если сбой случается раз в квартал, пилот автоматизации обычно рано. Если сбой ежедневный и его видно в чатах, съём as-is окупает время лучше, чем каталог интеграций.

Когда компания говорит «нам нужна консультация по автоматизации», я сначала спрашиваю: какой контур и какой исход вы хотите увидеть через неделю. Если ответа нет, это не консультация по стеку, а как раз аудит. Если ответ есть («тест-заявка из формы даёт строку и уведомление Анне»), можно спорить про таблицу, webhook или CRM.

Антипример, который я отговариваю: неделя интервью со всеми отделами и дорожная карта на год. Для малого контура это отчёт на полку. Мне достаточно пройти один реальный кейс от входа до выхода вместе с человеком, который это делает руками.

Связка с соседними темами: если уже ясно, что дыра в приёме заявок, читайте автоматизацию заявок. Если спор про ИИ «везде», держите внедрение ИИ в бизнес - там пилот одного процесса, не аудит всей фирмы.

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

Карта as-is текстом, которую я прошу сохранить в репозитории или в заметке рядом с пилотом:

contour: zayavka_do_ucheta
owner: Anna
as_is:
  trigger: "сообщение в Telegram или форма на сайте"
  input_artifacts: ["текст заявки", "телефон или username"]
  steps:
    - "владелец читает чат, когда освободился"
    - "суть копируется в таблицу или не копируется"
    - "мастер получает скрин в личку"
  output_success: "мастер знает слот и контакт"
  exceptions:
    - "повтор от того же клиента в другом канале"
    - "заявка без телефона"
    - "ночь и выходные"
  break_points:
    - "нет строки учёта после ответа в чате"
    - "два человека пишут клиенту"
pilot_criterion: "тест-заявка за рабочий день даёт одну строку, owner и уведомление"
out_of_scope: ["оплата", "лояльность", "агент без критерия"]

Кто даёт факты

Факты даёт тот, кто делает работу руками, не тот, кто купил CRM. Владелец бизнеса часто описывает процесс «как должно быть». Я прошу открыть реальный чат и таблицу и пройти сообщение за сообщением. Если фактов нет (нет логов, нет таблицы, всё в голове), первый результат аудита - завести след: хотя бы дату, канал, контакт, суть, статус.

Где ломается

Ломается на передачах. Человек ответил в мессенджере и считает заявку обработанной, учёта нет. Или учёта есть, а уведомления нет, и заявка висит до вечера. Или два канала, и клиент получает два разных обещания по сроку. На карте я помечаю передачу явно: от кого, кому, каким артефактом (строка, скрин, карточка).

Что считать успехом

Успех аудита - не «красивая схема». Успех: согласованные вход, выход, исключения и критерий пилота, которые можно проверить на следующей тест-заявке. Если команда спорит про поля CRM, аудит ещё не закончен.

Поля одной строки, которые я часто фиксирую до любой автоматизации:

{
  "contour": "zayavka_do_ucheta",
  "created_at": "2026-09-19T10:15:00+03:00",
  "channel": "telegram",
  "contact": "@client_example",
  "summary": "Нужен замер на следующей неделе",
  "status": "new",
  "owner": "Anna",
  "exception": null,
  "next_step": "подтвердить слот мастеру",
  "pilot_check": "row_exists_and_owner_notified"
}

Это не ТЗ на продукт. Это след, без которого аудит эффективности превращается в ощущения.

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

Как снимать:

1. 01

   Зафиксируйте created_at в момент, когда заявка появилась в канале, не когда её «вспомнили».

2. 02

   Зафиксируйте first_action_at: первый ответ клиенту или первая строка учёта - договоритесь, что считается действием.

3. 03

   Посчитайте переносы: чат → таблица → ещё один чат. Каждый перенос - кандидат на автоматизацию или на упрощение.

4. 04

   Отдельно пометьте исключения: ночь, повтор, пустой контакт. Их не смешивайте со «средним временем».

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

Связка с ИИ-агентами для бизнеса: агент уместен, когда есть инструмент, действие и проверка. Метрика «агент ответил» без строки учёта для меня не эффективность процесса, а шум в чате.

Ниже то, что ломает проведение аудита чаще, чем «не та нотация». Симптом - что вижу на разборе. Фикс - что прошу сделать до пилота.

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

Отдельно про «описание»: люди приносят BPMN без владельца и без исключения. Это не аудит эффективности, это картинка. Я прошу подписать схему именем человека, который делает шаг руками. Если имени нет, схема ещё не as-is.

Проходите по порядку. Если пункт не закрыт, к следующему не переходите.

1. 01

   Назовите контур одной фразой и поставьте границу: что внутри, что точно снаружи (оплата, лояльность, отчёт директору).

2. 02

   Запишите вход: канал, артефакт, кто его создаёт. Если каналов несколько, на пилот оставьте один.

3. 03

   Запишите выход успеха: что должно появиться в учёте или у следующего человека.

4. 04

   Назначьте одного owner контура на время пилота. Резерв для уведомлений не заменяет owner.

5. 05

   Соберите исключения: повтор, пустой контакт, нерабочее время, «клиент передумал голосом».

6. 06

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

7. 07

   Перечислите ручные шаги, которые копируют одно и то же поле. Это кандидаты на связку, не на агента.

8. 08

   Сформулируйте критерий пилота и решение: пилот / отказ / другой инструмент. Отказ - нормальный исход аудита.

После пункта 8 у вас есть материал для ТЗ пилота или для честного «пока не трогаем». Я предпочитаю отказ с причиной красивому стеку без критерия.

Аудит бизнес процессов услуга в моём оффере - не неделя обследования и не дорожная карта трансформации. Это разбор одного контура: факты, карта as-is, критерий, следующий шаг или отказ. Чеклист выше можно пройти сами. Имеет смысл звать меня, когда внутри компании пять версий процесса или уже купили инструмент и он стоит пустой.

Консультации по автоматизации после аудита нужны, когда критерий есть, а выбор между таблицей, ботом, n8n, CRM и небольшим кодом неочевиден. Тогда мы смотрим ограничения: есть ли API, кто будет сопровождать сценарий, какие данные нельзя тащить в сторонний сервис. Это уже не «аудит ради аудита».

Про хайп агентов отдельно. В документации n8n Assistant сценарий собирают из trigger, приложений, данных, успеха и ошибки, и просят просмотреть результат до продакшена. В гайде OpenAI по Agents тоже сначала инструменты, состояние и границы runtime. Я читаю это так: ассистент ускоряет сборку, если контур уже описан. Если as-is нет, вы автоматизируете чужой или выдуманный процесс.

Когда карта держится на живых заявках, можно говорить про автоматизацию бизнес процессов в смысле связки, а не лозунга. Мой порядок: уведомление и запись, потом бот на узком сценарии, потом n8n или код, если появились API и расписание. CRM - когда статусы и owner уже не спорят в чате. Подробная карта старта - в статье автоматизация бизнес-процессов. Пилот внедрения ИИ - во внедрении ИИ.

Что я не делаю после аудита: не обещаю загрузку календаря, не ставлю агента ночью «на всю компанию», не рисую ROI. Пилот либо даёт согласованный исход (строка, слот, уведомление), либо мы фиксируем отказ и не тратим бюджет на стек.

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