директор и машина · стратегия · запись № 014 · 6 июля 2026 · Давид Герштейн

План-факт без вранья: как смотреть на расхождения и не искать виноватых

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Если ваш план-факт всегда сходится — вас обманывают. Или вы обманываете себя: план подгоняют под факт, факт трактуют под план, и разбор превращается в ритуал.

Честный план-факт неприятен по определению: он показывает, где вы ошиблись в прогнозе. Именно поэтому он и полезен.

Собственнику принесли годовой план выручки. В документе, который реально согласовали руководители, стояла сумма в разы меньше. Разница не в ошибке округления — в двух разных сущностях. Кто-то считал сумму договоров, кто-то — авансовые платежи, которые составляют примерно 37–40% от той же выручки. Арифметика это подтверждает: согласованная цифра — это как раз около 40% от исходного плана, то есть похоже, что один документ считал полную сумму сделок, а другой — только авансовую часть от неё. Формально оба правы. По факту план-факт анализ в таком виде бессмысленен: сравнивать нечего, потому что никто не договорился, что такое «факт», а разница выглядит как катастрофа только до тех пор, пока не найдена эта развилка.

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

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

Я видел эту историю в разных декорациях десятки раз. Компания вроде бы считает цифры, строит таблицы, проводит планёрки — а решения принимаются на глазах у всех неправильно, потому что план и факт измеряют разные вещи. Дальше — как выглядит рабочий план-факт анализ, если убрать из него вранье, поиск виноватых и посчитать, во сколько часов и денег обходится его отсутствие.

Когда +40% к плану — не повод хвалить

Проверьте у себя: перевыполнение вдвое означает не героизм команды, а то, что вы неверно спланировали. И то и другое стоит разобрать.

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

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

Решение, которое приняли в этой истории — перейти от фиксированных цифр к формулам. Если темп роста составляет плюс 5% в месяц, формула пересчитывает плановые показатели автоматически при загрузке фактических данных за период. Например: план на месяц был условной единицей, за предыдущий месяц факт вырос на те же +5% — формула на следующий месяц ставит план не «из старой презентации», а с учётом этого роста, и +40% к устаревшей цифре превращаются в честные проценты к живой базе. План перестаёт быть документом, который переписывают раз в квартал под недовольство руководителей, и становится рабочим инструментом, который живёт вместе с бизнесом. Подробнее о том, как стратегия превращается из презентации в рабочий процесс, — в отдельном материале про стратегию как рабочий инструмент.

Всё начинается с определения факта

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

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

В одной из компаний это довели до предельной ясности: «Действуем по факту. Если в течение двух дней деньги заходят, я решу этот вопрос» — продажа признаётся не в момент устной договорённости и не в момент подписания, а в момент поступления денег в оговорённый срок, минуя лишние согласования с бухгалтерией. Жёстко, но честно: план-факт отклонения считаются от одной точки отсчёта, а не от трёх разных в зависимости от того, кто отчитывается.

Похожая проблема всплыла с аналитикой каналов продаж. Руководитель спросил SEO-специалиста, откуда конкретно приходят лиды из органического поиска. Специалист не смог назвать источники — аналитика не была настроена на связку «поисковый запрос → страница → продажа». Формально отчёты существовали. По факту план-факт анализ по каналу был фикцией: цифры были, а понимания, откуда они взялись, не было. Руководитель после этого потребовал перестроить отчётность так, чтобы каждый исполнитель стратегии понимал, за какие конкретные результаты он отвечает — иначе план-факт по каналу так и остаётся красивой таблицей без содержания. Если данные в CRM или аналитике сами по себе искажены или неполны, весь план-факт анализ строится на песке — похожий случай я разбирал в материале про то, как CRM врёт с датами.

Юнит-экономика как база для сравнения

Без понимания экономики по каждому направлению план-факт анализ превращается в сравнение двух случайных чисел. «Ты должна знать юнит-экономику каждого направления как свои пять пальцев. На гражданской — сколько зарабатываем, какая маржа, какие точки бизнеса. Это база, база, база. Любой финансовый директор знает всю эту юнит-экономику. Всё» — фраза руководителя финансовому директору звучит жёстко, но по делу. Если нет базовой единицы экономики, отклонение факта от плана нельзя интерпретировать: непонятно, хорошо это или плохо, дорого или дёшево.

