Что это

Операционный дашборд сети v0.9 — единый экран для COO. Девять вкладок:

1. Карта точек — heatmap точек (15 активных с мая 2026 — Котовск исключён по closure) × KPI с бэйджами K|S|D и композитным рангом из 9 KPI. При выбранном «Месяце» — последняя колонка «Прогноз на месяц ₽». Колонки «Выручка» и «Ср.чек» помечены как не участвующие в композите (ⓘ).
2. Точка — drill выбранной точки: 8 финансовых KPI (включая «Прогноз выручки» и «Опер. маржу» в конце) + 8 операционных (включая «Полка > 7 мин», «Время исполнения», «Скорость доставки»). Тренд + ТОП-5 + сравнение «vs Сеть / vs Топ-3». Виджет «Время исполнения заказов с доставкой» (3 группы 🟢/🟡/🔴 с подписью «vs сеть»). График «Нагрузка vs время на кухне» (двойная ось, час закрытия заказа = CloseTime, все каналы delivery+pickup+hall, диапазон 9:00–22:00, с пунктирами нормы 13/15 мин, серой линией среднего сетевого и текстовым инсайтом).
3. Себестоимость — встроенный детальный дашборд food cost по точкам (фильтры «Город» и «Месяц» в общей панели). Подробно — раздел «Вкладка «Себестоимость»» ниже.
4. Перетарка — где «заморожены» лишние деньги в излишках сырья. Подробно — раздел «Товарный запас» ниже.
5. Прогноз закупки — сколько каждого SKU довезти до следующей поставки. Подробно — раздел «Товарный запас» ниже.
6. Здоровье сети — 12 hero KPI (6 финансово-сетевые, 6 операционные) + 3 trend chart: «Тренд по выручке», «FC% и LC%», «Скидки».
7. Калькулятор ЗП — встроенный калькулятор зарплаты управляющей команды (вход по коду точки); подробности — в самой вкладке, раздел «Как пользоваться».
8. Методология — этот раздел.
9. Как пользоваться — инструкция по вкладкам товарного запаса (Перетарка, Прогноз закупки) для управляющих.

Вкладка «Себестоимость» (детальный FC по точкам)

Отдельный дашборд декомпозиции food cost (FC), встроенный во вкладку. Управляется из общей панели фильтров — «Город» и «Месяц» («Весь период» или конкретный месяц); прочие фильтры на этой вкладке скрыты. По выбранной точке показывает: вердикт-светофор, ключевые цифры в рублях, мост FC к прошлому месяцу (что изменило себестоимость), причины (Δ закупочных цен и списаний), KPI-плитки, структуру потерь и продаж, отклонения закупочных цен от средней по сети. Ниже — обзор сети: рейтинг точек по FC% и scatter (клик по строке открывает точку и синхронит фильтр «Город»).

Норматив: FC 🟢 ≤32% / 🟡 / 🔴 >35%; потери (порча + срок + удаление) 1.5 / 2.5%. «Сверх норматива ₽» = (FC% − 32%) × выручка.

FC % = (себестоимость продуктов + порча + срок + удаление) / нетто-выручка  (без упаковки и расходных материалов)

Источники:

• facts_monthly_calendar (by_point) — FC и потери по типам;
• OLAP продаж — микс блюд, наценка, скидки, структура продаж × себестоимость;
• приходные накладные iiko — закупочные цены по SKU/складу;
• OSV / учётные списания — списания со склада по SKU (порча / срок / удаление).

Нюансы при чтении:

• Окно месяцев — только завершившиеся (полные) месяцы 2026; текущий неполный месяц не показывается и появляется сам после закрытия.
• Свежие месяцы уточняются — текущий и предыдущий iiko дозакрывает (поздние документы переразмечаются между месяцами), поэтому цифры последних месяцев могут слегка меняться день ото дня; логика FC при этом не меняется.
• Списания (OSV) отстают ~на месяц — за самый свежий месяц пер-SKU потерь может ещё не быть (причины по ценам при этом есть).
• Себестоимость в «структуре продаж» — расчётная по техкартам (рецептура × продажи), ≈ на 7% выше фактического расхода — это сама по себе метрика overportioning.
• Комбо искажают FC по блюдам (выручка раскидана по компонентам) — у них FC помечен «—», но по вкладу в рублях они корректны.
• Отклонение цены — от средневзвешенной средней по сети (по точкам с объёмом SKU ≥ 3% сетевого), пересчитывается для выбранного месяца; бенчмарк «сеть» = среднее по 15 точкам. Аномальные строки накладных (вне диапазона 0.1×…10× медианы) отбрасываются.

