Прогноз попиту в ресторані: метод і точність

Чому пам’ять керівника зміни вже є прогнозом і де вона закінчується

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

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

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

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

Гості, чеки, виручка чи порції: чотири прогнози, які не можна підміняти один одним

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

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

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

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

Найменша придатна історія і те, що знищує місячна сума

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

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

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

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

База, денний множник і подвійний рахунок, який ховається між ними

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

Прогноз гостей = Гості базово × Денний множник × Множник події × Множник погоди

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

База — тільки рівень і річна сезонність. Тижневий профіль з неї навмисно вийнято, його несе окремий Денний множник.

Це розділення — не педантизм, а найчастіша арифметична поломка в саморобних ресторанних прогнозах. Якщо твоя база — «середнє за чотирма останніми п’ятницями», а потім ти множиш її на п’ятничний множник 1,35, п’ятницю пораховано двічі і кожен п’ятничний прогноз завищено на третину. База — це пласке середнє за всіма днями; день тижня живе в множнику; кожен факт входить у добуток рівно один раз.

Дораховано до кінця при базі 100 гостей, п’ятничному множнику 1,35, множнику місцевої події 1,20 і множнику поганої погоди 0,95: 100 × 1,35 = 135; 135 × 1,20 = 162; 162 × 0,95 = 153,9, тобто 154 гостя. Кожне з цих чотирьох чисел — навчальна величина. У справжній моделі кожне з них виміряне на власних минулих днях, а множник, який ти не вмієш виміряти, — це множник, який ти не ставиш.

Польський список неробочих днів змінився 1 лютого 2025 року, а історія — ні

Календар — найдешевший у здобутті чинник і найлегший, щоб тихо на ньому помилитися: календар сам по собі є законом, а закони змінюються. Польський список днів, вільних від роботи, лежить у законі від 18 січня 1951 року (чинна зведена редакція: Dz.U. 2025 poz. 296, оголошена 06.03.2025 — первісна редакція Dz.U. 1951 nr 4 poz. 28 історична і святвечора не містить), і 1 лютого 2025 року в ньому з’явилася ще одна позиція: закон від 6 грудня 2024 року додає після літери k, дослівно, ka) 24 grudnia - Wigilia Bożego Narodzenia, тобто 24 грудня, Святвечір (Dz.U. 2024 poz. 1965, чинний з 01.02.2025).

Подивись, що це робить з моделлю, навченою на 2023 і 2024 роках. У тій історії 24 грудня було звичайним робочим днем; з 2025 року це встановлений законом неробочий день, і офіси, школи та торгівля навколо них поводяться відповідно. Модель вивчила факт про країну, який відтоді перестав бути правдою. Жоден показник похибки про це не попередить: модель сумлінно відтворює те минуле, яке їй дали.

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

День виплат виглядає приватною справою роботодавця, а насправді вікно йому задає закон. Польський Kodeks pracy (Трудовий кодекс, ELI DU/1974/141) у статті 85 каже: виплату винагороди за працю здійснюють не рідше одного разу на місяць, у постійний і встановлений заздалегідь строк (§ 1); винагороду, що виплачується раз на місяць, платять за відпрацьоване, одразу після визначення її повної суми і не пізніше перших 10 днів наступного календарного місяця (§ 2); а якщо встановлений день виплати припадає на день, вільний від роботи, платять напередодні (§ 3) (Kodeks pracy, ст. 85, зведений текст Dz.U. 2025 poz. 277, оприлюднений 06.03.2025).

Прогнозистові ці три параграфи — добра новина, а не юридична дрібниця: вони звужують чинник, а не розмивають його. Виплата за минулий місяць іде слідом за ним і не пізніше десятого числа наступного, отже пік виплат фізично не може лягти на середину місяця: кандидатів жменька на стику місяців, а не тридцять. Строк мусить бути постійним і призначеним заздалегідь, отже одного разу виміряний множник не тікає від місяця до місяця — а § 1 дозволяє платити частіше, ніж раз на місяць, тому в частини роботодавців таких днів два, і вони теж постійні. Зсув із § 3 варто завести в колонку прямо: виплата, що припала на суботу чи неділю, переїжджає на попередній день, тому одна п’ятниця на місяць буває важча за решту з причини, яка до твоєї кухні не має жодного стосунку.

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

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

Перевірка погоди за показаннями станцій IMGW замість віри в неї

Погода — чинник, у якому всі впевнені найбільше і який перевірили найменше. І це той самий чинник, на перевірку якого Польща дає безкоштовні офіційні дані: інститут IMGW-PIB публікує поточні синоптичні показання та файли історичних спостережень на danepubliczne.imgw.pl, станція за станцією, а його живий синоптичний канал віддає температуру, вітер, вологість і опади по станції та по годині.

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

