Шесть принципов формирования дашбордов в девелопменте
Дашборд нужен не для того, чтобы «у нас тоже была аналитика», а чтобы компания быстрее видела отклонения, раньше принимала решения. Этому посвящен аналитический материал эксперта Академии девелопмента, финансового директора NEDVEX Дмитрия СОБОЛЕВА.
Принципы дашборда. Источник: Академия девелопмента
Большинство девелоперских компаний за последние три года в той или иной форме построили дашборды. Кто-то — на Power BI, кто-то — на специализированных платформах, кто-то — на самописных решениях поверх Excel. Но большинство этих дашбордов не управляет бизнесом. Они просто красиво показывают данные. Разница между «дашбордом для красоты» и «дашбордом для управления» — не в стеке технологий, а в шести базовых принципах, с которых стоит начинать проектирование любого управленческого экрана.
Но девелоперу нужен не экран с графиками. Ему нужен управленческий контур, который помогает быстрее принимать решения по продукту, цене, себестоимости, срокам, рискам и организационным издержкам. В девелопменте 70% себестоимости проекта фиксируется еще до выхода на стройку — в проектных решениях и тендерах. Это значит, что когда «факт» наконец попадает в отчет, часть управленческих рычагов уже отработала вхолостую. Поэтому правильно спроектированный дашборд — это не отчет о прошлом, а инструмент работы с будущей маржой.
Хороший дашборд должен отвечать не на вопрос, что произошло, а на вопрос, какое решение нужно принять сейчас, кто за него отвечает и какие данные это подтверждают
Ниже — шесть принципов, с которых стоит начинать проектирование любого управленческого дашборда в девелоперской компании. Принципы проверены практикой и одинаково применимы для разных сегментов — от масс-маркета до премиума.
Принцип 1. Начинать не с данных, а с решений
Первый артефакт при создании дашборда — не макет экрана и не перечень графиков. Это список управленческих решений, которые данный дашборд должен поддерживать.
Например:
- менять ли цену продаж;
- пересматривать ли продуктовый микс;
- останавливать ли изменение проекта;
- усиливать ли подрядчика;
- переносить ли ресурс между проектами;
- выносить ли отклонение на комитет.
Если конкретное решение не описано — метрика почти всегда превращается в декоративную отчетность. На практике это первая причина, по которой 80% графиков в типичном корпоративном дашборде никто не открывает повторно: они «про вообще», а не «про вот это решение к среде».
Сначала — список решений. Затем — метрики, которые эти решения подтверждают. И только потом — макеты и интеграции. Обратный порядок гарантирует красивый, но мертвый отчет.
Принцип 2. Смотреть на ведущие индикаторы, а не только на факт
Факт прошлого месяца редко помогает управлять. Когда перерасход уже попал в отчет, часть маржи зачастую уже потеряна. Поэтому дашборд должен показывать не только факт, но и ранние сигналы — те самые leading indicators (опережающие показатели), которые позволяют поймать проблему до того, как она стала бухгалтерской.
Базовый набор опережающих показателей для девелоперского проекта выглядит так:
- достаточность ресурса (рабочие на площадке);
- темпы выполнения работ;
- динамика изменения себестоимости;
- отклонения по графику;
- скорость получения разрешительной документации;
- стоимость выполнения (cost-to-complete);
- прогноз итоговой стоимости проекта (EAC).
Задача дашборда — увидеть проблему до того, как она стала бухгалтерским фактом. Иначе говоря, сместить фокус управления с «закрытия месяца» на ежедневный и еженедельный цикл, где влияние еще возможно.
Принцип 3. У каждой метрики должен быть владелец
Метрика без владельца — это коллективная безответственность. Важно различать получателя отчета и владельца метрики. Получатель смотрит. Владелец реагирует.
По каждой ключевой метрике должно быть однозначно понятно следующее:
- кто отвечает;
- какой допустимый порог отклонения;
- что делаем при выходе за порог;
- за какой срок должна быть реакция;
- куда эскалируется проблема.
Без этого простого набора правил дашборд становится «панелью наблюдения», а не инструментом управления. И именно здесь критически важно жесткое разграничение между ролями: финансовый блок, продуктовый блок, стройка и продажи — у каждого свой набор метрик и свой регламент реакции. Хороший дашборд явно показывает не только цифру, но и фамилию рядом с ней.
Метрика, у которой нет владельца и регламента реакции, гарантированно перестанет обновляться в течение трех-четырех месяцев. Это не вопрос дисциплины — это вопрос дизайна системы.
Принцип 4. Оперативность должна соответствовать скорости решения
Режим реального времени нужен не везде. Это одна из самых дорогих ошибок при внедрении BI-платформ: компания платит за стриминг и интеграции там, где решение принимается раз в месяц на инвестиционном комитете.
Если решение принимается раз в месяц, ежедневное обновление создает шум и съедает внимание команды. Если решение нужно принимать каждый день — например, по фронту работ или по тендерным заявкам — месячный отчет бесполезен и опасен.
Частота обновления должна зависеть от управленческого цикла, а не от технических возможностей платформы. На практике в девелопменте сосуществуют как минимум четыре следующих управленческих цикла:
1. ежедневный — стройплощадка, поставки, инциденты;
2. еженедельный — план-факт по бюджету, продажам, разрешительной документации;
3. ежемесячный — закрытие учетного периода, прогноз EAC и кэш-флоу;
4. квартальный/проектный — стратегические решения по продукту, цене, очередям.
Оперативность — это не «обновляется каждую минуту». Оперативность — это «данные приходят до момента принятия решения». Если решение уже принято — самые свежие данные больше не помогут.
Принцип 5. Прогноз важнее, чем факт
Девелопер управляет будущей маржой, а не прошлым отчетом. Поэтому хороший дашборд должен показывать не только бюджет и факт, но и прогноз — на горизонте от ближайшего месяца до завершения проекта.
Минимальный набор прогнозных метрик для проекта таков:
- EAC;
- стоимость выполнения;
- кэш-флоу;
- прогноз отклонения по срокам;
- прогноз маржи;
- прогноз покрытия эскроу;
- прогноз влияния изменений на экономику проекта.
Если дашборд показывает только прошлое — он помогает объяснять результат. Если показывает прогноз — он помогает менять результат. Разница принципиальная: первое — это работа PR-функции, второе — управленческой команды.
Принцип 6. Связывать продукт, продажи, финансы и стройку
Главная ошибка — делать отдельные дашборды для разных функций, которые «не разговаривают» друг с другом. Каждая функция справедливо строит свой контур контроля, но между ними возникают слепые зоны, в которых и теряется прибыль.
Типичная картина, при которой данные живут в разных системах, выглядит так:
1. продажи — в CRM;
2. финансы — в финмодели и в «1С»;
3. стройка — в графиках, BIM, КС-2 и отчетах площадки;
4. продукт — в маркетинговых исследованиях, планировках, ценах и индексе потребительской лояльности (NPS).
Фото предоставлено Академией девелопмента
Но прибыль девелопера рождается между этими блоками
Поэтому зрелый дашборд девелопера должен соединять в одной картине такие составляющие:
- воронку продаж;
- цену и продукт;
- наполнение эскроу;
- финмодель;
- стройготовность;
- бюджет;
- EAC;
- изменения;
- продуктовые характеристики;
- скорость управленческих решений.
Именно здесь дашборд перестает быть BI-отчетом и становится инструментом управления прибылью. Критично, чтобы определения метрик («что считается выручкой», «что считается стройготовностью», «что считается изменением») были согласованы один раз и для всех.
«Дашборд нужен не для того, чтобы "у нас тоже была аналитика", — подчеркивает автор аналитического материала, эксперт Академии девелопмента, финансовый директор NEDVEX Дмитрий Соболев (на фото) и резюмирует: — Он нужен для того, чтобы компания быстрее видела отклонения, раньше принимала решения и управляла не только себестоимостью, но и ценностью продукта, скоростью организации и будущей маржой».
Реклама. ИП Тугарев Алексей Львович. ИНН: 772480003006
Другие публикации по теме:
Четыре контура управления девелоперской прибылью
Феодальные колодцы: темная сторона девелоперских компаний