Виталий Афанасьев
Обсудить задачу
блог
25.07.2026
Аудит бизнес-процессов перед автоматизацией: что проверять до выбора инструмента
Автоматизация делает процесс быстрее — включая его ошибки. Показываю, что проверить до выбора CRM, интегратора или AI-инструмента.
Самая опасная автоматизация выглядит успешной.
Задача выполняется за секунды. Уведомления уходят вовремя. Данные появляются в отчёте. Только решение основано на неверном статусе, исключение никто не заметил, а сотрудник потом вручную исправляет последствия в другом месте.
Инструмент не сломался. Он идеально ускорил плохое правило.
Поэтому аудит бизнес-процессов перед автоматизацией нужен не для того, чтобы нарисовать все стрелки компании. Его задача — понять, как работа движется на самом деле, где принимаются решения, какие исключения удерживают люди и что изменится, если часть маршрута передать системе.

Что такое аудит бизнес-процессов

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

Почему нельзя начинать с выбора платформы

Демо инструмента задаёт удобную рамку. Компания начинает видеть собственную работу через сущности системы: заявки, статусы, роботы, поля, агенты, интеграции.
Но реальный процесс мог сложиться иначе.
Один сотрудник сравнивает данные из двух систем, потому что у них разные определения. Другой звонит коллеге перед согласованием, потому что формальное поле не отражает риск. Третий держит список исключений в голове. Четвёртый исправляет ошибку, о которой проект автоматизации даже не знает.
Если сначала выбрать инструмент, команда незаметно начинает подгонять описание под его возможности.
Я бы менял порядок:
результат → фактический маршрут → решения и исключения → потери и риск → только потом инструмент

Шесть слоёв аудита

1. Результат и границы

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

2. Фактический маршрут

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

3. Передачи

Каждая передача — потенциальная потеря контекста и времени.
Зафиксируйте:
  • что передаётся;
  • в каком формате;
  • кто подтверждает получение;
  • что должен сделать следующий участник;
  • когда ответственность действительно переходит;
  • что происходит, если данных недостаточно.
Особенно внимательно смотрите на места между функциями и системами. Там редко есть один владелец.

4. Решения

Где человек выбирает, а не просто выполняет действие?
Для каждого решения нужны:
  • входные данные;
  • правило или критерий;
  • уровень уверенности;
  • полномочие;
  • последствия ошибки;
  • способ пересмотра.
Два компетентных сотрудника всегда приходят к одному ответу при одинаковых данных? Тогда решение похоже на детерминированное.
Если ответы расходятся из-за контекста и опыта, перед нами суждение. Его можно поддерживать инструментом, но опасно маскировать под простое правило.

5. Исключения

Нормальный путь хорошо выглядит на схеме. Цена процесса раскрывается в исключениях.
Что происходит, если:
  • данные противоречат друг другу;
  • клиент меняет условия;
  • нужный человек недоступен;
  • система не знает статус;
  • правило не подходит;
  • срок уже нарушен;
  • два отдела считают результат своим?
Опытные сотрудники часто незаметно удерживают эти случаи. Автоматизация делает их знание видимым — или стирает его.

6. Потери и сигналы

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

Карта аудита процесса

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

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

Как выбрать первый процесс

Не выбирайте самый громкий и самый раздражающий.
Оцените кандидатов по семи критериям:
  1. Частота — как часто повторяется работа.
  2. Последствие — что стоит задержка или ошибка.
  3. Стабильность — насколько понятен нормальный маршрут.
  4. Качество данных — есть ли нужные входы.
  5. Вариативность — сколько типов исключений.
  6. Владелец — кто отвечает за результат целиком.
  7. Проверяемость — можно ли сравнить до и после.
Хороший первый кандидат достаточно важен, но не критичен настолько, чтобы ошибка пилота стала катастрофой.

Что автоматизировать, а что оставить человеку

Удобна простая развилка.
Автоматизировать повторяемые действия с понятным входом, правилом и проверяемым выходом.
Поддерживать ИИ там, где нужно собрать, классифицировать или предложить вариант, но ответственность за решение остаётся у человека.
Оставить человеку высокорисковые, редкие или контекстные решения, особенно если данные неполны и ошибка трудно обратима.
Граница меняется по мере накопления фактов. Не нужно принимать её навсегда.

План аудита на десять рабочих дней

Дни 1–2. Результат и выбор случаев

Согласуйте границы, владельца и три-пять реальных историй.

Дни 3–5. Наблюдение и восстановление маршрута

Пройдите процесс вместе с участниками. Не ограничивайтесь интервью руководителей.

Дни 6–7. Решения, исключения и данные

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

День 8. Потери и baseline

Зафиксируйте исходные сигналы без придуманных прогнозов.

День 9. Варианты изменения

Сначала убрать и упростить, потом стандартизировать, поддержать инструментом и автоматизировать.

День 10. Решение по пилоту

Опишите результат, владельца, границы, риск, метрику, срок и условие остановки.

Как проверить предложение подрядчика

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

Границы метода

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

Источники