Уверенность: FC-декомпозиция, потери и отклонения цен — высокая; драйверы — средняя. ~3% накладных по неименованным складам не размечены. Пересобирается ежедневно вместе с дашбордом; технически — отдельный dashboard_fc_decomposition_v3.html, встроенный через iframe.

Вкладки «Перетарка» и «Прогноз закупки» (товарный запас)

Два встроенных дашборда по складскому запасу сырья: Перетарка — где «заморожены» лишние деньги в излишках; Прогноз закупки — сколько довезти, чтобы хватило до следующей поставки. Обновляются ежедневно вместе с дашбордом (снимок остатков за вчерашний день). Все сроки — в днях.

Источники:

• Остатки — iiko, отчёт остатков по складам на конец дня (16 точек);
• Движение товара — iiko TRANSACTIONS OLAP («Расширенная ОСВ»): расход, списания, переработка, приходы по SKU × складу;
• Поставщики, цены, график поставок — Заявочная таблица + приходные накладные iiko.

Расход в день (D) — по фактическому движению товара, а не по рецептурам/ТТК: сумма списанных единиц по продажам + потерям (порча/срок/брак/питание) + переработке (полуфабрикаты), за скользящее окно 14 дней, с поправкой на сезон. Рецептурный расчёт теряет сырьё, ушедшее в перепроизведённый полуфабрикат и брак (мука: ТТК давал 0, движение — реальный расход). Для позиций без движения — резерв по складской тождественности (приход − изменение остатка).

Норматив, дн = (Review + Lead) × (1 + Буфер)
Перетарка, ₽ = max(0, Остаток − Норматив_ед) × Цена_за_ед
Заказ «К заказу» = D × Сезон × (Review + Lead) × (1 + Буфер) − Остаток

• Review (R) = 7 / число поставок в неделю (нет графика → 7 дн); Lead — срок доставки; Буфер — страховой запас по группе сырья (упаковка 1% … рыба 10%); Сезон — коэффициент месяца.
• Перетарка — сигнал-светофор: 🔴 критическая (>28 дн остатка или >1,5× норматива) · 🟠 умеренная · ⚫ мёртвый сток (расхода нет — деньги стоят) · 🟢 норма. Приоритет — по колонке «Перетарка ₽».
• Прогноз закупки — светофор по дням остатка: 🟥 не хватит на Review + Lead · 🟨 буфер недостаточен · 🟩 норма. Рекомендованный поставщик — из Заявочной таблицы.
• Оценка запаса — по iiko (sum_rub; цена за ед = sum_rub / количество).

Пошаговая инструкция — вкладка «Как пользоваться». Технически — самодостаточные inventory_overstock_v1.html и procurement_forecast_v3.html, встроены через iframe; пересобираются ежедневно (25_fetch_stock → 26_fetch_incoming → 47_fetch_goods_movement → 30_build_inventory_dashboard_data → build_inventory_dashboards).

Гранулярность

• Месяц — финансы + операционка + качество. Master финансов = facts_monthly_calendar/agg_YYYY-MM.json (агрегат из daily facts v1.7). История с янв 2025 по текущий месяц.
• Неделя — финансы + операционка из facts_daily, агрегация Пн-Вс на лету (см. decisions row 54). Без двойного pipeline — все 3 уровня day/week/month из одного источника.
• День — финансы (indirect сглажен; ФОТ кухни — по фактическим сменам, уборщицы исключены) + операционка. facts_daily/<YYYY>/<MM>/.

Источники (master по типу данных, зафиксировано 2026-05-22)

• Финансы (revenue, FC, LC, OM, потери) — iiko Resto API через SALES OLAP (revenue) + TRANSACTIONS OLAP (расходы, mapping v1.6/v1.8). Скрипты: 20_fetch_facts_month.py → facts_daily/ → 21_aggregate_facts.py → facts_monthly_calendar/.
• Операционка (kitchen, shelf, road, on-time) — iiko SALES OLAP daily, 15_fetch_sales_day.py + 16_build_operations_daily.py → operations_daily/daily_kpi.json. 13 полей группировки + 2 агрегата.
• Качество (pizza, cashier) — лист Риты Гостевой (Drive), snapshot в data/quality_history.json. Master приоритет над Свод-отчётом.
• Историческая операционка янв-мар 2026 — Сводный отчёт (Drive) как fallback пока OLAP не было настроено.

