Есть бизнесы, где на поверхности всё хорошо: гости есть, бар работает, касса постоянно пробивает чеки, а ощущение по деньгам "непонятно".

В Simple Coffee (крупная региональная сеть из Екатеринбурга 26 кофеен, более 10 лет на рынке) было именно так: чеков много, выручка выглядит бодро, а часть прибыли будто где-то теряется .

Причина обычно не одна: В общепите маржа уменьшается по нескольким направлениям : скидки, списания, лояльность, ошибки в заведении товаров, “переехавшие” категории, несостыковки по точкам...

Контекст: почему “не считать” стало опасно

В 2024–2025 у кофеен стало меньше права на ошибку. Давят сразу несколько факторов: сырьё, персонал, аренда, рост закупочных и операционных затрат. При таких обстоятельствах управление по ощущениям быстро превращается в “почему денег снова не хватает”.

Что было “до”: Excel, разрозненные данные и управление постфактум

При объёме 240 000+ чеков в месяц Excel-отчёт превращается в пересказ прошлого. Он отвечает на вопрос “что уже случилось?”, но почти не отвечает на “что делать завтра”.

Список вопросов, который обычно копится у собственника и управляющей команды:

• какие точки реально тянут сеть вверх, а какие тихо проедают маржу

• где мы зарабатываем на кофе, а где работаем в ноль из-за скидок, списаний и лояльности

• какие позиции в меню прибыльные, а какие “просто чтобы были”

• почему выручка растёт, а итоговая экономика стоит на месте

• что происходит каждый день, а не “по итогам месяца”

Задача: не просто нарисовать дашборд, а сделать систему управляемой

Клиент пришёл не за картинками, а с желанием автоматизировать отчетно-статистическ, а так же:

• собрать данные так, чтобы они обновлялись ежедневно

• отвечать на управленческие вопросы по точкам, ассортименту, скидкам

• иметь возможность провалиться до чека, когда что-то выглядит подозрительно

• не ломать текущую работу сети

Что мы мы сделали подключились к R‑Keeper и поставили ежедневную загрузку

Стартовали с базы:

• Через самописный коннектор по APIподключились к источнику данных R-Keeper (транзакции, позиции чеков, скидки, модификаторы)

• настроили ETL с ежедневным обновлением

• собрали витрину данных под управленческие задачи клиента

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

Момент, который многие пытаются проскочить “потом доделаем”, однако так лучше не делать.

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

Если это не поправить, любая аналитика начинает давать уверенные, но неправильные выводы...
Красиво?
- Да.
Полезно?
- Нет.

Что сделали вместо “давайте потом”:

• выровняли мастер-каталог (товары/категории/подкатегории)

• настроили правила маппинга

• добавили проверки качества данных на входе, чтобы “плохие” изменения не продвигались дальше

Архитектура: простая, но дисциплинированная

Мы строили процесс так, чтобы он:

• повторялся одинаково (одинаковый вход → одинаковый результат)

• не ломался при перезагрузках (повторная загрузка не портит факты)

• проверялся (можно сверить цифры с источником и быстро найти расхождение)
  

Слои получились стандартные:

• staging/raw — данные “как есть”

• clean — нормализация сущностей и справочников

• marts — витрины под вопросы (точки, день/неделя, daypart, скидки/лояльность, ассортимент)

• dashboards — доступы по ролям + короткое обучение

Что появилось “после”: ежедневные отчеты вместо ежемесячной рефлексии

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

• главный экран сети: выручка, чеки, средний чек, основные показатели

• витрина по точкам и сравнение кофеен

• ассортимент и юнит-экономика по позициям

• скидки/лояльность с детализацией до чека

• "daypart"(утро/день/вечер) и будни/выходные

Дальше смотрите на скринах (все данные анонимизированы, структура и логика, как в рабочем решении).

Демо-дашборд на анонимизированных данных. Интерактивную ссылку могу скинуть в л/с.

выручка не равна прибыль

Что конкретно удалось поймать

Если показатели обновляются ежедневно и можно провалиться до чеков, начинают всплывать вещи, которые в месяцах теряются:

• провалы по времени суток (точка работает, но в конкретные часы отдача хуже, чем кажется)

• реальная цена скидок/лояльности (конкретной суммой и долей чеков)

• точки и категории, которые выглядят сильными по обороту, но в реале не дотягивают по прибыли

• решения по графику смен, которые заметно улучшают экономику, потому что становятся видны “пустые” часы
  

Итог: вся сеть на одном экране за 3 месяца

В таких проектах результат - это не просто внедрили BI, а появилась бОльшая управляемость:

• ежедневная картина по сети и точкам

• меньше ручного труда и ошибок (данные собираются автоматически и сверяются)

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

Вопросы в комментарии (хочется реального обмена опытом)

• Справочники: у кого ещё “категории” — главный источник управленческой лжи? Чем лечите: регламентом, отдельной ролью, автоматическими проверками?

• Лояльность и скидки: кто считает экономику до уровня чека? Какие метрики оказались рабочими?

• Daypart: какие находки были по часам/дням недели в кофейнях или fast casual?

Небольшая ремарка про демо

Если хотите покрутить интерактивную версию демо-дашборда - напишите в личку, скину ссылку.

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