Дві умови, без яких погодна перевірка не міряє нічого

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

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

Якщо кошики вийдуть практично врівень, це теж результат, а не провал. Означає, що погода для твого закладу чинником не є, твій множник погоди дорівнює 1,00, і ти щойно прибрав джерело шуму з кожного прогнозу, який побудуєш.

Події по сусідству: чинник без офіційного набору даних

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

Лишаються дві чесні дороги і жодної третьої. Або хтось на твоєму боці веде календар — арена, два театри, конференц-центр, стадіон і щотижневий ринок на твоїй же вулиці — і позначає кожну дату в тому самому файлі, де лежать продажі, або ти купуєш це зведення як послугу. Саме цю роботу в нашому продукті роблять зовнішні сигнали, а сценарії what-if — це місце, куди ти ставиш таку дату й питаєш, як виглядає вечір, якщо множник утримається.

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

Броні заслуговують тут на окреме попередження, бо виглядають найчистішим сигналом попиту в будівлі, а ним не є. Книга, повна столів, які не прийшли, завищує завтра — і завищує непомітно, доки неявки не записуються як неявки. Ланцюжок підтверджень, який робить це число надійним, розбирає наша стаття про no-show у ресторані.

Прогноз окремої позиції меню, де нулі нормальні, а MAPE перестає працювати

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

На цьому рівні ламається вимірювання, а не метод.

Саме тому точність на рівні позиції відстежують через WAPE або через звичайну абсолютну похибку в порціях, а не через MAPE.

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

MAPE, WAPE і зміщення на тих самих п’яти днях: три числа, три сенси

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

MAPE = (100 ÷ n) × Σ ( |Фактᵢ − Прогнозᵢ| ÷ Фактᵢ )

• n — кількість порівнюваних періодів;
• Фактᵢ — те, що насправді сталося в періоді i, у гостях або у злотих;
• Прогнозᵢ — те, що на той самий період передбачали, у тій самій одиниці.

WAPE = 100 × Σ |Фактᵢ − Прогнозᵢ| ÷ Σ Фактᵢ

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

Зміщення = (1 ÷ n) × Σ (Прогнозᵢ − Фактᵢ)

Похибки зі знаком: −12, +9, +8, −14 і +15, у сумі +6; поділене на 5 дає зміщення = +1,2 гостя на день. Прочитай цю пару разом, і вона скаже те, чого жодне число не каже окремо: прогноз хибить приблизно на вісім відсотків у типовий день, але не кренить. Похибки, які взаємно гасяться, — це випадкова похибка, і керують нею діапазоном. Зміщення +12 при тому самому MAPE було б зовсім іншою хворобою: хронічним завищенням, з графіком і холодильником, переповненими щодня.

Чому ділення мусить стояти всередині суми

MAPE — це середнє відношень, а середнє відношень не дорівнює відношенню середніх.

Усі три друкуються з двома знаками після коми і всі три виглядають однаково поважно. Назвати одне з них ім’ям іншого — це спосіб, яким двоє, що порівнюють «наш MAPE», порівнюють ніщо.

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

MAPE (середня абсолютна відсоткова похибка) — середнє з абсолютних похибок прогнозу, кожну з яких виражено у відсотках від фактичної величини свого періоду.

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

Скільки точності потрібно графіку зміни і скільки — вівторковій поставці риби

Ця сторінка не називає достатнього MAPE. Не тому, що річ нецікава, а тому, що достатню похибку задає вартість твоєї власної похибки, а вона різниться між задачами всередині одного ресторану в один день. Загальна причина, з якої жодна наша сторінка не успадковує норму, що ходить галуззю, викладена на сторінці про prime cost ресторану; часткова причина тут іще простіша — похибка, нешкідлива для мішка рису, викине ящик палтуса.

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

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

Від прогнозу до годин і від годин до того, що не страшно закріпити

Прогноз, який не змінює графіка, не змінив нічого. Мостом слугує одне ділення:

Години графіка = Прогноз виручки ÷ Цільова виручка на годину роботи

• Прогноз виручки — прогнозна кількість гостей × власний середній чек, у злотих;
• Цільова виручка на годину роботи — власна ціль з виручки на людино-годину, у злотих на годину;
• Години графіка — людино-години, які зміні дозволено видати, у годинах.

При прогнозі 154 гостя, порахованому вище, і навчальному середньому чеку 60 злотих прогноз виручки становить 9 240 злотих; проти навчальної цілі 220 злотих на людино-годину це 42 людино-години на зміну. Звідки береться сама ціль і чому її треба будувати на власних минулих змінах, а не позичати, — цілком тема сторінки про виручку на годину роботи персоналу. Ця сторінка постачає чисельник; та володіє знаменником.

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

