Почему этого обычно не делают
Когда владелец сети из 5-15 точек приходит за BI поверх iiko, стандартный совет от рынка — «возьмите Power BI и подключите к стандартным отчётам iiko». Это работает для одного ресторана. Для сети, где нужен сводный food-cost, сравнение смен между точками и единый P&L с 1С, — упирается в потолок довольно быстро.
Альтернатива — лезть в iiko Service напрямую. И вот тут начинается самое интересное. Причин, по которым этот путь почти никто не проходит, несколько:
- Документация для внешнего интегратора закрытая и фрагментированная. Нет Swagger, нет полного OpenAPI. Есть PDF-ка, обрывки на форумах, ответы техподдержки — собираешь картину по кусочкам.
- API нестабильный между версиями. То, что работало в 7.x, может сломаться в 8.x. Структура ответа меняется, новые обязательные параметры появляются, endpoint-ы переименовываются.
- Авторизация через токен на каждый вызов, rate-limits без явных лимитов. Нигде не написано, с какой частотой можно тянуть — узнаёшь опытным путём, когда сервер iiko начинает отвечать 503.
- Custom-поля. У каждой сети своя надстройка — типы заказов, категории списаний, роли сотрудников, поля тех.карт. Зашить константы в код — гарантированно сломаться при следующем релизе у клиента.
- Нет общепринятого паттерна «iiko → DWH» на русскоязычных ресурсах. Habr, телеграм-каналы, ютуб — всё про Power BI над готовыми отчётами. Ни одного полноценного инженерного разбора мы не нашли.
В итоге обычный интегратор сразу отказывается, а клиент либо остаётся с встроенной аналитикой iiko, либо ждёт какого-нибудь облачного сервиса, который «за 5 тыс. в месяц» обещает всё — и обычно даёт те же срезы, что уже есть в iiko.
Что вообще можно вытащить из iiko Service
Если решиться на прямую интеграцию — под капотом iiko оказывается неплохой набор endpoint-групп. Без конкретных URL и версий (они всё равно меняются), чтобы у читателя сложилась картина, что там в принципе живёт:
- Чеки и позиции чеков — OLAP-подобный endpoint, основной источник продаж. Выдаёт строки чеков со всеми модификаторами, скидками, типами оплаты, официантом, точкой.
- Блюда и технологические карты — справочник блюд + ингредиенты с нормативами расхода. Тот самый источник для эталонного food-cost.
- Остатки по складам и движения — приходы, расходы, инвентаризации, межскладские перемещения.
- Списания по категориям — бой, брак, срок годности, внутреннее потребление. Критично для честного food-cost, потому что норматив по тех.карте и реальный расход — это разные цифры.
- Персонал — смены, должности, начисления, графики. Сюда ложится вся аналитика по людям.
- Поставщики и поставки — справочник контрагентов, входящие накладные, истории цен.
- Поступления — приёмка товара на склад с привязкой к конкретной поставке.
Этого набора хватает, чтобы собрать настоящий food-cost по блюду с раскладкой до ингредиента, честный P&L по точке и всё, что хочет финдиректор сети. Нужно только корректно вытащить, уложить в DWH и состыковать с 1С.
Архитектура решения
Ключевая идея — не пускать iiko в общее хранилище на равных с остальными источниками. Слой iiko изолируем в отдельную подпапку DWH. Это не академическая чистота, а страховка: когда через полгода выйдет новая версия iiko и половина полей поедет — мы перепишем ровно эту подпапку, а не весь куб и не всё хранилище.
Практически это выглядит так. В /DWH/Таблицы/iiko Service/ лежат сырые таблицы-отражения API и staging-витрины, которые всё ещё говорят на языке iiko. Оттуда данные переливаются в общие витрины DWH, где уже нет «заказа iiko» и «дока iiko», а есть просто «чек» и «списание» — в единой модели с 1С.
Дальше над общими витринами стоит SSAS Tabular, в нём меры, RLS по точкам и ролям — и отчёты Power BI подключены ровно туда. Это стандартная архитектура, которую мы описывали в разборе архитектуры BI на стек Microsoft, но с одним нюансом — слой iiko живёт отдельно.
Таблицы в DWH
Нотация у нас своя, она описана в методологии DEEONE: tf — таблица фактов, tr — справочник, tb — мост (bridge) для связи «многие-ко-многим». На слое iiko минимально получается вот такой набор:
| Таблица | Тип | Что внутри |
|---|---|---|
| tf Чеки iiko | факт | Номер чека, дата, точка, официант, касса, тип заказа, сумма, скидка, тип оплаты |
| tf Позиции чеков iiko | факт | Блюдо, цена, количество, модификаторы, категория списания (если сторно) |
| tf Движения ингредиентов iiko | факт | Поступления, списания, инвентаризации, межскладские перемещения |
| tr Блюда iiko | справочник | Справочник блюд: категории, группы меню, атрибуты (веган, алкоголь, срок годности) |
| tr Сотрудники iiko | справочник | ФИО, должность, ставка, график, даты приёма/увольнения |
| tr Ингредиенты iiko | справочник | Номенклатура сырья: единицы, группы, текущий поставщик, средняя закупочная цена |
| tb Блюдо — Ингредиент iiko | мост | Тех.карты: много-ко-многим блюдо ↔ ингредиент, норматив расхода на порцию |
| tf Смены iiko | факт | Открытие/закрытие смены, состав сотрудников, начисления, чаевые |
Мост tb Блюдо — Ингредиент критичен: одно блюдо состоит из 5-15 ингредиентов, один ингредиент (условная мука) входит в десятки блюд. Без моста любой честный расчёт food-cost разваливается — получите либо задвоение, либо потерю данных.
Все таблицы в пространстве имён iiko (tf ... iiko). На общем слое DWH такие таблицы трансформируются в tf Продажи, tf Движения запасов и т.д., где iiko становится одним из атрибутов «источник», а не отдельной вселенной.
Пять отчётов, которые получает клиент
Всё, что ниже, — живые отчёты, которые невозможно собрать на встроенной аналитике iiko. Каждый закрывает конкретный управленческий вопрос сети — от «почему падает маржа в марте» до «какого поставщика менять».
Food-cost по блюду с декомпозицией
Сравниваем реальный расход ингредиентов по списаниям с нормативной тех.картой. В отчёте две колонки — «норматив» и «факт», плюс отклонение в процентах и рублях. Видно, где повар даёт «лишку»: в круассане положено 85 г сливочного масла, а реально уходит 102 г — умножаем на 5 тысяч штук в месяц, получаем 85 кг масла в минусе.
Встроенные отчёты iiko показывают общий food-cost по точке, но не раскладывают его до отдельного блюда с учётом списаний.
Маржа блюда с учётом времени приготовления
Считаем маржу на «нагрузку повара» — маржу рубль/минуту приготовления, а не просто процент. Становится видно, какие блюда в пиковый час тормозят кухню: условный «бургер с трюфельным маслом» имеет 68% маржи, но готовится 14 минут, а сэндвич — 52% маржи и 3 минуты. На пике именно сэндвич должен быть в приоритете меню.
Это один из отчётов, после которого клиент пересобирает лэнч-меню и поднимает среднюю маржу смены на 4-6 п.п.
Эффективность смены
Выручка смены против её состава. Видно, кто из поваров/официантов стабильно вытягивает высокий чек, кто проседает, в какие часы. Срез по точкам позволяет выявлять системные провалы: например, во вторник утром на трёх точках одновременно падает выручка — значит, причина не в людях, а в трафике и надо менять расписание.
Оборачиваемость поставщиков ингредиентов
По каждому поставщику — стабильность цены (дисперсия между поставками), качество (доля списаний по категории «брак» от этого поставщика), ритмичность поставок. Поставщик, у которого цена прыгает на ±18% между поставками и 4% списаний по браку, — это реальные убытки на горизонте года. Отчёт даёт основание для переговоров и замены.
Списания — где теряется маржа
Декомпозиция списаний по категориям: истёкший срок, брак, корректировка после инвентаризации, внутреннее потребление. По точкам, по блюдам, в динамике по месяцам. Когда в одной точке списания «по сроку» составляют 0.8% от выручки, а в соседней — 3.4%, это не случайность. Это системная ошибка заказа сырья, и её видно только в таком разрезе.
Подводные камни, которые мы прошли
Теория закончилась, дальше — мелкие уроки, за которые мы заплатили неделями переделок.
Custom-поля каждой сети
При первом запуске выкачиваешь структуру как есть, без гипотез о том, что внутри. У клиента могут быть свои типы заказов («заказ на месте», «доставка», «кейтеринг», «корпоратив на офис»), свои категории списаний, свои роли в смене. Если в ETL-коде захардкожено перечисление — переезд на следующую сеть превращается в переписывание половины пайплайна. Мы храним словари значений как отдельные справочники и обновляем их каждую ночь.
Нестабильность API между версиями
Именно ради этого — изоляция в /DWH/Таблицы/iiko Service/. Однажды клиент обновил iiko с 7.x на 8.x, и у endpoint-а по списаниям сменилась структура ответа: вместо плоского списка пришёл вложенный объект с группировкой по типам. Переписывали ровно 3 staging-процедуры внутри подпапки iiko. Все витрины выше по стеку и все отчёты остались нетронутыми.
Разница с данными в 1С
iiko и 1С считают выручку чуть-чуть по-разному. Главные расхождения: учёт скидок (iiko может отражать их как отдельную строку, 1С — минусом к основной), модификаторы (доп. сыр, доп. эспрессо — в iiko это часть позиции, в 1С может прилететь отдельным номенклатурным кодом), возвраты. До запуска любых отчётов нужна сверка «iiko vs 1С» по дням за 3-6 месяцев, где каждый день должен сойтись до копейки. Без этой сверки финансовый директор не поверит ни одной цифре в отчётах.
Нагрузка на iiko Service
Если тянуть все endpoint-ы каждую ночь полной выгрузкой — сервер iiko ложится. У клиента это не просто «сломался отчёт» — это кассы не принимают заказы в утреннюю смену. У нас инкрементальная загрузка по меткам обновления: выкачиваем только дельту с последнего запуска, а тяжёлые справочники (блюда, ингредиенты, тех.карты) обновляем раз в сутки ночью.
Для кого это и когда оправдано
Прямая интеграция с iiko Service и собственное DWH — это не универсальный ответ. Она работает, когда:
- Сеть от 5-10 точек. На одной-двух точках встроенных отчётов iiko более чем достаточно.
- Нужен food-cost по блюду, эффективность смен, единый P&L c 1С. То, что встроенная аналитика не даст ни при каких настройках.
- У сети есть финансовый директор или CFO-функция. Без заказчика на стороне бизнеса, который способен задать правильные вопросы к данным, инвестиция в такое DWH не окупится.
- Есть бюджет и горизонт планирования от года. Это не проект на месяц, это инфраструктура, которая живёт и развивается.
Когда это не нужно:
- 1-2 точки со стандартными KPI — встроенных отчётов iiko хватит с запасом.
- Сеть на этапе запуска, где ещё не устоялись процессы — данные будут «шумные», выводы ненадёжные.
- Нет человека в бизнесе, который будет читать эти отчёты. BI без адресата — это кладбище дашбордов.
А пока
- У вас сеть общепита и встроенная iiko-аналитика уже не хватает — обсудим проект. Первый разговор бесплатный, 30 минут, без обязательств. По итогу скажем, окупится у вас такое решение или нет.
- Есть другая учётная система помимо iiko (Rkeeper, Storehouse, своя разработка) — подход тот же, только изолированную подпапку зовут иначе. Смотрите разбор связки 1С + iiko + Rkeeper.
- Хотите сначала оценить свою текущую аналитику — BI-аудит за 5 дней даёт полный план: что в ваших данных уже есть, что можно вытащить без переделки архитектуры, а что потребует DWH.
Связанные материалы:
- Интеграция 1С, iiko и Rkeeper в единое DWH — обзорный материал про связку учётных систем общепита
- DWH на стек Microsoft в 2026 — полное руководство по архитектуре хранилища
- Все методы выгрузки данных из 1С для BI — соседний сложный источник с похожими граблями
- Методология DEEONE — про нотацию
tf/tr/tbи принципы слоистой архитектуры DWH