Чому прогнозування продажів ламається на сезонних зсувах
Ручне планування зазвичай виглядає так: беруть продажі минулого періоду, множать на коефіцієнт і додають запас «про всяк випадок». Поки попит рівний, така таблиця влучає в ціль.
Але сезонні коливання попиту рідко повторюються день у день — пік зсувається на два-три тижні, і закупівля приходить до кінця сплеску, коли полиця вже порожня.
Друге джерело промаху — запізнення даних. Факт із облікової системи приїжджає вигрузкою раз на добу або рідше, частина каналів закривається із затримкою в кілька днів, а рішення про закупівлю та відвантаження ухвалюється раніше, ніж видно поточний рух.
Окремо розходяться довідники: у роздрібі, на маркетплейсах і в опті один товар живе під різними кодами й у різних одиницях, тому звести канали в одну картину вручну не виходить.
Акції та новинки ламають історію ще сильніше. Сплеск від розпродажу в даних виглядає як стійке зростання, його переносять у майбутній план і закуповують зайве. Новий товар приходить без сезонного профілю й без розуміння, які позиції він забере в сусідніх.
Ціна помилки подвійна: склад заповнюється тим, що не продається, а за ходовими позиціями виникає дефіцит і втрачений виторг, який уже не повернути.
Розбираємо, як це закривається: де в контурі прогнозування продажів з’являються дані, як рахуються сезонні індекси й як план звіряється з фактом.
Що дає керований прогноз попиту: ефект у цифрах
Ефект від моделі видно не у звітах про навчання, а в операційних метриках: як часто ходовий товар закінчується, скільки оборотних коштів завмерло на складі, наскільки рівно завантажені площі та зміни. Нижче чотири виміри, за якими ми порівнюємо стан до й після запуску прогнозування продажів.
Точність прогнозу на денному та тижневому горизонті
Модель на CatBoost рахує прогноз за кожною позицією окремо, а не за середньою категорією: історія відвантажень, сезонність, промо-календар, доступність товару на полиці.
На денному горизонті помилка за ходовими позиціями скорочується приблизно вдвічі — закупівля йде від прогнозу, а не від середнього за минулий період.
Дефіцит ходових позицій
Раніше сплеск попиту виявлявся за фактом — коли полиця вже порожня, а поставка прийде через тиждень.
Інтервальна оцінка прогнозу піднімає сигнал заздалегідь: частка днів «немає в наявності» за топом скорочується в рази, а втрачений попит не переходить у скасування та перехід до конкурента.
Заморожені залишки та оборотність запасів
Зворотний бік ручного плану — страховий запас «про всяк випадок» за всім асортиментом. Модель задає різну глибину запасу для стабільних і волатильних позицій: оборотність запасів прискорюється, частка неліквіду й товару, що пережив свій сезон, падає на третину.
Знятий клас помилок планування
Промо, стрибок цін, затримка поставки — ручний план ламається цілком і мовчки. Ми перевіряємо прогноз на стійкість і позначаємо позиції з високою невизначеністю для ручного рішення: клас помилок «зсув помітили надто пізно» зникає, зміну попиту видно за тижні до дефіциту.
Формати моделей прогнозування продажів: регресія та ансамблі
Вибір моделі прогнозування продажів диктує структура даних, а не складність алгоритму: довжина історії, горизонт планування, кількість рядів і те, як часто з’являються промо, зміна ціни та нові позиції. Нижче — чотири реальні альтернативи, між якими зазвичай іде вибір, з чесними обмеженнями кожної.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Проста регресія на лагах і ознаках | Стійкий тренд, десятки рядів, горизонт у межах одного циклу угоди | Не тримає нелінійні взаємодії «промо × канал», роз’їжджається на рідкісних подіях |
| Сезонні моделі (декомпозиція та експоненційне згладжування) | Виражена тижнева або річна сезонність, стабільна історія на два сезони й більше | Важко переживає структурні зсуви та відкриття нових точок, параметри потрібно переналаштовувати вручну |
| Ансамбль моделей (градієнтний бустинг на деревах і на часових рядах) | Сотні та тисячі позицій, десятки ознак, часта ціна та промо | Потрібні вітрина ознак і моніторинг дрейфу: без нього помилка зростає непомітно, пояснюваність нижча |
| Гібридний підхід: модель плюс правила експертів | Запуск нових категорій, дефіцит історії, жорсткі правила щодо мінімальної партії та лімітів складу | Правила треба версіонувати й підтримувати, є ризик зашити в них думку експерта замість даних |
На практиці варіант не вибирають «на око»: спочатку рахуємо базовий прогноз і наївну модель як точку відліку, потім проганяємо кандидатів на ковзному вікні й дивимося помилку окремо за топовими позиціями, новинками та промо-тижнями.
Часто підсумком стає ансамбль або гібрид — але вже з цифрами, що показують, де саме складна модель виграє у простої.
Як ми впроваджуємо прогнозну модель: етапи роботи
Прогноз продажів перестає приносити користь, коли його будують у відриві від даних і від процесу планування. Тому маршрут починається не з вибору алгоритму, а з аудиту джерел, і закінчується прийманням якості прогнозу на вашій стороні — на узгоджених метриках, а не на обіцянках.
- Аудит даних. Розбираємо джерела: облікову систему, склад, веб-аналітику, вигрузки з маркетплейсів. Дивимося глибину історії, затримки надходження, дублі, пропуски та зміну довідників — фіксуємо, чого не вистачає і що доведеться відновлювати.
- Схема та вітрина. Узгоджуємо гранулярність (день або тиждень, точка продажів, товарна група), ключі та правила перерахунку історії. Отримуємо відтворюваний шар, з якого модель бере дані однаково за кожного запуску.
- Проєктування ознак. Сезонність і календарні лаги, акції, ціни, наявність, поведінка постійних клієнтів. Кожну ознаку перевіряємо на стійкість за роками та на відсутність витоку даних із майбутнього.
- Навчання та валідація моделі. Історію ділимо за часом, а не випадково: інакше якість на перевірці виявляється завищеною. Порівнюємо результат із простим базовим прогнозом і з поточним плануванням, дивимося помилку окремо за горизонтами та групами товарів.
- Впровадження прогнозу. Оновлення за розкладом, видача у зручному контурі — звіт, вітрина або пряма передача у вашу систему. Відразу налаштовуємо моніторинг: розходження факту з прогнозом, деградація, зсув сезонності.
- Приймання та передача в експлуатацію. Регламент перенавчання, розбір інцидентів, навчання вашої команди. Приймання йде за метриками якості прогнозу, зафіксованими до початку робіт.
Кожен етап закривається артефактом: схемою даних, набором ознак, звітом про якість, регламентом. Якщо на аудиті видно, що даних для чесного прогнозу не вистачає, скажемо про це до старту, а не після.
Що ви отримуєте на руки: артефакти та регламенти
Передаємо не звіт із графіком, а робочий контур прогнозування: від опису джерел до регламенту, за яким модель оновлює ваша команда.
У кожного артефакту є власник і версія в репозиторії, склад фіксується під час здачі — рішення можна розвивати своїми силами або передати іншому підряднику без археології по коду.
- Схема потоків даних — які системи віддають факти продажів, з якою періодичністю, де відбувається очищення й агрегація та які поля обов’язкові на вході моделі.
- Словник метрик — єдині визначення виторгу, відвантажень, повернень і періоду визнання; узгоджуємо до старту, щоб прогноз і звітність рахували одне й те саме однаково.
- Налаштований контур перерахунку — прогноз оновлюється за розкладом, ведеться журнал запусків, у разі збою приходить оповіщення із зазначенням кроку, що впав.
- Регламент перенавчання — тригери (просадка якості, зміна асортименту або промо-календаря), порядок запуску та критерії приймання нової версії моделі.
- Контроль дрейфу — порівняння розподілу вхідних даних і цільової змінної з еталонним періодом, звіт «прогноз проти факту» за групами товарів.
- Регламент експлуатації — хто володіє моделлю, як відкотитися на попередню версію, що робити при деградації якості та куди звертатися при інциденті.
- Документація та навчання команди — опис ознак, інструкції із запуску, розбір типових збоїв і практичні заняття з вашими аналітиками.
Кейс: точність планування в роздрібі до та після
Мережа з трьома каналами збуту — роздрібні точки, інтернет-магазин і маркетплейси — планувала поставки в електронних таблицях.
Закупівельник брав середні продажі за минулий період і вручну коригував їх під акції, а рішення про дозамовлення ухвалювалося за поточним залишком і досвідом.
Що було до впровадження
Базову лінію знімали два тижні за трьома групами метрик: частка позицій у дефіциті, обсяг надлишкових запасів і трудовитрати планувальників.
На старті дефіцит тримався на 11–14% асортименту, оборотність товарних запасів сягала 74 днів, а двоє планувальників витрачали на перерахунок плану близько 30 годин на тиждень.
Що змінилося після
Модель рахує попит на рівні «позиція — точка — тиждень», окремо враховує промо, сезонність і графік поставок, перерахунок іде щодня. Планувальник більше не будує план з нуля: він розбирає лише позиції з відхиленням вище порогу — це 5–8% асортименту. Такий перехід ми робили для мережі «Меридіан».
За два квартали дефіцит опустився до 4–6%, оборотність скоротилася до 51 дня, точність відвантажень у строк зросла з 82% до 96%, а списання за термінами придатності впали майже вдвічі.
Трудовитрати на планування — близько 9 годин на тиждень замість 30; вивільнений час пішов на роботу з постачальниками та локальні акції.
Чим потоковий перерахунок відрізняється від нічного пакетного
Різниця в тому, у який момент рахується прогноз. За пакетного перерахунку завдання раз на добу читає всю історію продажів, перенавчає модель і записує результат у вітрину — до наступного запуску числа не змінюються.
Затримка прогнозу дорівнює періоду розкладу, зате навантаження на систему передбачуване: важкий перерахунок іде вночі, коли з ним конкурують лише регламентні вигрузки.
Потокове оновлення працює за подіями: замовлення, повернення, зміна залишку потрапляють у чергу, і модель перераховує прогноз у міру надходження.
Затримка падає до хвилин, але навантаження стає рівним і цілодобовим, а до моделі додається контроль зміщення — інакше потоковий перерахунок поступово веде прогноз убік, і це помічають лише за фактом промаху.
Потоковий режим виправданий там, де на прогнозі стоять дії: динамічна ціна, поповнення складу, пріоритет відвантаження, відсікання підозрілих замовлень.
Де рішення ухвалюється раз на тиждень — план закупівель, бюджет, завантаження виробництва — нічного пакетного перерахунку достатньо, і він дешевший у супроводі.
На практиці частіше ставлять гібрид: уночі модель перенавчається на повній історії, удень потік донавчає її на свіжих даних і перераховує лише задіяні позиції.
Такий розклад ми збираємо в Apache Airflow — один контур відповідає і за пакетний перерахунок, і за потокове оновлення, тому розходження між вітриною та моделлю не накопичується.
Часті технічні сумніви перед стартом
Перед стартом обговорюємо не вибір моделі, а два питання: чи вистачає даних і як прогноз вбудується в поточний обліковий контур. Нижче — чотири сумніви, які найчастіше гальмують проєкт, і як ми їх закриваємо.
Скільки історії потрібно, щоб прогноз працював?
Для сезонних рядів потрібно мінімум два повних річних цикли, краще три: інакше тренд не відокремлюється від разового сплеску. За короткої історії підключаємо зовнішні ряди — акції, свята — і стартуємо з прогнозу за категоріями, а не за кожною позицією.
Дані лежать у різних системах — це завада?
Завада не в розрізненості, а у відсутності спільного ключа. Зводимо облік, каси, склад та інтернет-магазин в єдиний шар, довідники товарів і точок приводимо до одного ідентифікатора.
Розходження не ховаємо, а показуємо: незбіжність залишків у пару відсотків зазвичай пояснює частину помилки прогнозу.
Як прогнозувати новинки, за якими немає історії?
За новим артикулом учити нічого, тому переносимо закономірності зі схожих позицій — за категорією, ціновим сегментом, сезоном і полицею. Перші тижні прогноз іде за групою, далі вага власних продажів зростає, і модель переходить на історію самого товару.
Як вбудувати прогноз в облікову систему?
Облік не підмінюємо: прогноз повертається в нього вигрузкою з розбивкою за горизонтами та версіями, щоб будь-яку версію можна було перерахувати й порівняти з фактом. Планувальник залишається у звичному інтерфейсі й бачить поруч прогноз, факт і відхилення.
Обговоримо вашу задачу та повернемося з планом робіт
Щоб обговорення задачі перетворилося на розрахунок строків, а не на переказ загальних слів, почнемо з розмови про ваші дані та процес планування.
Нам важливо зрозуміти, які джерела історії продажів доступні, з якою деталізацією і що вже відомо про майбутній період: від цього залежить і клас моделі, і обсяг робіт.
- які вигрузки є зараз — глибина історії, деталізація за точками та каналами, повнота даних про повернення й скасування;
- що відомо про майбутній період: графік акцій і знижок, поставки, сезонні обмеження, зміни асортименту;
- як план будується сьогодні, хто ним користується і як часто він перераховується — від цього залежить горизонт прогнозу;
- які системи віддають дані та чи можна забирати їх за розкладом, без ручних вигрузок;
- яка помилка прогнозу критична: переоцінка веде до затоварювання складу, недооцінка — до дефіциту та втрачених продажів;
- хто з боку замовника відповідає за дані, приймання результату та подальшу експлуатацію.
Повертаємося з планом робіт: перелік етапів, оцінка строків за кожним, склад команди та вимоги до даних, які потрібно закрити до старту.
Окремо описуємо передачу моделі — документацію за ознаками та метриками якості, навчання вашої команди, порядок перенавчання та контроль точності після запуску. Опишіть задачу — повернемося з оцінкою та планом.
