Комплексная система управления рестораном: склад, посадка и персонал

Мы спроектировали отраслевую систему для ресторанного бизнеса, которая объединяет управление залом, складом, сменами персонала и операционной аналитикой.

При этом мы сознательно не стали разрабатывать собственную кассовую систему. Продажи и фискальные операции остаются во внешней POS, а наша платформа получает необходимые данные через API и превращает их в единый операционный контур ресторана.

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

Это внутренний R&D-проект команды — модель того, как мы проектируем отраслевые информационные системы для бизнеса с большим количеством физических операций.

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

Целью было создать не ещё одну POS-систему, а операционный слой вокруг уже существующей кассовой инфраструктуры.

Мы отвечали за продуктовую архитектуру, UX/UI, backend-интеграции и проектирование модели данных.

В рамках проекта:

◆ описали основные ресторанные процессы;

◆ спроектировали роли сотрудников;

◆ разработали tablet-first интерфейс;

◆ создали модель зала и посадки;

◆ спроектировали складской контур;

◆ разработали управление сменами;

◆ предусмотрели API-интеграцию с внешней POS;

◆ объединили данные продаж, склада и персонала в управленческой аналитике;

◆ проработали сценарии деградации при нестабильном интернете.

В типичном ресторане операционная информация распределена между несколькими системами.

POS знает о заказах.

Складская система знает об остатках.

Менеджер составляет график сотрудников отдельно.

Бронирования могут находиться ещё в одном сервисе.

Часть информации вообще передаётся устно:

«Стол 12 скоро освободится».

«Лосось заканчивается».

«На вечер не хватает официанта».

«Эту позицию пора поставить в стоп».

Наша задача — собрать эти сигналы в одном интерфейсе и сделать состояние ресторана видимым в реальном времени.

Бизнес-цель

Дать управляющему и сотрудникам единый операционный инструмент, который отвечает на три основных вопроса:

Что происходит в зале?

Что происходит с запасами?

Что происходит с командой?

При этом система должна использовать существующую POS-инфраструктуру и не заставлять ресторан полностью менять кассовое решение.

Бизнес-проблемы

◆ POS показывает продажи, но не всегда отражает полный операционный контекст заведения.

◆ Управляющий получает информацию из нескольких систем и от сотрудников вручную.

◆ Стоп-листы часто обновляются реактивно — только когда продукт уже закончился.

◆ Фактическое движение ингредиентов сложно сопоставить с продажами.

◆ Состояние столов и загрузка официантов могут быть непрозрачны во время пиковых часов.

◆ Графики сотрудников и фактические смены существуют отдельно от загрузки ресторана.

◆ Большинство административных систем оптимизировано под desktop, хотя сотрудники ресторана постоянно перемещаются.

Мы построили систему вокруг четырёх основных контуров:

зал → заказы → склад → персонал.

Внешняя POS остаётся источником данных о чеках и продажах.

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

Интерактивная карта зала

Главный экран для операционной команды — интерактивная схема ресторана.

Каждый стол отображает своё текущее состояние:

◆ свободен;

◆ забронирован;

◆ ожидает гостей;

◆ гости размещены;

◆ заказ принят;

◆ блюда готовятся;

◆ требуется внимание официанта;

◆ ожидается расчёт;

◆ требуется уборка.

Состояние видно без открытия карточки.

Менеджер может за несколько секунд понять загрузку всего зала.

Посадка и бронирования

Бронирование связывается с конкретным гостем, временем и предполагаемой продолжительностью визита.

При посадке статус стола меняется автоматически.

Система учитывает:

• размер компании;
• пожелания гостя;
• объединение столов;
• ограничения по времени;
• будущие бронирования.

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

Контроль загрузки официантов

Столы распределяются между сотрудниками смены.

Система показывает текущую нагрузку каждого официанта:

• количество активных столов;
• количество гостей;
• открытые заказы;
• заказы, требующие действия;
• среднее время обслуживания.

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

Это позволяет не создавать ситуацию, когда у одного официанта одновременно семь активных столов, а у другого — два.

Интеграция с POS

Мы не стали дублировать функциональность кассовой системы.

POS продолжает отвечать за:

• создание кассового заказа;
• оплату;
• фискализацию;
• чеки;
• возвраты;
• кассовую дисциплину.

Через API наша система получает события:

заказ создан → позиция добавлена → блюдо отменено → чек закрыт → возврат оформлен.

После этого события становятся частью общей операционной модели ресторана.

Например, после закрытия заказа:

◆ стол переводится в состояние завершения обслуживания;

◆ ингредиенты учитываются в фактическом расходе;

◆ данные попадают в аналитику;

◆ учитывается выручка смены;

◆ обновляется производительность сотрудника.

POS остаётся специализированным инструментом, а ERP добавляет недостающий бизнес-контекст.

Складской контур

Склад построен не только вокруг количества упаковок, но и вокруг блюд.

Каждая позиция меню связана с технологической картой.

Например:

Паста с креветками

