Переход без потерь: как спланировать миграцию с R-keeper на iiko, сохранив историю заказов и бонусы гостей

Решение о смене POS-системы в ресторане почти никогда не принимается в спокойной обстановке. Обычно это реакция на накопившуюся боль: касса тормозит в час пик, склад «расходится» с фактом, программа лояльности живёт отдельно от заказа, а отчёты приходится сводить в Excel вручную. К этим раздражителям добавляется страх потерять то, что уже работает: накопленную за годы базу гостей, бонусные баллы, историю заказов, фотографии блюд в меню, настроенные склады и скидки. Именно поэтому миграция с R-keeper на iiko воспринимается владельцами как проект с высоким риском — даже если логически они уже понимают, что новая система нужна.

В 2026 году этот переход перестал быть уникальной историей. На рынке HoReCa в России сформировался устойчивый поток проектов по замене R-keeper на iiko: сети растут, открывают вторые и третьи концепции, добавляют доставку и агрегаторы, начинают работать с CRM и сквозной аналитикой, и старая архитектура перестаёт справляться. При этом сама технология миграции давно отработана: есть конвертеры баз, есть сценарии выгрузки чеков и бонусов, есть партнёры, которые ведут подобные проекты десятками в год. Проблема почти всегда не в технологиях, а в управлении проектом: владелец не понимает, кто отвечает за каждый кусок данных, когда нужно «замораживать» изменения, что делать с активными акциями и как повести себя в первую неделю после переключения.

Эта статья — пошаговое руководство для владельца, генерального директора или операционного директора ресторана. Мы разберём, как спланировать миграцию так, чтобы сохранить историю заказов, бонусные балансы гостей, настройки склада, меню и скидочные механики. Поговорим о типичных ошибках, из-за которых проекты «разваливаются» в первые выходные, и о том, как организовать работу с подрядчиком, чтобы он отвечал не за «внедрение iiko», а за конкретный результат: рабочий ресторан в понедельник утром и сохранённую лояльность гостей.

Хорошая миграция — это не перенос базы. Это проект, в котором владелец, операционный директор и подрядчик заранее договорились, что именно считается «сохранённым» и как это проверить.

Зачем вообще менять R-keeper на iiko в 2026 году

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

Боли, которые накапливаются в R-keeper за годы работы

Самая частая жалоба — разрозненные модули. В R-keeper CRM, склад, лояльность, доставка и отчёты исторически развивались как отдельные модули с собственной логикой и интерфейсом. Когда ресторану нужна сквозная аналитика, например «какие гости из программы лояльности заказывают доставку чаще двух раз в месяц и какие блюда они берут», приходится вручную выгружать данные из нескольких подсистем и сводить в Excel. На маленьком ресторане это терпимо, на сети из 5–10 точек превращается в ежедневную ручную работу аналитика.

Вторая болевая точка — работа с гостевой базой и бонусами. В R-keeper исторически сильная кассовая часть, но гостевые программы и бонусные механики часто реализованы либо через отдельный модуль, либо через интеграции с внешними сервисами. В результате база гостей и история заказов могут жить в разных контурах. При миграции на iiko владельцы часто хотят получить единый профиль гостя, в котором видны и бонусный баланс, и средний чек, и предпочтения, и реакция на акции.

Третья зона — интеграции с агрегаторами доставки и маркетплейсами. В 2026 году ресторан без доставки — скорее исключение. В iiko складывается более «коробочная» экосистема: есть встроенная работа с Delivery Club, Яндекс Едой, а также поддержка собственного модуля доставки. Для сетей, которые планируют масштабирование, это снижает количество внешних интеграций и упрощает сопровождение.

Четвёртая зона — отчётность и прозрачность для собственника. iiko давно используется как инструмент управленческого учёта: есть удобные отчёты по выручке, себестоимости, списаниям, явные панели для управляющих. Многие владельцы, которые раньше работали с R-keeper, переходят на iiko именно ради более понятной аналитики — особенно после того, как сеть выходит за пределы одной-двух точек и нужен контроль дистанционно.

Наконец, кадры и обучение. R-keeper долгое время остаётся стандартом в HoReCa, и найти кассира с опытом R-keeper обычно проще, чем с опытом iiko. Но обратная сторона — «так принято» мешает внедрять новые процессы. Сети, которые внедряют iiko осознанно, закладывают в проект обучение и сертификацию, а в перспективе — рост квалификации команды и снижение зависимости от «единственного человека, который умеет администрировать систему».

Если вы меняете R-keeper на iiko только потому, что у конкурента стоит iiko, — это плохой мотив. Если вы меняете, потому что текущая система перестала закрывать хотя бы две из задач выше, — это нормальный мотив.

Когда переход действительно оправдан

Миграция оправдана, если совпадают хотя бы три из пяти условий:

Вы открываете третью и последующие точки либо планируете это в ближайшие 6–12 месяцев, и текущая архитектура не масштабируется.
У вас есть программа лояльности, и вы хотите связать её с доставкой, бронированием и отзывами в единый профиль гостя.
Отчётность строится вручную, занимает больше 4–6 часов в неделю у операционного директора или бухгалтерии, и из-за этого решения принимаются «по ощущениям».
Вы хотите управлять сетью из одного кабинета, а не из десяти, и видеть сводные показатели в реальном времени.
У вас уже есть понимание, какие интеграции нужны (сайт, мобильное приложение, CRM, сервисы отзывов, системы чаевых, эквайринг), и текущая система не даёт нужного качества этих связок.

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

Что именно нужно сохранить при миграции: карта данных

