директор и машина · стратегия · запись № 013 · 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-чат: «план-факт отчёт за неделю не собран, проверь вебхук и лог». Ручной перезапуск — одна кнопка в меню таблицы, доступна ответственному, а не только тому, кто писал скрипт.

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

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

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

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

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

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

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

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

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

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

Управленческие решения на данных — а не на убедительном тексте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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