директор и машина · операционное управление · полный гайд · 27 августа 2026

полный гайд направления

Как управлять бизнес-процессами: от описания до автоматизации

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

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

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

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

Когда вам это действительно нужно

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

Управление бизнес-процессами — это не регламент и не схема в презентации. Это три действия по кругу: описать, кто что делает и сколько это занимает; найти стадию, где всё стоит дольше нормы; автоматизировать именно эту стадию, а не процесс целиком. Нужно это тогда, когда компания выросла настолько, что никто больше не помнит всю цепочку наизусть — по моим наблюдениям, это происходит где-то между 25 и 40 сотрудниками.

Масштаб проблемы виден в одной цифре, и она неприятная. По исследованию «Яков и Партнёры» (2026) ИИ в процессах уже применяют 71% компаний, но значимый финансовый эффект фиксируют только 9%. При этом 89% таких проектов остаются пилотами — данные TAdviser и MWS AI, 2026, 2026 — запустили, показали на демо, забыли. Разница между 71% и 9% — это не про модель и не про бюджет. Это про то, довели ли разбор до конкретной метрики и до человека, который за неё отвечает.

Ещё одна цифра, из исследования SpeShu.AI по малому и среднему бизнесу (86 глубинных интервью, 2026): 47% руководителей принимают решение о масштабировании ИИ-инициатив по кейсам с измеримыми результатами, а не по описанию функционала на демо. Проблема в том, что публичных кейсов с прозрачной экономикой на рынке почти нет: конкуренты по кругу повторяют одни и те же четыре цифры — «−30–50% рутины», «до 80% операций», «−40% издержек», «окупаемость 3–6 месяцев» — без единого числа, которое можно взять и проверить на своих данных. Этот гайд собран так, чтобы цифры можно было пересчитать: с ценой внедрения, а не только с эффектом, и с отдельным разделом про то, где расчёт не сработал.

Управление процессами не равно регламентам на полке: сам по себе документ ничего не меняет, если по нему не сверяются. И это не разовый аудит: без цикла повторения любой аудит устаревает за один квартал.

Как описать процесс, чтобы его можно было анализировать

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

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

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

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

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

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

Как найти узкое место: метрики, а не ощущения

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

Узкое место — это стадия процесса, где доля объектов (сделок, заявок, документов), стоящих дольше нормы, превышает 20–25% от числа объектов на этой стадии. Знаменатель тут решает всё: считать надо от того, что стоит на стадии сейчас, а не от всего месячного потока — иначе любая стадия выглядит благополучной и узкое место не находится никогда. Находится это выгрузкой времени прохождения по стадиям из CRM за месяц, а не опросом «где у нас тормозит» — на опрос каждый отдел честно скажет, что тормозит у соседей.

Пример на цифрах нашей условной компании. Оборот 9 млн ₽/мес при среднем чеке 180 тыс. ₽ — это 50 сделок в месяц на 8 менеджеров, то есть около 6 сделок на менеджера. Выгрузка по стадиям показала: на согласовании находятся 12 сделок, и 5 из них стоят дольше нормы — это 42%, вдвое выше порога. Риск таких зависших сделок = 5 × 180 000 = 900 000 ₽/мес (оценка) — не выручка, которую точно потеряют, а сумма, которая под угрозой, если сделки не разморозить.

После того как на стадию согласования назначили владельца и поставили ежедневный алерт о сделках старше 10 дней, доля стоящих дольше нормы упала с 42% до 25% — с 5 сделок до 3. Риск снизился с 900 000 ₽ до 540 000 ₽/мес, то есть на 360 000 ₽/мес (оценка). Это снижение риска, а не гарантированный прирост выручки: часть из этих сделок и без вмешательства закрылась бы сама.

На диаграмме — риск зависших сделок до и после того, как нашли стадию и назначили владельца.

Риск = число зависших сделок × средний чек (180 000 ₽). Было 5 сделок, стоящих дольше нормы, из 12 на стадии (42%), стало 3 из 12 (25%) — снижение риска на 360 000 ₽/мес, оценка.

Важная деталь про эту таблицу: доли на стадиях «Договор» и «Оплата» не изменились — там узкого места не было и мы туда не вмешивались. Это специально: автоматизация точечная, а не «давайте улучшим всё сразу». Если начать чинить сразу все стадии, ресурсов и внимания владельцев не хватит ни на одну, и через месяц окажется, что метрика не двинулась ни там, ни там.

