Методы прогнозирования продаж: исходные данные, расчёт и проверка ошибки

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

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

Ниже — воспроизводимый синтетический пример. Это не клиентский кейс, не выгрузка из CRM и не измеренный результат Switch On AI.

Какое решение должен поддерживать прогноз

Слово «продажи» может обозначать разные показатели. До расчёта выберите один объект:

• выручка — сумма признанных продаж за период;
• число закрытых сделок — количество сделок, которые соответствуют согласованному признаку закрытия;
• спрос — обращения, заказы или другие события по определённому правилу учёта.

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

Следом зафиксируйте период и решение. Например: «Оценить недельную выручку на следующие три недели, чтобы руководитель согласовал нагрузку отдела и разобрал сделки с риском переноса». Формулировка связывает число с действием. Если отдел ничего не меняет при отклонении, польза прогноза не определена.

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

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

Какие данные собрать и как проверить качество

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

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

Сначала проверьте полноту календаря. Если между второй и четвёртой неделей нет третьей строки, это ещё не нулевая продажа. Возможны три разных состояния:

1. Продажи действительно были равны нулю.
2. Значение неизвестно: запись потеряна или выгрузка неполна.
3. Наблюдения не было: показатель тогда не собирали или объект ещё не работал.

Только первое состояние можно записать числом 0. Подстановка нуля вместо неизвестного значения снижает среднее и создаёт событие, которого не было. Пропуск нужно восстановить из источника либо явно исключить по заранее записанному правилу. Причину исключения сохраняют вместе с расчётом.

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

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

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

Как выбрать метод прогнозирования

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

Модель «последнее значение» предполагает, что следующий период похож на последний известный. Среднее нескольких периодов сглаживает обычные колебания, но реагирует на выбросы. Обе модели просты, однако именно поэтому подходят как базовая проверка для более сложного прогнозирования.

Воронка полезна, когда результат зависит от уже открытых возможностей. Руководитель может считать ожидаемое значение как сумму сделок с согласованными весами стадий. Но вес 70% не становится фактом только потому, что его записали в CRM. Его нужно определить и затем проверять на истории сопоставимых сделок.

Временной ряд работает с порядком наблюдений. Он может описывать тренд и сезонность, если история достаточно длинная и сопоставимая. Набор из нескольких недель годится для объяснения проверки, но не для заявления о найденной сезонности или будущей бизнес-точности.

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

У конкретных продуктов есть собственные условия. Согласно предоставленной официальной документации Microsoft, predictive forecasting в стандартных приложениях Dynamics 365 Sales Hub и Sales Professional оценивает выручку по историческим результатам и текущей воронке. Документация требует включённой predictive opportunity scoring как минимум с одной настроенной моделью, функции premium forecasting, подходящей лицензии и необходимых ролей. При недостатке данных столбец прогноза остаётся пустым; документ также указывает автоматический пересчёт раз в семь дней без ручного запуска. Это описание функции Dynamics 365, а не результат нашего теста, не подтверждение совместимости с системой конкретной компании и не гарантия точности. Тариф, права, конфигурацию и доступность API нужно проверять отдельно перед проектом.

Как проверить прогноз на отложенном периоде

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

Порядок проверки:

1. Задайте показатель, шаг времени и горизонт.
2. Выберите границу истории и проверочного периода.
3. Рассчитайте базовый прогноз, не используя факты проверочного периода.
4. Сравните прогноз и факт одной формулой для всех моделей.
5. Разберите строки с большой ошибкой и только затем меняйте метод или данные.

В учебном примере история — недели 1–6, проверочный период — недели 7–9, горизонт — три недели. Мы фиксируем его до просмотра фактов недель 7–9. Если после ошибки передвигать границу или менять горизонт только ради лучшего числа, проверка перестаёт быть честной.

Для одной недели используем абсолютную ошибку:

AE = |факт − прогноз|

Она измеряется в тех же единицах, что и показатель. Средняя абсолютная ошибка на трёх неделях:

MAE = (AE₇ + AE₈ + AE₉) / 3

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

Обычная процентная ошибка для отдельной строки имеет знаменатель «факт»:

APE = |факт − прогноз| / |факт| × 100%

При нулевом факте деление на ноль не определено. Нельзя незаметно записать 0%, 100% или заменить знаменатель единицей. Для такой строки оставляют абсолютную ошибку и отмечают, что APE и обычная MAPE неприменимы. Если бизнесу нужна агрегированная относительная метрика, её формулу, смысл и поведение при нулях выбирают отдельно до сравнения моделей.

Учебное сравнение двух прогнозов

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

• история, недели 1–6: 100, 110, 0, 120, 130, 600;
• проверочный период, недели 7–9: 140, 0, 150.

Ноль в третьей и восьмой неделе означает именно подтверждённое отсутствие продаж, а не пропуск. Значение 600 обозначает крупную сделку. Это учебное условие; оно не описывает данные или результаты клиента Switch On AI.

Первая базовая модель переносит последнее известное значение. На момент расчёта это неделя 6:

Прогноз последним значением = 600

На всём заранее установленном горизонте из трёх недель прогноз остаётся равным 600. Факты недель 7–9 при расчёте не используются.

Вторая модель берёт среднее только по истории:

Среднее = (100 + 110 + 0 + 120 + 130 + 600) / 6 = 1060 / 6 = 530 / 3 ≈ 176,67

Для точного итогового расчёта сохраняем дробь 530 / 3, а 176,67 используем только для отображения.

Для модели последнего значения:

Сумма AE = 460 + 600 + 450 = 1510

MAE = 1510 / 3 ≈ 503,33

Для среднего считаем по точному значению 530 / 3, а не складываем преждевременно округлённые числа:

AE₇ = |140 − 530/3| = 110/3

AE₈ = |0 − 530/3| = 530/3

AE₉ = |150 − 530/3| = 80/3

Сумма AE = (110 + 530 + 80) / 3 = 240

MAE = 240 / 3 = 80

На этих трёх учебных неделях среднее ошибается меньше, чем перенос последнего значения. Это не доказывает его превосходство в реальном бизнесе: выборка короткая, а результат сильно зависит от значения 600.

Отдельный сценарий без повторения крупной сделки

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

(100 + 110 + 0 + 120 + 130) / 5 = 460 / 5 = 92

Прогноз 92 даёт ошибки:

• неделя 7: |140 − 92| = 48;
• неделя 8: |0 − 92| = 92;
• неделя 9: |150 − 92| = 58.

Сумма AE = 48 + 92 + 58 = 198

MAE = 198 / 3 = 66

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

Как внедрить прогноз в работу руководителя

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

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

Диапазон неопределённости нельзя автоматически объявлять равным прогноз ± MAE без отдельного правила и проверки. На короткой истории MAE нестабильна и сама зависит от нескольких наблюдений. Способ построения диапазона, минимальный объём истории и допустимый уровень риска нужно согласовать для конкретного процесса. До этого диапазон остаётся параметром будущего прототипа, а не готовым обещанием.

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

Switch On AI может помочь разобрать одну такую операцию, подготовить данные и спроектировать проверяемый расчёт в составе разработки ИИ-агента или подходящей автоматизации. Сначала нужно проверить качество истории, доступные API, права и ограничения систем. Конкретная совместимость, лицензии и состав подключений определяются отдельно; работа с 1С в эту услугу не входит. Прототип ключевого сценария помогает согласовать логику, но не равен полноценному внедрению и не гарантирует будущие продажи.

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