Процессы · диагностика · внедрение
Как проводить аудит
бизнес-процесса
Полезный аудит объясняет не только где возникло отклонение, но и почему система работы воспроизводит его снова. Для этого нужно пройти фактический маршрут, сопоставить действия с данными и перевести выводы в управляемые изменения.
Антон Коннов · 9 августа 2026 · 8 минут
Точка старта
Сначала определить объект решения
Формулировка «проверить отдел» почти всегда слишком широка. Лучше выбрать сквозной результат: исполненный заказ, закрытый месяц, согласованную закупку или обработанное обращение клиента. Тогда появляется начало, конец, владелец результата и возможность увидеть передачу ответственности между функциями.
До интервью полезно зафиксировать управленческий вопрос: какое решение должен принять заказчик аудита. Это удерживает работу от превращения в каталог замечаний.
Подготовка
Что собрать по одному маршруту
Назовите один сквозной маршрут и собирайте материалы только по нему. Ниже — стартовый перечень, который стоит адаптировать к границам процесса. Это не стандарт сертификации или внутреннего аудита и не исчерпывающий чек-лист.
Вопрос и границы. Какое управленческое решение нужно принять, какое событие запускает процесс и чем он заканчивается, кто клиент результата и кто за результат отвечает.
Действующие правила. Регламенты, формы и шаблоны, которые используются сейчас, и кто фактически отвечает за каждый этап.
Примеры операций. Несколько реальных случаев: обычные, выполненные в срок; задержанные или возвращённые на доработку; исключения. Подбирайте их так, чтобы охватить варианты, важные для вопроса, а не ради количества.
След событий. То, что уже есть в системах, почте и журналах: когда операция поступила и стала полной, когда запросили уточнение, когда назначили исполнителя, начали и завершили работу; статусы, возвраты и их причины; источник, версия и владелец каждой выгрузки.
Прежде чем сравнивать сроки, договоритесь, что означает каждая отметка времени: «поступила» в одной системе и «зарегистрирована» в другой могут быть разными событиями. Если данных нет, отметьте пробел, а не восстанавливайте историю по памяти.
Для первого обращения документы не нужны: достаточно описать симптом, границы маршрута и то, какая информация доступна.
Шесть шагов
От факта к плану изменений
Границы и результат
Определить событие начала и завершения процесса, клиента результата, владельца и критерий готовности. Всё, что не влияет на этот результат, пока остаётся за границами.
Фактический маршрут
Пройти несколько реальных примеров по документам, системам и коммуникациям. Регламент показывает предполагаемый процесс; конкретный заказ или операция показывает, как работа выполняется на самом деле.
Роли и передачи
Зафиксировать не только исполнителей, но и точки ожидания, возврата, ручного согласования и смены ответственного. Именно на стыках подразделений часто теряются сроки и информация.
Данные и показатели
Сопоставить управленческую отчётность с первичными событиями. Важно различать время работы и время ожидания, единичное отклонение и повторяющийся сценарий, симптом и причину.
Причины и целевая модель
Для существенных разрывов определить механизм возникновения: правило, мотивацию, нехватку данных, ограничение мощности или дефект системы. Затем описать роли, сценарии, контроль и требования целевого процесса.
Приоритет и внедрение
Разделить быстрые организационные меры, системные изменения и гипотезы, требующие пилота. У каждого действия должны быть владелец, срок, критерий приёмки и способ проверить результат после запуска.
Рабочие материалы
Что должно остаться после аудита
Карта as is
Шаги, роли, системы, документы, ожидания и точки возврата.
Реестр причин
Факты, повторяемость, последствия и связь с управленческой задачей.
Модель to be
Целевой маршрут, ответственность, данные, контроли и требования к автоматизации.
План внедрения
Приоритеты, владельцы, пилоты, критерии приёмки и мониторинг.
Пример
От задержки к проверяемой причине
Условный пример, а не история реального клиента. В процессе согласования заявок на закупку видно, что задержанные заявки часто возвращаются на уточнение. Один такой случай не доказывает причину и тем более не говорит о небрежности сотрудника.
Наблюдение. Задержанные заявки возвращаются на уточнение, но пока неизвестно, чем именно они отличаются от обычных.
Что сравнить. Выбранные задержанные и обычные заявки: полноту и версию заявки на входе, отметки времени, передачи между ролями и исключения.
Гипотеза. Требования к заявке на входе или ответственность в момент передачи определены нечётко. Альтернативы остаются открытыми: очередь и нехватка мощности, сбои системы.
Что подтвердит или опровергнет. Если возвраты связаны с одними и теми же недостающими сведениями, а ожидание копится после передачи без владельца, гипотеза усиливается. Если обычные заявки так же неполны или задержка возникает в очереди либо из-за сбоев, одной этой гипотезы недостаточно: нужно проверить альтернативы и возможное сочетание причин.
Что фиксирует аудит. Находку, её источник, степень неопределённости и владельца следующего шага.
Следующее решение остаётся ограниченным. Если сравнение поддерживает гипотезу, можно проверить на части потока более чёткие требования к заявке и назначенного владельца уточнений, сопоставляя с исходной точкой при сравнимой нагрузке срок, число возвратов и качество результата. Если не поддерживает, проверяется следующая гипотеза, а системы не меняются наугад.
Типичная ошибка
Автоматизировать процесс до диагностики
ERP, CRM или новый отчёт не исправляют неопределённую ответственность и противоречивые правила. Если сначала перенести исторический процесс в систему, организация получит те же потери, только быстрее и дороже.
Технологические требования разумно формировать после того, как понятны целевой сценарий, необходимые данные и критерии результата.
Разобрать процесс
Начнём с одного проблемного маршрута
Определим границы, участников, доступные данные и формат первичной диагностики.