директор и машина · операционное управление · запись № 015 · 12 июля 2026 · Давид Герштейн

Узкие места в процессах: как найти то, что тормозит всю компанию

В апреле компания платила за несколько каналов связи. В мае — уже в разы больше при том же штате. На каждого сотрудника подключены и WhatsApp, и Telegram, хотя фактически столько каналов на человека не нужно. Руководитель посмотрела на список и сказала прямо: столько сотрудников, чтобы это использовать, в компании нет. Если считать грубо: 45 из 52 каналов — «лишние», то есть почти 90% всех подключений компания оплачивала просто так (оценка, точное число нужных каналов не считали). Формула для своего случая простая: (число оплачиваемых каналов на сотрудника минус фактически нужное) × стоимость одного канала = переплата в процентах от бюджета на связь. Никто не отключал ненужное, потому что за это не отвечал ни один конкретный человек. Это и есть узкое место в бизнесе: расход, за который никто не отвечает, пока кто-то не задаст правильный вопрос.

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

Как найти узкие места в бизнесе: три вопроса вместо интуиции

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

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

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

Узкое место — это структура, а не человек

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

15 минут концентрации — вот реальная метрика узкого места. Не «сотрудник не справляется», а «структура дня физически не даёт сосредоточиться».

Делегирование — это не «дать ещё рук»

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

Деньги утекают там, где никто не считает

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

С деньгами работает тот же принцип, что и с расписанием, — только вместо часа в дне тут лишняя строчка в счёте. Разработчик использовал дорогую модель (уровня Opus) для задач, которые дешёвая версия (уровня Sonnet) решала с идентичным результатом. Проверили на одном и том же промпте — разницы в качестве не нашли, а разница в цене за токен была ощутимой: по открытым прайсам топовые модели обычно в 5-10 раз дороже «мини»-версий на сопоставимых задачах извлечения и структурирования текста (оценка по публичным тарифам, не внутренние цифры компании). Инструмент подключили «на всякий случай» и забыли проверить, нужен ли он в такой конфигурации — почти дословно та же история, что и с каналами связи.

Данные, которые говорят на разных языках

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

Именно с этого симптома обычно и начинается разговор о том, что CRM врёт — я подробно писал, как поймать систему на сдвиге дат и что делать, если данным нельзя доверять, в статье про Битрикс24.

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

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

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

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

Механика: как провести диагностику за неделю

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

1. День 1-2. Сбор жалоб. Что → фразы сотрудников на планёрках и в личных разговорах («не успеваю», «опять переделывать», «где взять цифру»). Чем → простой список без анализа. Куда → одна таблица на всех, колонки «кто сказал», «про что», «дата».
2. День 2-3. Кросс-выгрузка данных. Что → один и тот же показатель (число клиентов в воронке, сумма дебиторки, конверсия) выгружается из CRM, из отчёта аналитика и из ручной таблицы менеджера. Чем → штатные фильтры системы, без доработок. Куда → сравнительная таблица с тремя колонками и расхождением в процентах.
3. День 3-4. Аудит расходов на инструменты. Что → счета за подписки и коммуникационные каналы за последние 2 месяца. Чем → выгрузка из платёжной системы или бухгалтерии. Куда → список «инструмент — стоимость — кто реально пользуется» с пометкой «оставить/отключить».
4. День 4-5. Замер пропускной способности узких звеньев. Что → количество задач на входе и на выходе у звена, на которое жалуются чаще всего (документооборот, согласование, поддержка). Чем → ручной подсчёт за 2-3 дня или счётчик в боте. Куда → таблица «поступило / обработано / в очереди».
5. День 5. Синтез. Кто → руководитель направления вместе с тем, кто вёл таблицы. Что делает → сопоставляет три вопроса метода с собранными данными и выбирает 1-2 узких места с наибольшим денежным весом. Куда → короткая дорожная карта на ближайший месяц, а не список из двадцати пунктов.

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

ИИ-связка: как автоматизировать сбор сигналов об узких местах

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

Конвейер: голосовое сообщение в Telegram-бот → транскрибация → структурирование моделью по шаблону → запись в Google Sheets → уведомление руководителю с приоритетами.

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

Роль: аналитик бизнес-процессов.
Тебе дана расшифровка голосового сообщения менеджера по одному этапу воронки продаж.

Входные данные (JSON):
{
  "stage": "Название этапа воронки",
  "manager": "ID менеджера",
  "transcript": "Текст расшифровки голосового сообщения за этот этап"
}

Задача:
1. Опиши, что сейчас происходит на этом этапе (current_state) — 1-2 предложения.
2. Отметь, что уже работает и трогать не нужно (working).
3. Выдели рутинные операции, которые можно автоматизировать (automation_candidates) — список.
4. Оцени приоритет внедрения по шкале 1-5, где 5 — критично тормозит процесс (priority).
5. Дай короткое обоснование приоритета (reason), не длиннее 20 слов.

