Задержки из-за ручных согласований: сначала измерьте скрытое время ожидания

Куда исчезает время

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

Менеджер может потратить шесть минут на согласование скидки, условия договора или изменения перед релизом. По календарю это согласование может занять два дня, потому что оно лежит в очереди, ждет контекста или сначала попадает не к тому человеку.

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

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

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

Занятые команды обычно не замечают это простоиное время, потому что все помнят, что были заняты. Руководитель продаж помнит, как готовил сделку. Финансы помнят, как проверяли цифры. Инженеры помнят, как оценивали влияние. Никто не видит весь разрыв между этими моментами, пока кто-то не разложит запрос от начала до конца.

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

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

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

Как выглядит статус ожидания

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

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

Большинство команд замечают проверку. Но обычно большие потери сидят именно в очереди.

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

Статус ожидания можно заметить по нескольким типичным признакам:

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

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

В каждом случае сама задача не остановила работу. Это сделал запрос на решение.

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

Где накапливаются согласования

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

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

Быстрее всего это обычно чувствуют продуктовые команды. Функция уже готова, но кому-то еще нужно подтвердить финальный объем работ. Маркетинговый текст может неделями лежать в черновике, пока его не прочитает один человек. Релиз может сорваться, потому что тот, кто должен его утвердить, весь день на встречах.

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

Финансы часто прячут задержки за рутинной административной работой. Запрос на покупку ждет менеджера. Счет-фактура ждет проверки бюджета или правильного кода затрат. Продление ПО лежит в чьем-то почтовом ящике, потому что никто не хочет одобрять расход без еще одной проверки. Люди называют это осторожностью. Часто это просто время в очереди.

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

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

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

Как описать текущий путь

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

Берите один реальный запрос, а не гипотетический. Проследите его от первого обращения до финального «да», «нет» или выпуска. Если запрос клиента сначала появляется в CRM, потом уходит в чат, а потом попадает в тикет, проследите именно этот путь по порядку.

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

Для простой карты нужны пять вещей:

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

Это важнее, чем многие ожидают. Задержки часто прячутся в передачах между инструментами, а не в самом согласовании. Менеджер может одобрить что-то за две минуты, но запрос способен пролежать девять часов в почте, прежде чем его кто-то увидит.

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

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

Память звучит аккуратно, но она вырезает задержки.

Сначала карта может быть очень простой. Таблицы в документе или в spreadsheet достаточно. Цель — увидеть маршрут, паузы и повторяющиеся циклы.

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

Как измерить это шаг за шагом

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

Для каждого запроса запишите четыре момента:

• когда его отправили
• когда первый проверяющий открыл его или ответил на него
• когда кто-то одобрил или отклонил его
• когда работа действительно завершилась

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

Затем разделите временную линию на время активной работы и время ожидания. Активная работа — это когда кто-то читает, проверяет, редактирует или завершает запрос. Время ожидания — все, что находится между этими этапами. Если финансы тратят 12 минут на проверку запроса на скидку, но он лежит 19 часов, прежде чем его кто-то увидит, задержка не в медленной работе. Она в простое.

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

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

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

Простой пример для четырех команд

В понедельник утром менеджер по продажам получает сообщение от крупного потенциального клиента. Он хочет скидку 15% на годовой контракт и хочет получить ответ до конца недели. Менеджер не может сказать «да» сам, поэтому запрос начинает двигаться от команды к команде.

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

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

Финансы подключаются после частичного ответа продукта. Они проверяют маржу, условия оплаты и то, имеет ли смысл скидка, если клиент попросит оплату net-60. Эта проверка занимает 15 минут. А ожидание до нее — почти весь день.

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

• Запрос от продаж ждет 4 часа, прежде чем его посмотрит продукт.
• Вопрос от продукта ждет 18 часов ответа от инженеров.
• Проверка финансов ждет 6 часов в очереди.
• Ответ инженеров ждет до утра подтверждения по релизу.
• Продажам нужно полдня, чтобы обновить предложение и назначить следующий звонок.

Никто не работал над этим запросом очень долго. Общее время реальной работы — меньше часа. А прошло почти четыре дня.

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

Ошибки, которые искажают цифры

Задержки согласований выглядят меньше, чем есть на самом деле, когда команды измеряют только чистые, завершенные случаи. Если считать только запросы, которые дошли до финального «да», вы пропускаете грязную часть: запросы, которые висели в черновике, возвращались на доработку, истекали или просто исчезали, потому что никто не хотел снова их догонять. Все эти случаи тоже отнимали время у product, sales, finance или engineering.

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

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

Несколько привычек вызывают большинство ошибок в измерениях:

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

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

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

Если после этого цифры все еще плохие, тогда уже имеет смысл думать о софте или найме.

Что проверить перед автоматизацией или наймом

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

Прежде чем добавлять софт или нанимать еще одного проверяющего, проверьте путь с помощью нескольких простых вопросов:

• Может ли один человек одобрять обычные случаи?
• Собирают ли ваши формы все данные, которые проверяющие всегда запрашивают?
• Видят ли все один и тот же статус запроса в одном месте?
• Проходят ли простые запросы через дублирующие согласования?
• Есть ли у каждого шага время ответа?

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

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

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

Что чинить сначала и что делать дальше

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

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

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

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

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

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

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

Если согласования проходят через product, sales, finance и engineering, внешний разбор может сэкономить много проб и ошибок. Именно такую работу fractional CTO делает Oleg Sotnikov через oleg.is: разобрать реальный процесс, убрать лишние ожидания и подключать AI-автоматизацию только там, где она действительно помогает.