Глава 22. Прогнозирование продаж на основе накопленного спроса

Введение

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

Будущая продажа редко возникает в момент подписания договора. До Deal существует спрос, затем формируется Demand Episode, клиент проходит квалификацию, меняет коммерческие состояния, откладывает решение, возвращается, становится SQL, Opportunity, временно выходит из активного процесса или снова в него входит. Поэтому значительная часть будущего результата существует в системе задолго до того, как появляется в отчёте о продажах.

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

Традиционная логика в упрощённом виде:

Архитектурная логика иная:

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

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

Если план требует 150 сделок, а структура текущего спроса, SQL, Opportunities, возраст объектов, наблюдаемая вероятность созревания, товарная доступность и пропускная способность указывают на 115–125 сделок, прогноз не должен искусственно превращаться в 150. Разница между желаемым и вероятным результатом создаёт управленческий объект — Forecast Gap.

Ключевая идея главы состоит в следующем: будущие продажи частично уже существуют внутри сегодняшнего коммерческого потока. Задача прогнозирования — определить, какие Demand Episodes уже находятся в системе, в каком состоянии они находятся, какова вероятность Deal в заданном горизонте и какую часть этого потенциала система действительно способна реализовать.

22.1. Почему традиционного прогноза продаж недостаточно

Один из наиболее распространённых способов прогнозирования — run-rate. Если за первые десять дней месяца компания продала 40 автомобилей, можно экстраполировать текущий темп на весь период. Такой расчёт отвечает на вопрос: что произойдёт, если текущая скорость сохранится? Но почти ничего не говорит о том, почему она должна сохраниться.

Два дилерских центра могут иметь одинаковые продажи за первые десять дней, но различную структуру будущего результата. В одном — много свежих SQL и Opportunities, низкий ageing и достаточный товар. В другом — мало Opportunities, высокий WIP и дефицит нужных моделей. Исторический темп одинаков, будущая способность системы производить Deal — различна.

Продажи являются запаздывающим показателем. Сегодняшний Deal может быть результатом MQL, созданного несколько недель назад. Поэтому ухудшение сначала может проявиться как сокращение спроса, затем MQL, SQL, Opportunities и лишь позднее — Deal. Если компания управляет только продажами, она обнаруживает проблему на самой поздней стадии.

Календарная агрегация также способна искажать реальность. Сравнение «MQL сентября» и «Deal сентября» не показывает истинную конверсию, если часть сентябрьских Deal возникла из августовских MQL, а часть сентябрьских MQL созреет только в октябре или ноябре.

Поэтому переход новой архитектуры можно выразить так:

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

Таблица 425. Традиционный и архитектурный прогноз

Таблицу можно прокручивать по горизонтали.

22.2. Прогнозируемый портфель спроса

Под прогнозируемым портфелем спроса (Forecastable Demand Portfolio) будем понимать совокупность существующих на дату прогноза Demand Episodes, которые статистически ещё способны привести к Deal в пределах рассматриваемого горизонта.

Не любой исторический объект входит в прогноз. Терминально завершённые эпизоды исключаются. Ключевой единицей прогнозирования является не Customer ID и не стадия воронки, а конкретный Demand Episode.

Один клиент может иметь несколько самостоятельных эпизодов спроса, но один Demand Episode должен учитываться в прогнозе только один раз — в своём наиболее актуальном состоянии.

Например, если эпизод прошёл MQL → SQL → Opportunity, нельзя одновременно считать его как три объекта прогнозного портфеля.

Будущий результат формируется из трёх источников:

1. уже существующего на дату прогноза портфеля;
2. нового спроса, который возникнет внутри горизонта;
3. повторного спроса, который возникнет из Ownership Episodes.

Основная формула главы:

Накопленный спрос является частью существующего портфеля, а не четвёртым независимым источником.

Таблица 426. Источники прогнозного результата

Таблицу можно прокручивать по горизонтали.

Прогнозируемый портфель является снимком на конкретную дату. Через неделю часть объектов станет Deal, часть перейдёт в другие состояния, часть состарится, появятся новые Demand Episodes. Поэтому портфель динамичен.

Таблица 427. Пример текущих состояний уникальных Demand Episodes

Таблицу можно прокручивать по горизонтали.

Все значения далее в автомобильных примерах являются условными.

22.3. Коммерческие состояния как основа прогноза

Коммерческое состояние — не просто строка CRM. Оно должно однозначно отвечать как минимум на три вопроса: что уже известно о Demand Episode, какое коммерческое событие произошло и какое событие должно произойти следующим.

