Дашборд ресторана: какие KPI нужны владельцу и управляющему

Дашборд — интерфейс принятия решений

Дашборд ресторана должен сокращать путь от сигнала к решению. Большая цифра на экране сама по себе не приносит пользы. До выбора графиков выпишите вопросы собственника и управляющего: сопоставимы ли продажи с планом, где растёт нагрузка на сервис, какие обещания просрочены и каким данным пока нельзя доверять?

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

Начните с решения

Запишите решения, которые команда принимает ежедневно или еженедельно: изменить закупку, скорректировать смену, разобраться с обращением гостя. Каждый блок дашборда должен помогать ответить на один из этих вопросов.

Согласуйте определения

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

Свяжите уведомления с действиями

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

Первый набор KPI и формулы

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

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

Пример: как читать изменение производительности

Возьмём вымышленную неделю: 300 000 бат сопоставимых продаж и 600 отработанных часов. Выручка на трудочас равна 500 бат. Следующая неделя дала 330 000 бат при 550 часах — 600 бат за час. Показатель улучшился на 20%. Расчёт верный, но вывод «можно ещё сократить часы» из него автоматически не следует.

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

Паспорт показателя: источник, ответственный и свежесть

Для каждого KPI заведите паспорт: определение, источник, часовой пояс, частота обновления, ответственный и способ сверки. Укажите, предварительная цифра или закрытая. Недоступный источник показывается как отсутствие данных, а не ноль. Выводите время последнего успешного обновления и охваченный операционный период. Календарная полночь может не совпадать с границей смены заведения, работающего ночью.

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

Полезное уведомление требует ответственного и действия

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

Разбирайте ложные срабатывания и повторы. Если сотрудники отключают канал уведомлений, увеличение их количества не поможет. Объединяйте связанные сигналы и различайте подтверждение прочтения и устранение проблемы. Push и email настраивайте отдельно. В демо прямо обозначайте, что переключатели показывают поведение и не подключаются к реальным системам или отправке сообщений.

Таблица, дашборд или полноценная интеграция?

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

Внедряйте по этапам: согласуйте определения, сверьте тестовый период, покажите первый экран, проверьте потерю данных и исправления, затем добавляйте уведомления. Заменяет ли один экран финансовую отчётность? Нет. Доказывает ли красивое демо рабочее подключение? Нет. Готовность подтверждают наблюдаемый поток данных, права доступа, восстановление после сбоя и способность команды действовать по показателям.

Продолжить чтение