Кого назначить владельцем

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

У каждого процесса должен быть один именованный человек, который отвечает за метрику стадии — не отдел, не «продажи в целом», а конкретная должность. Без этого любая автоматизация превращается в надзор вручную: бот шлёт алерты, а разбираться с ними всё равно приходится тому, кто случайно их заметил.

На одной из планёрок операционный директор Лена задала простой вопрос: «Кто владелец этого процесса?» — про стадию согласования договоров. Молчание длилось секунд десять. Отдел продаж считал, что это забота юристов; юристы — что это забота продаж; проект-менеджер думал, что процесс вообще ничей, потому что документооборот всегда «как-то сам разбирался». Через неделю владельца назначили — и оказалось, что у него физически нет времени на эту роль: он уже вёл три параллельных проекта. Роль пришлось переносить на другого человека.

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

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

Ещё одно наблюдение по этой теме: должность владельца не должна плыть по тексту документов компании. Если в одном регламенте он «руководитель отдела продаж», а в другом — «ответственный за воронку», через полгода никто не может быстро найти, кто это. Зафиксируйте должность один раз в одном месте и ссылайтесь на неё, а не переизобретайте название роли под каждый новый документ.

Какие каналы связи незаметно душат процесс

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

Реальный случай: в апреле было оплачено 7 каналов связи, в мае — уже 52, хотя на каждого сотрудника при этом просто задублировали WhatsApp и Telegram по отдельным тарифам, реально работая в одном из двух. Такая переплата обычно всплывает вместе с зависшими сделками — оба симптома растут из одного и того же неконтролируемого процесса.

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

Проверка, которая занимает 15 минут раз в месяц и почти всегда себя оправдывает: выгрузить список активных подписок на связь из бухгалтерии, сверить с числом реально работающих сотрудников и спросить прямо — «этот канал кто-то использует сегодня, или это наследство от прошлого сотрудника, которого уже нет в компании». Обычно один такой вопрос закрывает 3–5 ненужных подписок за раз.

С чего начать за одну неделю

Минимальный рабочий контур на неделю — это не «внедрить систему управления процессами», а четыре конкретных действия: выбрать один процесс, выгрузить по нему цифры, назначить владельца, поставить один автоматический алерт. Дальше — по результатам первой недели решать, что делать со вторым процессом.

Понедельник — выбрать процесс. Не тот, что кажется важным вам, а тот, на который чаще жалуются клиенты или коллеги: спросите прямо на планёрке. Вторник и среда — выгрузка из CRM: время прохождения каждой стадии за 30 дней, медиана и доля тех, кто застрял дольше нормы. Четверг — вслух назвать владельца стадии, где дольше нормы стоит больше 20% находящихся на ней сделок. Пятница — включить один алерт (вебхук в Bitrix24 или формула в Google Sheets), который сам напомнит о превышении нормы, — и на этом неделя заканчивается, дальше идёт по результатам.

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

Дашборд не заменяет живой разговор на планёрке — он его сокращает. Раньше на обсуждение этой стадии уходило 20–30 минут, потому что цифры собирали на ходу устно; с готовым экраном на это нужно 5 минут — цифры уже перед глазами у всех, спорить не о чём, обсуждать можно сразу решение.

ИИ-связка: три промпта под разные задачи процесса

Для управления процессами нужно минимум три разных промпта на трёх разных этапах: найти узкое место в данных (дешёвая модель, потому что задача формальная), оценить качество взаимодействия по чек-листу (дорогая модель, потому что нужно понимать контекст диалога), проверить структуру документа перед публикацией (снова дешёвая модель, задача техническая). Смешивать их в один универсальный промпт — способ получить средний результат по всем трём направлениям.

Промпт 1 — найти узкое место в воронке (amoCRM API, дешёвая модель для классификации). На входе — выгрузка сделок с полями стадии и датами входа-выхода.

Ты аналитик процессов продаж. На входе — список сделок в формате JSON
с полями: id, stage (название стадии), entered_at (дата входа на стадию),
exited_at (дата выхода, может быть null для незакрытых), manager, amount.