Главная причина провалов миграции — не техническая сложность переноса базы, а отсутствие у владельца чёткого представления, что именно считается «сохранённым». Подрядчик спрашивает: «Перенести историю заказов?», владелец отвечает: «Да, конечно». Через месяц выясняется, что «история» — это только последние 90 дней, а данные за два года остались в архиве R-keeper и в новую систему не попали. Чтобы этого не происходило, ещё до старта проекта нужно составить «карту данных» — явный список того, что переносим, в каком виде и в каком объёме.

Категории данных, которые обычно переносят

Меню и техкарты. В этот блок входит актуальное меню с ценами, модификаторами, техкартами (рецептурами), схемами приготовления, аллергенами и фотографиями. В R-keeper и iiko структура техкарт различается: в iiko она ближе к классическому «блюдо + ингредиенты + выход», в R-keeper — к собственным каталогам. Поэтому при миграции часто не «переносят» техкарты один в один, а пересобирают их в новой системе, опираясь на старые данные. Важно заранее понять, какие блюда вы реально используете, какие техкарты «живые», а какие давно устарели — иначе переедете с грузом мусора.

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

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

История заказов. Здесь важно определить глубину: за 3 месяца, за год, за весь срок. Полная история заказов в iiko технически переносится, но редко нужна в оперативной работе — она нужна для аналитики и маркетинга. В большинстве проектов переносят последние 12–24 месяца, а более старую историю архивируют в отдельный отчёт, чтобы при необходимости достать.

Гостевая база и бонусы. Это самый «эмоциональный» блок. Гости — это актив ресторана, и потеря бонусного баланса воспринимается ими как обман. При миграции нужно сохранить: - ФИО/имя, телефон, email, дату рождения (если собирали). - Сумму накопленных бонусов и срок их действия. - Статус в программе лояльности (уровень, категория). - Историю начислений и списаний хотя бы за последний год. - Связанные карты, если использовались физические или виртуальные носители.

Скидки и акции. Активные промо-акции, купоны, механики «шестой кофе бесплатно» и подобные — всё это нужно либо корректно перевести в формат iiko, либо корректно «закрыть» в R-keeper до переключения. Иначе гости придут с купоном, который в новой системе не читается, и будет скандал.

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

Блоки, которые не нужно переносить

Существуют данные, которые при миграции лучше обнулить или архивировать, а не переносить:

Старые неактивные карты гостей, по которым не было визитов более 12–18 месяцев: они замусорят базу и исказят аналитику.
Прайс-листы, которые больше не действуют: их можно держать в архиве вне iiko.
Тестовые и «мусорные» позиции меню, созданные при настройке и забытые.
Закрытые складские документы, приходы и акты списания за периоды старше года.
Устаревшие скидки и акции, которые давно не используются.

Перед миграцией пройдитесь по всем справочникам R-keeper с операционным директором и маркетологом. Каждый пункт спросите: «Это нужно в новой системе?» Если ответ «не уверен» — лучше не переносить.

Этапы проекта: от решения до стабильной работы

Миграция — это не «включили iiko в понедельник». Это проект длительностью обычно 6–12 недель для одной точки и 3–6 месяцев для сети. Разделим его на смысловые этапы, чтобы вы понимали, что происходит в каждый момент и какие решения принимаете лично вы.

Подготовительный этап: 2–4 недели

На этом этапе вы не трогаете R-keeper, а только готовите почву. Главная задача — собрать требования и зафиксировать их в документе, который станет ТЗ для подрядчика. Звучит скучно, но именно на этом шаге большинство проектов либо выстраиваются, либо ломаются.

Что входит в подготовку:

Аудит текущей системы: какие модули R-keeper реально используются, какие отчёты строятся, какие интеграции работают, где «костыли» и ручные операции.
Формирование карты данных: что переносим, что не переносим, в каком объёме, с какой глубиной истории.
Выбор партнёра-внедрителя. Здесь важно смотреть не на «цену за внедрение», а на опыт миграций именно с R-keeper на iiko, наличие сертификатов iiko, готовность показать кейсы и предоставить контакты предыдущих клиентов.
Согласование бюджета и сроков. В бюджет закладывайте не только лицензии и работы подрядчика, но и потенциальные расходы на инвентаризацию, обучение, возможный «тихий» период после запуска (когда скорость обслуживания временно ниже обычной).
Назначение проектной команды со стороны ресторана. Минимум: владелец или операционный директор, администратор R-keeper, бухгалтер/калькулятор, старший смены. У каждого — своя зона ответственности.
Составление плана-графика с контрольными точками. Не «примерный план в голове», а документ с датами, ответственными и критериями завершения каждого этапа.

На этом же этапе вы выбираете модель лицензирования iiko: облако или сервер on-premise, пакет модулей, количество рабочих мест, необходимость модуля CRM, доставки, склада, бонусной программы. Это влияет и на бюджет, и на архитектуру.

Этап настройки: 3–6 недель

Когда требования зафиксированы, подрядчик начинает разворачивать iiko. На этом этапе R-keeper продолжает работать — это ключевое правило, которое многие нарушают. Нельзя «для удобства» начать вбивать параллельно данные в обе системы, иначе к моменту переключения они разойдутся.

Что происходит в фазе настройки:

Установка и настройка iiko: сервер, база, роли, типы оплат, склады, юридические лица, точки.
Заведение меню, модификаторов, техкарт, аллергенов, фотографий. Это самый трудоёмкий кусок: 100–300 позиций меню с модификаторами — это нормальный объём для среднего ресторана.
Настройка склада: места хранения, единицы измерения, поставщики, приходные цены.
Настройка прав доступа сотрудников, графиков смен, ставок.
Создание дисконтной и бонусной программы в iiko: уровни, правила начисления, срок действия, комбинации с акциями.
Настройка интеграций: эквайринг, фискализация, агрегаторы доставки, сайт, мобильное приложение, CRM, системы отзывов, чаевые.
Тестовые прогоны: чеки, возвраты, скидки, бонусы, складские операции, Z-отчёт, X-отчёт.