Верни только JSON без пояснений вокруг, строго в этой структуре:
{
  "stage": "",
  "current_state": "",
  "working": "",
  "automation_candidates": [],
  "priority": 0,
  "reason": ""
}

Пример ответа модели на реальный кусок расшифровки про подготовку договоров:

{
  "stage": "Оформление договора",
  "current_state": "Два специалиста вручную готовят договоры, работают по выходным",
  "working": "Шаблон договора стабилен, ошибок в тексте нет",
  "automation_candidates": ["Автозаполнение полей из CRM", "Уведомление о просрочке подготовки"],
  "priority": 5,
  "reason": "Пропускная способность звена ниже потока лидов, риск потери сделок"
}

Инженерная обвязка. Хранилище — лист Google Sheets «Дорожная карта», каждая строка — один ответ по одному этапу. Триггер — Telegram-бот принимает голосовое, отправляет на транскрибацию, скрипт (Google Apps Script или n8n) формирует JSON из шаблона выше и вызывает API модели. Результат пишется обратно в таблицу и дублируется в Telegram-чат руководителя со scoring по приоритету — тот же принцип, что применили для ежедневной сводки по задачам и встречам. Стоимость вызовов модели логируется отдельным столбцом — чтобы не повторить историю с дорогой моделью там, где хватает дешёвой.

Если транскрипция пустая или модель вернула невалидный JSON — строка помечается статусом «ошибка», и в отдельный технический чат уходит алерт с минимумом контекста, достаточным, чтобы разработчик не открывал таблицу вручную:

⚠️ Ошибка обработки голосового отчёта
Менеджер: ID 214
Этап: Квалификация лида
Причина: модель вернула невалидный JSON (обрыв на поле automation_candidates)
Время: 09:42
Строка в таблице: Дорожная карта, row 37
Действие: нажмите /retry_37 для повторной обработки

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

Прикинуть стоимость эксплуатации можно так: один голосовой отчёт менеджера — это примерно 300-500 слов расшифровки, то есть около 700-900 токенов на вход плюс промпт, и ещё около 150-200 токенов на ответ модели — итого порядка 1000 токенов за вызов (оценка). При потоке в 20-30 сообщений в день это 20 000-30 000 токенов в день, или 600 000-900 000 токенов в месяц. На дешёвой модели это укладывается в единицы долларов в месяц (оценка по порядку публичных тарифов), плюс сопоставимые копейки за транскрибацию голоса. Формула для своего случая: количество сообщений в день × токены на вызов × цена за токен × дни в месяце = месячный счёт за модель.

Экономика: что стоит найти узкое место и что это даёт

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

Формула для строки с аналитиком, если хотите прикинуть свой случай: минуты экономии в день × 30 дней ÷ 60 = часы экономии в месяц. Здесь 30 минут × 30 ÷ 60 = 10,5 часа — это чуть больше рабочего дня, который каждый месяц высвобождается на одного сотрудника для другой работы. При типичной ставке менеджера это условная стоимость освобождённого времени, сопоставимая с четвертью недельного дохода на одного сотрудника — не «живые» деньги в кассе, а часы, которые можно направить на аналитику вместо копирования цифр.

Отдельно — иллюстративный пример того, во сколько обходится расхождение данных, если его не замечать. Отдел из нескольких менеджеров, каждый ведёт около 10 сделок в месяц со средним чеком, сопоставимым с несколькими месячными окладами специалиста — в сумме десятки сделок в воронке. Если из-за нестыковки данных между источниками (как в примере с расходящимися выгрузками по числу клиентов) около 10% сделок «зависает» и выпадает из поля зрения — это несколько сделок, которые никто не сопровождает вовремя, потому что в отчётах их как будто нет. При типичном среднем чеке это риск, сопоставимый с месячным фондом оплаты труда небольшого отдела, которые компания не обязательно теряет физически, но которыми не управляет — сделки просто зависают между версиями правды, пока кто-то вручную не сверит три таблицы (оценка, консервативный расчёт по условному отделу, не факт из практики конкретной компании). Это не сумма, которую можно сложить с переплатой за каналы связи или с высвобожденным временем аналитика — три разных узких места, три разных источника риска, и путать их в один «эффект от ИИ» было бы нечестно перед читателем.

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

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

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

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

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

Как понять, что в компании есть узкое место?

Если один и тот же вопрос всплывает на трёх разных встречах — от разных людей и по разным поводам — это симптом узкого места, а не совпадение.

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

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

Автоматизация рутинных задач решает узкие места?

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

#аналитика и отчётность #автоматизация #деньги