В проектном бизнесе при расчёте оплат очень опасна логика общего котла. По одному проекту заказчик оплатил аванс 3 млн. По другому заказчик наоборот задерживает расчёт, а подрядчик уже ждёт оплату 700 тыс., иначе проект встанет. А хочется же поскорее набрать исполнение. На счёте что-то есть — значит, можно временно закрыть дыру с фразой: «Потом заказчик оплатит, это и мы там вернём». Деньги же в “общем котле” есть.

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

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

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

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

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

Раньше могло казаться: ничего страшного, если одна работа внутри проекта в минус, зато другая в плюс и в конце всё сойдётся. Нет. Это слишком оптимистично. Заказчик в любой момент может остановить проект в том числе и по причинам от него не зависящим. И если ты уже выполнил часть работ ниже себестоимости в расчёте на будущие прибыльные этапы, то ты фактически прокредитовал заказчика. Только без договора займа, без процентов и без гарантии, что доберёшь деньги потом. И тема себестоимости здесь не бухгалтерская, а вполне управленческая: если работа не покрывает свою долю расходов, она может быть убыточной даже внутри “прибыльного” проекта».

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

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

Главный вывод для меня такой: портфелем проектов нельзя управлять по остатку на расчётном счёте. Остаток показывает, что деньги есть, но он не показывает, чьи это деньги внутри портфеля. А в проектном бизнесе это принципиальная разница.