Механика по шагам

Соберёте за вечер: план, факт, отклонение, причина. Четыре колонки, из которых сложнее всего заполняется последняя — и именно ради неё всё затевается.

Ниже — последовательность, которую можно повторить с любой командой за одну-две недели, без закупки новых систем.

1. Зафиксировать факт письменно. Один документ, один критерий: деньги на счёте, а не обещание менеджера. Ответственный — финансовый директор или собственник, не отдел продаж (у него конфликт интересов).
2. Выбрать источники данных. Сделки и стадии — CRM (в наших примерах Bitrix24), поступления денег — банк/бухгалтерия, лиды по каналам — рекламные кабинеты и аналитика сайта. Три источника, а не один общий Excel «на глаз».
3. Свести данные в один регистр. Google Таблица или BI-лист, куда раз в сутки выгружается срез: план по неделе, факт по неделе, статус сделки, ответственный менеджер.
4. Назначить ритм сверки. Фиксированный день недели, один и тот же блок вопросов: маркетинг, продажи, авансы. Не «как получится», а каждую неделю в один день.
5. Разметить отклонения по статусам. Зелёный/жёлтый/красный — не проценты в вакууме, а понятные пороги, одинаковые для всех менеджеров.
6. Разобрать красные позиции на планёрке. Не весь список, а только критические — иначе совещание превращается в перечитывание таблицы вслух.

ИИ-связка: автоматическая еженедельная сверка

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

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

Схема конвейера: Bitrix24 (сделки, стадии, суммы, даты) → вебхук выгружает срез в Google Sheets раз в сутки → по четвергам скрипт Apps Script собирает недельный срез, обогащает его прошлой неделей и отправляет в LLM → модель возвращает JSON со статусами и приоритетами → результат записывается обратно в лист «Итоги недели» и дублируется сообщением в Telegram-чат руководителей.

Ты — аналитик план-факт отчёта. На входе список сделок в JSON
(поля: client_id, manager, plan_amount, fact_amount, stage,
days_overdue, week_start).

Правила:
1. Факт — только сумма, реально поступившая на счёт (fact_amount).
   Договорённости и обещания менеджера в расчёт не идут.
2. Статус сделки:
   - green: отклонение факта от плана по срокам ≤ 5%, просрочки нет
   - yellow: отклонение 5-15% или просрочка 1-3 дня
   - red: отклонение >15% или просрочка более 3 дней
3. Не придумывай причины отклонений, если их нет в данных —
   только фиксируй факт и статус.
4. Верни JSON: агрегаты по статусам, список red-клиентов
   с долей риска в процентах от планового чека, и не более 3 пунктов
   "куда посмотреть в первую очередь" — коротко, без общих фраз.

Данные: {{json_сделок_за_неделю}}

Модель здесь — дешёвая, уровня GPT-4o-mini или аналогичного класса: задача классификаторская, а не творческая, и переплачивать за «умную» модель нет смысла — она с той же вероятностью либо верно посчитает проценты, либо ошибётся, но стоит в разы дороже.

{
  "summary": {"green": 21, "yellow": 6, "red": 4},
  "red_clients": [
    {"client_id": "C-1042", "manager": "Игнатова", "risk_share_pct": 18, "days_overdue": 6},
    {"client_id": "C-1090", "manager": "Седов", "risk_share_pct": 27, "days_overdue": 9}
  ],
  "top_actions": [
    "Проверить C-1090: просрочка 9 дней, доля риска 27% планового чека",
    "У Седова 2 из 4 red-сделок — разобрать нагрузку менеджера",
    "Просрочки концентрируются в среду-четверг — проверить оплату по этим дням"
  ]
}

Так этот же результат выглядит для руководителя не в JSON, а в листе «Итоги недели», куда скрипт кладёт агрегаты и список красных клиентов:

Инженерная обвязка. Скрипт крутится в Google Apps Script по триггеру времени (четверг, утро). Вебхук Bitrix24 настроен на выгрузку изменений по сделкам раз в сутки в промежуточный лист. Если LLM не отвечает или возвращает невалидный JSON — скрипт не затирает предыдущий отчёт, а шлёт сообщение об ошибке в тот же Telegram-чат: «план-факт отчёт за неделю не собран, проверь вебхук и лог». Ручной перезапуск — одна кнопка в меню таблицы, доступна ответственному, а не только тому, кто писал скрипт.

