Бизнес-процессы компании: как описать, найти узкие места и улучшить

Когда компании пора описывать процессы

Формализация нужна не по достижении определенного числа сотрудников. Я бы ориентировался на признаки потери управляемости:

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

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

Начните с результата для клиента

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

Я бы начал с четырех вопросов:

• Кто клиент процесса?
• Какой результат он должен получить?
• Что запускает работу?
• По каким признакам понятно, что процесс завершен?

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

Такой подход не дает оптимизировать отдельный отдел ценой ухудшения общего результата.

Выберите один процесс для первого разбора

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

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

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

Сформулируйте границы. Например: процесс начинается при поступлении квалифицированной заявки и заканчивается подписанием договора либо зафиксированным отказом. Без границ обсуждение быстро захватывает всю компанию.

Опишите процесс «как есть»

Сначала нужна честная модель текущей работы — As Is. Не рисуйте схему того, как процесс должен работать по инструкции. Покажите реальное положение дел.

Для каждого шага зафиксируйте:

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

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

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

Измерьте исходное состояние

Без начальных показателей нельзя понять, принесло ли изменение пользу. Для процесса обычно достаточно нескольких метрик:

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

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

Спроектируйте процесс «как будет»

Модель To Be должна отвечать на конкретную проблему. Я бы проверил каждый этап несколькими вопросами:

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

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

Назначьте владельца процесса

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

Владелец процесса:

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

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

Зафиксируйте роли и правила передачи

На каждом этапе должны быть понятны четыре вещи:

• кто выполняет действие;
• кто принимает решение;
• кому передается результат;
• что считается готовностью к передаче.

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

Чем точнее критерий готовности, тем меньше споров на стыке подразделений.

Регламент должен помогать работать

Регламент процесса не обязан быть длинным. Для типового процесса часто достаточно:

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

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

Автоматизируйте после упрощения

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

В комментарии для АБН от 20 августа 2026 года я обращал внимание на ту же проблему: новая система не дает результата, если прежний порядок работы сохраняется. Внедрение требует изменения процессов, правил и регламентов.

Перед автоматизацией проверьте:

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

Программа закрепляет правила. Если правила не согласованы, цифровой инструмент только делает конфликт менее заметным для руководителя.

Запустите пилот

Будущую схему лучше проверить на ограниченном потоке: одном типе заказа, одном регионе, одной команде или группе клиентов.

Для пилота задайте:

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

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

Внедрите изменение в ежедневное управление

После утверждения схемы начинается самая сложная часть — переход к новому порядку. Я бы включил в план:

• Объяснение причины и ожидаемого результата.
• Обучение на реальных задачах.
• Обновление шаблонов, статусов и прав доступа.
• Период адаптации с быстрым разбором ошибок.
• Контроль соблюдения новых правил.
• Измерение результата.
• Корректировку схемы по данным.

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

Проверяйте экономический смысл

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

• сколько времени и денег теряется сейчас;
• сколько будет стоить изменение;
• какой эффект ожидается;
• какие риски появятся;
• когда нужно остановить эксперимент.

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

Короткий план работы

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

• Выберите один проблемный процесс.
• Определите клиента, вход и конечный результат.
• Пройдите реальные задачи и нарисуйте As Is.
• Измерьте время, очередь, возвраты и ошибки.
• Найдите главное ограничение.
• Спроектируйте простую модель To Be.
• Назначьте владельца и правила передачи.
• Проведите пилот.
• Обновите регламент и инструменты.
• Сравните показатели и решите, масштабировать ли изменение.