Бизнес умеет считать зарплаты, маржу, стоимость оборудования, логистику и даже минуты простоя серверов. Но есть один расход, который почти никогда не появляется в отчётности: время, когда всё готово двигаться дальше — кроме решения.
10:17.
Поставщик пишет:
Оборудование есть на складе.
Цена подтверждена.
Резерв можем держать до конца дня.
Хорошая новость.
Клиент согласовал конфигурацию.
Технический специалист подтвердил спецификацию.
Коммерческие условия понятны.
Деньги предусмотрены.
Осталось совсем немного:
получить одно внутреннее согласование.
Письмо отправлено.
Теперь ждём.
11:06
Ответа нет.
Ничего страшного.
У всех встречи.
12:43
Поставщик спрашивает:
“Any update?”
Пока нет.
14:18
Человек, который должен согласовать заказ, отвечает:
«В целом всё нормально. Давайте ещё Finance посмотрит».
Письмо уходит в Finance.
15:37
Finance задаёт один вопрос.
Вопрос отправляется Procurement.
Procurement пересылает его Sales.
Sales уточняет у поставщика.
Поставщик отвечает через двадцать минут.
Ответ возвращается обратно по той же цепочке.
17:11
Все вопросы закрыты.
Но человек, который должен поставить финальное Approved, уже вышел с работы.
Завтра.
Следующее утро, 09:24
Approval получен.
Заказ можно размещать.
Поставщику уходит письмо:
“Please proceed.”
Через несколько минут приходит ответ:
Unfortunately, the stock was allocated yesterday.
Оборудование всё ещё можно заказать.
Но теперь lead time — шесть недель.
Сколько стоили эти 23 часа?
На первый взгляд — нисколько.
Никто не сломал оборудование.
Не произошло cyberattack.
Не было штрафа.
Сотрудники получили ту же зарплату.
В бухгалтерской системе не появилась строка:
«Убыток от ожидания согласования — $X».
Поэтому для компании кажется, что ничего не произошло.
Но произошло.
Компания потеряла stock.
Срок поставки изменился.
Менеджеру нужно снова разговаривать с клиентом.
Procurement снова включается в процесс.
Инженер проверяет альтернативу.
Поставщик делает новый quotation.
Возможно, изменится цена.
Возможно, курс валюты.
Возможно, клиент не готов ждать шесть недель.
Один день ожидания создал несколько дней новой работы.
Мы умеем считать стоимость действия. Но удивительно плохо считаем стоимость бездействия.
У бизнеса есть огромная скрытая статья расходов — ожидание
Посмотрите на обычный рабочий день любой компании.
Кто-то ждёт:
approval.
PO.
бюджет.
подпись.
ответ Legal.
ответ IT.
ответ клиента.
ответ поставщика.
решение директора.
подтверждение Finance.
доступ к системе.
создания account.
согласования договора.
И самое интересное:
в каждый конкретный момент никто вроде бы не делает ничего неправильного.
Finance имеет право проверить.
Legal должен изучить договор.
CEO занят.
Procurement следует процедуре.
IT нужны дополнительные данные.
Каждый отдельный участник процесса ведёт себя рационально.
Но весь процесс вместе может быть катастрофически медленным.
Проблема не в том, сколько человек работает над задачей
Мы привыкли измерять работу через activity.
Сколько часов отработано?
Сколько tickets закрыто?
Сколько calls сделано?
Сколько quotations отправлено?
Сколько contracts обработано?
Но для бизнеса существует другая единица времени:
сколько времени прошло от появления возможности до принятия решения?
Представим два конкурента.
Обе компании получили одинаковое предложение от поставщика в понедельник утром.
У обеих есть деньги.
У обеих одинаковая техническая экспертиза.
У обеих одинаковая цена.
Компания A принимает решение за три часа.
Компания B — за четыре дня.
На бумаге они могут выглядеть одинаково эффективными.
Но на рынке это уже две совершенно разные компании.
Первая движется.
Вторая ждёт.
И здесь появляется метрика, которую редко считают: Cost of Waiting
Стоимость ожидания — это не просто зарплата сотрудников за время, пока они ничего не делают.
На самом деле она гораздо шире.
Допустим, решение задержалось на три дня.
За эти три дня может произойти следующее:
stock закончился;
цена изменилась;
валюта выросла;
discount истёк;
production slot занял другой заказчик;
специалист переключился на другой проект;
клиент начал переговоры с конкурентом;
deadline стал ближе;
логистика стала дороже;
команда вынуждена делать работу повторно.
Именно поэтому стоимость ожидания часто растёт нелинейно.
Первый час может стоить почти ничего.
Двадцать четвёртый — уже очень дорого.
Есть большая разница между “время выполнения” и “время прохождения”
Представим обычное согласование договора.
Legal реально работает над документом:
47 минут.
Finance:
22 минуты.
Procurement:
31 минуту.
CEO:
6 минут.
Итого фактической работы:
1 час 46 минут.
Но от момента получения договора до подписания прошло:
9 дней.
Где исчезли остальные восемь дней и двадцать два часа?
Нигде.
Они находились между людьми.
В inbox.
В очередях.
В ожидании встречи.
В словах:
«Посмотрю завтра».
«Нужно ещё согласовать».
«Напомните после обеда».
«Я думал, это уже подтвердили».
Вот почему ускорение самой работы не всегда ускоряет компанию.
AI может подготовить документ за 30 секунд. А человек будет согласовывать его три дня
Это один из самых интересных парадоксов нынешней автоматизации.
Компании инвестируют огромные деньги, чтобы сократить:
20 минут до 2 минут;
2 часа до 15 минут;
один день до одного часа.
AI пишет.
CRM автоматически распределяет.
ERP рассчитывает.
Workflow отправляет notification.
Dashboard обновляется в real time.
А затем результат попадает человеку.
И лежит в его inbox 17 часов.
Мы автоматизировали работу.
Но не автоматизировали решение.
В результате компания может иметь невероятно быстрые технологии и оставаться организационно медленной.
Самая медленная часть современной цифровой компании иногда находится не в системе. Она находится между двумя решениями.
Но давайте не совершать очевидную ошибку: скорость не означает отсутствие контроля
Можно прочитать всё это и решить:
«Значит, нужно убрать согласования».
Нет.
Некоторые approvals существуют по очень хорошим причинам.
Финансовый контроль нужен.
Cybersecurity review нужен.
Legal нужен.
Procurement нужен.
Technical validation нужен.
Особенно когда речь идёт о крупных контрактах, инфраструктуре, данных или значительных финансовых обязательствах.
Проблема начинается не тогда, когда решение проверяют.
Проблема начинается тогда, когда компания не знает, сколько времени должна занимать проверка и кто имеет право закончить её решением.
Это принципиальная разница.
У каждого важного решения должен быть владелец
Очень часто внутри компании можно найти пять человек, которые имеют право сказать:
«Я не согласен».
И ни одного, кто имеет право сказать:
«Решение принято. Двигаемся дальше».
Это создаёт странную организационную архитектуру.
Responsibility распределена.
Authority размыта.
Risk видят все.
Decision не принадлежит никому.
Тогда появляется бесконечный цикл:
Finance → Legal → Procurement → IT → Management → обратно Finance.
Каждый добавляет комментарий.
Документ становится всё лучше.
Решение — всё позже.
Попробуйте задать в компании один простой вопрос
Не:
«Кто участвует в согласовании?»
А:
«Кто конкретно должен принять окончательное решение?»
Имя.
Не department.
Не committee.
Не management.
Человек.
Если на этот вопрос невозможно быстро ответить — у процесса уже есть проблема.
Есть ещё один вид ожидания, который особенно дорого стоит: ожидание плохих новостей
Допустим, инженер в понедельник понимает:
проект, скорее всего, не будет завершён вовремя.
Но пока это не 100%.
Он ждёт.
Во вторник вероятность уже 70%.
Он сообщает менеджеру.
Менеджер хочет сначала найти решение.
Среда.
Поставщик подтверждает задержку.
В четверг информация доходит до директора.
В пятницу — до клиента.
Само событие произошло в понедельник.
Организация официально отреагировала в пятницу.
Компания потеряла четыре дня не из-за проблемы.
Она потеряла четыре дня из-за скорости движения информации и решений.
И это тоже Cost of Waiting.
Скорость компании определяется не скоростью её сотрудников
Это важно.
Быстрые сотрудники не обязательно создают быструю компанию.
Можно собрать очень сильную команду, где каждый отвечает на письма за десять минут, — и всё равно принимать решения неделями.
Почему?
Потому что организационная скорость определяется не тем, насколько быстро движутся люди.
Она определяется тем, насколько быстро задача проходит между людьми.
Именно в этих переходах обычно живёт ожидание.
Поэтому CEO стоит посмотреть не только на KPI, но и на очереди
Большинство dashboards показывают то, что произошло.
Revenue.
Margin.
Pipeline.
Tickets.
Projects.
Costs.
Но очень полезно было бы открыть другой dashboard:
Что сейчас ждёт решения?
Не просто список задач.
А:
что ждёт;
с какого момента;
кого ждёт;
почему;
каково финансовое или операционное последствие задержки;
когда отсутствие решения становится критическим.
Так руководитель увидит совершенно другую компанию.
Не компанию, которая работает.
А компанию, которая ждёт.
Можно начать вообще без новой IT-системы
Возьмите десять последних важных процессов.
Например:
закупку;
договор;
найм;
коммерческое предложение;
IT-проект;
оплату;
изменение цены;
выбор поставщика;
инцидент;
клиентскую эскалацию.
Для каждого восстановите timeline.
Когда процесс начался?
Когда реально выполнялась работа?
Когда он ждал?
Кого?
Сколько?
Почему?
Результат может оказаться неприятным.
Возможно, процесс длился десять дней, но реальной работы в нём было четыре часа.
Тогда у вас проблема не с productivity.
У вас проблема с flow.
И это совершенно разные проблемы
Если проблема — productivity, нужно сделать работу быстрее.
Автоматизировать.
Обучить.
Дать AI.
Улучшить систему.
Если проблема — flow, нужно изменить другое:
количество handoffs;
approval levels;
decision rights;
thresholds;
escalation rules;
ownership;
время реакции.
Очень многие компании пытаются решить вторую проблему инструментами для первой.
Покупают более быстрые технологии.
И получают более быстро выполненную задачу, которая затем быстрее попадает в очередь ожидания.
Что можно изменить практически
Для начала не нужен большой transformation project.
Можно установить несколько простых правил.
Первое — срок должен быть не только у задачи, но и у решения.
Если quotation нужно отправить в пятницу, нельзя оставлять approval с формулировкой:
«Как сможете, посмотрите».
У решения тоже должен быть deadline.
Второе — определить decision owner.
Кто имеет последнее слово?
Третье — установить финансовые thresholds.
Не каждый заказ на $1,000 должен проходить тот же путь, что контракт на $1 million.
Четвёртое — escalation должна происходить до deadline, а не после него.
Если решение должно быть принято за 24 часа, система не должна обнаружить проблему на 25-м.
Пятое — измерять не только execution time, но и waiting time.
Иногда одна эта цифра полностью меняет представление руководства о процессе.
Есть ещё один вопрос, который стоит задавать чаще
Когда кто-то говорит:
«Нам нужно больше времени для решения»,
спросите:
«Какую новую информацию мы ожидаем получить?»
Это очень полезный вопрос.
Потому что дополнительное время имеет смысл, если завтра появится новая информация.
Новый расчёт.
Заключение инженера.
Ответ клиента.
Legal opinion.
Новая цена.
Результат тестирования.
Но если завтра мы будем знать ровно то же, что знаем сегодня, то дополнительные 24 часа — это не анализ.
Это просто отсрочка решения.
16:42
Вернёмся к нашему заказу.
Оборудования на складе больше нет.
Менеджер нашёл альтернативу.
Она на 7% дороже.
Инженер снова проверил конфигурацию.
Клиенту объяснили изменение сроков.
Finance пересчитал экономику.
Procurement запросил новую цену.
Поставщик выпустил новый quotation.
Шесть человек снова работают над задачей, которая вчера уже была практически закончена.
В отчёте всё это будет выглядеть как работа.
И формально это действительно работа.
Но значительная её часть появилась только потому, что в 10:17 вчера утром компания не смогла вовремя принять одно решение.
Мы слишком долго считали стоимость людей. Возможно, пора считать стоимость времени между ними.
В следующую эпоху бизнеса преимущество получат не обязательно компании с самым большим количеством сотрудников.
Не обязательно те, у кого больше AI.
Не обязательно те, у кого самый дорогой ERP.
И даже не обязательно те, где отдельные сотрудники работают быстрее всех.
Преимущество могут получить организации, которые умеют быстро превращать:
информацию → в решение → решение → в действие.
Потому что рынку всё равно, сколько часов ваша команда обсуждала вопрос.
Рынок видит только момент, когда вы сделали выбор.
И поэтому следующий раз, когда важный документ будет лежать в inbox с пометкой “Waiting for approval”, возможно, стоит посмотреть на часы.
Не потому, что кто-то обязательно работает медленно.
А потому, что прямо сейчас может работать другой механизм:
стоимость ожидания.
И главный вопрос уже не:
«Сколько времени нам нужно, чтобы выполнить эту работу?»
А:
«Сколько нам стоит каждый час, пока мы её не двигаем дальше?»