Чем больше я работаю, тем чаще замечаю одну вещь: компании редко принимают по-настоящему плохие решения. Гораздо чаще они принимают усталые.

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

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

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

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

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

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

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

Усталые решения почти всегда выглядят рационально в моменте. Они экономят время, снижают напряжение, позволяют быстро двигаться дальше.

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

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