Смета живёт отдельно от сделки: как связать расчёт с продажей и увидеть маржу проекта

У отделочника воронка в CRM показывает сумму договора по каждому объекту. А смета к этому договору живёт в отдельном файле Excel, и с карточкой сделки она никак не сведена. Итог по объекту в рублях — сколько проект реально принёс после материалов, работы бригады и доставки — остаётся закрытым до сдачи работ.

Собственник видит выручку и не видит прибыль по объекту

Когда смета и факт не сверяются по каждому проекту, убыток по сделке обнаруживается уже по факту выполненных работ — на этом шаге на цифру повлиять нельзя (по данным профильного издания об управленческом учёте в строительстве). Бригада отработала, материалы закуплены, акты подписаны — и только теперь видно, что объект отработал в минус.

По оценке одного зарубежного источника про подрядчиков, около 65% небольших компаний ведут учёт затрат вручную — в таблицах и на бумажных сметах — и не считают маржу по каждому объекту (цифра по рынку США, под наши реалии беру как ориентир). Механика везде одинаковая: пока затраты и цена продажи лежат в разных местах, ответ на вопрос «сколько заработал этот объект» собирается вручную и с задержкой.

Механика связки: расчёт, сделка, факт

CRM умеет считать маржу по сделке из трёх введённых величин — себестоимости, дополнительных расходов (логистика, комиссии, налоги, доставка) и цены продажи. Результат сохраняется в рублях и процентах прямо в таймлайне сделки (по документации Bitrix24). Расчёт затрат при этом физически привязан к конкретной сделке и к сотруднику, который её ведёт.

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

План-факт по этапам, а не одним разбором в конце

Валовая прибыль проекта — это разница между объёмом работ по актам и их реальной себестоимостью. При отклонении факта от сметы прибыль падает (по данным сервиса управленческого учёта). Пример из того же источника: земляные работы заложены в смету на 500 тыс. ₽, по факту вышли 550 тыс. ₽ из-за скального грунта. Пятьдесят тысяч ₽ на одной статье — и объект зарабатывает меньше. Когда смета сведена со сделкой, этот сдвиг виден на этапе, пока работы ещё идут, и по нему можно двигать цену следующих этапов или согласовывать допработы с заказчиком.

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

Прибыль по проекту и деньги на счету — два разных вопроса

Проект может быть прибыльным по отчёту о прибылях и убытках и при этом давить кассу. Заказчик платит после сдачи, а подрядчикам и за материалы платить надо вперёд (по данным издания о проектном учёте). Прибыль по объекту и остаток денег на счету — две разные величины, и держать в поле зрения нужно обе.

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

Что связка даёт для окупаемости и потока сделок

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

Есть и оценка эффекта: внедрение сметного и учётного программного обеспечения с посделочным разбором затрат даёт до 20% сокращения перерасходов, а в одном кейсе — экономию до 1 млн ₽ в первый год (из публичного зарубежного кейса внедрения, привожу как иллюстрацию; это единичные примеры и чужая выборка, под наш рынок беру их как ориентир, а не как норматив).

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