Вступление: зачем нужна классификация моделей проектного бизнеса
Проектный бизнес выглядит просто: нашёл заказ, собрал команду, сделал результат, получил оплату. На практике одна и та же «стройка» или «ремонт» может жить по разным правилам. Где-то компания держит на себе гарантию и сроки, где-то продаёт управление, где-то выполняет один вид работ как субподрядчик.
Модель проектного бизнеса удобно описывать через три вопроса. Кто отвечает перед заказчиком за результат. Кто держит деньги и через чьи руки проходят материалы, авансы, подотчёт. За что именно платит заказчик: за фиксированный объём, за время команды, за управление, за этапы, за комплектацию.
Эта классификация полезна в момент, когда проектов становится больше одного и решения «по ощущениям» перестают выдерживать нагрузку. У тебя растёт оборот, становится больше людей и контрагентов, а прибыль начинает теряться в деталях. В блоге 101 этот переход хорошо описан в статье про управление проектным бизнесом: там фокус на целях, плане, инструментах и контроле бюджета. https://101-app.com/blog/project-business-management
Содержание:
- Вступление: зачем нужна классификация моделей проектного бизнеса
- Модель 1. Генподряд «под ключ» с фиксированной ценой
- Модель 2. Субподряд по специализации
- Модель 3. Управляющий подряд (техзаказчик) за вознаграждение
- Модель 4. Дизайн + реализация как единый продукт
- Модель 5. Инжиниринг и комплектация (EPC-логика)
- Модель 6. Пакетные проекты и стандартизированные услуги
- Финальный блок: как выбрать модель и зачем подключать Приложение 101 с веб-версией
Модель 1. Генподряд «под ключ» с фиксированной ценой
Суть модели: ты подписываешь договор на результат и берёшь на себя координацию всех работ. Заказчик платит за готовый объект или за этапы, внутри которых уже твоя ответственность — люди, материалы, субподрядчики, контроль качества, срок.
Деньги в этой модели любят дисциплину. Кассовый разрыв легко появляется даже при полной загрузке: авансы ушли в материалы, по субподряду уже пора платить, заказчик задержал этап. Полезно держать отдельный контур контроля по каждому объекту и видеть, что оплачено, что потрачено, что «в пути». В блоге 101 есть разбор причин кассовых разрывов именно в строительных проектах. https://101-app.com/blog/cash-gap-in-construction
Ситуация из жизни генподряда: объект идёт по плану, прораб закрывает работы, заказчик доволен. Внезапно всплывает пересогласование: меняются материалы, добавляются мелкие «хотелки», растёт смета, команда продолжает закупать. Если изменения не фиксируются сразу, прибыль растворяется.
Что стоит заранее решить в генподряде: как оформляются допработы, как часто сверяется бюджет по статьям, кто может тратить деньги, где лежит «источник правды» по платежам. С этим проще держать маржу и спокойно вести переговоры о цене. Про принципы ценообразования в ремонте и отделке тоже есть отдельный материал. https://101-app.com/blog/pricing-in-repairs
Модель 2. Субподряд по специализации
Суть модели: ты делаешь один вид работ и входишь в чужой проект. Часто это инженерка, штукатурка, электрика, фасады, кровля, отдельные этапы отделки. Договор обычно проще, цикл короче, контроль результата понятнее.
Плюс субподряда — фокус. Минус — зависимость от чужого календаря и чужой платёжной дисциплины. Если у генподрядчика поехали сроки или бюджет, твои деньги тоже начинают задерживаться. Поэтому в субподряде важны правила по авансам, актированию и приёмке этапов.
Ситуация из субподряда: бригада приехала на объект, готовность не соответствует обещаниям, фронта нет, два дня простоя. Вроде мелочь, только по факту это прямые потери, которые редко удаётся выставить отдельной строкой. В таких точках помогает учёт фактических затрат по проектам и понимание, где начинается работа «в минус».
Ещё одна зона риска — подотчёт и мелкие закупки. Когда в команде несколько мастеров и каждый покупает расходники, деньги уходят быстро. Нужна привычка фиксировать траты сразу и привязывать к объекту, иначе прибыль по заказам будет жить в догадках.
Модель 3. Управляющий подряд (техзаказчик) за вознаграждение
Суть модели: ты продаёшь управление. Компания организует календарь, контролирует подрядчиков, ведёт документы, следит за качеством, помогает заказчику принимать решения. Деньги за работы и материалы проходят напрямую между заказчиком и исполнителями, твой доход — фикс или процент за управление.
В этой модели важно формализовать границы ответственности. Что считается «управлением», какие метрики используются (срок, бюджет, качество), как принимаются решения по изменениям. Без этого заказчик будет ожидать, что управляющий подряд возьмёт на себя ещё и гарантию результата по чужим рукам.
Ситуация техзаказчика: заказчик выбрал подрядчика «подешевле», тот сорвал этап и пропал. Управляющий подряд остаётся на объекте и вытаскивает проект, хотя формально не подписывал договор на работы. Спасает заранее прописанный регламент: как выбираются подрядчики, какие документы обязательны, как фиксируются отклонения и претензии.
Сильная сторона модели — масштабирование через процессы: можно вести больше проектов меньшей командой, если управленческий учёт и отчётность работают как система. База по проектному управлению, ролям и метрикам разобрана в статье «Основы управления проектами для предпринимателя». https://101-app.com/blog/osnovy-upravleniya-proektami-dlya-predprinimatelya
Модель 4. Дизайн + реализация как единый продукт
Суть модели: ты продаёшь комплекс — проектирование, комплектацию, стройку, авторский надзор. Для заказчика это удобно: меньше подрядчиков, выше согласованность решений, понятнее ответственность.
Главный риск — продавать дизайн и стройку как одно обещание, при этом считать экономику раздельно. Дизайн-команда может работать в ноль «ради стройки», стройка может уйти в минус из-за доработок проекта, комплектация может съесть маржу на логистике и возвратах. Здесь нужна единая финансовая модель на проект с понятными статьями доходов и расходов.
Ситуация из дизайн+реализации: заказчик согласовал визуализации, потом на объекте выяснилось, что часть решений конфликтует с реальными размерами. Начинаются переделки, сроки сдвигаются, закупки уже сделаны. Если все изменения проходят «в чате», деньги начнут расходиться с договором. Если изменения фиксируются как события проекта, управлять проще.
Отдельная тема — договорная структура: что входит в базовый объём, как считается комплектация, как учитываются изменения по материалам, кто отвечает за поставщиков. Когда эти правила заданы, команда меньше спорит про «кто это должен» и чаще занимается работой.
Модель 5. Инжиниринг и комплектация (EPC-логика)
Суть модели: ты берёшь на себя инженерную часть, поставку оборудования и монтаж, часто вместе с пусконаладкой. Проекты крупнее, документов больше, циклы поставок длиннее. Ошибка в спецификации или сроке поставки быстро превращается в срыв этапов и штрафы.
В EPC-логике деньги «размазываются» по времени. Закупка может занимать месяцы, авансы поставщикам уходят заранее, работы оплачиваются позже, заказчик принимает этапы по документам. Поэтому ключевой управленческий навык — видеть, где зависли авансы, что уже закрыто актами, какие обязательства впереди.
Ситуация из инжиниринга: поставщик подтвердил срок, потом перенёс отгрузку. Монтажная бригада простаивает, заказчик требует объяснений, план рушится. В таких проектах важно держать отдельный контроль по договорам и предоплатам, плюс регулярно пересобирать прогноз движения денег.
Когда проектов несколько, помогает разделять проектные расходы и расходы компании. В 101 это часто связывают с Фондом компании и аналитикой на уровне бизнеса, чтобы понимать, где проблема: в конкретном объекте или в постоянных тратах.
Модель 6. Пакетные проекты и стандартизированные услуги
Суть модели: ты упаковываешь проект в повторяемый продукт. Это может быть «ремонт санузла», «электрика под ключ», «черновая отделка по проекту», «комплектация кухни». Цена и состав работ заранее стандартизированы, решения повторяются, команда работает по шаблонам.
Плюс — предсказуемость. Минус — опасность «просесть» на исключениях. Один нестандартный объект с кривыми стенами и странными коммуникациями может съесть маржу, если пакет продавался без диагностического этапа и правил по допработам.
Ситуация из пакетов: менеджер продал «фикс», замерщик на объекте увидел дополнительные работы, прораб начал делать «чтобы не ругаться», потом возник спор по оплате. Пакетная модель держится на трёх вещах: чётких границах, понятном процессе согласования изменений, учёте фактических затрат по проекту.
Чтобы пакеты росли, нужен контроль себестоимости. Когда ты знаешь, сколько реально стоят этапы, можно улучшать продукт: менять технологию, пересобирать комплектацию, точнее считать труд. Если себестоимость живёт в головах, масштабирование будет упираться в людей.
Финальный блок: как выбрать модель и зачем подключать Приложение 101 с веб-версией
Выбор модели проектного бизнеса лучше начинать с честного ответа себе: где ты хочешь быть в цепочке и за что готов отвечать деньгами. Генподряд даёт контроль и крупный чек, забирает риски. Субподряд даёт фокус и скорость, добавляет зависимость от чужих графиков. Управляющий подряд продаёт мозги и процессы, требует ясных границ ответственности. Пакеты дают повторяемость, требуют жёсткого контроля исключений.
Чтобы не выбирать «по настроению», пройдись по вопросам:
- Кто подписывает договор с заказчиком и кто будет крайним по срокам и качеству.
- Через чей счёт проходят материалы, авансы, выплаты людям и субподряду.
- Как считается цена: фикс за результат, поэтапно, за время команды, процент за управление.
- Какие правила по изменениям объёма: допработы, замены материалов, пересогласования.
Дальше вопрос инструментов. Когда проектов больше одного, управление держится на системе учёта: каждый объект как отдельный проект, прозрачные расчёты с подрядчиками и поставщиками, понятный баланс денег по работам и материалам. Это как раз фокус Приложения 101: оно показывает финансовую картину проекта в реальном времени, помогает учитывать контрагентов, авансы, отчёты, акты и рентабельность.
Важно, что у Приложения 101 есть полноценная веб-версия. На мобильном удобно фиксировать события на объекте, в веб-версии проще разбирать движение денег, выплаты, авансы и аналитику, когда нужно спокойно принять управленческое решение.
Если хочется посмотреть, как это ляжет на твою модель проектного бизнеса, проще всего начать с демо и разбором настройки под процессы компании. Приложение 101 и веб-версия дают связку «поле + офис», которая закрывает боль проектных команд: деньги проходят через много рук, значит нужен один источник правды по проекту.