Посчитай для каждой стадии:
1. Медианное время нахождения сделки на стадии в днях (для открытых сделок
   считай от entered_at до текущей даты).
2. Долю сделок, находящихся на стадии дольше 14 дней.
3. Количество сделок на стадии.

Верни только JSON-массив без пояснений:
[{"stage": "...", "median_days": N, "share_over_14d": 0.NN, "count": N}]
Не давай рекомендаций и выводов — только цифры.

Пример ответа модели:

[
  {"stage": "Согласование", "median_days": 9, "share_over_14d": 0.34, "count": 12},
  {"stage": "Договор", "median_days": 3, "share_over_14d": 0.05, "count": 8},
  {"stage": "Оплата", "median_days": 1, "share_over_14d": 0.02, "count": 6}
]

Промпт 2 — оценить звонок по внутреннему чек-листу (дорогая модель, нужен разбор смысла разговора). На входе — транскрипт звонка менеджера с клиентом.

Ты оцениваешь звонок менеджера по продажам. На входе — текст транскрипта
диалога. Оцени по шкале 0–2 четыре пункта:
- приветствие_и_представление
- выявление_потребности
- работа_с_возражениями
- договорённость_о_следующем_шаге

Для каждого пункта дай оценку и одну короткую цитату из диалога
как подтверждение (или null, если пункт не выполнен).
Верни только JSON без комментариев.

Пример ответа модели:

{
  "приветствие_и_представление": {"score": 2, "quote": "Добрый день, меня зовут..."},
  "выявление_потребности": {"score": 1, "quote": "А что вам важно в первую очередь?"},
  "работа_с_возражениями": {"score": 0, "quote": null},
  "договорённость_о_следующем_шаге": {"score": 2, "quote": "Договорились, жду от вас документы до среды"}
}

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

Промпт 3 — проверить структуру документа перед публикацией (Google Диск + скрипт-триггер, дешёвая модель). На входе — текст инструкции или регламента.

Ты проверяешь текст инструкции на соответствие структуре. На входе —
текст документа. Проверь наличие четырёх разделов: Цель, Шаги
(нумерованный список действий), Ответственный, Критерий готовности.

Верни JSON:
{"есть_цель": bool, "есть_шаги": bool, "есть_ответственный": bool,
"есть_критерий": bool, "замечания": ["..."]}

Если раздел отсутствует или сформулирован нечётко — укажи это в замечаниях.

Пример ответа модели:

{
  "есть_цель": true,
  "есть_шаги": true,
  "есть_ответственный": false,
  "есть_критерий": true,
  "замечания": ["Не указан ответственный за выполнение инструкции"]
}

Такая проверка снимает необходимость перечитывать документ на 20 страниц вручную каждый раз, когда его редактируют: автор загружает файл на Google Диск, триггер запускает скрипт, отчёт приходит в Telegram за минуту.

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

Экономика: что стоит автоматизация узкого места и что она даёт

Настройка мониторинга одной стадии процесса занимает около 8 часов работы аналитика, эксплуатация — примерно 1 500 ₽/мес на API и хранение данных, а эффект от снижения риска зависших сделок в разобранном примере ≈ 360 000 ₽/мес (оценка). Отдельно от этого экономия часов на ручной сверке — около 20 000 ₽/мес (оценка). Это две разные строки, складывать их в один «эффект» нельзя: одна показывает снижение риска, другая — освободившееся время сотрудника, переведённое в деньги.

Посчитайте риск зависших сделок на своих цифрах — формула та же, что и в разобранном примере: сделки в месяц × средний чек × доля зависших.

Пример с подстановкой: на стадии согласования 12 сделок, средний чек 180 тыс. ₽, доля стоящих дольше нормы падает с 42% до 25% — это 2 сделки, которые раньше стояли бы дольше нормы. 2 × 180 000 ₽ = 360 000 ₽/мес риска, который перестаёт висеть (оценка). Окупаемость по консервативной части (только экономия часов 20 000 ₽/мес против разовых 12 000 ₽ настройки) — меньше месяца. Окупаемость по риску в месяцах не считаем: это не гарантированный денежный поток, а вероятность потери, которая снизилась.

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

Что мы не считаем эффектом. Если освободившиеся от ручной сверки часы никуда не пошли — просто «стало свободнее», а нагрузка не изменилась, — деньги здесь считать нельзя. Это перераспределение времени, а не эффект в кассе; фиксируйте его отдельно и проверяйте через квартал.

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

