Прогноз

Прогноз попиту, навантаження та ключових показників — розрахований з вашої історії та з того, що відбувається ззовні: сезону, погоди та подій у місті.

• AURA THINKРівень
• IntelligenceСім'я
• в абонементі AURAОплата

Проблема

Попит нерівномірний, а графік змін, замовлення постачальникам та кампанії рідко встигають за його ритмом. Вівторок стоїть порожнім, у п'ятницю вистраюється черга, а рішення про зміну та товар приймаються «як зазвичай» — тобто за минулим тижнем та за відчуттям. Заднім числом завжди зрозуміло, як було; зазради цього не знає ніхто.

Що робимо

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

• Основа — ваша власна історія продажів, а не галузеве середнє
• До історії додаємо сезонність та зовнішні сигнали: погоду, події, вихідні
• Прогноз — це число з діапазоном, а не одна обіцянка, і показуємо ми його саме так

Що входить

Чотири елементи; останній і відрізняє прогноз від ворожіння:

• Історія продажів та потоку, приведена в порядок настільки, щоб по ній можна було рахувати
• Сезонність та повторювані ритми тижня
• Зовнішні сигнали: погода, події в місті, вихідні
• Звірка прогнозу з тим, що відбулося насправді

Терміни

Модуль не запускається окремо — він включається разом з рівнем AURA, до якого входить. Зате у нього є власна умова старту: прогноз рахується з історії, тому поки історії немає в системі, будувати його немає з чого. Чим довше модуль працює, тим більше йому є з чим порівнювати — тому звірка прогнозу з фактом входить в обсяг з першого дня, а не додається потім.

Вартість

Прогноз не можна вийняти із системи і продати окремо — він рахується з історії, яку збирають решта модулів, і без них показував би порожню вісь. Розрахунок іде за всю систему в закладі. Скільки саме — виходить із того, наскільки довгу історію ви вже маєте і скільки місць треба передбачати одночасно.

Прогноз попиту входить в рівень THINK. На рівні SEE залишаються показники та базові зовнішні сигнали, тобто те, що вже відбулося, — без випередження.

Що ви отримуєте

Рішення, що приймаються заздалегідь, а не заднім числом: зміна, замовлення постачальнику та кампанія вибудовуються під очікуваний потік. Прогноз з діапазоном говорить і про те, коли він сам собі не довіряє, — а це не менш корисно: видно, де не варто ставити все на одну карту. Результату ми не обіцяємо: прогноз зменшує вгадування, а не замінює рішення.

Як вимірюється точність прогнозу

Прогноз без міри похибки — це просто число, якому можна вірити або ні. Стандартний статистичний метод — середня відсоткова похибка:

• Похибка прогнозу (MAPE) = середнє від |прогноз − фактичний результат| ÷ фактичний результат, рахується після кожного завершеного періоду і виражається у відсотках
• Рахується окремо для кожного періоду (день, тиждень), бо похибка в понеділок і похибка в суботу зазвичай різні
• Тренд похибки в часі каже більше, ніж одне значення — спадна похибка означає, що модель вчиться вашого ритму, а не просто повторює середнє

Тому прогноз в AURA показується з діапазоном, а не одним числом: сам діапазон — це інформація про те, наскільки модель впевнена.

Скільки історії потрібно, щоб прогноз мав сенс

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

• Щоб модель побачила ритм тижня, потрібно кілька повних тижнів історії — інакше вона не відрізнить п’ятницю від вівторка, а просто усереднить обидва
• Щоб побачити річний сезон (літо, свята, відпустки), потрібен щонайменше один повний рік — коротша історія не містить жодного повного циклу
• Дані мають бути впорядковані на рівні транзакції чи дня, а не як одна місячна сума — з місячної суми ритм тижня не відновити

У нового закладу без власної історії просто немає з чого рахувати прогноз — і це не технічне обмеження, а статистичний факт: прогноз — це формула на повторюваності, а повторюваності ще немає.

Чому прогноз рахується з вашої історії, а не з усередненої галузевої кривої

Усереднена галузева крива звучить спокусливо — вона одразу дає число, без очікування власних даних. Проблема в тому, що вона усереднює сотні різних закладів в одну криву, яка точно не пасує жодному з них.

• Два ресторани на одній вулиці можуть мати зовсім різний ритм тижня — один живе бізнес-ланчем, інший суботньою вечерею
• Галузева крива не знає про ваші локальні події, ремонт по сусідству чи зміну годин роботи конкурента
• Похибку прогнозу, порахованого за чужою кривою, не можна виміряти власними даними, поки не порівняєш її з власним результатом, — а для цього все одно потрібна власна історія

Тому ми не наводимо тут жодної усередненої галузевої норми: у нас немає таких даних, а вигадане число було б гірше за її відсутність.

Коли прогноз не спрацює

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

• Заклад працює менше одного повного сезонного циклу, тож модель ще не бачила візерунок, який має передбачати
• Бізнес тримається переважно на разових, неповторюваних подіях (весілля, банкети під індивідуальне замовлення) без повторюваного тижневого ритму
• Компанія якраз змінює щось фундаментальне — локацію, меню, години роботи, — через що історія до зміни перестає описувати майбутнє
• Ніхто з вашого боку заздалегідь не планує зміни чи замовлення — тоді прогноз стає числом без отримувача рішення

Що має бути з вашого боку

Прогноз рахується за даними, тож якість даних визначає якість прогнозу — це не формальність, а умова старту.

• Історію продажів чи трафіку в машинно-читаному вигляді, а не в паперових звітах
• Когось, хто позначить відомі винятки (ремонт, аварія, разовий захід) — інакше модель вивчить їх як нормальний ритм
• Регулярний експорт нових даних, щоб прогноз оновлювався на актуальних даних, а не на даних піврічної давності
• Людину, яка справді ухвалює на цій основі рішення про зміни й замовлення — прочитаний, але не використаний прогноз нічого не змінює

Як через місяць перевірити, чи корисний прогноз

Не оцінюйте один влучний чи невдалий прогноз — оцінюйте тренд за кількома періодами поспіль.

• Похибка прогнозу (MAPE) із попереднього пункту — знижується чи стоїть на місці, якщо рахувати кілька періодів поспіль
• Кількість термінових коригувань замовлення в постачальника «просто зараз» — має знижуватися, якщо зміни й замовлення плануються заздалегідь
• Різниця між запланованою і фактичною зміною персоналу, виміряна в годинах понаднормової роботи чи простою

Порівнюйте той самий тип періоду з таким самим: п’ятницю з п’ятницею, а не п’ятницю з вівторком.

Чого прогноз не робить

Прогноз показує число і діапазон невизначеності — він не ухвалює за вас жодного рішення. Він не замовляє товар у постачальника сам, не складає графік змін (це сфера іншого модуля рівня ACT), не передбачає випадкові події поза закономірністю, такі як аварія чи раптовий протест, і не працює без плану на власну похибку — адже будь-який прогноз із діапазоном за визначенням іноді помиляється.

Найпоширеніша помилка при використанні прогнозу

Найпоширеніша помилка — читати середину діапазону як гарантію і ігнорувати те, наскільки широкий сам діапазон. Прогноз «120 осіб, плюс-мінус 40» — це зовсім інша інформація, ніж «120 осіб, плюс-мінус 5», і рішення про зміну має бути різним в обох випадках, хоча центральне число однакове. Друга поширена помилка — не повідомляти моделі про власні винятки: ремонт, про який сказали постфактум, псує точність не лише того тижня, а й кількох наступних.