Розробка AI-системи прогнозування попиту для ресторанів

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

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

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

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

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

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

Окремо кожен дає невеликий зсув, разом вони складаються в день, де попит вищий за норму на десятки відсотків — і це саме той день, коли зал і склад працюють на межі.

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

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

Що дає система прогнозу: ефект у закупівлях, змінах і списаннях

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

• Точність прогнозу продажів — частка днів, де відхилення факту від прогнозу вкладається в робочий допуск за групами меню, зростає з двозначних значень до 80–90% на горизонті тижня. Важливо, що прогноз будується за позиціями та годинами, а не за виручкою точки загалом.
• Зниження списань на кухні — швидкопсувні, заготовки та напівфабрикати плануються під очікуваний потік за інтервалами. Списання зміщується з «постійного фону» в разові події: брак поставки, аварія, свято.
• Завантаження змін — розрахунок іде від прогнозу на кожен інтервал, тому графік збирається під піки та провали. Зникає переробка в години затишшя та нестача рук у залі.
• Планування закупівель по днях — заявка постачальнику формується з прогнозу з урахуванням залишків на складі, кратності партій і терміну придатності. Закупівля перестає бути «раз на тиждень на око».
• Знятий клас відмов «порожня полиця в годину пік» — за критичними позиціями система заздалегідь попереджає про ризик дефіциту та пропонує добір або заміну.
• Прозорість якості — точність вимірюється щоденно і видна по кожній точці. Це дозволяє відрізняти помилку моделі від збою в даних: переоблік, незакрита зміна, разова акція.

Прогноз будується на історії продажів касового контуру — найчастіше це iiko, r_keeper або власна база.

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

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

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

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

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

Так сплеск на свято не «розмазується» по сусідніх днях, а залишається окремим сценарієм із зрозумілим поясненням.

Перевіряємо на відкладеному періоді: середня помилка за днями і окремо за святковими та піковими. Якщо статистика тримає 15–20%, а гібрид знижує до 8–12% — перехід виправданий.

Етапи впровадження: від розбору історії продажів до роботи в зміні

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

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

1. Аудит даних про продажі. Вивантажуємо історію чеків і позицій за весь доступний період, звіряємо з касою та складом, відзначаємо пропуски, дублі та дні з акціями або ремонтом залу.
2. Схема розрахунку прогнозу. Фіксуємо горизонт — зміна, доба, тиждень — і гранулярність: позиція, категорія або точка. Визначаємо зовнішні фактори: день тижня, свята, погода, локальні події.
3. Складання моделі. Навчаємо кілька підходів — від сезонної регресії до бустингу на часових рядах — і беремо той, що стійкіший на вашій історії, а не той, що красивіший на графіку.
4. Перевірка якості прогнозу на відкладеному періоді. Рахуємо метрики й порівнюємо з базовою лінією «середнє за днем тижня», окремо за ходовими та рідкісними позиціями.
5. Пілот. Прогноз іде паралельно з поточним плануванням, менеджер відзначає розбіжності з досвідом — їх розбираємо до запуску.
6. Впровадження прогнозу попиту в зміну. Розрахунок живе в робочому контурі: прогноз на наступний день готовий до відкриття зміни і потрапляє у звіт менеджера, а не в окремий файл.
7. Передача та регламент. Залишаємо схему даних, порядок перенавчання при зміні меню або цін і контроль відхилень з повідомленням при розходженні вище порогу.

Що передаємо на руки: моделі, схеми, регламенти та інструкції

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

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

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

Кейс мережі точок: менше списань і точніші закупівлі після запуску

Як планували до

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

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

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

Що показали метрики

Помилка прогнозу на денному горизонті скоротилася з 28–30% до 12–14%, частка ручних правок у заявках — з 100% до 18–20%. Списання впали з 7% до 3% від обороту, стоп-листи за ходовими позиціями майже зникли, а час на планування стиснувся з кількох годин на тиждень до півгодини.

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

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

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

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

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

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

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

Часті сумніви перед впровадженням прогнозу продажів

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

Як прогноз зв'яжеться з обліковою системою?

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

Свята та разові сплески не зламають прогноз?

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

Хто супроводжує модель після запуску?

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

Обговоримо задачу: що знадобиться від вас і як піде робота

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

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

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

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