Разработка 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 или через выгрузку, если прямого доступа нет. Результат возвращаем туда же — планом закупки и заданием на производство, чтобы менеджер оставался в привычном интерфейсе, а обмен шёл по расписанию.

Праздники и разовые всплески не сломают прогноз?

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

Кто сопровождает модель после запуска?

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

Обсудим задачу: что понадобится от вас и как пойдёт работа

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

• История продаж: выгрузка из кассы или учётной системы в разрезе точек, позиций меню, дней и часов — чем длиннее период, тем устойчивее прогноз по каждой точке.
• Разница между спросом и продажами: списания, остатки и отказы по стоп-листу. Без них модель учится на искажённой картине, где дефицит выглядит как низкий спрос.
• Календарь влияний: праздники, акции, открытия и закрытия точек, поставки, а по возможности — погода по городам присутствия.
• Справочник меню и замен: как позиции связаны между собой и что можно считать аналогом при отсутствии блюда.
• Доступы: выгрузка данных, тестовый контур или копия базы, контакт человека, который подтверждает корректность цифр.
• Ответственный за предметную сторону и регламент обратной связи — например, одна сверка в неделю: смотрим ошибку прогноза и решаем, что уточнить.

Порядок работ идёт от данных к пилоту: сначала разбираем выгрузки и договариваемся о горизонте прогноза и метрике качества, затем собираем и проверяем модель, потом запускаем её на части точек и сверяем с фактом. Только после этого расширяем на всю сеть и передаём вашей команде.

Опишите задачу и то, что уже есть по данным, — вернёмся с оценкой, планом этапов и списком того, чего не хватает для старта.