Где это не сработало у меня

Голосовые роботы для обзвона клиентов — пример автоматизации, которая заработала технически, но не окупилась экономически: при нашем объёме звонков срок окупаемости превышал два года. Мы отказались от разработки внутри и взяли оператора на часть ставки — дешевле и быстрее.

Разработка «естественной» речевой системы требует записи тысяч комбинаций диалогов и обучения нейросети на них — это отдельный проект, а не настройка на пару часов. По прикидкам, она стоила бы около 350 000 ₽ разово (оценка) плюс постоянные правки под новые сценарии. Задача, которую должен был решать робот, — обзвон с напоминанием об оплате, около 50 звонков в месяц по 15 минут, то есть 12,5 часов человеческого труда; при ставке 1 000 ₽/час это 12 500 ₽/мес (оценка). Разовые 350 000 ₽ на робота против 12 500 ₽/мес живого оператора — вот и весь расчёт по срокам.

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

Третья история короче, но обиднее: мы автоматизировали сбор отчётов по звонкам через речевую аналитику, а разбираться в присланных цифрах всё равно приходилось руководителю отдела вручную — формат выгрузки не совпадал с тем, как он привык читать отчёт, и он просто пересобирал всё заново в своей таблице. Технически система работала правильно. Просто никто не спросил заранее, в каком виде человек реально готов эти цифры принимать.

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

Зрелость по уровням: старт, квартал, год

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

Старт (0–1 месяц). Один процесс описан в таблице «шаг — ответственный — время». Найдено одно узкое место по цифрам, а не по ощущениям. Назначен владелец стадии.

Квартал (3 месяца). Автоматизирован мониторинг зависших сделок или задач хотя бы на одной стадии. Введён регулярный (не разовый) аудит каналов связи. У 2–3 ключевых процессов есть именованные владельцы, а не «отдел в целом».

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

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

Чек-лист первого понедельника

• Выбрать один процесс с наибольшим числом жалоб за последний месяц.
• Выгрузить из CRM время прохождения каждой стадии этого процесса за 30 дней.
• Посчитать долю сделок или задач, застрявших дольше нормы на каждой стадии.
• Назвать вслух на планёрке: «Владелец этой стадии — [конкретное имя]».
• Настроить один автоматический алерт о превышении нормы (Bitrix24-вебхук, Google Sheets с формулой или Telegram-бот).
• Зафиксировать текущую сумму риска зависших объектов как точку отсчёта — сравнивать с ней через месяц.
• Поставить в календарь повторную проверку через 4 недели — без этого пункта всё остальное держится только на энтузиазме.

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

Как связать описание с автоматизацией и не увязнуть в бумажной работе — в бесплатном курсе.

С чего начать именно вам

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

Дальше у вас будет выбор: чинить организационно или автоматизировать. И в вашем случае, скорее всего, первое даст результат быстрее.

И про навык, ради которого всё это. Читать процесс по цифрам — дни на этапе, доля возвратов, кто ответственный — такой же базовый навык руководителя, как читать отчёт о прибылях. Я сам годами обходился без него: спрашивал у людей «как идёт» и получал ответ «нормально». Нормально означало 540 дней у одной сделки. Пока вы не видите процесс числами, вы им не управляете — вы его сопровождаете.

Частые вопросы

С чего начать управление бизнес-процессами, если ничего не описано?

Возьмите один процесс с наибольшим числом жалоб, опишите его в 5–7 шагов за один день и сразу посчитайте время каждого шага — без этого числа описание бесполезно.

Как найти узкое место без сложной аналитики?

Выгрузите из CRM время прохождения каждой стадии за месяц и посчитайте долю сделок, стоящих дольше нормы, от числа сделок на этой стадии — узкое место там, где эта доля выше 20–25%.

Сколько стоит автоматизация одного узкого места?

По нашей практике настройка занимает 6–10 часов и 1000–2000 ₽/мес эксплуатации; эффект нужно считать отдельно как снижение риска, а не как гарантированную прибыль.

Кто должен быть владельцем процесса, если в компании нет отдельной роли под это?

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

Как часто нужно пересматривать описание процесса и найденное узкое место?

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