Внутри любой компании постоянно движется пять потоков: люди, товары и запасы, документы, деньги и информация. Пока эти потоки согласованы, бизнес работает как система. Стоит согласованию сломаться, и появляются просрочки, двойная работа, потерянные заявки и деньги, которые утекают незаметно.
Первая реакция руководителя обычно одна: виноваты сотрудники. Кто-то не так понял, не туда передал, забыл перезвонить. Эдвардс Деминг, один из основателей современного менеджмента качества, в книге «Выход из кризиса» оценил это соотношение иначе: около 94% проблем принадлежат системе и находятся в зоне ответственности руководства, и только около 6% приходятся на частные причины. Точные цифры остаются авторской оценкой, но вектор подтверждается практикой: чаще ломается не человек, а процесс, в который его поставили.
Именно поэтому в 2025–2026 годах бизнес-процессы перестают быть внутренней «кухней» и становятся инструментом управляемости. Растущие расходы, дефицит специалистов и общая сложность ведения бизнеса делают цену хаоса ощутимой. Компании, которые видят, как создают ценность и где теряют ресурсы, адаптируются быстрее и масштабируются легче.
Ниже разбор того, как описывать, моделировать, анализировать и улучшать бизнес-процессы, чтобы они приносили больше денег и меньше зависели от отдельных людей. Материал будет полезен собственникам и руководителям, которые выстраивают процессы с нуля или чувствуют нехватку системности.
Что такое бизнес-процессы и зачем их описывать
Бизнес-процесс, это повторяющаяся последовательность шагов, с помощью которой компания создаёт ценность для клиента и получает результат для себя: выручку, прибыль, управляемость или рост. Любой бизнес-процесс состоит из трёх элементов: этапов (что делают и в каком порядке), участников (кто за что отвечает) и результатов (что должно получиться).
У процесса всегда есть начало и конец, и он создаёт измеримый результат: документ, звонок, договор, отгруженный заказ. Результат должен иметь ценность для клиента, причём клиентом бывает не только внешний покупатель, но и коллега. Например, клиент отчёта менеджера за неделю, это его руководитель. Отсюда практический критерий: если результат процесса никому не нужен, процесс скорее всего лишний и его стоит убрать, а не описывать.
Процессы редко бывают линейными: они включают множество задач, операций, подпроцессов и ветвлений. Например, основной процесс рекламного агентства, это оказание услуг: чтобы сделка состоялась, нужно найти клиента, подготовить предложение, согласовать условия и выставить счёт. Каждый шаг раскладывается на подпроцессы с разными исполнителями. При этом важно отличать бизнес-процесс от разовой задачи и от временного проекта.
| Понятие | Ключевой признак | Пример |
|---|---|---|
| Бизнес-процесс | Повторяется снова и снова, стандартизирован и предсказуем, управляется через регламенты и KPI | Приём заявок, расчёт зарплаты, отгрузка товара |
| Задача | Разовое действие с конкретным сроком и исполнителем | Позвонить клиенту, отправить предложение |
| Проект | Уникальная деятельность с началом и концом, управляется через сроки, бюджет и ресурсы | Запуск нового продукта, внедрение CRM |
Различие между процессом и проектом на практике важнее, чем кажется. Любое улучшение процесса, это проект: у него есть цель, срок, бюджет и ответственный. Об этой связке будет отдельный разговор ниже, потому что попытка «оптимизировать процессы» без рамок проекта почти всегда превращается в бесформенную инициативу без результата.
Зачем описывать бизнес-процессы
Описание процессов даёт компании пять практических выгод.
Независимость от людей. Описание фиксирует экспертность сотрудников и делает её воспроизводимой, бизнес начинает работать как система, а не как набор незаменимых героев, которые держат всё в голове
Корень проблем, а не симптомы. Видны узкие места, где теряются деньги, время или качество, и их можно устранить, а не тушить последствия по кругу
Масштабирование практик. Удачный подход (например, скрипт продаж с конверсией 30%) описывают и тиражируют на всю команду, новички быстрее выходят на высокий результат
Подготовка к автоматизации. Чёткая схема показывает, что именно автоматизировать, и помогает составить корректное ТЗ, а не автоматизировать хаос
Взаимодействие отделов. Зафиксированный процесс, это общий язык: ясно, кто, что и когда делает и где границы ответственности
Браться за описание стоит тогда, когда это помогает найти точки роста, усилить производство или увеличить прибыль. Не нужно описывать процессы, если стартап на стадии проверки гипотез, бизнес живёт два-три месяца, нет управленческого запроса или процессы меняются каждую неделю. В такой ситуации описание устареет раньше, чем принесёт пользу.
Виды бизнес-процессов: основные, поддерживающие и управляющие
Управлять всеми процессами сразу невозможно, поэтому первым делом их раскладывают на группы, иногда это называют системой процессов или процессным ландшафтом по аналогии с картой. Классификаций несколько: по масштабу, по степени документирования и, самое полезное для приоритизации, по роли в создании ценности. Разбор ниже начинается именно с последней, потому что она подсказывает, за какие процессы браться в первую очередь.
Помимо роли в создании ценности процессы делят и по другим признакам. По масштабу они бывают внутри одного отдела или сквозными (кросс-функциональными), которые проходят через несколько подразделений. Например, путь от лида до заказчика: отдел продаж обрабатывает заявку, юристы готовят договор, бухгалтерия принимает оплату. Именно в сквозных процессах ответственность чаще всего размывается: каждый отдел делает свою часть, а за конечный результат не отвечает никто.
Процессный взгляд против функционального
Главный вывод этого раздела: процессы должны определять структуру компании, а не наоборот. Большинство организаций строятся по функциям: есть финансы, маркетинг, продажи, HR. Каждое подразделение со временем растёт как отдельное королевство: делает отчёты для себя, конкурирует за ресурсы, перекладывает задачи на соседей. Результат, это функциональная рассогласованность, потери и конфликты на стыках. По наблюдению Деминга, значительная часть проблем предприятия возникает именно в пространстве между подразделениями, а не внутри них.
Процессный подход не отменяет функции и оргструктуру, он добавляет горизонтальный взгляд. Процесс пересекает функции, и у него появляется владелец, единое ответственное лицо за сквозной результат. Сразу становится видно, где теряется время и деньги, где происходят сбои и кто за что отвечает. Улучшения перестают быть тушением пожаров и становятся системными.
Отсюда вытекает правильная последовательность построения: сначала стратегия, затем бизнес-модель, потом процессы под эту модель и только в конце оргструктура под процессы. Частая ошибка обратная: процессы натягивают на уже существующую структуру. Старая структура при этом блокирует изменения, люди оказываются не на тех позициях, а часть подразделений не участвует в ключевых процессах. Поэтому логичнее менять структуру под эффективные процессы, а не подгонять процессы под структуру.
Владелец процесса
Владелец процесса, это один человек на весь сквозной процесс, который отвечает за финальный результат, а не за отдельный этап. Он координирует работу между подразделениями, вмешивается при сбое и ведёт переговоры с руководителями функций. Важно не путать его с ответственным на этапе: например, в процессе обзвона клиентов ответственный на этапе, это менеджер по продажам, а владелец процесса, это руководитель отдела продаж, который переживает за итог всей цепочки.
Без такой роли сквозной процесс остаётся ничьим, и именно там накапливаются потери. Назначение владельца, это самый дешёвый управленческий шаг, который резко повышает управляемость, потому что появляется человек, с которого можно спросить за результат целиком.
Описание и моделирование: в чём разница
Описание, это свод правил, по которым работает процесс: оно объясняет, почему процесс устроен именно так и в чём его цели. Может быть текстовым, табличным, устным или в виде сценария. Моделирование, это визуализация: модель показывает, как движется работа, порядок шагов, развилки и контрольные точки, и строится через нотации (условные обозначения). Описание можно сравнить с техзаданием на дом (что должно быть), модель, с чертежом (как всё расположено и связано). Они не заменяют, а дополняют друг друга.
Как описать бизнес-процесс
Работа начинается с описания текущего состояния (AS-IS, «как есть»). Цель, беспристрастно зафиксировать реальность, а не сразу улучшать или подгонять под идеальный регламент. Общий алгоритм укладывается в четыре шага.
Методы описания: текст, SIPOC, блок-схемы, BPMN, RACI
Выбор метода зависит от задачи, сложности процесса и того, кто будет работать с результатом. На практике эффективнее не один инструмент, а связка: текстовое описание, SIPOC, блок-схема и матрица RACI.
| Метод | Что это | Когда подходит |
|---|---|---|
| Текстовое (сценарное) | Пошаговая инструкция: что запускает процесс, действия, ответственные, правила, результат | Простые процессы, небольшие команды, регламенты |
| SIPOC | Верхнеуровневое описание: поставщик, входы, процесс, выход, клиент | Быстро обозначить границы и суть, вовлечь команду |
| Блок-схема | Последовательность шагов фигурами: действия, развилки «да/нет», начало и конец | Обсуждения, интервью, воркшопы, многоуровневые процессы |
| BPMN | Формальный язык моделирования со стандартными графическими элементами | Глубокая детализация и автоматизация, понятно бизнесу и IT |
| RACI | Матрица ответственности: исполнитель, ответственный, консультант, информируемый | Чёткое распределение ролей в процессе или проекте |
Расшифровка RACI: R (responsible), исполнитель, выполняет работу. A (accountable), ответственный, принимает решение и отвечает за результат (всегда один на этапе). C (consulted), консультант, с ним советуются. I (informed), информируемый, его уведомляют о результате.
Нотации моделирования: от классики до BPMN
Нотация, это набор условных обозначений для схемы процесса. Общая методология у всех схожая: на верхнем уровне строят потоковую диаграмму, которая раскладывает большой процесс на подпроцессы и показывает материальные и информационные потоки, а на нижнем, блок-схему (workflow-диаграмму) с последовательностью шагов, событиями и логическими операторами. Различаются нотации деталями и строгостью.
| Нотация | Особенность | Когда уместна |
|---|---|---|
| Классическая (без дорожек) | Простые диаграммы, ответственные показаны рядом с шагом, только начальные и конечные события | Массовая регламентация, где схема должна быть простой и читаемой |
| Дорожки (swimlanes) | Шаги распределены по дорожкам ответственных, сразу видно распределение ролей | Когда важно наглядно показать, кто за что отвечает |
| IDEF0 / IDEF3 | Входы, управление, механизмы и выходы; строгая структура верхнего уровня | Формальное описание, унаследованные корпоративные стандарты |
| ARIS (VAD, EPC) | Событийная цепочка процессов с промежуточными событиями и операторами | Детальное моделирование в крупных компаниях |
| BPMN | Гибкий современный стандарт, работает и в простом, и в сложном виде | Универсальный выбор, особенно под автоматизацию |
Отдельно про BPMN, потому что это сегодняшний стандарт де-факто. Его сила в гибкости: промежуточные события и операторы «и», «или» можно ставить, а можно не ставить. Из-за этого различают два режима. Simple BPMN рисуют почти как классическую схему: подпроцессы, потоки, ответственные и только начальные и конечные события, без лишней логики на верхнем уровне. Powerful BPMN разворачивает всю мощь нотации с промежуточными событиями и сложными развилками, ближе к ARIS.
Практика последних лет показывает встречный тренд: для массового применения компании снова возвращаются к простым схемам. Причина прагматична: сложную диаграмму с десятками потоков и операторов никто не читает, а значит она не работает. Поэтому чем шире аудитория регламента, тем проще должна быть нотация. И при любом выборе нужно соглашение по моделированию, документ, который фиксирует, как именно команда рисует схемы, иначе гибкость превращается в разнобой.
Для описания достаточно любого текстового редактора или корпоративной базы знаний, для моделирования есть бесплатные инструменты (Draw.io, BPMN.io) и более продвинутые платформы с общим репозиторием и командной работой. BPMN особенно важен, когда процесс готовят к автоматизации: однозначная модель ложится в основу разработки. О том, как процессы превращаются в работающую систему, BPA Develop рассказывает в материале про BPM-системы.
Как анализировать бизнес-процессы
Чтобы оценить эффективность процесса, смотрят на KPI, ключевые показатели эффективности. Они бывают финансовыми (выручка, маржинальность, себестоимость), временными (скорость задачи, длительность цикла), качественными (ошибки, возвраты, переделки), клиентскими (NPS, удовлетворённость, жалобы) и операционными (загрузка сотрудников, доля ручного труда). Расплывчатые формулировки вроде «часто жалуются на доставку» не дают основы для решений: нужно перейти к измеримым показателям, насколько чаще, сколько жалоб было раньше и что именно не устраивает.
Самый универсальный метод, это AS-IS → TO-BE. Сначала описывают процесс «как есть», затем по KPI выявляют проблемные участки (ошибки, лишние шаги, задержки, дублирование), потом проектируют целевой процесс «как должно быть». Есть и более прикладные методы анализа.
Метрики потока и узкое место: как считать
Чтобы анализ был не на глаз, а в цифрах, процесс раскладывают на несколько базовых величин. Их можно посчитать даже вручную в таблице, отдельная система для старта не нужна.
Эти величины связывает закон Литла, простое и надёжное правило теории очередей: количество единиц в процессе равно скорости потока, умноженной на время потока. Например, если поступает 10 обращений в час, а среднее время обработки 3 часа, то в процессе одновременно находится около 30 обращений. Формула помогает прикинуть нагрузку и размер очереди без сложной аналитики.
Производительность и утилизация показывают, как загружены ресурсы. Производительность операции равна числу исполнителей, делённому на время выполнения: если оператор тратит на анкету 12 минут, а операторов пятеро, за час они обработают около 25 анкет. Утилизация, это загрузка: здоровым уровнем считают около 70%, потому что загрузка под 100% вне узкого места приносит вред, а не пользу, копятся очереди и растёт время ожидания.
Узкое место, это шаг с самой низкой производительностью, и именно оно определяет пропускную способность всей цепочки, как самое слабое звено определяет прочность цепи. Правило работы простое: не переделывать весь процесс сразу, а найти узкое место, подтянуть его параметры к остальным, затем искать следующее. Так, шаг за шагом, процесс приближается к целевому состоянию TO-BE. Отдельно проверяют баланс между спросом и мощностью: если спрос превышает узкое место, его расширяют, если мощность избыточна, ресурсы перераспределяют, а не наращивают.
Модель зрелости процессов: пять уровней
Компании приходят к управлению процессами не сразу, а по ступеням. Сначала полезно увидеть общую траекторию: бизнес растёт в три этапа, от хаоса на энтузиазме к появлению регламентов и дальше к стабильной системе, которую можно масштабировать. Главный вывод этой части короткий: без системы масштабируется хаос, поэтому сначала строят систему, а уже потом растят обороты. Детальнее зрелость раскладывают на пять уровней.
Типичные ошибки при описании и оптимизации
Работа с процессами даёт эффект только тогда, когда обходит несколько ловушек. Ниже те, что встречаются чаще всего в реальных проектах, и цена каждой измеряется временем и деньгами.
Методы оптимизации бизнес-процессов
Оптимизация особенно нужна, когда компания планирует рост, хочет увеличить прибыль, внедрить автоматизацию или навести порядок в зонах ответственности. Оптимизация, это управляемое изменение процесса ради конкретного эффекта: действие становится быстрее, дешевле, стабильнее, качественнее или менее зависимым от людей. Метод подбирают под эффект, а не наоборот, и фокусируются на одной ключевой проблеме, а не пытаются исправить всё сразу.
Помимо этих базовых приёмов есть именованные методологии, каждая под свою задачу.
| Методология | Что даёт | Когда применять |
|---|---|---|
| Lean (бережливое производство) | Устраняет 7 видов потерь: перепроизводство, ожидание, лишние перемещения, избыточную обработку, запасы, лишние движения, дефекты | Оптимизация уже существующих процессов, быстрый и наглядный эффект |
| Теория ограничений | Находит и расшивает узкое место, самое слабое звено системы | Когда улучшение одного участка не даёт общего эффекта |
| Дизайн-мышление, сервис-дизайн | Переосмысливает процесс вокруг клиента, а не оптимизирует текущий | Когда процесс создают с нуля или меняют радикально |
| Lean Startup | Гипотеза, MVP, проверка и итерации вместо готового плана | Выход на новый рынок, цифровизация, смена бизнес-модели |
Разница между методами принципиальная: Lean и теория ограничений улучшают то, что есть, а дизайн-мышление переосмысливает процесс целиком. ERP- и CRM-системы в этом ряду не отдельный метод, а инструмент, который закрепляет уже налаженный процесс, поэтому их внедряют как часть стратегической инициативы, а не как самоцель.
Улучшение процессов, это всегда проект
Любое изменение процесса стоит вести как проект с чёткой целью, сроком, бюджетом и ответственным. Без этих рамок улучшение превращается в бесформенную инициативу: цель не зафиксирована, сроки плывут, в конце невозможно оценить результат. Проект живёт в трёх ограничениях, качество, бюджет и время, и изменение одного параметра влияет на остальные. Отклонение в пределах 10% по срокам и бюджету считается нормой, поэтому такой запас закладывают заранее.
Начинать переход к процессному управлению стоит не с горящих, а с ключевых процессов, которые влияют на доход и удержание клиентов. По практике внедрения для среднего бизнеса переход занимает ориентировочно от 6 до 12 месяцев, точный срок зависит от масштаба и того, насколько работа синхронизирована со стратегией и операционным планом. Разумная тактика, это начать с одного процесса, показать результат и затем масштабировать, вовлекая исполнителей, потому что именно они лучше всех знают, где потери.
Наконец, улучшать процессы в отрыве от стратегии бессмысленно. Стратегия задаёт направление сверху, а управление процессами обеспечивает стабильность снизу через регламенты, KPI и контроль. Если стратегии нет, можно быстро бежать не туда: процессы станут отлаженными, но приведут не к той цели. Поэтому цель всех улучшений, это не идеальные схемы, а больше прибыли, меньше потерь и меньше зависимости от отдельных людей.
Без описания процессов невозможно понять, почему что-то идёт не так, а без оптимизации, это исправить. Последовательная работа с процессами даёт предсказуемость, управляемость и возможность масштабироваться без хаоса. Когда дело доходит до автоматизации, команда BPA Develop помогает пройти весь путь: от аудита и описания процессов до разработки и внедрения BPM-, ERP- и CRM-решений, а связку с управленческой аналитикой выстраивает через BI-системы.
Часто задаваемые вопросы