Параллельно ваша команда готовит «обратный отсчёт»: сценарий заморозки изменений в R-keeper, план инвентаризации, список активных гостевых карт и обязательств, которые нужно перенести в первую очередь.

Этап «заморозки» и тестового переноса: 1 неделя

За 5–7 дней до переключения прекращаются любые изменения в R-keeper, которые нельзя «откатить» вручную. Это значит:

Не вводятся новые позиции меню, не меняются техкарты, не создаются новые акции.
Не проводятся крупные складские операции: массовые приходы, инвентаризации с пересортицей.
Гостям не выдаются новые бонусные карты с длительным сроком действия «вперёд». Если гость приходит и просит завести карту, его предупреждают, что через неделю будет переход, и баланс будет перенесён в полном объёме.
Активные акции с длинным сроком действия (например, «кешбэк 10% до конца месяца») либо завершаются досрочно, либо явно пролонгируются в новой системе.

В эти же дни подрядчик делает тестовый перенос данных: выгрузка из R-keeper, конвертация, загрузка в тестовую базу iiko, сверка. Тестовый прогон позволяет выявить несоответствия в форматах, потерянные записи, ошибки в техкартах. После тестового переноса вы получаете отчёт: «Из 18 432 гостей перенесено 18 410, по 22 — не нашлось совпадений по телефону, рекомендуем ручную обработку». Это нормально. Главное — увидеть эти цифры до боевого переключения.

Этап переключения: выходные или ночь

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

Что происходит в момент переключения:

В R-keeper закрывается смена, печатается Z-отчёт, фиксируется состояние склада.
Делается финальная выгрузка данных из R-keeper: меню, склад, сотрудники, гости, бонусы, история заказов за согласованный период.
Данные загружаются в iiko, запускается сверка.
Проводятся «дымовые тесты»: открытие смены, продажа тестового блюда, начисление и списание бонусов, возврат, скидка.
Если всё в порядке — ресторан открывается на iiko.

Не пытайтесь переключиться «втихую», в обычный рабочий день, в надежде, что «и так сойдёт». Один час хаоса в час пик стоит дороже, чем сутки простоя в выходные.

Этап стабилизации: 2–4 недели

После переключения начинается период, в течение которого выявляются «детские болезни» системы: непривычные интерфейсы, ошибки в правах доступа, спорные моменты в скидках, разное поведение фискального регистратора. Это нормально, и к этому нужно быть готовым.

В фазе стабилизации:

На линии постоянно находится старший смены и представитель подрядчика, готовый ответить на вопросы и оперативно исправить настройки.
Первые 3–5 дней — ежедневная сверка отчётов iiko с фактическими данными: касса, склад, выручка, средний чек.
Гостям с бонусными картами при визите выдаётся «обновлённая» карта или подтверждается, что старый номер телефона работает в новой системе.
Сбор обратной связи от персонала: что неудобно, где «тормозит», каких кнопок не хватает.
Корректировка настроек по факту: расширение прав, перенастройка складов, правка техкарт.

Через 3–4 недели, когда отчёты стабильно сходятся и скорость обслуживания возвращается к прежнему уровню, проект можно считать «завершённым в основной части». Дальше — плановая поддержка и развитие: новые отчёты, новые интеграции, оптимизация склада.

Ключевые сценарии: перенос истории заказов и бонусов

Теперь разберём две самые чувствительные зоны миграции подробно: история заказов и бонусные программы. Здесь больше всего рисков и больше всего нюансов.

Перенос истории заказов

История заказов нужна не «для галочки». У неё три конкретных применения:

Аналитика и управление. Владелец и операционный директор смотрят динамику среднего чека, выручки по точкам, популярности блюд, сезонности. Без истории эти отчёты начинаются «с нуля», и первые 2–3 месяца после миграции вы принимаете решения «вслепую».
Маркетинг и лояльность. Сегментация гостей, персональные предложения, реактивация «спящих» клиентов — всё это строится на истории заказов. Без неё вы не сможете отличить гостя, который приходил 20 раз за год, от гостя, который пришёл однажды.
Бухгалтерия и налоговая. Закрытие периодов, сверка выручки, восстановление документов при проверках — всё это требует доступа к чекам за прошлые периоды.

При переносе истории заказов важно учитывать следующее:

Формат и объём. Полная история заказов за 2–3 года в среднем ресторане — это сотни тысяч строк. Перенести их «в лоб» в оперативную базу iiko можно, но это замедлит работу системы. Поэтому в большинстве проектов делают двухслойный перенос: оперативные данные за последние 6–12 месяцев попадают в основную базу iiko, более старая история — в отдельный аналитический слой (отчёт, OLAP-куб, выгрузка в BI-систему). В iiko.biz и iikoChain есть встроенные инструменты для работы с большими объёмами, но чаще используют внешнюю аналитику — например, выгрузку в Power BI или собственный дашборд.

Связка с гостями. История заказов без привязки к гостю — это просто финансовая статистика. История с привязкой — это инструмент CRM. Поэтому при переносе критически важно сохранить связку «заказ — гость». В R-keeper гость определяется по карте или номеру телефона, в iiko — по номеру телефона или гостевой карте. Подрядчик должен заранее проработать маппинг: если у гостя в R-keeper была карта № 100123, а в iiko он теперь идентифицируется по телефону +7 999 123-45-67, то все заказы по карте должны «прилипнуть» к этому телефону. Если в базе были дубли (один гость — две карты), их объединяют.