Від прогнозу до кількості в замовленні, через термін поставки постачальника

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

Кількість до замовлення = Прогнозна витрата за термін поставки + Страховий запас − Поточний залишок

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

Продовжуючи той самий приклад: 46 порцій на день на триденному терміні поставки — це 138 порцій; додай навчальний страховий запас 40 і відніми 55 порцій, перерахованих у морозильнику, і замовлення виходить 123 порції. Зверни увагу, куди входить похибка прогнозу: вона не змінює 138, вона задає розмір цих 40. Як ставляться страховий запас і par-рівні та яка оборотність із них випливає, належить сторінці про оборотність запасів ресторану.

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

Вартість схиблення, порахована один раз, а не двічі

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

Вартість похибки прогнозу, коли Прогноз > Факт: (Прогноз − Факт) × Витрати на персонал на гостя

Вартість похибки прогнозу, коли Факт > Прогноз: Необслуговані гості × Маржинальний прибуток на гостя

• Витрати на персонал на гостя — власні повні витрати на персонал, поділені на кількість гостей, у злотих на гостя;
• Маржинальний прибуток на гостя — середній чек мінус змінні витрати на його обслуговування, у злотих на гостя;
• Необслуговані гості — ті, кого справді не вдалося посадити чи нагодувати, а це не автоматично весь недобір.

Переоцінка на 24 гостя при навчальних витратах на персонал 12 злотих на гостя: 24 × 12 = 288 злотих оплачених годин, які нікого не обслужили. Недооцінка на 24 гостя, з яких 10 ти розвернув, при навчальному маржинальному прибутку 34 злотих: 10 × 34 = 340 злотих маржі, якої не сталося.

Дві гілки не можуть стосуватися одного дня

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

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

Розбір дня, який схибив, і те, що можна впускати в модель

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

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

Чого статися не має, так це нового множника на кожен поганий день. Модель, що отримує черговий коефіцієнт щоразу, коли її присоромили, закінчує ідеальним припасуванням до власного минулого і нульовим передбаченням, а симптом помітити легко: похибка на днях, які ти вже знаєш, падає, а похибка на днях наступного тижня стоїть на місці. Тримати це порівняння на видноті з першого дня — і є сенс того, щоб прогноз і факт стояли на одному екрані. Живе ця пара в модулі прогнозу: звірка прогнозу з тим, що сталося насправді, входить до його складу з першого дня, а не докладається пізніше. Панелі показників та звіти з ШІ роблять інше, і межу варто тримати: панель збирає ключові показники фірми — ліди, продажі, маркетинг і фінанси — на одному екрані, а звіт із ШІ надсилає щотижневе зведення по лідах, кампаніях або продажах, написане простою мовою. Жоден із них прогнозу не рахує і поруч із фактом його не ставить, тож шукати там пару «прогноз і факт» — марно згаяний вечір.

Чого прогноз не може в принципі і де насправді сидить машинне навчання

Дві чесні межі, а далі частина про наш власний продукт.

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

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

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

Одне виміряне зауваження про те, куди завищення приземляється фізично. Ресторани та заклади громадського харчування в Польщі виробили у 2023 році 293 062 тонни харчових відходів, 8 кілограмів на мешканця, при 4 651 137 тоннах по країні загалом (Eurostat, env_wasfw, звітний рік 2023, оновлено 18.02.2026). Це число охоплює все, що сектор викидає, — обрізь, залишки з тарілок, псування, — і ніхто не виділив із нього частку, спричинену поганим прогнозуванням, тож економією, яку хтось може пообіцяти, воно не є. Це розмір відра, у яке стікає перевиробництво, і тільки.

Питання, які ресторатори ставлять про прогноз попиту

Які дані потрібні ресторану, щоб прогнозувати попит?

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

Яка точність достатня для графіка зміни, а яка для замовлення постачальнику?

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

Що таке MAPE і навіщо його використовують?

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

Як перевірити на власній історії, чи впливає погода на мій попит?

Підклей до кожного минулого дня показання найближчої станції IMGW, які публікуються безкоштовно на danepubliczne.imgw.pl, потім розклади дні по кількох кошиках — дощ проти відсутності дощу або дві-три температурні смуги — і порівняй середню кількість гостей по кошиках усередині того самого дня тижня. Обмеження за днем тижня і робить перевірку дійсною: теплі дні збираються влітку, тож порівняння теплих із холодними за цілий рік міряє сезон і винуватить термометр. Якщо кошики вийдуть урівень, погода в тебе чинником не є, а множник погоди дорівнює 1,00.

Наскільки далеко наперед ресторану варто прогнозувати?

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

Чи може ресторан прогнозувати окремі позиції меню?

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

Як із прогнозу виходить графік зміни?

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

Що робити, коли прогноз сильно помилився?

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

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