План-факт анализ: порядок действий и промпты для ИИ

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

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

Почему план-факт съедает неделю, хотя формула в нём одна

Разложите свою цепочку на шаги — и станет видно, где именно уходит время. Типичный маршрут выглядит так: данные выгружаются из OLAP-куба в промежуточный Excel, причём в два приёма — отдельно прошлый год, отдельно текущий, потому что одним куском не выгружается. Дальше из справочного файла через ВПР подтягиваются аналитики. Часть колонок считается формулами, часть проставляется руками: выбрал фильтром группу строк — присвоил аналитику. Потом всё копируется в чистовой файл как значения. И только в конце — сверка сводных данных с P&L по основным статьям.

Пять шагов, из которых расчётный — один. Остальные четыре — перекладывание данных. Именно их и стоит отдавать модели, а не «анализ» целиком.

Вторая часть боли — комментарии. Цифры посчитаны, отклонения видны, но к оперкому нужен текст: что произошло, на сколько, за чей счёт, что делаем. Этот текст пишется вручную по каждой существенной строке, и на следующей неделе пишется заново примерно то же самое.

Что должно быть готово до того, как вы откроете ИИ

Модель не знает вашей учётной политики. Она не догадается, что «прочие расходы» в одном округе — это аренда, а в другом — эквайринг. Всё, что вы держите в голове, надо вынести в файл.

Минимальный комплект — три файла. Первый: план на период в разрезе «статья × ЦФО × месяц». Второй: факт в том же разрезе. Третий и самый важный: справочник соответствий «статья из системы → группа статей отчёта → ЦФО → ответственный». Именно третий файл заменяет ручную простановку аналитик через фильтры. Если справочника нет в явном виде — его придётся собрать один раз, и это единственная по-настоящему трудоёмкая часть подготовки. Зато дальше он работает каждый месяц.

Сопоставимость — отдельная проверка, которую никто за вас не сделает. План без НДС, а факт с НДС — отклонение будет на 22% и совершенно бессмысленное. План по начислению, факт по оплате — то же самое. План в рублях по курсу на начало года, факт по текущему — снова мимо. Модель молча посчитает разницу и даже напишет красивый комментарий к ней. Проверьте правила сбора до расчёта, а не после.

И ещё: полмиллиона строк проводок в чат грузить незачем. Дело даже не в лимитах на размер файла — дело в том, что для план-факта нужен свод, а не первичка. Сверните выгрузку в кубе или в Power Query до уровня «статья × ЦФО × месяц»: по моему опыту вместо 500 тысяч строк остаётся несколько тысяч, хотя порядок зависит от числа статей, ЦФО и периодов. С таким файлом модель работает точно и быстро.

Разметка аналитик: промпт вместо ВПР по строкам

Первый шаг, который отдаётся целиком. Задача — подтянуть к факту группу статей и ЦФО, а главное, честно показать, для чего соответствия не нашлось. Ручной ВПР даёт #Н/Д, которые потом ищут глазами; промпт должен сразу выдать список проблемных статей с суммами, чтобы вы понимали цену вопроса.

Ты — финансовый аналитик. Во вложении два файла:
1) fakt.csv — выгрузка: дата, ЦФО, статья из учётной системы, сумма
2) spravochnik.csv — соответствие: статья из системы → группа статей отчёта → ответственный

Сделай:
1. Подтяни к каждой строке fakt.csv группу статей и ответственного
   по ТОЧНОМУ совпадению названия статьи.
2. Строки без совпадения вынеси на отдельный лист «Не найдено»:
   статья, количество строк, сумма. Отсортируй по убыванию суммы.
3. Не подбирай похожие названия, не создавай новые статьи,
   не исправляй опечатки в исходных данных.
4. Сверни результат до уровня: группа статей × ЦФО × месяц.
5. Верни файл xlsx с листами «Свод», «Разметка», «Не найдено».

Покажи код, которым считал, и выведи контрольные суммы:
сумма по исходному файлу = сумма по «Своду» + сумма по «Не найдено».

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

ChatGPT в режиме анализа данных выполняет для таких задач код на Python в изолированной среде. У Claude механизмов два, и их стоит различать: встроенный analysis tool исполняет JavaScript в песочнице браузера, а файлы вроде xlsx собираются в серверной песочнице с Python — промпту выше нужна именно она. Через API у Anthropic для этого есть отдельный code execution tool. Принципиально важно другое: цифры получаются вычислением, а не «в уме» языковой модели. Поэтому требование «покажи код» — не любопытство, а страховка.

Отклонения: как заставить модель считать, а не пересказывать

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

Файл plan_fact.xlsx: группа статей, ЦФО, план, факт за сентябрь 2026.

Посчитай по каждой строке:
— отклонение в рублях (факт − план) и в процентах к плану;
— долю строки в суммарном отклонении по модулю.