Связка с меню и складом. Исторический заказ «Стейк рибай, 250 г» в R-keeper ссылается на конкретную позицию меню с конкретной техкартой. После миграции эта позиция может называться иначе или иметь другую техкарту. Чтобы отчёты «что заказывали чаще всего» работали корректно, нужен маппинг старых и новых позиций меню. Подрядчик делает таблицу соответствия: «Блюдо в R-keeper → Блюдо в iiko», и переносит историю заказов с использованием этой таблицы.

Возвраты и сторнирования. Возвраты в R-keeper и в iiko учитываются по-разному. При переносе важно, чтобы возвраты за прошлые периоды не «висели» в системе как обычные продажи. Обычно их переносят отдельным документом — корректировочной записью, чтобы отчёты по чистой выручке оставались корректными.

Что делать с очень старой историей. Если ресторан работает 5–7 лет и в R-keeper скопилась история за весь срок, переносить её всю в iiko обычно не нужно. Достаточно: - иметь выгрузку за весь срок в виде Excel/CSV на случай налоговой или внутренней сверки; - в iiko загрузить последние 12–24 месяца — этого хватает для оперативной аналитики; - по более старым данным — построить агрегированные отчёты (выручка по месяцам, топ-50 блюд за год), которые занимают мало места и дают общее понимание динамики.

Если подрядчик говорит «мы перенесём всю историю за 5 лет в iiko и всё будет работать» — задайте вопрос: «А зачем?» Чаще всего 90% аналитических задач закрываются 12–24 месяцами, а старшая история нужна только для редких сверок.

Перенос бонусов и гостевой базы

Это самый чувствительный блок миграции — и технически, и репутационно. Гость, у которого на карте 1500 бонусов, должен прийти в ресторан после перехода и увидеть те же 1500 бонусов. Если баланс «потеряется», вы получите негативный отзыв, пост в соцсетях и, возможно, жалобу в Роспотребнадзор.

Что нужно сохранить:

Идентификация гостя. В R-keeper гость может быть привязан к карте, к телефону или к тому и другому. В iiko базовый идентификатор — телефон. Поэтому на этапе подготовки важно: - выгрузить список гостей с указанием карты, телефона, ФИО, email, даты рождения; - провести дедупликацию: один гость мог получить несколько карт за время участия в программе; - убедиться, что у большинства гостей есть телефон — без него идентификация в iiko будет работать плохо.

Если у значимой части базы (более 10–15%) нет телефонов, перед миграцией стоит провести коммуникацию: «Уважаемые гости, обновите свои данные, чтобы мы могли сохранить ваши бонусы». Это делается через email-рассылку, push в приложении, посты в соцсетях, информацию в зале.

Бонусный баланс. Баланс переносится по состоянию на дату переключения с точностью до копеек. Подрядчик делает выгрузку текущих балансов из R-keeper и загружает их в iiko в виде начального сальдо. После переключения новые начисления и списания идут уже в iiko по правилам новой программы.

Здесь важно заранее определиться с двумя вещами: - Срок действия бонусов. В R-keeper у бонусов мог быть свой срок жизни (например, 6 месяцев с момента начисления). В iiko срок можно настроить, но если вы решите поменять правила, у гостей, которые «копят» бонусы годами, может возникнуть справедливое возмущение. Лучший подход — сохранить старые правила для уже начисленных бонусов и ввести новые только для будущих начислений. - Минимальная сумма списания. В R-keeper могло быть ограничение «списать можно от 500 бонусов». В iiko это тоже настраивается, но менять правила в момент миграции — плохая идея.

Уровни и статусы. Если в R-keeper была многоуровневая программа («Базовый», «Серебро», «Золото»), уровни нужно перенести в iiko. Здесь возможны два подхода: - Прямой маппинг: «Базовый» → «Базовый», «Серебро» → «Серебро», «Золото» → «Золото». Понятно гостям, но требует, чтобы в iiko были те же уровни. - Пересчёт по новым правилам: например, в iiko уровни зависят от оборота за 6 месяцев, и гость с «Золотом» в R-keeper может стать «Серебром» в iiko, потому что в последние полгода он приходил редко. Это честнее, но требует грамотной коммуникации: «Ваш статус пересчитан по новым правилам, у вас есть 3 месяца, чтобы подтвердить его активностью».

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

Технически история переносится в виде отдельной таблицы, к которой можно обращаться из iiko, но чаще всего она живёт в аналитическом слое (BI-система, отчёт). Главное — чтобы баланс «на сейчас» был корректным.

Физические носители. Если в ресторане использовались пластиковые карты, при миграции есть три варианта: - Оставить старые карты как «идентификатор по штрихкоду» и просто пробивать их сканером, привязав в iiko к нужному гостю. - Заменить карты на новые в момент миграции (с совмещением акций «обменяй карту — получи бонус»). - Полностью уйти на идентификацию по телефону и QR-коду.

Каждый сценарий стоит просчитывать по расходам: перевыпуск пластика — это типография, дизайн, логистика, остатки старых карт на складе. В 2026 году большинство сетей уходит на идентификацию по телефону и QR-коду, оставляя пластик только как элемент VIP-статуса.

Не пытайтесь «обнулить» старые бонусы и начать программу с чистого листа. Гости воспринимают это как обман, и вы потеряете больше на оттоке, чем сэкономите на бонусах.

Технические нюансы переноса данных

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

Откуда берутся данные в R-keeper

