Как объединить разрозненные iiko-базы ресторанной франшизы

Откуда берётся «зоопарк» баз

У iiko есть встроенный модуль для работы с франшизами — iikoFranchise. Он умеет реплицировать эталонную базу головной организации на базы франчайзи и рассылать обновления меню. Инструмент рабочий, но в реальной эксплуатации у него оказалось сразу несколько ограничений: лицензия на использование модуля платная и не все франчайзи её оплачивают, сама репликация выполняется медленно, а часть новых точек в принципе не заводилась через этот модуль — вместо этого меню выгружали в CSV и импортировали в базу франчайзи вручную. В одном из показательных случаев франчайзи вообще сначала завёл весь ассортимент в 1С, а затем перенёс его в iiko — то есть в обход и репликации, и структуры эталонного меню.

К этому добавляется особенность самой iiko: типоразмерные шкалы. Инструмент удобный — можно завести одно блюдо с одним артикулом и продавать его сразу в нескольких размерах (например, пельмени по 10, 15 и 20 штук), и вся аналитика по нему будет собираться под одним названием. Но сторонние интеграторы — сервисы доставки, внешние приложения для заказа — с размерными шкалами работать не умеют. Им нужен отдельный артикул на каждый размер. В результате там, где интеграция была нужна, франчайзи вручную разводили одно блюдо на несколько кодов — иногда так, что связь с исходной позицией терялась.

Ещё один нюанс: размеры порций в iiko хранятся не числом, а произвольной строкой. Ресторан может назвать порцию не «10 штук», а «средняя порция» — и сопоставить такие записи между двумя базами напрямую, простым сравнением значений, невозможно.

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

Что это ломает

Разнородность баз бьёт сразу по нескольким задачам:

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

Чем это отличается от встроенного iikoFranchise

Логично спросить: зачем строить отдельный инструмент, если у iiko уже есть модуль для франшиз? На практике оказалось, что iikoFranchise решает не совсем ту задачу.

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

Что мы построили: эталонное меню и инструмент сопоставления

Решение строится на двух вещах: эталонном меню в головной организации и инструменте сопоставления номенклатуры — мы называем его экспортом номенклатуры.

Логика работы:

1. Технолог головной компании заводит новое блюдо (или обновляет техкарту существующего) один раз — в эталонной базе iiko.
2. В инструменте экспорта номенклатуры выбирается позиция или группа позиций для распространения по сети. Интерфейс сразу показывает, что уходит вместе с блюдом — ингредиенты, модификаторы, апсейлы, — чтобы ничего не потерялось при переносе.
3. Позиция экспортируется в базу конкретного франчайзи. Если в этой базе уже есть похожая запись — например, франчайзи и так уже продаёт эти пельмени, просто завёл их сам, — инструмент это обнаруживает и предлагает не плодить дубль, а связать существующую запись с эталонной.
4. Расхождения — разные названия одной и той же позиции, задвоенные артикулы — подсвечиваются в интерфейсе. Если расхождений нет, запись помечается как готовая к сопоставлению без дополнительных действий.
5. Между эталонным идентификатором и локальным идентификатором франчайзи сохраняется связь — на уровне отдельного UID, а не по совпадению текстовых полей. Для блюд с несколькими размерами порций такая связь строится по каждому размеру отдельно, и здесь же учитывается особенность iiko: если у франчайзи размер назван произвольной строкой, а не числом, сопоставление всё равно происходит на уровне конкретной записи, а не через сравнение названий.
6. После того как связь установлена, все дальнейшие операции идут через неё: платформа знает, что артикул чесночного соуса в базе франчайзи №12 — это тот же чесночный соус, что и в эталонном меню, забирает по этой связи актуальную цену и наличие, использует именно этот идентификатор при создании заказа в конкретной базе.
7. Когда техкарта обновляется в эталонной базе, обновлённую позицию можно одним действием раскатить по всем ресторанам, у которых уже есть сопоставление.

Дубли и неправильные названия чаще всего результат ручных ошибок — кто-то дважды экспортировал одну и ту же позицию, кто-то завёл не то блюдо. Автоматическое переименование или удаление в чужой базе — рискованная операция; вместо этого инструмент показывает, где именно проблема.

Само сопоставление баз — техническая операция, скрытая от повседневного использования: франчайзи и сотрудники головной компании видят только список экспортированной номенклатуры — что уже отправлено в конкретный ресторан, что предстоит отправить. Связи между идентификаторами хранятся во внутренней таблице платформы и в интерфейс, которым пользуется бизнес, не выводятся — там нет пользовательской ценности, только технический служебный слой.

С чего начать внедрение в своей сети

Если франшиза узнаёт себя в описанной проблеме, порядок работ обычно такой:

1. Инвентаризация. Прежде чем строить инструмент сопоставления, нужно понять масштаб хаоса: сколько баз iiko реально используется, у кого репликация через iikoFranchise, у кого меню заведено вручную или через CSV.
2. Эталонное меню. Формируется единый источник истины — база головной организации, из которой в дальнейшем идёт вся номенклатура.
3. Пилот на одном франчайзи. Сопоставление запускается на одной точке, чтобы увидеть реальные расхождения — обычно их находится больше, чем ожидалось на старте.
4. Раскатка по сети. После обкатки процесс масштабируется на остальные рестораны — уже с понятной картиной, сколько расхождений типично для одной точки и сколько времени занимает их разбор.
5. Регламент для новых франчайзи. Отдельная задача — прописать, как заводится номенклатура у новой точки с первого дня, чтобы зоопарк баз не начал копиться заново.

Как эта же связка данных ложится в основу омниканальности

Архитектура единого меню для сайта, приложения и киоска

Читать статью

Как устроена вся платформа целиком

Как мы объединили 18 независимых iiko в единую систему управления франшизой

Смотреть кейс