Отметь «существенное», если выполнено ЛЮБОЕ из условий:
|отклонение| ≥ 500 000 ₽ ИЛИ |отклонение| ≥ 10% от плана строки.

Отсортируй по модулю отклонения в рублях.
Отдельно выведи строки, которые вместе дают 80% суммарного отклонения.

Проверка: сумма отклонений по строкам должна совпадать с отклонением итога.
Если не совпадает — напиши, где расхождение. Не правь цифры молча.

Порог существенности подставьте свой. Смысл двойного критерия в том, что крупная статья отклоняется на 3% и это миллионы, а мелкая скачет на 40% и это копейки — одним процентным порогом обе ситуации не ловятся.

Фраза «не правь цифры молча» появилась не случайно. Модель склонна сглаживать нестыковки, чтобы отчёт выглядел цельным. Явный запрет переводит нестыковку из скрытой в видимую — а это ровно то, что вам нужно перед сверкой с P&L.

Факторный разбор: объём, цена и гибкий бюджет

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

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

Разложи отклонение выручки на два фактора:
— влияние объёма = (объём_факт − объём_план) × цена_план
— влияние цены   = (цена_факт − цена_план) × объём_факт

Проверь по каждой категории: влияние объёма + влияние цены = 
(объём_факт × цена_факт) − (объём_план × цена_план).
Если равенство не выполняется — останови расчёт и покажи строку.

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

С переменными затратами работает гибкий бюджет. Сравнивать фактические затраты при объёме 120% с планом, свёрстанным на 100%, некорректно — перерасход возникнет сам собой и ни о чём не скажет.

Переменные затраты: плановая сумма на плановый объём,
фактическая сумма на фактический объём.

1. Посчитай плановую ставку на единицу: план_сумма / план_объём.
2. Построй гибкий бюджет: плановая ставка × фактический объём.
3. Раздели отклонение на две части:
   — за счёт объёма  = гибкий бюджет − план
   — за счёт цены и эффективности = факт − гибкий бюджет
4. Выведи таблицу и укажи, какая часть отклонения управляемая.

Вторая часть — та, за которую отвечает руководитель подразделения. Первая — следствие продаж. Разделение этих двух сумм снимает половину споров на оперкоме ещё до его начала.

Комментарии и записка к оперкому

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

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

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

Собери проект пояснительной записки к оперкому:
— по каждой строке: что произошло, на сколько (руб. и %), ЦФО, что делаем;
— формулировки короткие, без прилагательных и оценок;
— одинаковая структура у всех пунктов;
— в конце — список строк, по которым у меня нет пометки,
  отдельным блоком «Требуется комментарий от ответственного».

Запрет: не придумывать причины отклонений. Если пометки нет —
так и писать: «причина не указана». Не менять мои цифры.

[таблица]
[пометки]

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

Где ИИ ломается: ограничения, которые лучше знать заранее

Честный список, чтобы вы не выясняли это на боевом отчёте.

Генеративная часть ответа не воспроизводится байт в байт от запуска к запуску: один и тот же промпт на одних и тех же данных может дать чуть иначе оформленную таблицу. Числовой результат, если он получен кодом на тех же данных, повторяется. Лечится тем, что промпт фиксируется как регламент: один текст, одна структура выходного файла, обязательные контрольные суммы в конце. Тогда отличаться будет оформление, а не цифры.

Модель не знает вашей учётной политики и не спросит про неё сама. Всё, что определяет сопоставимость — НДС, метод признания, курс, границы периода — задаёте вы в промпте или в справочнике.

Модель не заменяет сверку с учётной системой. Финальные цифры в управленческом отчёте берутся из системы, и последний шаг — сверка сводных данных с P&L по основным статьям — остаётся человеческим. Это не формальность: именно на нём ловятся потерянные при выгрузке строки.

Приватность. В ChatGPT на личных тарифах использование переписок для обучения моделей включено по умолчанию и отключается в настройках. В Claude выбор предлагается явно — при обновлении политики переключатель показан включённым, и его можно выключить. Проверьте обе настройки до первой загрузки. В корпоративных планах обучение на данных клиентов по умолчанию не ведётся. Простое и работающее правило: в выгрузке не должно быть ФИО, зарплат и договорных условий с контрагентами. Коды ЦФО и коды статей читаются моделью ничуть не хуже названий.

И последнее. Если отчёт полностью регламентный, структура не меняется годами, а объём измеряется сотнями тысяч строк — дешевле один раз собрать Power Query или витрину в BI, а ИИ оставить на том, что плохо формализуется: разметка новых статей, разбор отклонений, текст. Автоматизировать через чат то, что стабильно повторяется, — значит платить вниманием каждый месяц вместо одной настройки.

Как поставить это в еженедельный ритм

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

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

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

С чего начать на этой неделе

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

Дальше посчитайте отклонения с вашим порогом существенности и сверьте итог с P&L. Если сошлось — переходите к факторному разбору выручки. Если нет — расхождение почти всегда в правилах сбора, а не в модели.

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