Федеральная сеть пекарен-кофеен с несколькими десятками точек. Учёт — на iiko. Встроенная отчётность давала короткие срезы, но не отвечала на главные вопросы сети: где утекает маржа, какая смена реально зарабатывает, какой поставщик стабильно играет с весом. Мы собрали DWH поверх iiko Service через REST API и свели его с 1С.
iiko из коробки закрывает базовую операционку: продажи, чеки, склад. Но как только сеть задаёт более тонкий вопрос — встроенные отчёты упираются в свой потолок. Короткие срезы, ограниченная глубина, нельзя, например, посчитать food-cost по конкретному блюду с учётом реальных списаний поставщика за период.
Параллельно у бухгалтерии живёт своя 1С с финансовыми итогами. Цифры есть, но они не связаны с iiko — сводить приходится руками в Excel, каждый раз по-новому.
У руководителя сети в голове было три вопроса, на которые никто не отвечал одновременно: какая реальная маржинальность каждого блюда, какая эффективность каждой смены, какая оборачиваемость каждого поставщика ингредиентов.
Пробовали подключать Power BI напрямую к iiko через стандартные отчёты — получалась витрина поверх тех же ограничений. Нужен был другой уровень доступа к данным.
Ушли от готовых отчётов к внутренним REST API iiko Service. Это редкий технический сценарий — публичных русскоязычных материалов по связке «iiko + полноценное DWH» единицы. Мы вытаскиваем сырые сущности и раскладываем их в собственный слой хранилища.
Подключение на уровне внутренних API, а не готовых отчётов. Тянем чеки, блюда в чеках, остатки по складам, движения ингредиентов, списания, персонал со сменами, себестоимость блюд.
Специфика iiko изолирована от остальной модели. Если завтра в сети появится вторая касса — её слой ляжет рядом, не задевая общий Core.
Финансовые итоги из 1С сводятся с операционкой iiko — чтобы в Power BI был один согласованный P&L, а не две расходящиеся версии.
Три домена в одной модели. Меры DAX — food-cost, эффективность смены, оборачиваемость поставщика, доля списаний — считаются на лету.
Пакеты забирают инкрементом данные ночью. К утру все дашборды сети показывают свежие цифры за вчерашний день.
Компактное решение — ни одной лишней сущности. Документация на каждую процедуру, логика обновлений прозрачна команде сети.
Разложение до ингредиентов и реальных списаний. Видно, где себестоимость уходит в рецепт, а где — в списания.
Не только цена минус себестоимость, а ещё время приготовления и загрузка повара. Блюдо может быть маржинальным на бумаге — и убыточным по времени в час пик.
Выручка за смену против часов, которые отработал конкретный состав. Управляющий видит, какая связка «бариста + повар» реально продаёт.
Кто даёт лучшую цену, у кого стабильнее качество, кто возит чаще. На живых данных видно, что «выгодный» поставщик по прайсу — не всегда выгодный по списаниям.
Выделяет аномалии: одна точка списывает молочку втрое чаще остальных, у одного поставщика хлебная мука уходит в списание систематически. Раньше такие сигналы терялись в месячной сводке — теперь появляются на следующий день.
Мы видим food-cost каждого блюда в день, а не в конце месяца. И сразу замечаем, где поставщик играет с весом или повар с рецептурой. До этого такие вещи всплывали только в инвентаризацию — когда уже поздно.
Операционный директорСеть пекарен-кофеен · HoReCa
Разберём, какие данные iiko уже даёт, а какие — прячет за ограничениями отчётов. Покажем, что реально вытащить через Service API и как это связать с 1С.