Ритм: план-факт отклонения нужно видеть еженедельно

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

Компания, о которой шла речь, находилась не в теоретической ситуации. Выпало два источника дохода — один на два месяца, другой на больший срок, — новых сделок осталось лишь несколько десятков в месяц, денег не хватало ни на увеличение продаж, ни на поддержание уровня прошлого месяца, зарплата выплачивалась с резервного налогового счёта. «Мы все прекрасно понимаем, что по закрытиям счетов у нас просадка... прилетов у нас немного, точка. Глобально у нас есть проблемы... у нас нет денег на то, чтобы вложиться в увеличение продаж» — в такой момент план-факт анализ раз в квартал — роскошь, которую компания не может себе позволить. При таком скромном потоке даже несколько сделок в статусе «красный» — это уже 10–15% всего месячного объёма (оценка), и заметить их нужно за неделю, а не постфактум в конце месяца. Еженедельный ритм — единственный способ поймать проблему до того, как она станет фатальной.

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

Три цвета вместо одной цифры

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

Смысл системы не в красоте, а в том, что она убирает субъективность из разговора «как дела с клиентом». Либо клиент зелёный, либо нет — критерий один и тот же для всех менеджеров. План-факт анализ на уровне отдельной сделки перестаёт зависеть от того, кто и как красиво отчитывается на планёрке.

Похожий принцип виден и на уровне каналов продаж за годы. Когда собственник потребовал переделать презентацию стратегии маркетинга — цифры по выручке (годовые) не совпадали с бюджетом (месячным), информация была неупорядочена, отсутствовали временные маркеры реализации, — новая структура зафиксировала прогресс по годам явно: в 2025-м доля SEO-лидов была 5%, в 2026-м — 35%. Не абстрактный «рост», а конкретная точка до и точка после.

На диаграмме — доля SEO-лидов в общем потоке до и после пересборки маркетинговой стратегии: с 5% в 2025 году до 35% в 2026-м.

Такой формат «до/после» по каждому каналу отдельно — SEO, Telegram, реферальные источники — заставляет план-факт отчёт отвечать не только «сколько», но и «за счёт чего»: «Я не говорю, за счёт чего он даст больше лидов. Я хочу понимать: за счёт SEO или за счёт SMM?» — это требование к плану, а не к красивой презентации.

Решения на данных, а не на убедительном тексте

Вам будут приносить объяснения. Ваша задача — требовать под каждое объяснение цифру, иначе разбор превращается в конкурс красноречия.

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

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

Обещание — не факт

Самая частая подмена в отчётах, которые вам показывают. Проверьте, не считаете ли вы фактом то, что ещё не случилось.

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

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

Экономика: что стоит и что даёт вам

Час вашего времени в неделю против решений, принятых с опозданием на месяц.

Ваши затраты — час в неделю. Отдача — решения, принятые на неделю раньше, чем раньше.

Настройка ручной дисциплины плана-факта занимает около 8–12 часов работы руководителя и аналитика (оценка), автоматизация сборки данных экономит порядка 72 часов в месяц ручного труда менеджеров (оценка), а еженедельная сверка помогает раньше увидеть риск на сумму около 1 800 000 ₽ оборота под угрозой (оценка) — три разных числа, которые нельзя складывать в один эффект.

Формула для собственной прикидки простая: количество сделок в месяц × доля «зависших» (не отменённых явно, а просто не дошедших до оплаты в срок) × средний чек = оборот под риском. Дальше отдельно: часы ручной сверки × ставка сотрудника = стоимость рутины, которую можно снять автоматизацией. Ниже — расчёт на условной компании с отделом из 12 менеджеров и оборотом ~18 млн ₽/мес, чтобы формулу было видно в цифрах.

При среднем чеке 300 000 ₽ отдел закрывает около 60 сделок в месяц. Если 10% сделок «зависает» — это 6 сделок в месяц, риск ≈ 1 800 000 ₽ месячного оборота (оценка). Это не потерянные деньги — это деньги, судьба которых неизвестна до тех пор, пока нет чёткого критерия факта и еженедельной сверки.

