Чому прогнозування попиту дає збій на реальних даних
Прогнозування попиту ламається частіше не на алгоритмі, а на даних. Модель, навчена на охайній історії, на реальній вигрузці бачить інше: дні з нульовим залишком, перейменовану номенклатуру, задвоєні позиції після об'єднання складів, розірвані ряди при зміні облікової системи.
Помилка прогнозу зростає, хоча метод не змінювався — відновити попит за такою історією просто нема чим.
Окремий клас — нерегулярні продажі. Товар іде кілька разів на місяць: медіана дорівнює нулю при великому розкиді, і будь-яка усереднювальна модель видає або нулі, або рівну «середню» полицю, якій не відповідає жоден день.
Сезонність додає складності: річний цикл стійко видно лише на двох-трьох повних періодах, а піки свят щороку зсуваються, тому їх не можна прив'язати до календарної дати.
Акції, розпродажі, нові точки та новинки — це події без передісторії. Сплеск від акції модель приймає за зростання попиту і переносить у базову лінію, після чого прогноз залишається завищеним ще кілька тижнів.
У нової точки немає ні сезонного профілю, ні локальних звичок покупця — тут працює лише перенесення профілю зі схожих об'єктів.
Найнепомітніше джерело розходжень — ручні правки плану. Планувальник коригує цифру зі знанням ринку, але правки не зберігаються окремим шаром, модель на них не вчиться, а якість рахують за вже скоригованим планом: метрика показує точність, якої в реальності немає. Розбираємо, як це закривається.
Що дає модель: ефекти в запасах і плануванні
Модель прогнозує не одне число на всю мережу, а ієрархію: товарна позиція — склад — тиждень, з окремими сезонними профілями для кожної групи.
Точковий прогноз доповнюється квантильними межами, тому план закупівлі будується не від «середнього», а від рівня обслуговування, який ви задаєте самі. На ретро-періоді середня помилка тримається в діапазоні 12–18% проти 30–40% у планування «від минулого місяця».
Звідси перший вимірюваний ефект — оборотність запасів. Надлишки на складі з'являються там, де планувальник перестраховувався: модель враховує внесок акцій, свят і сезонності, але не роздуває запас за позиціями зі стійким попитом. Страховий запас рахується від волатильності попиту і терміну постачання, а не «на око».
З іншого боку закриваються втрачені продажі: дефіцит за ходовими позиціями видно за 2–4 тижні до піку і потрапляє в замовлення раніше, ніж полиця спорожніє.
Ансамбль моделей на табличних ознаках, наприклад LightGBM, перенавчається за розкладом — зсуви попиту підхоплюються без переписування правил вручну.
Цикл планування стискається: замість тижневого збору даних по підрозділах прогноз і рекомендація щодо замовлення готові до ранкової звірки. Разом із ручним плануванням іде цілий клас помилок — забуті акції, дублі замовлень, різні версії файлу в суміжних відділів.
Точність прогнозу перевіряємо до запуску: ретро-тест показує, як модель відпрацювала б минулі сезони, і в контур планування вона потрапляє лише після цього.
Підходи до прогнозування попиту: статистика і машинне навчання
Вибір між статистичною моделлю і машинним навчанням — не питання «новіше означає краще». Його визначають горизонт планування, довжина історії продажів і те, скільки зовнішніх чинників реально рухає попит.
Відкриті інструменти на кшталт Prophet дають базову лінію через розкладання тренду і сезонності — її рахують до того, як ускладнювати модель.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Статистична модель (сезонне згладжування, ARIMA) | Рівний ряд, стійка сезонність, короткий і середній горизонт, мало історії за товаром | Акції, промо, погода і відкриття сусідньої точки в модель не входять — зовнішні зсуви ламають прогноз |
| Машинне навчання на ознаках | Тисячі позицій, є історія цін, промо, календаря і постачань | Потрібні підготовлені ознаки і контроль витоків; на рідкісних рядах модель перенавчається |
| Ієрархічний прогноз | Прогноз потрібен одразу за товаром, категорією і складом | Рівні потрібно узгоджувати, інакше суми не сходяться і план закупівель розходиться з фактом |
| Ансамбль моделей | Ряди різнорідні: частина рівні, частина рвані | Дорожче в підтримці, потрібен моніторинг внеску кожної моделі та перезбирання при зміні асортименту |
Далі вирішує горизонт планування. На один-два тижні статистика часто не поступається машинному навчанню, а на квартал і далі без зовнішніх ознак прогноз стає інерційним.
Тому ми порівнюємо кілька варіантів на вашій історії і залишаємо той, що тримає точність на потрібному горизонті, — а не той, що складніше влаштований.
Етапи впровадження: від аудиту даних до передачі моделі
Порядок етапів тут важливіший за швидкість: у прогнозуванні попиту якість даних впливає на результат сильніше, ніж вибір алгоритму. Тому ми починаємо з аудиту джерел і закінчуємо передачею моделі команді замовника, а не навпаки.
- Аудит даних. Звіряємо продажі з кас і облікових систем із залишками і постачаннями, знаходимо періоди, де нульові продажі означають відсутність товару на полиці, а не відсутність попиту. Окремо збираємо промо-календар, ціни, графік відвантажень і свята — без них модель пояснює сплеск випадковістю.
- Схема даних. Фіксуємо гранулярність (товар × точка × день), правила агрегації, обробку повернень, скасувань і лагів постачання. На виході — вітрина, з якої ознака перезбирається однією і тією самою процедурою під час навчання і під час роботи в реальному контурі.
- Побудова і налаштування моделі. Рахуємо базову лінію за зіставними тижнями як точку відліку, потім додаємо сезонність, регресію і відбір ознак. Перевіряємо якість ковзним вікном за часом, а не випадковим розбиттям вибірки.
- Валідація на відкладеному періоді. Останні тижні тримаємо поза навчанням і рахуємо помилку за кожною групою товарів. Там, де прогноз гірший за базову лінію, повертаємося до даних, а не підкручуємо коефіцієнти.
- Перевірка в робочому процесі. Прогноз іде в закупівлю і планування виробництва, звіряється з рішенням категорійного менеджера — так видно, де розходження спричинене даними, а де зміною самого ринку.
- Передача моделі і навчання команди. Віддаємо документацію за ознаками, регламент перенавчання, запуск за розкладом і контроль відхилень прогнозу від факту. Інженери замовника далі ведуть модель самостійно.
Обговоримо вашу задачу — повернемося з оцінкою і планом за етапами.
Артефакти проєкту: схема даних, модель, регламент оновлення
Проєкт із прогнозування попиту цінний не самою моделлю, а тим, що залишається в контурі замовника після здачі. Ми передаємо не лише прогнози, а й повний комплект: звідки беруться дані, як відтворити розрахунок і що робити, коли поведінка попиту змінюється. Нижче — мінімальний набір артефактів, без яких модель за місяць перетворюється на чорну скриньку.
- Конфігурації розрахунку: горизонт прогнозу, гранулярність (товар, склад, день), параметри сезонності, правила обробки промо і періодів дефіциту — з поясненням, чому вибрано кожен параметр.
- Схеми потоків даних: джерела, розклад вигрузок, точки контролю якості на вході та карта перетворень від сирих транзакцій до ознак.
- Політики доступу: ролі за групами товарів і складами, розділення «бачить сирі дані» і «бачить лише прогноз», журналювання звернень до вигрузок.
- Документація моделі: які ознаки впливають на результат, на якому періоді вона перевірялася, де межі застосовності і що вважається виходом за них.
- Регламент перенавчання: умови запуску (зсув попиту, накопичення нових продажів, сезон), періодичність, хто ініціює і як результат перевіряється до публікації.
- Моніторинг якості: щоденні метрики помилки за групами товарів, контроль зміщення прогнозу, оповіщення при виході за поріг.
- Інструкція із супроводу: типові збої, порядок відкату на попередню версію моделі, зони відповідальності та контакти інженерів.
Такий комплект дозволяє вашій команді змінювати параметри і перезапускати розрахунок самостійно, а нас підключати лише до розвитку — а не до щомісячного «підтримання життя».
Кейс: залишки і втрачені продажі до і після впровадження
Мережа зі 180 магазинів і близько 12 тисяч активних позицій. Прогноз будували за середніми продажами минулих періодів: на акції, погоду і локальні сплески він не реагував, тому планувальники правили цифри руками.
Замовлення йшли в облікову систему 1С:ERP вже з поправками «на око», а розходження з фактом розбирали постфактум.
Що показав замір
| Метрика | До | Після |
|---|---|---|
| Частка ручних коригувань прогнозу | 34% позицій | 9% |
| Точність на горизонті 7 днів | 71% | 88% |
| Точність на горизонті 30 днів | 62% | 79% |
| Рівень запасів, днів покриття | 48 | 33 |
| Втрачені продажі, частка попиту | 7,4% | 2,6% |
Що змінили: прогноз розділили за рівнями — мережа, магазин, товарна група, окремий товар — і додали ознаки акцій, цін, свят і наявності на полиці. Гіпотези перевіряли ретро-тестом на двох сезонах, у роботу йшла лише та, що покращувала точність на обох горизонтах.
Ручні коригування не прибрали, а зробили винятком: система підсвічує позиції, де прогноз розходиться з фактом, і правка планувальника зберігається як правило для схожих випадків.
Запас перестав бути страховкою від помилки прогнозу — його скоротили на третину, а втрачені продажі знизилися майже втричі без зростання списань за термінами придатності.
Що робити, якщо дані розкидані по кількох системах?
Прогноз будується за однією часовою шкалою, тому розрізнені джерела перш за все приводимо до спільного зерна — день і склад.
Зведення даних майже завжди розкриває розходження: десь продажі списані за відвантаженням, десь за оплатою, в інтернет-магазину залишки живуть окремо від складу. Поки ці визначення не узгоджені, модель вчиться на суперечливих рядах і видає коливання замість сезонності.
Ключ до всього — єдиний довідник товарів. Ми будуємо таблицю відповідностей: внутрішній код, артикул постачальника, штрихкод, назва в кожній системі, ієрархія категорій.
Дублі, перейменування і заміни упаковки закриваються правилами, а не ручною правкою — інакше історія товару рветься на кілька коротких рядів.
Далі — якість вигрузок. Перевіряємо повноту за датами і точками продажів, ловимо пропущені дні, від'ємні залишки, задвоєні документи і правки заднім числом.
Кожне завантаження проходить контроль сходження: сума відвантажень сходиться з рухом по складу, а розходження йдуть в окремий звіт, а не в модель.
Історичні дані зберігаємо в незмінному вигляді: навіть після перебудови довідника минулі періоди залишаються в початковому розміченні. Для сезонних категорій потрібна глибина у два-три повних цикли — тоді модель відрізняє зростання від сезонного піку. Якщо історії мало, відновлюємо її з архівів і вводимо поправку на період.
На виході — вітрина даних із датою зрізу і версією довідника. Це дозволяє перезібрати прогноз на будь-яку дату і порівняти результат; без такої основи будь-яка модель дає гарні, але неправильні числа.
Технічні сумніви: дані, якість, інтеграція
Сумніви перед стартом зазвичай стосуються не моделі, а даних, доступу до облікової системи і того, що буде з прогнозом за півроку. Нижче — відповіді на питання, які найчастіше ставлять технічні керівники.
Скільки історії продажів потрібно для стійкого прогнозу?
Для сезонних груп — два повних цикли: модель встигає вивчити річний профіль і святкові сплески. Якщо історії менше, стартуємо на агрегованих групах і короткому горизонті, а окремі позиції підключаємо в міру накопичення. Пропуски відновлюємо за відвантаженнями, залишками і аналогами.
Як прогноз вбудовується в облікову систему?
Через окремий контур читання: вигрузки в проміжне сховище або підключення до репліки. Продуктивна база не навантажується, права — лише на читання. Зіставлення довідників живе окремим шаром, тому перейменування номенклатури не ламає розрахунок.
Як забезпечується захист даних?
Розрахунок іде у вашому контурі або в ізольованому, доступ розмежований за ролями і журналюється. Персональні ознаки обезлюднюються там, де вони не потрібні для розрахунку, а ключі доступу зберігаються в захищеному сховищі, а не в коді.
Хто супроводжує модель після запуску?
Без супроводу прогноз деградує: змінюється асортимент, акції, постачальники. Тому в контур вбудовані контроль розходження прогнозу і факту та автоматичне перезбирання при виході за поріг. Поправки планувальника повертаються в модель як ознака.
Обговоримо вашу задачу і повернемося з планом
Предметна розмова про прогнозування попиту тримається на двох речах: на історії продажів і на тому, як рішення вбудується в поточний процес планування. Чим точніше ви описуєте склад даних і горизонт прогнозу, тим менше допущень в оцінці проєкту. Нижче — що корисно підготувати до обговорення задачі.
- Історія відвантажень і продажів — вигрузка за достатній період у розрізі товару і точки, з відмітками повернень, списань і обнулень залишку. Це база для оцінки проєкту: за нею одразу видно, чи вистачає даних на сезонність і на рідкісні позиції.
- Календар промо і зовнішніх подій — акції, свята, зміни цін, постачання і перебої. Без них модель припише сплески попиту, а не рішенню про знижку.
- Ієрархія товарів і локацій — товарні категорії, склади, магазини або виробничі лінії. Вона задає, на якому рівні будувати прогноз і як агрегувати результат.
- Горизонт і крок прогнозу — на скільки днів або тижнів уперед і з якою частотою перерахунок. Це визначає і склад даних, і терміни впровадження.
- Поточний процес планування — хто і в який момент ухвалює рішення про закупівлю або виробництво, де прогноз має з'явитися: в обліковій системі, у звітності чи в окремому інтерфейсі.
- Цільова точність і ціна помилки — як рахується розходження і яка помилка допустима для різних категорій. Для ходових позицій і для довгого хвоста вимоги різні.
- Обмеження за даними і доступами — що не можна вигружати за периметр, які системи доведеться зв'язати, хто з боку вашої команди підтверджує доступи.
Опишіть задачу — повернемося з оцінкою проєкту і планом робіт, де буде зафіксовано, які дані потрібні на старті, що можна додати пізніше і як перевіряємо результат.