Нормативная цепочка сохраняется:

Разные состояния обладают разной прогнозной информативностью. MQL подтверждает наличие целевого спроса, SQL — более глубокую квалификацию, Opportunity — конкретную коммерческую возможность. Deal является уже реализованным исходом и используется для обучения модели, расчёта лагов, когорт и проверки точности.

Важный принцип:

Но нельзя назначать стадиям произвольные веса вроде «SQL = 30%, Opportunity = 50%». Если значения не подтверждены историческими данными, это экспертные коэффициенты, а не наблюдаемые вероятности.

Точно так же:

и:

Состояния должны иметь воспроизводимые критерии входа и выхода, владельца и timestamp. Иначе одна и та же стадия будет означать разные вещи в разных подразделениях и прогноз потеряет статистическую устойчивость.

Таблица 428. Коммерческие состояния и их прогнозный смысл

Таблицу можно прокручивать по горизонтали.

22.4. Возраст объекта и вероятность созревания

Состояние отвечает на вопрос «где находится Demand Episode?», но прогноз требует второго измерения — времени.

Необходимо различать три величины:

Episode Age — сколько времени прошло с момента создания Demand Episode:

Time in State — сколько времени объект находится в текущем состоянии:

Lag — время между двумя конкретными событиями, например:

Эти величины не являются синонимами.

Для прогнозирования важна не только вероятность Deal вообще, а вероятность Deal в пределах заданного горизонта. Поэтому базовая вероятностная модель главы:

В некоторых процессах вероятность сначала растёт по мере созревания, а затем снижается из-за ageing. Поэтому нельзя универсально утверждать, что любой более старый объект хуже. Форма зависимости должна определяться данными.

Таблица 429. Возрастно-стадийная матрица

Таблицу можно прокручивать по горизонтали.

Ageing имеет не только прогнозное, но и диагностическое значение. Рост Time in State может отражать не ухудшение спроса, а bottleneck, высокий WIP, дефицит товара или слабое управление следующим действием.

22.5. Когортный анализ и кривые созревания

Когорта — совокупность сопоставимых Demand Episodes или коммерческих объектов с общей точкой отсчёта времени. Например, все MQL, созданные в одну неделю.

Когортный анализ исправляет одну из ключевых ошибок календарной воронки. Вместо сравнения «MQL сентября» с «Deal сентября» анализируется, какая доля MQL конкретной когорты стала Deal через 7, 14, 30, 60 и 90 дней.

Накопительная конверсия:

Пример:

Таблицу можно прокручивать по горизонтали.

Таблица 430. Пример кривой созревания когорты

Кривая показывает, какая часть результата уже реализована, сколько потенциала остаётся и когда когорта практически выходит на плато.

Неполные когорты нельзя сравнивать со зрелыми напрямую. Молодую когорту следует сравнивать со зрелыми когортами на одинаковом возрасте:

Иначе низкая текущая конверсия молодой когорты может быть ошибочно интерпретирована как ухудшение качества спроса.

Для объекта, который ещё не стал Deal к текущему возрасту, можно оценивать остаточную условную вероятность. Например:

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

Таблица 431. Зрелые и незрелые когорты

Таблицу можно прокручивать по горизонтали.

Исторические когорты служат мостом между прошлым и текущим портфелем:

22.6. Накопленный спрос и потенциал восстановления

Накопленный спрос — не архив старых лидов. Это Demand Episodes предыдущих периодов, не завершившиеся Deal, но не обязательно утратившие коммерческий потенциал.

Необходимо различать:

• Active;
• Maturing;
• Deferred;
• Nurture;
• Recycling;
• Recoverable;
• Dormant;
• Terminal.

Ключевой принцип:

но одновременно:

Recovery Potential — вероятность того, что неактивный Demand Episode вернётся в активное коммерческое состояние:

При согласованном горизонте прогнозный вклад recovery можно концептуально представить как:

Таблица 432. Классификация накопленного спроса

Таблицу можно прокручивать по горизонтали.

Причина закрытия — важный прогнозный признак. «Нет товара», «покупка отложена», «не отвечает», «купил у конкурента» могут иметь разную вероятность восстановления. Поэтому recovery следует оценивать по когортам причин и возрасту с момента закрытия.

Таблица 433. Пример Recovery Potential по причинам

Таблицу можно прокручивать по горизонтали.

Все значения условны.