Сверка с P&L Жидкиной (2026-05-26)

Наша revenue_official = выручка с НДС (по чекам из iiko SALES OLAP). «Выручка» в P&L Жидкиной = выручка без НДС (управленческая для ОПиУ).

• По сети 2025: наше 953.99 М ₽ vs Жидкина 946.58 М ₽ → дельта +0.78% = ровно сумма «НДС с продаж» из её P&L.
• По точкам без НДС юрлиц (Курчатов, Грязи, и др.): дельта 0.00%.
• По точкам с НДС (Семилуки, Нововоронеж): дельта 0.00% при учёте НДС.
• Воронеж — у нас мердж двух iiko-юрлиц (старое + Революции после переоформления апр-2026) в одну точку. У Жидкиной они ведутся отдельно.

Заключение: наш источник верный, расхождение объясняется учётом НДС.

Операционная маржа — формула и состав

Расчёт:

Операционная маржа (OM) % = (Выручка − Себестоимость − ФОТ − Списания − Питание сотрудников − Комиссия агентов + Прочие доходы) / Выручка × 100

Все статьи — на основе P&L Жидкиной (mapping v1.8), агрегированы из транзакций iiko Resto.

Изменение 2026-06-08: Косвенные расходы исключены из OM. Месячные лумповые проводки (аренда, ПО, фонды — документ 1-го числа) садились на первую неделю месяца целиком и искажали недельный/дневной OM. Косвенные остаются отдельной строкой (indirect_pct), но в OM не вычитаются.

Что видно в дашборде явно:

• Выручка (channels.revenue_rub) — фактическая выручка без НДС
• Себестоимость продуктов % (food_cost_pct) — стоимость продуктов от выручки
• Зарплата % (labor_pct) — весь ФОТ от выручки, с мини-баром по 2 ролям (Кухня + Курьеры — см. ниже)
• Потери % (losses_pct) — Порча + Срок реализации + Удаление со списанием + Проработка (4 цвета на мини-баре)
• Доля скидок (discount_pct) — скидки от валовой выручки
• Опер. маржа % (operating_margin_pct) — итог

Косвенные расходы (indirect_pct ≈ 8% от выручки) — отдельная строка, в OM НЕ входят. Состав:

• ФОНД услуг банка — комиссия СБП, эквайринг, комиссия сайта
• ФОНД Управляющей Компании — роялти, call-центр, сервис УК, HR, маркетинг УК
• ФОНД обслуживания помещений — аренда, коммуналка, ТБО, связь, охрана, ремонт
• ФОНД обновления оборудования — ремонт, новая оргтехника, мебель, инвентарь
• Коммерческие расходы — реклама онлайн/офлайн, комиссия агрегаторов
• Административные расходы — ПО, командировки, авто, представительские
• Постоянный ФОНД персонала — взносы НДФЛ, мотивация, обучение, спецодежда, такси, медкомиссия, бесплатная еда сотрудников

На дне и неделе строка косвенных сглажена равномерно по дням месяца (месячный документ аренды/ПО/фондов проводится 1-го числа — без сглаживания он садился бы целиком на первую неделю и строка «прыгала» бы на стыке месяцев). На месяце — сырая месячная сумма.

Если нужна детализация по этим группам — следующий релиз раскроет indirect_pct на 4-5 категорий.

Зарплата — формула и состав

Расчёт:

Зарплата % (LC) = (Все начисления по статье ФОТ) / Выручка × 100

Все начисления берутся из P&L Жидкиной (mapping v1.8): включают переменный ФОНД персонала (Производство, Курьеры, Управляющий, Яндекс-курьеры) + те статьи постоянного фонда, которые в маппинге помечены как labor (взносы НДФЛ, мотивация, обучение и т.д.).

Мини-бар «Кухня / Курьеры» под показателем labor_pct показывает только два из этих компонентов:

