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

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

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

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

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

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

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

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

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

После непростого, но предельно честного разговора о финансовом положении, топ-менеджеру была предложена прозрачная мотивационная схема: минимальный фикс + KPI, жестко привязанный к маржинальности новых контрактов.

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

Интересно ваше мнение: сталкивались ли вы в своей практике с ситуацией, когда личные компромиссы с сотрудниками («неудобно уволить», «он же старается») начинали приносить компании вполне осязаемые финансовые убытки? Как решали этот баг?