6 моделей проектного бизнеса

Вступление: зачем нужна классификация моделей проектного бизнеса?

Проектный бизнес выглядит просто: нашёл заказ, собрал команду, сделал результат, получил оплату. На практике одна и та же «стройка» или «ремонт» может жить по разным правилам. Где-то компания держит на себе гарантию и сроки, где-то продаёт управление, где-то выполняет один вид работ как субподрядчик.

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

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

Модель 1. Генподряд «под ключ» с фиксированной ценой

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

Деньги в этой модели любят дисциплину. Кассовый разрыв легко появляется даже при полной загрузке: авансы ушли в материалы, по субподряду уже пора платить, заказчик задержал этап. Полезно держать отдельный контур контроля по каждому объекту и видеть, что оплачено, что потрачено, что «в пути». В блоге 101 есть разбор причин кассовых разрывов именно в строительных проектах. Кассовые разрывы в строительных проектах

Условный пример генподряда: объект идёт по плану, прораб закрывает работы, заказчик доволен. Внезапно всплывает пересогласование: меняются материалы, добавляются мелкие «хотелки», растёт смета, команда продолжает закупать. Если изменения не фиксируются сразу, прибыль растворяется.

Что стоит заранее решить в генподряде: как оформляются допработы, как часто сверяется бюджет по статьям, кто может тратить деньги, где лежит «источник правды» по платежам. С этим проще держать маржу и спокойно вести переговоры о цене. Про принципы ценообразования в ремонте и отделке тоже есть отдельный материал. Ценообразование в ремонте и отделке

Модель 2. Субподряд по специализации

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

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

Условный пример субподряда: бригада приехала на объект, готовность не соответствует обещаниям, фронта нет, два дня простоя. Вроде мелочь, только по факту это прямые потери, которые редко удаётся выставить отдельной строкой. В таких точках помогает учёт фактических затрат по проектам и понимание, где начинается работа «в минус».

Ещё одна зона риска — подотчёт и мелкие закупки. Когда в команде несколько мастеров и каждый покупает расходники, деньги уходят быстро. Нужна привычка фиксировать траты сразу и привязывать к объекту, иначе прибыль по заказам будет жить в догадках.

Модель 3. Управление проектом за вознаграждение

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

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

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

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

Модель 4. Дизайн + реализация как единый продукт

Суть модели: вы продаёте комплекс — проектирование, комплектацию, стройку, авторский надзор. Для заказчика это удобно: меньше подрядчиков, выше согласованность решений, понятнее ответственность.

Главный риск — продавать дизайн и стройку как одно обещание, при этом считать экономику раздельно. Дизайн-команда может работать в ноль «ради стройки», стройка может уйти в минус из-за доработок проекта, комплектация может съесть маржу на логистике и возвратах. Здесь нужна единая финансовая модель на проект с понятными статьями доходов и расходов.

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

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

Модель 5. Инжиниринг и комплектация (EPC-логика)

Суть модели: вы берёте на себя инженерную часть, поставку оборудования и монтаж, часто вместе с пусконаладкой. EPC — это проектирование, закупки и строительство под ответственностью одного исполнителя. Здесь рассматривается близкая логика инжиниринга, поставки и монтажа; конкретный объём и ответственность задаёт договор. Проекты крупнее, документов больше, циклы поставок длиннее. Ошибка в спецификации или сроке поставки может привести к срыву этапов и договорным штрафам.

В EPC-логике деньги «размазываются» по времени. Закупка может занимать месяцы, авансы поставщикам уходят заранее, работы оплачиваются позже, заказчик принимает этапы по документам. Поэтому ключевой управленческий навык — видеть, где зависли авансы, что уже закрыто актами, какие обязательства впереди.

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

Когда проектов несколько, помогает разделять проектные расходы и расходы компании. В 101 это часто связывают с Фондом компании и аналитикой на уровне бизнеса, чтобы понимать, где проблема: в конкретном объекте или в постоянных тратах.

Модель 6. Пакетные проекты и стандартизированные услуги

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

Плюс — предсказуемость. Минус — опасность «просесть» на исключениях. Один нестандартный объект с кривыми стенами и странными коммуникациями может съесть маржу, если пакет продавался без диагностического этапа и правил по допработам.

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

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

Финальный блок: как выбрать модель и зачем подключать Приложение 101 с веб-версией?

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

Чтобы не выбирать «по настроению», пройдите по вопросам:

• Кто подписывает договор с заказчиком и кто будет крайним по срокам и качеству?
• Через чей счёт проходят материалы, авансы, выплаты людям и субподряду?
• Как считается цена: фикс за результат, поэтапно, за время команды, процент за управление?
• Какие правила по изменениям объёма: допработы, замены материалов, пересогласования?

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

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

Если хочется посмотреть, как это ляжет на вашу модель проектного бизнеса, проще всего начать с презентации и разбора задач компании. Приложение 101 и веб-версия дают связку «поле + офис», которая закрывает боль проектных команд: деньги проходят через много рук, значит нужен один источник правды по проекту.