В большинстве компаний план-факт анализ уже есть. Формально.
Есть Excel. Есть цифры. Есть отклонения.
Иногда даже есть презентация для руководства.
Иногда даже есть презентация для руководства.
Но при этом управленческие решения не всегда принимаются на основе этих данных — чаще они требуют дополнительной ручной аналитики.
Почему ваш план-факт не работает
Если убрать иллюзии, в 8 из 10 компаний ситуация выглядит так:
- план формируется в одном файле
- факт — в 1С:ERP или 1С:Бухгалтерия
- сведение — вручную
- отклонения считаются агрегировано — без детализации до причин
Дальше начинается самое затратное — по времени и вниманию.
Финансовый директор видит:
“Отклонение по прибыли -12%”
И дальше:
- нужно идти в Excel
- разбираться вручную
- писать запросы коллегам
- собирать объяснения
На это уходит от нескольких часов до нескольких дней.
К этому моменту:
- часть данных уже устаревает
- решения принимаются с задержкой
- причины отклонений могут интерпретироваться по-разному
В такой модели план-факт фиксирует отклонение,
но не помогает быстро перейти к его анализу и управленческому действию.
но не помогает быстро перейти к его анализу и управленческому действию.
Главная ошибка: вы анализируете цифры, а не бизнес
План-факт почти всегда делают как бухгалтерский отчет:
- статьи регламентированного учета
- суммы
- отклонения
Но бизнес управляется не статьями, а факторами, которые влияют на финансовый результат.
Если в дашборде нет ответа на вопрос
«за счет каких факторов произошло отклонение»,
он остается инструментом фиксации, а не управления.
«за счет каких факторов произошло отклонение»,
он остается инструментом фиксации, а не управления.
Как должен выглядеть рабочий план-факт
Рабочий управленческий дашборд решает три задачи:
- Быстро показывает, где есть отклонение
- Позволяет понять, какие факторы на него повлияли
- Помогает определить, куда смотреть дальше
Если этого нет — пользователь все равно возвращается к ручному анализу.
Что происходит на практике
Типичный кейс:
Компания видит:
- выручка ниже плана на 10%
Без детализации появляются общие гипотезы:
- «просел рынок»
- «сезонность»
Но после декомпозиции картина меняется:
- в дашборде есть разбивка:
- по продуктам
- по каналам продаж
- по менеджерам
- дополнительно — факторный анализ:
- объем
- цена
За счет этого за 1–2 минуты становится видно:
- просел конкретный продукт
- внутри него — один канал
- внутри канала — группа клиентов у конкретного менеджера
- основная причина — снижение объема, а не цены
В результате:
- причина локализуется до управляемого уровня
- становится понятно, какое действие нужно:
- пересмотреть воронку
- проработать клиентов
- изменить план продаж
Разница — не в данных, а в том, как они структурированы в дашборде.
Почему BI не решает проблему автоматически
Частое ожидание:
“Соберем дашборд в Power BI — и анализ станет быстрее”
BI действительно ускоряет работу с данными.
Но он не заменяет управленческую модель.
Если в модели отсутствуют:
- декомпозиция
- факторный анализ (объем / цена / структура)
- связь с ответственностью
дашборд будет быстрее показывать цифры, но не даст ответа на вопрос «что делать».
Как собрать рабочий дашборд за 1 день
Важно:
здесь описана логика и структура.
здесь описана логика и структура.
{$te}
Техническая реализация — какие показатели делать мерами, какие поля использовать как измерения, как выстраивать модель данных — требует отдельной проработки.
Подробно этот процесс разобран в отдельном материале.
1. Ограничьте себя: 5–7 показателей
Если на первом экране больше 7 KPI — внимание рассеивается.
Базовый набор:
- выручка
- валовая прибыль
- операционные расходы
- EBITDA / чистая прибыль
Остальные показатели — на уровень детализации.
2. Приведите данные к сопоставимому виду
Не требуется идеальная модель данных.
Необходимо обеспечить:
- наличие плана и факта
- единая структура статей
- сопоставимые уровни детализации
Если план и факт нельзя корректно сопоставить — дальнейший анализ будет искажаться.
3. Сделайте декомпозицию обязательной
Любое отклонение должно раскрываться:
- по подразделениям
- по продуктам / проектам
- по направлениям
Пользователь должен пройти путь:
от общей метрики → к конкретной зоне ответственности
без выгрузок и ручных расчетов.
от общей метрики → к конкретной зоне ответственности
без выгрузок и ручных расчетов.
4. Добавьте факторный анализ (драйверы)
Ключевой элемент.
Отклонение должно раскладываться на факторы:
- объем
- цена
- структура
Это позволяет:
- разделить причины
- не смешивать разные управленческие эффекты
- принимать точечные решения
5. Зафиксируйте ответственность
Отклонения должны быть связаны с:
- подразделениями
- центрами финансовой ответственности
- ролями или руководителями
Это позволяет перейти от обсуждения цифр к управлению действиями.
6. Визуализируйте отклонения, а не только значения
Важно показывать не только данные, но и их интерпретацию:
- план vs факт
- отклонение (%)
- визуальные индикаторы
Это сокращает время первичного анализа и снижает нагрузку на пользователя.
Что вы получите уже на следующий день
Даже базовый дашборд дает эффект:
- сокращается время анализа
- причины отклонений выявляются быстрее
- обсуждение становится предметным
- повышается прозрачность ответственности
И главное — решения начинают опираться на структуру данных, а не на интерпретации «вручную».
Где обычно возникают ограничения
Даже при наличии BI компании сталкиваются с типовыми ограничениями:
1. Несопоставимость плана и факта
План и факт формируются по разной логике или с разной детализацией.
2. Отсутствие единой структуры данных
Справочники не синхронизированы между системами.
3. Ручные корректировки
Часть данных изменяется вне системы, что снижает прозрачность.
4. Недостаточный уровень доверия к данным
Пользователи перепроверяют цифры и возвращаются к Excel.
5. Разрыв между финансовой и операционной моделью
Финансовые показатели не связаны с операционными драйверами.
Важно: это не ограничения BI как инструмента, а следствие текущей управленческой и учетной модели.
Ключевой вывод
План-факт анализ начинает работать как инструмент управления, когда он отвечает на три вопроса:
- где отклонение
- за счет каких факторов оно возникло
- кто на него влияет
Если текущая система этого не делает — задача не в доработке отчета, а в пересборке логики анализа.