22.7. Повторный спрос и Owner Management в прогнозе

После Deal коммерческая история клиента не заканчивается. Возникает Ownership Episode. Но владелец не является готовой Opportunity, поэтому недопустима прямая логика:

Правильная последовательность:

Повторный спрос следует отличать от recovery. Recovery возвращает существующий Demand Episode. Repeat Demand создаёт новый эпизод спроса у уже существующего клиента.

Для прогнозирования повторной сделки необходимо учитывать два события: вероятность появления нового Demand Episode и вероятность его дальнейшего созревания в Deal.

Owner Management особенно важен на более длинных горизонтах, поскольку на Forecast₉₀ возрастает доля результата, который ещё не существует в виде конкретных MQL, SQL и Opportunities.

Customer ID обеспечивает связь между эпизодами, но не должен смешивать их:

22.8. Вероятностная модель переходов

История переходов между состояниями позволяет оценить вероятности движения коммерческого потока. В простейшем виде:

Но для прогнозирования время критично, поэтому корректнее использовать:

Модель может оценивать как вероятность следующего перехода, например $P(Opportunity|SQL)$, так и конечную вероятность Deal в заданном горизонте.

После расчёта индивидуальных или групповых вероятностей ожидаемое число Deal определяется суммой вероятностей:

Таблица 434. Иллюстративная матрица переходов

Таблицу можно прокручивать по горизонтали.

Значения условны.

Марковская модель может использоваться как один из способов описания переходов:

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

Последовательность зрелости:

Сложность должна появляться после того, как корректны сами объекты, состояния и данные.

22.9. Пропускная способность и ограниченный прогноз

Даже если спрос существует и вероятность Deal оценена корректно, коммерческая система может не иметь возможности реализовать весь потенциал. Поэтому необходимо различать Potential Forecast и Realizable Forecast.

Capacity — максимальный объём коммерческой работы, который элемент системы способен обработать в заданном горизонте без разрушения качества процесса. Она существует на разных уровнях: LLM, Sales Operations, товар, Owner Management.

Особенно важно, что capacity не просто создаёт верхний предел результата. Перегрузка увеличивает WIP и Time in State, а это способно снижать transition probabilities.

Таблица 435. Пример ограничений capacity

Таблицу можно прокручивать по горизонтали.

Товарное ограничение должно оцениваться не только через количество автомобилей, но и через соответствие спроса конкретному mix моделей, комплектаций, цен и сроков поставки.

Если Demand > Capacity, дополнительный Lead Acquisition способен ухудшить систему: вырастет WIP, ageing и потери. Поэтому при Forecast Gap сначала необходимо определить, ограничена ли система спросом, capacity или товаром.

22.10. Прогноз на 30, 60 и 90 дней

Один и тот же портфель формирует разные прогнозы в зависимости от горизонта.

30 дней — операционный горизонт. Основная часть результата должна происходить из уже существующих SQL, Opportunities и Commercial Progression.

60 дней — тактический горизонт. Возрастает роль MQL, recoverable demand и нового входящего потока.

90 дней — планово-прогнозный горизонт. Значительная часть результата ещё не существует как конкретные Demand Episodes, поэтому растёт роль Demand Stimulation, Owner Management, рынка, будущей capacity и товара.

Таблица 436. Сравнение горизонтов

Таблицу можно прокручивать по горизонтали.

В книге Forecast₃₀, Forecast₆₀ и Forecast₉₀ трактуются как rolling horizon от даты прогноза. Календарный прогноз «до конца месяца» следует показывать отдельно.

22.11. Сценарный прогноз

Сценарий — это не механическое $Base\pm 10\mathrm{\%}$. Это согласованный набор предпосылок, который приводит к определённому будущему состоянию коммерческой системы.

Минимально используются три сценария:

• базовый;
• оптимистичный;
• стрессовый.

Базовый строится на текущем портфеле, наблюдаемых когортных вероятностях, текущей capacity, ожидаемом новом спросе и подтверждённом товаре. Оптимистичный отражает подтверждаемое улучшение предпосылок. Стрессовый — последствия реализации конкретных рисков.

Таблица 437. Сценарные предпосылки

Таблицу можно прокручивать по горизонтали.

Прогнозный диапазон и сценарий — разные понятия. Диапазон отражает неопределённость внутри одного набора предпосылок. Сценарии отражают разные наборы предпосылок.