R-keeper — это модульная система. Данные хранятся в нескольких местах: - Кассовый сервер (RK7) — чеки, смены, оплаты. - Менеджерская станция (RK7 Manager) — отчёты, склады, приходы. - Модуль складского учёта (StoreHouse) — складские документы, техкарты, инвентаризации. - CRM-модуль — гости, карты, история визитов (если используется). - Внешние модули — лояльность, доставка, бронирование, отзывы — могут хранить данные в собственных базах.

Миграция из R-keeper — это, по сути, сборка данных из нескольких источников и их конвертация в формат iiko. Чем больше модулей вы использовали, тем сложнее проект.

Куда приходят данные в iiko

В iiko большинство данных хранится в одной базе: - iikoServer (или iikoCloud) — центральное ядро. - iikoOffice — административный интерфейс. - iikoFront — кассовое приложение. - iikoKitchen — экран повара. - iikoDelivery — модуль доставки. - iikoCard — гостевые карты и бонусы. - iikoReports — аналитические отчёты (OLAP).

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

Конвертеры и сценарии переноса

На рынке существует несколько конвертеров данных из R-keeper в iiko — как от самой компании iiko, так и от партнёров-внедрителей. Типичный сценарий переноса:

Выгрузка данных из R-keeper в CSV/XML: меню, склад, гости, бонусы, история.
Очистка и нормализация: приведение к единым справочникам, дедупликация, устранение «мусорных» записей.
Маппинг: соответствие старых и новых сущностей (блюдо в R-keeper → блюдо в iiko, тип оплаты → тип оплаты и т. д.).
Загрузка в iiko в правильном порядке: сначала справочники (сотрудники, типы оплат), затем меню, склад, гости, бонусы, история.
Сверка: отчёт «было столько-то, стало столько-то, расхождения такие-то».

Уточните у подрядчика, какой конвертер он использует, есть ли у него автоматизированные скрипты или каждое сопоставление делается вручную. Автоматизация снижает риск ошибки и ускоряет проект.

Фискализация и ОФД

Отдельный технический блок — фискализация. Если вы меняете не только бэк-офис, но и кассовое оборудование, нужно заранее: - проверить совместимость фискального регистратора с iiko; - перерегистрировать кассу в ФНС при необходимости; - убедиться, что ОФД корректно принимает чеки из iiko; - протестировать связку до переключения, а не «в день Х».

В 2026 году для большинства моделей ФР интеграция с iiko стандартная, но бывают нюансы: например, при работе с несколькими юрлицами или при использовании облачной кассы.

Типичные ошибки владельцев при миграции

За годы проектов на рынке выделились устойчивые паттерны ошибок. Разберём их — каждую с признаками, последствиями и тем, как её избежать.

Ошибка 1: «Перенесём всё, а потом разберёмся»

Признаки: владелец не утверждает карту данных, говорит подрядчику «делайте как считаете нужным», не назначает ответственного со стороны ресторана.

Последствия: в iiko переезжает 5-летняя база с дубликатами, неактивными гостями, устаревшими техкартами. Система тормозит, отчёты показывают странные цифры, команда не понимает, что считать «правдой».

Как избежать: утвердить карту данных на этапе подготовки, провести очистку в R-keeper, переносить только то, что реально нужно.

Ошибка 2: «Бонусы обнулим, так проще»

Признаки: владелец или маркетолог решает, что проще начать программу лояльности с чистого листа, чем разбираться со старыми балансами.

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

Как избежать: переносить бонусы в полном объёме, даже если это технически сложно. Если правила меняются — ввести новые только для будущих начислений.

Ошибка 3: «Подрядчик всё сделает сам»

Признаки: владелец подписывает договор с партнёром-внедрителем и устраняется от проекта до момента приёмки.

Последствия: подрядчик принимает решения, которые не соответствуют ожиданиям владельца, не учитывает внутренние процессы, делает «как у всех». В день запуска выясняется, что отчётность настроена не так, как хотел бухгалтер, а склад работает по другой логике.

Как избежать: назначить проектного менеджера со стороны ресторана, проводить еженедельные статус-встречи, согласовывать ключевые настройки (меню, склад, бонусы, права) до их внедрения.

Ошибка 4: «Переключимся в обычный день, авось никто не заметит»

Признаки: владелец не хочет «терять день» и решает переключиться в будний день или в вечернее время, чтобы «меньше было гостей».

Последствия: в момент пиковой нагрузки сотрудники не понимают, что делать, чеки оформляются с ошибками, гости ждут, в чатах поддержки iiko — очередь из ваших сотрудников.

Как избежать: выделять под переключение выходные или нерабочее время, иметь «дежурного» от подрядчика в первые 3–5 дней.

Ошибка 5: «Инвентаризацию сделаем потом»

Признаки: владелец считает, что склад можно перенести «на глаз» и провести инвентаризацию через месяц.

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

Как избежать: проводить инвентаризацию за 2–3 дня до переключения, фиксировать остатки, иметь в первую неделю после запуска ежедневную сверку.

Ошибка 6: «Обучение проведём в день запуска»

Признаки: обучение сотрудников откладывается на последний момент, а в день запуска проводится 30-минутный инструктаж.

Последствия: официанты не понимают, как разбить чек, кассиры не знают, где начислять бонусы, повара путаются в статусах заказов. Скорость обслуживания падает в 2–3 раза, гости жалуются, выручка проседает.

Как избежать: обучать сотрудников до переключения, в течение 1–2 недель на этапе настройки. Каждый должен «потрогать» систему в тестовом режиме минимум 2–3 раза.

Ошибка 7: «Отчёты потом настроим»

Признаки: после запуска владелец не смотрит отчёты 1–2 месяца, занимается «тушением пожаров».

Последствия: вы не понимаете, действительно ли iiko даёт ту аналитику, ради которой затевалась миграция. Через 2–3 месяца оказывается, что нужные отчёты не настроены, а данные «утекли» в непривычные формы.

