«Модель управления» звучит как тема для бизнес-школы. На практике это ответ на приземлённый вопрос: кто принимает решения, по каким правилам команда работает, где видно результат, как растут деньги.
Проблемы обычно начинаются одинаково. Вчера хватало пары созвонов и чата. Сегодня объектов стало больше, людей стало больше, задач стало больше, ошибок стало больше. Руководитель снова в операционке, согласования растут, сроки расползаются.
Разговор о моделях управления нужен не ради модных терминов. Он нужен, чтобы выбрать опоры: структуру, ритм, показатели, правила ответственности. Тогда масштабирование выглядит как управляемый процесс, не как лотерея.
- Зачем компании модель управления
- Структурные модели: линейная, функциональная, дивизиональная
- Проектная и матричная модели
- Процессная модель
- Управление по целям и показателям
- Гибкие подходы: Agile, Kanban
- Как выбрать модель под этап развития
- Как закрепить модель инструментами
- Признаки, что модель пора менять
Зачем компании модель управления
Модель управления задаёт три вещи: где живут решения, как передаётся ответственность, как выглядит контроль без ручного «дожима». Это скелет бизнеса, который держит форму, когда нагрузка растёт.
Возьмём типовую историю из стройки. Было два прораба и один объект, руководитель держал всё в голове. Потом стало пять объектов, закупки по разным точкам, авансы и частичные оплаты, бригады пересекаются. Если модель не оформлена, управление превращается в бесконечные уточнения и конфликтующие ожидания.
Ещё один маркер: команда «живёт в переписке». Пишут много, договорённости разъезжаются, а из этого часто вырастает микроменеджмент и привычка согласовывать каждую мелочь. В блоге 101 есть отдельный разбор, как микроменеджмент выглядит в строительстве и почему он так быстро съедает время руководителя: https://101-app.com/blog/micromanagement-in-construction-and-renovation.
Структурные модели: линейная, функциональная, дивизиональная
Самая понятная рамка — структура. Она отвечает за распределение людей по ролям и за то, кому кто подчиняется. На этом уровне легко увидеть, почему решения застревают.
Линейная модель держится на прямой вертикали: мастер → прораб → руководитель. Она хороша для небольшой команды, где задачи однородные, а руководитель держит контекст. В момент роста появляется типовой побочный эффект: руководитель начинает быть «диспетчером» по всем вопросам.
Функциональная модель собирает специалистов по функциям: снабжение, производство, продажи, финансы. Выигрыш — стандарты и профессиональная глубина. Риск — объектам сложнее получать приоритет, если функции начинают жить «каждая про своё».
Дивизиональная модель похожа на «мини-компании» внутри компании: по регионам, направлениям работ, продуктам. Она помогает, когда у направлений разные рынки и разные процессы. При этом неизбежно приходится договариваться о единых правилах учёта, качества и финансов.
Если хочется разложить по полкам, какие структуры бывают и как их собирать под проектную работу, пригодится статья 101: https://101-app.com/blog/struktura-upravleniya-proektom.
Проектная и матричная модели
Если бизнес живёт в проектах (объектах), организационная схема начинает работать иначе. Важнее становится не «отдел», а проектная команда и ответственность за результат проекта: сроки, качество, маржа, денежный разрыв.
Проектная модель строится вокруг руководителей проектов и команд под каждый объект. Она понятна для стройки и ремонта: есть объект, есть бюджет, есть график, есть ответственные. Цена за ясность — нужно уметь распределять ресурсы между проектами, чтобы не было войны за людей и технику.
Матричная модель возникает, когда функциональные отделы остаются (снабжение, финансы, инженерия), при этом проекты требуют отдельного управления. В матрице у сотрудника два «вектора»: функциональный руководитель отвечает за стандарт работы, проектный руководитель отвечает за результат на объекте. Здесь важно заранее договориться, кто решает спорные вопросы приоритетов.
Про проектный подход в строительстве и то, как технологии помогают удерживать сроки, договорённости и контроль, можно почитать в материале 101: https://101-app.com/blog/project-management-technologies.
Процессная модель
Процессная модель отвечает на вопрос «как именно тут принято делать работу». Она строится вокруг повторяемых цепочек: лид → договор → запуск объекта → закупки → работы → закрывающие документы → гарантия.
В небольшом бизнесе процессы живут в голове у сильных сотрудников. В момент роста это превращается в зависимость от отдельных людей: ушёл мастер — ушёл порядок. Процессная модель помогает снять зависимость: правила остаются в компании.
Важно не путать процессность с бюрократией. Процесс — это минимальный набор стандартов, который бережёт деньги и сроки. Один чек-лист по закупкам иногда экономит больше, чем лишний контролёр.
Хороший ориентир: если процессы уже есть, их легко «приземлить» в инструментах проектного управления. Для выбора инструментов под реальную работу в проектах полезен разбор 101: https://101-app.com/blog/sistema-upravleniya-proektami-kak-vybrat.
Управление по целям и показателям
Когда структура и процессы собраны, возникает следующий слой: управление по целям. Это про то, как компания выбирает приоритеты и как проверяет, что движется туда, куда нужно.
KPI-подход удобен там, где работа повторяемая и есть понятный стандарт: скорость обработки заявок, конверсия, соблюдение графика, доля перерасхода по объектам, дебиторка. Он требует качественных данных, иначе KPI превращаются в игру «как нарисовать отчёт».
OKR-подход лучше ложится на изменения: выход в новый сегмент, упаковка услуги, перестройка снабжения, внедрение управленческого учёта. В OKR полезно держать ограниченное число целей, иначе команда тонет в «параллельных инициативах».
В проектном бизнесе цели обычно упираются в управленческий учёт: нужно видеть прибыльность и маржинальность по каждому проекту, управлять авансами, понимать, где деньги зависли. Если эта тема актуальна, пригодится статья 101 про организацию управленческого учёта: https://101-app.com/blog/upravlencheskii-uchet-v-proektnom-biznese.
Гибкие подходы: Agile, Kanban
Agile часто воспринимают как набор встреч. В реальности это способ управлять неопределённостью: короткие циклы, частые проверки результата, гибкое планирование.
В стройке неопределённости хватает: скрытые работы, задержки материалов, изменения от заказчика, пересогласования. Тут полезно брать не «весь Agile целиком», а рабочие элементы. Kanban-доска по объекту, недельное планирование, ограничение параллельных задач у прораба дают эффект быстро.
Есть ловушка: попытка сделать гибкий подход без договорённостей о роли руководителя. Если руководитель продолжает согласовывать каждую мелочь, гибкость превращается в суету. Тогда снова всплывает тема микроменеджмента и доверия к прорабам.
Если хочется увидеть, какие принципы Agile реально применимы в строительстве, есть разбор 101: https://101-app.com/blog/agile-in-construction.
Как выбрать модель под этап развития
Одна и та же модель по-разному работает на разных стадиях. Компания на трёх людях не потянет «полный набор» процессов, отчётов и комитетов. Компания на тридцати людях развалится, если всё держится на личной памяти собственника.
Полезно смотреть на управление через этапы развития. У 101 есть статья про эволюцию бизнеса и 6 этапов развития компании: https://101-app.com/blog/six-stages-of-company-development. Там хорошо видно, что переходы между этапами почти всегда требуют пересборки правил и ролей.
Внутри одного этапа можно жить годами, если не замечать сигналы. Классическая ситуация: компания выросла, роли формально есть, при этом решения снова в одном человеке. Хочется «делегировать», при этом нет границ: до какой суммы прораб решает сам, какие закупки идут без согласования, какие отчёты обязательны.
Чтобы выбрать модель, удобно пройти короткую самопроверку и честно ответить: где чаще всего ломается работа — в ответственности, в коммуникациях, в деньгах, в сроках? Что из этого даёт компании основной убыток?
Шаг 1. Зафиксируй три повторяющиеся проблемы, которые стоят денег (перерасход, переделки, простой, кассовый разрыв).
Шаг 2. Найди место, где проблема рождается: структура (непонятно кто решает), процесс (нет стандарта), цели (нет критерия «хорошо/плохо»), данные (не видно цифр).
Шаг 3. Выбери модель как «лекарство»: структурную, процессную, проектную, по показателям. Одной модели обычно достаточно как фокуса на ближайшие 2–3 месяца.
Шаг 4. Закрепи правила в инструментах: отчётность, согласования, деньги, доступы. Если правила живут в чатах, они исчезают.
Как закрепить модель инструментами
Любая модель управления упирается в данные. В проектном бизнесе главный риск часто сидит в финансах: подотчёт, авансы, перерасход, задержки оплат, «мелкие» покупки без подтверждений. Именно поэтому управлять одними задачами и чатами мало.
В блоге 101 мы часто возвращаемся к мысли: проект становится управляемым, когда видно финансовую картину по объекту и понятно, кто за что отвечает. Посмотреть, как выстраивается терминология и логика учёта, можно в статье про финансовый учёт доходов и расходов: https://101-app.com/blog/financial-accounting-of-income-and-expenses.
Если нужна практическая сторона проектного управления — как собрать набор инструментов и не утонуть в сервисах — пригодится материал 101 про инструменты управления проектами и связку управления работами с финансовым контролем: https://101-app.com/blog/instrumenty-upravleniya-proektami.
Когда модель управления выбрана, остаётся «прошить» её в ежедневную работу: отчёты, согласования, правила по статьям расходов, дисциплина по подотчёту. Тут полезно иметь единое место, где события фиксируются сразу и становятся общей правдой для команды. В Приложении 101 это строится вокруг проекта и финансовых событий, а в PRO+ появляется более плотный контроль показателей и возможностей для управленческой аналитики.
Признаки, что модель пора менять
Менять модель управления стоит не по календарю, а по симптомам. Часто кажется, что «надо дожать дисциплину», при этом проблема уже в конструкции.
- Решения застревают на руководителе: без него ничего не двигается, даже если задачи простые.
- В компании много коммуникаций, мало ясных договорённостей: по одному и тому же вопросу спорят снова и снова.
- Сроки едут из месяца в месяц, при этом причины повторяются: закупки, переделки, ожидания людей.
- По финансам туман: прибыльность проекта понятна задним числом, перерасход «вылезает» в конце.
- Команда растёт, роли формально есть, ответственности нет: каждый «помогает», владельца результата не видно.
Если узнал свою ситуацию, начни с одного слоя: структура, процессы, цели, учёт. Дальше добавляй следующий слой. В проектном бизнесе хороший порядок такой: сначала прозрачность по деньгам, потом правила ответственности, потом показатели и ритм управления. Это спокойнее для команды и надёжнее для результата.