Стоимость внедрения ручной части — не про деньги, а про часы: договориться о критерии факта, развести таблицу по трём блокам, обучить менеджеров вносить статус — это разовые 8–12 часов работы руководителя и аналитика. При ставке ~1 000 ₽/час это около 10 000 ₽ разово — меньше одного дня простоя одного менеджера.

Автоматизация сборки данных (вебхук Bitrix24 → Google Sheets → LLM-классификация) экономит не стратегию и не продажи — только рутину сведения отчёта. Если раньше каждый из 12 менеджеров тратил около 1,5 часа в неделю на ручное заполнение и сверку своих сделок для еженедельного отчёта, это 18 часов в неделю на отдел, то есть около 72 часов в месяц. При ставке ~1 000 ₽/час это около 72 000 ₽ в месяц рабочего времени, которое уходит на копирование цифр в таблицу вместо продаж.

Что мы не считаем эффектом: высвобожденные 72 часа менеджеров — это поток времени, а не автоматическая прибавка к выручке. Если менеджер потратит освободившиеся часы не на звонки клиентам, а на другую рутину, денежного эффекта не будет вообще. И риск оборота 1 800 000 ₽, и экономия часов — это два разных числа: одно про то, что дисциплина помогает раньше увидеть проблему (но не гарантированно её решает — часть зависших сделок всё равно не закроется), другое — про экономию рутины. Складывать их в один «результат внедрения» нельзя.

Эксплуатация модели-классификатора: при недельном прогоне среза на 60 сделок объём текста на вход и выход укладывается в несколько тысяч токенов за прогон. Четыре прогона в месяц (по четвергам) при тарифах дешёвых моделей уровня GPT-4o-mini — это меньше 100 ₽ в месяц суммарно, то есть дешевле одной чашки кофе на всю автоматизацию, при условии что через модель гоняется только еженедельный агрегированный срез, а не весь массив сделок построчно.

С чего начать в понедельник

• Зафиксировать письменно, что именно считается фактом: деньги на счёте, договор или аванс — один критерий, один документ.
• Назначить фиксированный день недели для сверки и одного ответственного, кто сводит данные (не тот, кто отчитывается по продажам).
• Разметить сделки по трём статусам — зелёный/жёлтый/красный — с одинаковыми порогами для всех менеджеров.
• Проверить, актуален ли план: если условия рынка изменились, не сравнивать факт с устаревшими цифрами — пересчитать план формулой.
• Настроить минимальную автоматическую выгрузку данных (CRM → таблица) прежде чем звать ИИ считать отклонения.
• Раз в квартал прогонять конкретные цифры отчёта руками — премии, комиссии и бонусы первыми выпадают из автоматики.

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

И ещё одно, про вас лично. Держать план-факт живым — это отдельный управленческий навык, а не бухгалтерская функция, которую спускают вниз вместе с таблицей. Руководитель, который за минуту отвечает, что в его компании считается фактом, на какую дату он зафиксирован и кто его сводит, управляет бизнесом. Тот, кто не может, управляет пересказом отчётов. Этому навыку не учат — его добирают сами, обычно после первой цифры, которая развалилась на совете.

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

Как автоматизировать еженедельную сверку и получать отклонения списком — в бесплатном курсе.

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

Частые вопросы

Как посчитать отклонение факта от плана?

Отклонение = (факт − план) ÷ план × 100 %. Положительное значение — перевыполнение, отрицательное — недобор. Сложность не в формуле, а в определении факта: в разобранном случае план оказался построен на неверной базе, и перевыполнение на 40 % означало ошибку в допущениях, а не успех.

Что делать, если факт превышает план на 40%?

Сначала проверить, не устарел ли сам план — если да, хвалить рано, план надо пересчитывать формулой, а не премией.

Как часто нужно сверять план и факт?

Еженедельно по фиксированным блокам — маркетинг, продажи, авансы, — иначе проблема копится месяц и теряется её источник.

Что считать фактом продажи — договор или деньги?

Деньги, поступившие на счёт в оговорённый срок. Договор — это обещание, а не факт, и план-факт отклонения, посчитанные от обещания, всегда врут.

#аналитика и отчётность #контроль и надёжность #деньги