Роль	Что входит	Что НЕ входит
Кухня (labor_by_role.kitchen)	Пиццамейкеры и повара. Дневной ФОТ кухни считается по фактически отработанным сменам (реальные начисления за смену), а не равномерным размазыванием месячного ФОТ по дням. Месячные премии и доплаты распределяются по дням пропорционально дневной базе.	Кассиры, уборщицы, управляющие, администраторы, курьеры. Зарплата уборщиц исключена из ФОТ кухни везде — и в дне, и в месяце.
Курьеры (labor_by_role.couriers)	Выплаты курьерам по факту дня (PAYOUT)	Яндекс-курьеры (учитываются отдельно в ФОТ, но не показаны в мини-баре)

Разница labor_pct − (kitchen + couriers) ≈ 4-6% — это управляющие, кассиры, уборщицы, постоянный ФОТ (взносы НДФЛ, мотивация, обучение). Эта часть в дашборде явно не визуализируется, но входит в общий labor_pct и в OM.

Так как зарплата уборщиц вынесена из ФОТ кухни (а не размазана по дням вместе с поварами, как было раньше), LC% и OM% по кухне получаются немного ниже, чем по «грязному» бухгалтерскому ФОТ, где уборщицы сидят внутри кухонной статьи. Это сделано осознанно: кухонный ФОТ отражает только работу кухни. Курьерская часть при этом не менялась.

Потери (новый KPI)

Потери = сумма списаний по 4 статьям из iiko:

• Порча (spoilage) — испорченное сырьё / готовый продукт
• Проработка (test_kitchen) — тестовые блюда, дегустации, проработки рецептов
• Срок реализации (expiry) — закончился срок годности
• Удаление со списанием (dish_deletion) — отмена заказа клиентом с потерей продукции

В процентах от выручки: losses_pct = (Порча + Проработка + Срок + Удаление) / Revenue × 100%

Не входят в Потери: Бесплатная еда сотрудников (это HR-статья, отдельно) и Благотворительность.

Источник: iiko Resto API TRANSACTIONS OLAP, фильтр TransactionType=WRITEOFF + Account.Name. Подтянуто в v1.7 daily facts pipeline (закрыт пункт reminders 19.05).

Норматив: 🟢 ≤ 1.5% · 🟡 1.5-2.5% · 🔴 > 2.5%. Закреплён в `kpi_dictionary.md` §2.8.

Спот-чек Апр 2026: сетевые Потери = 1.14% (норма зелёная), Семилуки 1.04%, Курчатов и Бобров — самые низкие.

Прогноз выручки (RUN rate)

В вкладке Точка (виджет «Прогноз выручки») и в Карте точек (колонка «Прогноз на месяц ₽», видна только при grain=Месяц) — одна и та же цифра для одного и того же месяца:

• Формула: forecast[month] = avg(посуточная выручка) × days_in_month.
• Для прошедших полных месяцев avg×days_in_m ≈ фактическая сумма.
• Для текущего неполного месяца — линейная экстраполяция текущей средней до конца месяца.
• Прогнозируется только выручка (без profitability, без breakdown).

Источник посуточных значений: data.day[d].network.revenue_total для сети и data.day[d].by_point[pt].finance.revenue для точек.

Модуль: _scripts/forecast_runrate.py. Старая YoY × season 2025 модель архивирована в _archive/forecast_yoy_2026-05-26.py.

Композитный рейтинг точки (Карта точек)

Во вкладке «Карта точек» в столбце «Ранг» — общая оценка точки одним числом 1–N (N = число активных точек на дату: до мая 2026 = 16, с мая = 15 без Котовска). Меньше = лучше. Реализация: _scripts/rating.py + build_v0_9.py (day/week/month).

Композит — взвешенное среднее рангов по 9 KPI (v0.9.5, Илья 2026-06-02). Для каждого KPI точки ранжируются 1..N, итог = Σ(ранг × вес) / Σ(вес). Сумма весов = 29.

Вес	KPI	Направление
5	Опер. маржа %	↑ выше = лучше
3	On-time % · Качество Пицца · Время кухни · Время в пути	on-time / пицца ↑, время ↓
3	Полка > 7 мин %	↓ ниже = лучше
3	Качество Кассир · FC% · LC%	кассир ↑, FC / LC ↓

Алгоритм:

