Как объединить iiko и r_keeper в одном ресторанном холдинге

В одной группе часто живут разные POS: исторически сложилось, M&A, франшиза. Задача — не «перевести всех на одну систему завтра», а выстроить управляемый контур: меню, заказы, delivery, финансы и BI без Excel-мостов между брендами.

Картина систем в холдинге

Инвентаризация: какие точки на iiko, какие на r_keeper, какие модули delivery, где CRM, где 1С. Карта потоков данных показывает, где уже есть ручной труд и дублирование справочников.

На практике холдинг из 30 точек обнаруживает 4 версии меню в разных форматах — это первый риск для единого приложения гостя.

Справочники и номенклатура

Выберите стратегию master data: центральный каталог с маппингом на локальные POS или федеративная модель с согласованными SKU. Без политики каждая интеграция создаст свой «уникальный» борщ.

Минимум для согласования

• категории и эталонные позиции;
• правила ценообразования по форматам;
• аллергены и маркировка;
• идентификаторы для BI.

Шина и адаптеры

Типовой паттерн: integration hub с адаптерами iiko и r_keeper, единый API для сайта, приложения и BI. Прямые point-to-point связи быстрее на старте, но не масштабируются на новые бренды.

Единый delivery-контур

Гость может видеть один бренд и несколько точек. Backend выбирает ресторан, создаёт заказ в нужном POS, отдаёт статусы в общее приложение. Стоп-листы и зоны — per location, правила — централизованно.

Сводная аналитика

BI-слой нормализует выручку, food cost, delivery-SLA и NPS по сопоставимым измерениям. CFO получает один отчёт, управляющие — drill-down до POS-транзакции.

Поэтапная миграция

1. пилот на 2 точках разных POS;
2. единое приложение гостя для одного города;
3. раскатка analytics и master data;
4. решение о консолидации POS — отдельно, по экономике.

Не смешивайте «единое приложение гостя» и «миграцию всех на iiko». Первый даёт быстрый эффект, второй — многолетнюю программу.

Для каждого адаптера опишите ownership: маппинг меню, реакция на обновление POS, окно релизов.

Guest layer должен быть независим от выбора POS точки: гость видит бренд, backend маршрутизирует заказ в нужную систему.

Единая CRM поверх multi-POS требует согласованного guest id: телефон, email, device id. Без этого лояльность «рвётся» при заказе из точки на другой системе.

Юридически разделите контуры персональных данных по юрлицам группы, если точки работают на разных ООО — это влияет на архитектуру шины.

Стандартизируйте коды блюд для BI там, где taste-of бренда совпадает, но POS разный — это удешевляет отчётность без forced migration.

Заложите budget на поддержку двух адаптеров минимум три года, даже если стратегия — eventual single POS.

Документируйте decision log по спорным кейсам master data — через полгода команда забудет, почему SKU сопоставлены именно так.

Пилотируйте изменения master data на ограниченном наборе SKU — полный big bang для меню сети обычно слишком рискован.

Связанные страницы