Логотип Студии Ивана Удачника Автоматизация, которая окупается
статьи - «Как понять, что компания выросла из ручного управления»

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

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

Как понять, что компания выросла из ручного управления
короткий ответ

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

Компания перерастает ручное управление, когда собственник становится очередью

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

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

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

На узком экране таблицу можно прокручивать по горизонтали

Сначала составьте карту решений, а не карту должностей

Оргструктура отвечает на вопрос «кто кому подчиняется». Для ручного управления важнее другой вопрос: какие решения возникают каждую неделю, кто их инициирует, кто владеет контекстом и кто имеет право поставить точку

Карта решений собственника

РешениеЧастотаОбратимо?Максимальный ущербКто знает контекстКто должен решать
скидка постоянному клиентуежедневнодо обещания клиенту; после - не всегдаограниченныйруководитель продажруководитель продаж в пределах лимита
исключение по оплатенесколько раз в неделючастичносреднийфинансы + продажифинансовый руководитель по порогу
смена ценовой моделиредкодорого обратимовысокийруководствособственник или коллегиальный орган

На узком экране таблицу можно прокручивать по горизонтали

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

Делегировать нужно не ответственность вообще, а классы решений

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

Типовые

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

Пороговые

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

Стратегические

Влияют на компанию надолго или несут большой риск. Здесь важнее качество обсуждения, чем скорость согласования

В разборе McKinsey права на решение связаны с ответственностью, подготовкой сотрудников и порогами эскалации. Это рекомендации по организации работы, а не доказательство, что любая передача полномочий ускорит компанию. Для решений на стыке функций нужно также согласовать, кто и когда передаёт исходные данные [2]

Порог эскалации лучше фразы «если что - спроси меня»

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

На узком экране таблицу можно прокручивать по горизонтали

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

Сколько ожидания накапливается в очереди решений

Заполните все поля. Если значение равно нулю, укажите 0

Формула: число решений × среднее ожидание. Для выбранной части результат дополнительно умножается на долю типовых решений и на долю готовых среди них. Последняя доля считается именно внутри типовых решений; произведение двух независимых долей из всей выборки здесь было бы некорректно. В расчёте предполагается одинаковое среднее ожидание для обеих групп. Часы разных решений могут идти одновременно: это не рабочее время сотрудников, не длительность недели и не денежная экономия. Сравнивайте завершённые решения за один период, а незавершённую очередь учитывайте отдельно

Как перейти от ручного управления без управленческого бардака

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

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

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

Источники и границы выводов

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

  1. HBR: How Fast-Growing Companies Can Make Better Decisions, 8 мая 2026. Доступны аннотация и начало; полный текст при проверке недоступен
  2. McKinsey: Untangling your organization’s decision making, 21 июня 2017. Разбор делегирования и прав на решение; классификация автора источника отличается от трёх групп в статье

Хотите понять, что уже пора вывести из ручного управления?

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

Разобрать процессСначала проверим экономику процесса, а уже потом можно обсуждать внедрение

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

Значит ли это, что собственнику надо уйти из операционной работы?

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

Как понять, что решение можно делегировать?

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

Что делать с исключениями?

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

Когда нужна автоматизация?

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