→ паста — 120 г
→ креветки — 90 г
→ сливки — 80 мл
→ пармезан — 20 г
→ дополнительные ингредиенты.

Когда POS фиксирует продажу блюда, система рассчитывает нормативное потребление ингредиентов.

Это позволяет сравнивать:

теоретический остаток и фактический остаток после инвентаризации.

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

Остатки

По каждому товару система хранит:

◆ текущий остаток;

◆ единицу измерения;

◆ минимальный остаток;

◆ критический остаток;

◆ среднее потребление;

◆ прогнозируемое время исчерпания;

◆ поставщика;

◆ последнюю закупочную цену.

Вместо простого предупреждения «товар закончился» система может заранее показать:

При текущем темпе продаж сливок хватит примерно до завтрашнего вечера.

Это превращает склад из реестра в инструмент планирования.

Умный стоп-лист

Одна из ключевых функций — автоматический контроль доступности меню.

Если критичный ингредиент заканчивается, система определяет, какие блюда больше невозможно приготовить в нормативном количестве.

Управляющий получает предложение:

«Остаток лосося позволяет приготовить ещё примерно 4 порции. Добавить блюда в предварительный стоп-лист?»

После подтверждения информация может автоматически передаваться в POS и связанные цифровые меню.

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

Закупки

На основе минимальных остатков и средней скорости расхода система формирует предложение на закупку.

Например:

Моцарелла
Остаток: 4,2 кг
Средний расход: 3,1 кг/день
Поставка: 2 дня
Рекомендованный заказ: 12 кг

Управляющий может скорректировать количество и сформировать заявку поставщику.

Инвентаризация с планшета

Инвентаризация спроектирована как мобильный процесс.

Сотрудник идёт по складу с планшетом и последовательно вводит фактические остатки.

Интерфейс показывает:

• название продукта;
• фотографию;
• единицу измерения;
• ожидаемый остаток;
• поле фактического значения.

После завершения система автоматически рассчитывает расхождения.

Такой сценарий значительно естественнее, чем распечатанная ведомость с последующим переносом значений в компьютер.

Персонал и смены

В ERP встроен базовый workforce management.

Управляющий составляет график сотрудников:

◆ официанты;

◆ хостес;

◆ бар;

◆ кухня;

◆ менеджеры смены;

◆ другой операционный персонал.

Для каждой смены фиксируются:

• плановое время;
• фактическое начало;
• фактическое завершение;
• перерывы;
• роль;
• зона ответственности.

Открытие смены

При входе сотрудник отмечает начало работы с корпоративного планшета или рабочего терминала.

Система сразу понимает, кто находится на смене, и использует это в операционных сценариях.

Например, стол нельзя назначить официанту, который сегодня не работает.

Чек-листы смены

Для разных ролей предусмотрены собственные операционные чек-листы.

Открытие ресторана

◆ проверить кассовые терминалы;

◆ принять зал;

◆ проверить резерв столов;

◆ подтвердить критические остатки;

◆ проверить стоп-лист;

◆ открыть смену.

Закрытие

◆ закрыть открытые столы;

◆ проверить неоплаченные чеки;

◆ выполнить списания;

◆ зафиксировать остатки критичных позиций;

◆ завершить смены сотрудников;

◆ сформировать отчёт управляющего.

ERP хранит не только факт выполнения, но и сотрудника, время и комментарий.

Журнал инцидентов

Дополнительно мы добавили единый журнал операционных событий.

В нём можно фиксировать:

• жалобы гостей;
• поломки оборудования;
• проблемы с поставкой;
• возвраты;
• нарушения технологического процесса;
• нестандартные списания;
• конфликтные ситуации.

Инцидент можно связать со столом, заказом, сотрудником или сменой.

Это помогает не терять информацию после окончания рабочего дня и выявлять повторяющиеся проблемы.

Передача смены

Отдельный сценарий — handover между менеджерами.

Перед завершением работы управляющий видит автоматически сформированную сводку:

Что произошло за смену

• выручка;
• количество гостей;
• средний чек;
• незакрытые инциденты;
• критические складские позиции;
• стоп-лист;
• будущие крупные бронирования;
• сотрудники следующей смены;
• задачи, требующие внимания.

Следующий менеджер начинает работу уже с контекстом предыдущей смены.

Tablet-first интерфейс

Мы исходили из того, что ресторан — это физическое пространство.

Менеджер не должен постоянно возвращаться к компьютеру.

Поэтому основные интерфейсы оптимизированы под планшет:

◆ крупные touch-targets;

◆ минимум текстового ввода;

◆ быстрые действия;

◆ понятная цветовая индикация состояний;

◆ управление одной рукой;

◆ отсутствие сложных многоуровневых таблиц в операционных сценариях.

Tablet используется непосредственно там, где возникает событие:

в зале, на складе, у кухни или во время обхода ресторана.

Режим управляющего

У управляющего есть отдельный operational dashboard.

На одном экране отображаются:

• загрузка зала;
• активные заказы;
• текущая выручка;
• средний чек;
• количество гостей;
• сотрудники на смене;
• критические остатки;
• стоп-лист;
• незакрытые инциденты.

Задача этого экрана — ответить на вопрос:

«Есть ли сейчас в ресторане что-то, что требует моего вмешательства?»

Аналитика собственника

Для собственника система агрегирует показатели уже на уровне бизнеса.

Он видит:

◆ выручку;

◆ средний чек;

◆ количество гостей;

◆ оборачиваемость столов;

◆ food cost;

◆ payroll cost;

◆ списания;

◆ маржинальность категорий меню;

◆ загрузку по дням и часам;

◆ эффективность использования посадочных мест.

Важным показателем становится не просто количество продаж, а экономика одного гостя, блюда, часа и посадочного места.

Аналитика управляющего

Управляющий смотрит на более операционные метрики:

◆ среднее время обслуживания;

◆ загрузку официантов;

◆ скорость оборота столов;

◆ процент стоп-листа;

◆ отклонение фактического расхода от технологических карт;

◆ количество списаний;

◆ опоздания сотрудников;

◆ незакрытые чек-листы;

◆ количество инцидентов за смену.

Таким образом разные роли получают разные представления одной системы.

Работа при нестабильном интернете

Для ресторанной инфраструктуры критично учитывать качество связи.

Операционные tablet-интерфейсы проектировались с расчётом на временную деградацию сети.

Часть данных кэшируется локально, а действия помещаются в очередь синхронизации.

Если соединение кратковременно пропадает, сотрудник не должен видеть пустой экран посреди обслуживания гостя.

Критические кассовые операции при этом остаются ответственностью внешней POS-системы.

Ролевая модель

Система адаптируется под роль сотрудника.

Официант видит свои столы и необходимые действия.

Хостес — карту зала и бронирования.

Склад — остатки, поставки и инвентаризации.

Менеджер смены — весь операционный контур.

Управляющий — персонал, склад и аналитику.

Собственник — агрегированные бизнес-показатели.

Это уменьшает количество интерфейсного шума и одновременно ограничивает доступ к чувствительной информации.

1. Моделирование ресторанных процессов

Мы начали с описания полного операционного цикла:

бронирование → посадка → заказ → приготовление → обслуживание → расчёт → освобождение стола.

Отдельно построили процессы склада и сотрудников.

2. Разделение ответственности систем

Одним из принципиальных архитектурных решений стало не заменять POS.

Мы определили границу:

POS отвечает за кассовую транзакцию.

ERP отвечает за операционный контекст вокруг неё.

Это снизило сложность и сделало решение потенциально совместимым с различными POS-платформами.

3. Проектирование tablet-first UX

Основные сценарии проходили проверку с вопросом:

«Можно ли выполнить это действие стоя посреди ресторана за несколько секунд?»

Если для операции требовалась сложная таблица или длинная форма, сценарий перерабатывался.

4. Связка продаж и склада

Данные из POS связали с технологическими картами.

Это позволило автоматически переводить проданные блюда в нормативное потребление ингредиентов.

5. Управление залом

Создали событийную модель стола, благодаря которой его состояние отражает не только факт открытого заказа, но весь процесс обслуживания.

6. Workforce management

Добавили смены, роли, чек-листы и контроль фактической работы сотрудников.

7. Управленческая аналитика

На общей модели данных построили разные аналитические представления для управляющего и собственника.

В результате сформирована архитектура комплексной ресторанной системы, объединяющей:

◆ посадку гостей;

◆ бронирования;

◆ состояния столов;

◆ нагрузку официантов;

◆ внешнюю POS;

◆ склад;

◆ технологические карты;

◆ стоп-листы;

◆ закупки;

◆ инвентаризации;

◆ сотрудников;

◆ смены;

◆ чек-листы;

◆ инциденты;

◆ управленческую аналитику.

Главное отличие решения — оно не пытается стать универсальной системой «для всего ресторана».

Вместо этого мы оставляем специализированные функции специализированным продуктам и строим вокруг них единый операционный слой.

Что получил бы бизнес

При внедрении такой архитектуры ресторан получает единое состояние своих физических процессов.

Управляющий видит проблемы до того, как они превращаются в конфликт с гостем.

Склад связан с фактическими продажами.

Состояние меню связано с остатками.

Работа сотрудников связана с загрузкой зала.

А собственник получает показатели, сформированные из реальных операционных событий, а не из нескольких отчётов разных систем.

Автоматизация ресторана — это не установка ещё одной кассовой программы.

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

Поэтому в центре решения мы поставили не кассу, а операционное состояние заведения.

POS фиксирует продажу.

Наша система отвечает на более широкий вопрос:

что сейчас происходит с рестораном и где требуется действие человека?

Tablet-first интерфейс позволяет работать с этой информацией непосредственно там, где возникает проблема — в зале, на кухне или на складе.

Так информационная система перестаёт быть административным инструментом в кабинете управляющего и становится частью физической работы ресторана.