Сценарные эффекты нельзя безусловно складывать: увеличение capacity может одновременно улучшать conversion, новый спрос использует ту же capacity, recovery увеличивает WIP. Поэтому взаимодействия необходимо учитывать при пересчёте.

22.12. План и прогноз: управление разрывом

План задаёт требуемый результат. Прогноз показывает вероятный результат при текущих условиях. Их разница формирует Forecast Gap:

Forecast Gap — ранний управленческий сигнал, а не просто будущий Plan–Fact. Его необходимо декомпозировать по причинам: дефицит спроса, недостаток SQL, низкий объём Opportunities, ageing, снижение transition probabilities, bottleneck, capacity или товар.

Нельзя закрывать любой Gap дополнительными лидами. Если ограничение находится в capacity или inventory, рост входящего спроса способен ухудшить ситуацию.

Полезно сопоставлять два направления:

Top-down requirement:

Bottom-up forecast — от существующего портфеля, вероятностей и capacity.

Разница между требуемым результатом и bottom-up forecast формирует Execution Gap.

Forecast Bridge декомпозирует путь от текущего прогноза к целевому сценарию:

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

Таблица 438. Пример Forecast Bridge

Таблицу можно прокручивать по горизонтали.

Forecast Bridge отличается от списка мероприятий тем, что для каждого действия фиксируется ожидаемое изменение прогноза.

22.13. Точность прогноза и обратная связь

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

Абсолютная процентная ошибка:

Для серии наблюдений может использоваться MAPE, но с оговорками для малых и нулевых фактических значений.

Кроме размера ошибки необходимо анализировать систематическое смещение:

Положительный Bias означает устойчивое завышение, отрицательный — устойчивое занижение.

Особенно важен Forecast Vintage — история версий прогноза на одну и ту же будущую дату. Он показывает не только финальную ошибку, но и то, насколько рано система распознала изменение траектории.

Таблица 439. Пример Forecast Vintage

Таблицу можно прокручивать по горизонтали.

Backtesting должен использовать только данные, которые были доступны на дату прогноза:

Иначе возникает data leakage.

Если модель присваивает вероятности Deal, необходимо проверять их калибровку: объекты с прогнозом около 70% должны в большой выборке становиться Deal примерно с сопоставимой частотой.

Финальный цикл обучения:

22.14. Управленческий контур прогнозирования

Даже качественная модель не создаёт эффекта без Governance. Должны быть определены Forecast Owner, Data Owners, Decision Rights, cadence пересчёта и единая официальная версия прогноза.

Forecast Owner отвечает не за выполнение плана продаж, а за целостность процесса прогнозирования: методологию, своевременность пересчёта, согласованность предпосылок, Forecast Review и историю версий.

Data Owners отвечают за качество конкретных слоёв: MQL, SQL, Opportunities, Deal, inventory, Ownership Episodes и другие данные.

Экспертные корректировки допустимы, но должны быть прозрачны. Например:

Тогда позднее можно понять, ошиблась модель или override.

Forecast Review должен включать текущий forecast, изменение относительно прошлого vintage, Gap to Plan, причины изменения, ключевые риски и решения.

Таблица 440. Роли в прогнозном контуре

Таблицу можно прокручивать по горизонтали.

Минимально жизнеспособный прогнозный контур включает: прогнозируемый объект, состояния, timestamps, историю переходов, cohort behavior, probabilities, horizon, capacity, Forecast Owner и Accuracy Feedback.

Зрелость прогнозирования можно описать как последовательность:

1. исторический run-rate;
2. pipeline-based forecast;
3. State + Age + Cohort;
4. Capacity-Constrained Forecast;
5. Dynamic Predictive Forecast.

Это авторская практическая градация, а не универсальный отраслевой стандарт.

22.15. От прогноза продаж к предиктивному управлению коммерческой системой

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

Эволюцию использования данных можно представить так:

• Descriptive — что произошло?
• Diagnostic — почему произошло?
• Forecasting — что, вероятнее всего, произойдёт?
• Predictive — где и когда возникнет риск или возможность?
• Prescriptive — какое действие способно изменить траекторию?

Предиктивное управление не начинается с AI. Оно возможно уже тогда, когда организация умеет использовать State, Age, Time in State, cohort curves, observed probabilities, WIP, capacity и Forecast Gap.

Главный объект управления смещается от уже состоявшегося Deal к текущему коммерческому состоянию, из которого Deal формируется.

Центральный управленческий цикл главы:

После изменения состояния прогноз пересчитывается:

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

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

Итог главы

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

Финальная архитектура главы:

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