Как избежать: с первого дня после запуска ежедневно смотреть 3–5 ключевых отчётов: выручка, средний чек, складские остатки, активность бонусной программы, отмены и возвраты. Через месяц — расширять набор.

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

Как выбрать подрядчика и не пожалеть

В 2026 году на рынке достаточно партнёров iiko, чтобы выбрать было из кого. Но не все из них одинаково хороши именно в миграциях с R-keeper. Вот на что смотреть.

Признаки сильного подрядчика

Опыт миграций именно с R-keeper. Спросите: «Сколько проектов по переходу с R-keeper на iiko вы провели за последние 2 года?» Хороший ответ — 10+. Попросите 2–3 контакта клиентов, у которых можно спросить о впечатлениях.
Сертификация iiko. У подрядчика должны быть действующие сертификаты iiko (обычно публикуются на сайте компании). Без них нельзя продавать лицензии и оказывать официальную поддержку.
Команда, а не один человек. Если весь проект держится на одном внедрителе — это риск: он заболеет, уволится, уйдёт в отпуск, и проект встанет. Нормальная команда: менеджер проекта, аналитик, технический специалист, специалист по обучению.
Готовность показать процесс. Хороший подрядчик на этапе продаж покажет: план-график, шаблон карты данных, пример отчёта о миграции, описание рисков. Слабый — ограничится коммерческим предложением с итоговой суммой.
Поддержка после запуска. Миграция — это не разовый проект, а переход на новое сопровождение. Уточните: что входит в поддержку, какое время реакции, сколько стоит расширенная поддержка, есть ли выделенный менеджер.

Вопросы, которые стоит задать на первой встрече

Какой конвертер данных вы используете? Можете показать пример отчёта о тестовом переносе?
Как вы решаете вопрос с дубликатами в гостевой базе?
Что делаете с бонусами, у которых в R-keeper был срок действия, а в iiko будет другой?
Как организовано обучение? Сколько часов на каждую роль?
Кто будет на связи в день переключения и в первую неделю после?
Как фиксируете расхождения между R-keeper и iiko после переноса?
Что входит в стоимость, а что оплачивается отдельно?
Можете дать контакты 2–3 клиентов, у которых мы могли бы уточнить впечатления?

Красные флаги

«Мы всё сделаем за 2 недели» — для ресторана с историей это нереально. Минимум 6 недель, обычно 8–12.
«Перенесём всю историю в iiko и всё будет летать» — без обсуждения объёма и формата это пустые слова.
«У нас собственная методика миграции, мы не используем стандартные конвертеры» — либо ноу-хау (что хорошо), либо попытка продать «уникальность» вместо отработанного процесса (что плохо). Спрашивайте детали.
«Стоимость фиксированная, что бы ни случилось» — в реальности в проекте бывают форс-мажоры. Жёстко фиксированная цена — повод насторожиться: либо подрядчик заложил огромный запас, либо будет «экономить» на этапах.
«Обучение можете провести сами, я дам вам мануал» — обучение нельзя отдавать на откуп самому ресторану. Это зона ответственности подрядчика.

Лучший подрядчик — тот, который на этапе продаж задаёт вам неудобные вопросы: «А зачем вам это?», «А вы уверены, что хотите это переносить?», «А какие у вас KPI от миграции?». Если подрядчик только кивает и называет цену — это плохой признак.

Что делать в первые недели после запуска

После того как iiko запущен в боевом режиме, начинается, как мы уже говорили, этап стабилизации. Разберём его по неделям.

Неделя 1: ежедневный контроль

Утро: сверка кассы за прошлый день, проверка X-отчёта.
Середина дня: проверка склада, сверка с фактическими остатками по «быстрым» позициям (мясо, рыба, молочка).
Вечер: анализ пиковой нагрузки, скорости обслуживания, времени печати чеков.
Конец смены: Z-отчёт, фиксация любых сбоев и ошибок.

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

Неделя 2: расширение контроля

Подключение аналитических отчётов: динамика выручки, средний чек, популярность блюд, активность бонусов.
Сверка с бухгалтерией: совпадают ли цифры в iiko с тем, что ушло в 1С (или другую учётную систему).
Проверка интеграций: все ли агрегаторы доставки получают корректное меню, все ли отзывы приходят в нужный канал.
Сбор обратной связи от гостей: «Всё ли работает с бонусной картой? Удобно ли пользоваться новым приложением?»

Неделя 3: оптимизация

Корректировка прав доступа (по факту реальной работы).
Оптимизация скорости работы кассы: если что-то тормозит — выяснять, почему.
Настройка дополнительных отчётов: те, которые не успели на этапе внедрения.
Обучение продвинутым функциям: например, как работать с расписанием смен, как закрывать смену, как проводить инвентаризацию.

Неделя 4: приёмка проекта

Формальная приёмка: подписание акта выполненных работ, сверка результатов с ТЗ.
Фиксация «открытых вопросов» — того, что нужно доделать в ближайший месяц.
Переход на плановую поддержку: подрядчик перестаёт быть «на линии 24/7» и переходит в режим регулярных обращений.
Подведение итогов: совпадает ли результат с теми KPI, ради которых затевалась миграция.

Как оценить, что миграция прошла успешно

Через 1–2 месяца после запуска полезно остановиться и честно оценить результат. Есть несколько метрик, которые показывают, достигли ли вы целей.

Скорость обслуживания

До миграции вы знаете среднее время обслуживания гостя: от прихода до получения счёта. После запуска iiko эта метрика может временно ухудшиться. Если через 4–6 недель она вернулась к прежним значениям или стала лучше — миграция прошла без серьёзных потерь по сервису.

