Содержание:
Что такое модель управления компанией?
Модель управления задаёт три вещи: кто принимает решения, как передаётся ответственность, как выглядит контроль выполнения задач. Это скелет бизнеса, который держит форму, когда нагрузка растёт.
Возьмём типовую историю из стройки. Было два прораба и один объект, руководитель держал всё в голове. Потом стало пять объектов, закупки по разным точкам, авансы и частичные оплаты, бригады пересекаются. Если модель не оформлена, управление превращается в бесконечные уточнения и конфликтующие ожидания.
Ещё один маркер: команда «живёт в переписке». Пишут много, договорённости разъезжаются, а из этого часто вырастает микроменеджмент и привычка согласовывать каждую мелочь. В блоге 101 есть отдельный разбор, как микроменеджмент выглядит в строительстве и почему он так быстро съедает время руководителя.
Структурные модели управления компанией
Самая понятная рамка — структура. Она отвечает за распределение людей по ролям и за то, кому кто подчиняется. На этом уровне легко увидеть, почему решения застревают.
Линейная модель держится на прямой вертикали: мастер → прораб → руководитель. Она хороша для небольшой команды, где задачи однородные, а руководитель держит контекст. В момент роста появляется типовой побочный эффект: руководитель начинает быть «диспетчером» по всем вопросам.
Функциональная модель собирает специалистов по функциям: снабжение, производство, продажи, финансы. Выигрыш — стандарты и профессиональная глубина. Риск — объектам сложнее получать приоритет, если функции начинают жить «каждая про своё».
Дивизиональная модель похожа на «мини-компании» внутри компании: по регионам, направлениям работ, продуктам. Она помогает, когда у направлений разные рынки и разные процессы. При этом неизбежно приходится договариваться о единых правилах учёта, качества и финансов.
Если хочется разложить по полкам, какие структуры бывают и как их собирать под проектную работу, пригодится статья 101: https://web2.101-group.ru/blog/struktura-upravleniya-proektom.
Проектная и матричная модели
Если бизнес живёт в проектах (объектах), организационная схема начинает работать иначе. Важнее становится не «отдел», а проектная команда и ответственность за результат проекта: сроки, качество, маржа, денежный разрыв.
Проектная модель строится вокруг руководителей проектов и команд под каждый объект. Она понятна для стройки и ремонта: есть объект, есть бюджет, есть график, есть ответственные. Цена за ясность — нужно уметь распределять ресурсы между проектами, чтобы не было войны за людей и технику.
Матричная модель возникает, когда функциональные отделы остаются (снабжение, финансы, инженерия), при этом проекты требуют отдельного управления. В матрице у сотрудника два «вектора»: функциональный руководитель отвечает за стандарт работы, проектный руководитель отвечает за результат на объекте. Здесь важно заранее договориться, кто решает спорные вопросы приоритетов.
Про проектный подход в строительстве и то, как технологии помогают удерживать сроки, договорённости и контроль, можно почитать в материале 101.
Процессная модель
Процессная модель отвечает на вопрос «как именно тут принято делать работу». Она строится вокруг повторяемых цепочек: лид → договор → запуск объекта → закупки → работы → закрывающие документы → гарантия.
В небольшом бизнесе процессы живут в голове у сильных сотрудников. В момент роста это превращается в зависимость от отдельных людей: ушёл мастер — ушёл порядок. Процессная модель помогает снять зависимость: правила остаются в компании.
Важно не путать процессность с бюрократией. Процесс — это минимальный набор стандартов, который бережёт деньги и сроки. Один чек-лист по закупкам иногда экономит больше, чем лишний контролёр.
Хороший ориентир: если процессы уже есть, их легко «приземлить» в инструментах проектного управления. Для выбора инструментов под реальную работу в проектах полезен разбор 101.
Управление по целям и показателям
Когда структура и процессы собраны, возникает следующий слой: управление по целям. Это про то, как компания выбирает приоритеты и как проверяет, что движется туда, куда нужно.
KPI-подход удобен там, где работа повторяемая и есть понятный стандарт: скорость обработки заявок, конверсия, соблюдение графика, доля перерасхода по объектам, дебиторка. Он требует качественных данных, иначе KPI превращаются в игру «как нарисовать отчёт».
OKR-подход лучше ложится на изменения: выход в новый сегмент, упаковка услуги, перестройка снабжения, внедрение управленческого учёта. В OKR полезно держать ограниченное число целей, иначе команда тонет в «параллельных инициативах».
В проектном бизнесе цели обычно упираются в управленческий учёт: нужно видеть прибыльность и маржинальность по каждому проекту, управлять авансами, понимать, где деньги зависли. Если эта тема актуальна, пригодится статья 101 про организацию управленческого учёта.
Гибкие подходы (Agile, Kanban)
Agile часто воспринимают как набор встреч. В реальности это способ управлять неопределённостью: короткие циклы, частые проверки результата, гибкое планирование.
В стройке неопределённости хватает: скрытые работы, задержки материалов, изменения от заказчика, пересогласования. Тут полезно брать не «весь Agile целиком», а рабочие элементы. Kanban-доска по объекту, недельное планирование, ограничение параллельных задач у прораба дают эффект быстро.
Есть ловушка: попытка сделать гибкий подход без договорённостей о роли руководителя. Если руководитель продолжает согласовывать каждую мелочь, гибкость превращается в суету. Тогда снова всплывает тема микроменеджмента и доверия к прорабам.
Если хочется увидеть, какие принципы Agile реально применимы в строительстве, есть разбор 101.
Как выбрать модель под этап развития компании?
Одна и та же модель по-разному работает на разных стадиях. Компания на трёх людях не потянет «полный набор» процессов, отчётов и комитетов. Компания на тридцати людях развалится, если всё держится на личной памяти собственника.
Полезно смотреть на управление через этапы развития. У 101 есть статья про эволюцию бизнеса и 6 этапов развития компании. Там хорошо видно, что переходы между этапами почти всегда требуют пересборки правил и ролей.
Внутри одного этапа можно жить годами, если не замечать сигналы. Классическая ситуация: компания выросла, роли формально есть, при этом решения снова в одном человеке. Хочется «делегировать», при этом нет границ: до какой суммы прораб решает сам, какие закупки идут без согласования, какие отчёты обязательны.
Чтобы выбрать модель, удобно пройти короткую самопроверку и честно ответить: где чаще всего ломается работа — в ответственности, в коммуникациях, в деньгах, в сроках? Что из этого даёт компании основной убыток?
Шаг 1. Зафиксируйте три повторяющиеся проблемы, которые стоят денег (перерасход, переделки, простой, кассовый разрыв).
Шаг 2. Найдите место, где проблема рождается: структура (непонятно кто решает), процесс (нет стандарта), цели (нет критерия «хорошо/плохо»), данные (не видно цифр).
Шаг 3. Выберите модель как «лекарство»: структурную, процессную, проектную, по показателям. Одной модели обычно достаточно как фокуса на ближайшие 2–3 месяца.
Шаг 4. Закрепите правила в инструментах: отчётность, согласования, деньги, доступы. Если правила живут в чатах, они исчезают.
Как закрепить модель инструментами?
Любая модель управления упирается в данные. В проектном бизнесе главный риск часто сидит в финансах: подотчёт, авансы, перерасход, задержки оплат, «мелкие» покупки без подтверждений. Именно поэтому управлять одними задачами и чатами мало.
В блоге 101 мы часто возвращаемся к мысли: проект становится управляемым, когда видно финансовую картину по объекту и понятно, кто за что отвечает. Посмотреть, как выстраивается терминология и логика учёта, можно в статье про финансовый учёт доходов и расходов.
Если нужна практическая сторона проектного управления — как собрать набор инструментов и не утонуть в сервисах — пригодится материал 101 про инструменты управления проектами и связку управления работами с финансовым контролем.
Когда модель управления выбрана, остаётся «прошить» её в ежедневную работу: отчёты, согласования, правила по статьям расходов, дисциплина по подотчёту. Тут полезно иметь единое место, где события фиксируются сразу и становятся общей правдой для команды. В Приложении 101 это строится вокруг проекта и финансовых событий, а в PRO+ появляется более плотный контроль показателей и возможностей для управленческой аналитики.
Признаки, что модель пора менять
Менять модель управления стоит не по календарю, а по симптомам. Часто кажется, что «надо дожать дисциплину», при этом проблема уже в конструкции.
- Решения застревают на руководителе: без него ничего не двигается, даже если задачи простые.
- В компании много коммуникаций, мало ясных договорённостей: по одному и тому же вопросу спорят снова и снова.
- Сроки едут из месяца в месяц, при этом причины повторяются: закупки, переделки, ожидания людей.
- По финансам туман: прибыльность проекта понятна задним числом, перерасход «вылезает» в конце.
- Команда растёт, роли формально есть, ответственности нет: каждый «помогает», владельца результата не видно.
Если узнал свою ситуацию, начни с одного слоя: структура, процессы, цели, учёт. Дальше добавляй следующий слой. В проектном бизнесе хороший порядок такой: сначала прозрачность по деньгам, потом правила ответственности, потом показатели и ритм управления. Это спокойнее для команды и надёжнее для результата.