Портфельное планирование в девелопменте: когда Excel уже не держит проекты и деньги

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

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

Где Excel начинает ломаться

Excel удобен, пока проект живет отдельно. Финансист обновил продажи, сметчик внес себестоимость, проектный офис поправил график, казначейство пересобрало платежи. Проблема начинается, когда эти изменения нужно связать между собой.

В девелопменте один месяц задержки редко остается внутри одного файла. Он меняет график поступлений, потребность в финансировании, лимиты подрядчиков, платежи за землю, проценты, ввод очередей и показатели всего портфеля.

Excel обычно ломается не из-за формул. Он ломается из-за процесса:

• у разных команд появляются разные версии одного проекта;

• изменения в графике продаж не сразу попадают в ДДС;

• сценарии считают вручную и сравнивают глазами;

• руководитель получает итог позже, чем нужно для решения;

• план-факт показывает отклонение, но плохо объясняет его причину.

Если портфель состоит из нескольких очередей и проектов, ручная склейка быстро превращается в отдельную управленческую функцию. Она ест время и все равно оставляет риск ошибки.

Что должно быть в модели портфеля

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

В минимальном контуре обычно нужны:

• график продаж по проектам, очередям и типам помещений.

• себестоимость и график строительных затрат.

• поступления, платежи, кредиты и проценты.

• ограничения по подрядчикам, этапам и разрешительной документации.

• план-факт по продажам, затратам, ДДС и срокам.

• сценарии по цене, темпу продаж, ставке, срокам и стоимости строительства.

Здесь важно не количество показателей, а связь между ними. Если темп продаж падает, модель должна показать не только выручку. Руководителю нужно увидеть кассовый разрыв, потребность в финансировании, изменение NPV/IRR и влияние на соседние проекты, чтобы заранее перенести лимиты или пересмотреть график.

Как внедрять без большой перестройки сразу

Начинать стоит не с идеальной архитектуры, а с управленческого вопроса. Например: какие проекты финансировать в первую очередь, где риск кассового разрыва, какой сценарий выдержит портфель при росте себестоимости на 10%.

После этого можно собрать первый контур.

Первый шаг — выбрать пилотный периметр. Это может быть три-пять проектов или один крупный проект с несколькими очередями. Важно, чтобы внутри были продажи, строительство, ДДС и финансирование. Иначе модель не покажет портфельный эффект.

Второй шаг — договориться о справочниках. Проекты, очереди, статьи затрат, источники финансирования, статусы и версии должны называться одинаково. Иначе комитет снова получит несколько «правильных» цифр. Решение по финансированию уйдет в обсуждение источников, а не портфельного риска.

Третий шаг — настроить версии. Базовый план, рабочий прогноз, стресс-сценарий и факт должны жить отдельно. Тогда можно понять, что изменилось: цена, срок, объем продаж, подрядчик или ставка.

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

Какие сценарии нужны руководителю

В девелопменте сценарное планирование полезно только тогда, когда сценарий ведет к действию. Абстрактные «оптимистичный» и «пессимистичный» варианты быстро превращаются в презентационные слайды.

Практичнее считать конкретные развилки:

• продажи замедлились на два месяца;

• ставка финансирования выросла;

• подрядчик сдвинул график работ;

• себестоимость выросла по одной группе материалов;

• ввод очереди перенесли на следующий квартал;

• часть платежей покупателей ушла на более поздний период.

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

Именно поэтому портфельное планирование проектов нельзя сводить к отчету о статусе. Отчет фиксирует, что произошло. Модель показывает, что будет с деньгами и сроками, если входные условия изменятся.

Когда нужна CPM/EPM-платформа

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

CPM/EPM-платформа становится полезной, когда требуются единая версия данных, контроль изменений, сценарии, план-факт и быстрый пересчет по портфелю. В Optimacros такую логику можно собрать как модель девелоперского портфеля: связать продажи, строительные графики, БДР, БДДС, баланс, NPV/IRR и сценарии по ставке, срокам, себестоимости и темпу продаж.

Смысл не в том, чтобы заменить все корпоративные системы. ERP, CRM, казначейские инструменты и DWH могут оставаться источниками факта и первичных данных. Платформа планирования нужна как слой, где бизнес проверяет будущие решения: что будет с портфелем, если сроки съедут, продажи замедлятся или финансирование станет дороже.

Что проверять на пилоте

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

Проверочный список простой:

• модель пересчитывает ДДС по портфелю, а не только по одному проекту.

• версии планов разделены и сравнимы.

• источник каждого крупного отклонения можно проследить до драйвера.

• сценарий пересчитывается за часы, а не за неделю.

• роли владельцев данных понятны.

• руководитель видит последствия решения по всему портфелю.

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

Как понять, что контур заработал

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

Это нормальный спор. Он управленческий.

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

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