Корректность складских остатков

Расхождение между остатками в системе и фактическими остатками на складе. В норме — не более 1–2% в денежном выражении. Если расхождение больше 5% — есть проблема с настройкой склада или с качеством инвентаризации.

Сохранность гостевой базы

Доля гостей, которые «активировались» в новой системе (пришли в ресторан, использовали бонусную карту, зашли в приложение). Если через 2 месяца после миграции «проснулись» 60–70% гостей из активной базы — отлично. Если меньше 40% — что-то пошло не так в коммуникации или в технической части.

Скорость построения отчётов

Время, которое нужно операционному директору, чтобы получить ответ на вопрос: «Какие блюда приносят больше всего выручки по вторникам в точке на Тверской?» Если раньше это занимало 2 часа в Excel, а теперь — 2 минуты в iiko, цель достигнута.

Удовлетворённость персонала

Опрос сотрудников: «Вам удобнее работать в R-keeper или в iiko? Что раздражает в новой системе?» Если команда жалуется на конкретные вещи (например, «неудобно открывать смену» или «непонятно, где начислять бонусы»), это сигнал к доработке настроек, а не к откату на R-keeper.

Финансовые показатели

Корректный управленческий учёт — главная цель большинства миграций. Если через 2 месяца вы: - видите реальную маржинальность по блюдам, - понимаете, какие скидки «съедают» прибыль, - можете быстро посчитать эффективность акций, - сверяете кассу и склад без Excel,

значит, миграция окупается.

Стоимость миграции и от чего она зависит

Владельцы часто ожидают, что миграция стоит «как лицензия iiko плюс немного работы подрядчика». На практике это более сложная история, и стоимость проекта зависит от нескольких факторов.

Что входит в бюджет миграции

Лицензии iiko. В 2026 году iiko предлагает несколько моделей: подписку с ежемесячной оплатой, покупку лицензий, облачное решение. Базовый пакет (iikoFront, iikoOffice, iikoServer) для небольшого ресторана — ориентировочно от нескольких тысяч рублей в месяц за рабочее место. Полный набор с CRM, доставкой, складом — дороже.

Работы подрядчика. Включают аудит, настройку, перенос данных, обучение, поддержку на этапе запуска. Стоимость сильно зависит от объёма: для одной точки без сложных интеграций это диапазон «несколько сотен тысяч рублей», для сети с 5+ точек и сложным меню — «несколько миллионов».

Оборудование. Если вместе с iiko вы меняете кассовое оборудование, фискальные регистраторы, терминалы оплаты, экраны повара — это отдельная статья расходов.

Инвентаризация. Перед миграцией желательно провести полную инвентаризацию, а это либо время вашей команды, либо деньги на приглашённого специалиста.

Обучение. Хороший подрядчик включает обучение в стоимость проекта, но иногда за дополнительные часы (например, для второй смены или для новых сотрудников через 2 месяца) приходится доплачивать.

Потери выручки в период стабилизации. Это не «расход» в чистом виде, но реальные потери, которые нужно заложить в финмодель. В первые 1–2 недели скорость обслуживания падает, часть гостей уходит, потому что «раньше было удобнее». Обычно это 5–15% выручки в период стабилизации с восстановлением в течение месяца.

От чего зависит итоговая стоимость

Количество точек. Сеть мигрировать дороже, чем одиночный ресторан, но и экономия на масштабе есть.
Сложность меню. 50 блюд без модификаторов и 300 блюд с 10 модификаторами каждое — это разные проекты.
Количество используемых модулей. Если вы используете R-keeper только как кассу, проект простой. Если есть CRM, склад, доставка, бронирование, лояльность — проект сложный.
Состояние текущей базы. Если в R-keeper чисто, понятная структура, минимум «мусора» — перенос дешевле. Если 5 лет хаоса — дороже.
Необходимость нового оборудования. Замена касс, фискальных регистраторов, экранов — отдельная история.
Регион и удалённость. В Москве и Петербурге больше выбора подрядчиков, в регионах — меньше, и командировочные расходы могут быть существенными.

Не экономьте на подрядчике за счёт качества миграции. Потерянная гостевая база и испорченная репутация обойдутся дороже, чем разница между «средним» и «сильным» внедрителем.

Чек-лист готовности к миграции

Чтобы не упустить ничего важного, держите под рукой этот чек-лист. Он разбит по этапам и может использоваться как повестка проектных встреч.

Подготовка (за 6–8 недель до переключения)

[ ] Сформулированы цели миграции в измеримых показателях.
[ ] Проведён аудит текущего использования R-keeper: какие модули активны, какие отчёты строятся, где «ручные» процессы.
[ ] Составлена карта данных: что переносим, что нет, в каком объёме.
[ ] Выбран подрядчик-внедритель, подписан договор с описанием объёма работ и KPI.
[ ] Согласован бюджет, включая лицензии, работы, оборудование, обучение, резерв на форс-мажоры.
[ ] Назначена проектная команда со стороны ресторана: владелец, операционный директор, администратор, бухгалтер, старший смены.
[ ] Утверждён план-график с контрольными точками.
[ ] Принято решение по модели лицензирования iiko: облако или сервер, состав модулей.
[ ] Подготовлен план коммуникации с гостями: когда и как предупредить о переходе, что будет с бонусами.

Настройка (за 4–6 недель до переключения)