1. Для каждого из 9 KPI точки ранжируются 1..N. Higher-better → макс = ранг 1; lower-better → мин = ранг 1. При равенстве — одинаковый ранг, следующий пропускается.
2. composite = Σ(ранг × вес) / Σ(вес) по доступным KPI. Если KPI у точки отсутствует (Пицца/Кассир не замерялись и т.п.) — он исключается из числителя и знаменателя, точка не штрафуется.
3. Точки сортируются по composite по возрастанию. Лучшая = финальный ранг 1.

Зоны: 🥇🥈🥉 топ-3 · 🟢 топ-5 · 🟡 6–11 · 🔴 12–N.

Что НЕ в композите (показывается в heatmap для контекста, ⓘ-курсивом): Выручка (размер точки) и Ср.чек (сегмент / ассортимент) — характеризуют не операционную эффективность; Время исполнения (kitchen + road — производная, чтобы не дублировать веса); Прогноз выручки (прогнозная, не фактическая).

Сравнение по конкретному KPI — клик по точке → вкладка «Точка» (ТОП-5 + vs Сеть / vs Топ-3 / vs Анти-3 / vs конкретная точка).

Нормативы (светофоры)

Источник: 00_context/kpi_dictionary.md §2.

Anti-pattern бэйджи K|S|D

Три мини-индикатора слева от имени точки в heatmap. Цвет считается через light() по соответствующему NORMS:

• K — Kitchen time (общее время приготовления). 🟢 ≤13 мин · 🟡 13-15 · 🔴 >15. Источник: NORMS.kitchen_time_sec = {good 780, warn 900}.
• S — Shelf time (среднее время на полке). 🟢 ≤1 мин · 🟡 1-2 · 🔴 >2. Источник: NORMS.shelf_time_sec = {good 60, warn 120}.
• D — On-time % (эффективность доставки). 🟢 ≥95% · 🟡 93-95% · 🔴 <93%. Источник: NORMS.on_time_pct.

Что такое «>7 мин %» (Shelf overhold)

Доля заказов, простоявших на полке после готовности больше 7 минут. Источник критерия 7 мин — БЗ «Скоро Пицца», страница «Расчёт KPI»: после 7 мин на полке пицца теряет качество (остывает, корка теряет хруст). Норма ≤ 2%, жёлтая зона 2-4%, красная > 4%.

Источник с round 4 (27.05.2026): per-order из iiko OLAP. Формула: shelf_sec = Delivery.SendTime − Delivery.CookingFinishTime для каждого заказа, count(shelf > 420s) / total delivery. Реализация в 16_build_operations_daily.py, поле shelf_over_7min_iiko {count, total, share_pct} в daily_kpi.json. Раньше брали готовый процент из Сводного отчёта (только янв-март 2026, 10/16 точек) — это был shortcut, не отвечавший ТЗ §7.2.1 «брать по этапам заказа iiko».

Формула «опоздание» / эффективность доставки

Опоздание считается через поле Delivery.Delay из iiko OLAP (фактическая задержка vs обещанного времени):

• Тип заказа «Доставка» — опоздание с 10 минуты задержки.
• Тип заказа «Отложенная доставка» — опоздание с 30 минуты задержки.

Эффективность доставки = 1 − (опоздавшие / все доставки).

Полная карта нормативов (БЗ Скоро Пицца, 2026-05-22)

KPI	🟢 хорошо	🟡 удовл.	🔴 плохо
Kitchen доставка	≤15 мин	15-17	>17
Kitchen самовывоз	≤13 мин	13-15	>15
Kitchen зал	7-10 мин	10-12	>12
Время на полке (shelf)	<1 мин	1-2	>2
% заказов >7 мин на полке	<2%	2-4%	>4%
Эффективность доставки (on-time)	≥95%	93-95%	<93%
Время в пути (road)	≤10 мин	10-15	>15
Время исполнения (kitchen+road)	≤33 мин	33-40	>40
Completion time (без отложенных)	<32 мин	32-36	>36
Рейтинг ТТ	>97%	90-97%	<90%
Процент рекламаций	<0.5%	0.5-1%	>1%
Качество пицца / сервис	>92%	90-92%	<90%

Источник: БЗ «Скоро Пицца», страница «Расчёт KPI», подтверждено COO 2026-05-22. Эти пороги — закреплённый стандарт сети.