[ ] Установлен и настроен iiko: сервер, база, юрлица, точки.
[ ] Заведено меню с модификаторами, техкартами, аллергенами, фотографиями.
[ ] Настроен склад: места хранения, единицы измерения, поставщики.
[ ] Настроены права доступа сотрудников и графики смен.
[ ] Настроена программа лояльности: уровни, правила начисления, срок действия, ограничения.
[ ] Настроены интеграции: эквайринг, фискализация, агрегаторы, сайт, CRM.
[ ] Проведены тестовые прогоны кассовых операций.
[ ] Проведено обучение сотрудников (минимум 2 занятия на каждую роль).
[ ] Проведён тестовый перенос данных, получен отчёт о расхождениях.
[ ] Согласован сценарий заморозки изменений в R-keeper за 5–7 дней до переключения.
[ ] Назначена дата и время переключения (рекомендуется: ночь воскресенья на понедельник или утро понедельника, если ресторан закрыт).

Заморозка (за 5–7 дней до переключения)

[ ] Прекращены изменения в R-keeper: меню, склад, акции.
[ ] Гостям прекращена выдача карт с длительным сроком действия.
[ ] Активные акции либо завершены, либо явно пролонгированы в iiko.
[ ] Проведена инвентаризация склада в R-keeper.
[ ] Отправлена финальная коммуникация гостям о переходе и сохранении бонусов.
[ ] Подрядчик подтвердил готовность к боевому переносу.

Переключение (день Х)

[ ] В R-keeper закрыта смена, напечатан Z-отчёт.
[ ] Сделана финальная выгрузка данных из R-keeper.
[ ] Данные загружены в iiko, проведена сверка.
[ ] Проведены «дымовые тесты»: открытие смены, продажа, бонусы, возврат, скидка.
[ ] Проверена работа фискального регистратора и эквайринга.
[ ] На линии присутствует представитель подрядчика.
[ ] Персонал работает в режиме «повышенной готовности»: вопросы фиксируются, ответы — сразу.
[ ] Запущена «горячая линия» для гостей: если у кого-то не сработала карта, можно быстро решить.

Стабилизация (первые 2–4 недели)

[ ] Ежедневная сверка кассы и склада в течение первой недели.
[ ] Сбор и обработка обращений гостей по бонусам и картам.
[ ] Корректировка настроек по факту реальной работы.
[ ] Расширение набора аналитических отчётов.
[ ] Опрос персонала: что неудобно, что доработать.
[ ] Формальная приёмка проекта с подписанием акта.
[ ] Переход на плановую поддержку.
[ ] Оценка результатов по KPI: скорость, точность склада, активность гостей, удовлетворённость персонала.

Распространённые мифы о миграции

В заключение разберём несколько устойчивых мифов, которые мешают владельцам принять взвешенное решение.

Миф 1: «Миграция — это всегда катастрофа»

В реальности — катастрофой бывает не сама миграция, а её плохая организация. Десятки сетей в России перешли с R-keeper на iiko в последние годы без потери выручки и гостей. Ключ — правильный проектный подход, понятные KPI, опытный подрядчик.

Миф 2: «В iiko всё неудобно»

В iiko другая логика интерфейса, и первое время она может казаться менее привычной, чем R-keeper. Но после 2–3 недель работы большинство сотрудников признают, что в iiko многие операции выполняются быстрее: например, разделение чека, начисление бонусов, оформление доставки. «Неудобство» — это в основном эффект новизны и недостаточного обучения.

Миф 3: «Гости не заметят, если мы потеряем их бонусы»

Заметят, и очень быстро. Бонусная программа — это «долг» ресторана перед гостем. Если баланс исчез, гость чувствует себя обманутым. В эпоху соцсетей и мессенджеров один негативный отзыв виден сотням потенциальных гостей. Сохранять бонусы нужно обязательно.

Миф 4: «Подрядчик сделает всё за нас, нам останется только подписать акт»

Нет. Без активного участия владельца и команды ресторана проект «развалится» в первые выходные. Подрядчик привносит экспертизу и технологию, но решения по бизнес-логике (что важно, какие отчёты, какие правила) принимаете вы.

Миф 5: «После миграции всё сразу станет идеально»

Не сразу. Будет 2–4 недели адаптации, в течение которых скорость обслуживания временно снизится, часть процессов придётся докручивать, сотрудники будут привыкать. Это нормально, и к этому нужно быть готовым. Идеально станет через 1–2 месяца.

Миф 6: «iiko — это только для больших сетей»

В 2026 году iiko активно используется и одиночными ресторанами, и небольшими сетями. Модульная архитектура позволяет не платить за то, что вам не нужно, и подключать новые модули по мере роста.

Что делать прямо сейчас

Если вы уже приняли решение о миграции, начните с трёх вещей:

Составьте карту данных — даже черновую, на одном листе. Что переносим, что нет, в каком объёме. Это станет основой ТЗ для подрядчика и предметом разговора с потенциальными исполнителями.
Соберите 2–3 коммерческих предложения от партнёров iiko с опытом миграций с R-keeper. Не выбирайте по цене — выбирайте по пониманию вашего бизнеса и по качеству ответов на неудобные вопросы.
Определите 3–5 KPI проекта. Например: «сохранить 100% базы гостей и бонусов», «снизить время построения отчёта по выручке до 2 минут», «обеспечить скорость обслуживания не ниже прежней через 30 дней после запуска». Эти KPI станут критериями приёмки.

И последнее. Миграция с R-keeper на iiko — это не столько технический проект, сколько управленческий. Технически конвертеры данных давно отработаны, специалистов хватает. Реальный риск — в людях, процессах и коммуникациях. Если вы выстроите проект правильно — с понятными ролями, сроками, KPI и регулярной обратной связью — переход пройдёт без потерь. И через 2–3 месяца вы будете удивляться, почему не сделали этого раньше.

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

Переход без потерь: как спланировать миграцию с R-keeper на iiko, сохранив историю заказов и бонусы гостей