Переход с iiko, Poster или другой POS-системы на r_keeper: как сократить простой

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

Обычно вопрос о смене системы возникает, когда:

До начала переноса нужно сформулировать ожидаемый результат. Например: объединить несколько заведений, организовать единые справочники, сократить ручной ввод, настроить права сотрудников или связать кассу со складским учётом. Если цель не определена, есть риск перенести в r_keeper старую структуру вместе со всеми её недостатками.

В работающем ресторане POS-система связана почти со всеми операциями. Поэтому проект начинается с описания текущего контура. В него входят:

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

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

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

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

Конфигурация r_keeper подбирается под реальную структуру заведения. Для небольшой кофейни это может быть одна касса, ККТ, кухонная печать и отчётность. Для ресторана с несколькими цехами потребуются отдельные маршруты заказов, рабочие места официантов, кухонные экраны и более детальные права. Для сети важны единые справочники, централизованные настройки и сводные данные по точкам.

На этапе проектирования определяются:

Исправная работа устройства со старой программой ещё не означает, что его можно без проверки оставить в новой конфигурации. До запуска оцениваются:

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

Меню загружается в тестовую базу, где можно спокойно проверить его до первой рабочей смены. На этом этапе контролируются:

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

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

Если используются доставка, программа лояльности, маркировка или складской учёт, для каждого контура проводится отдельная проверка.

Сотрудникам не нужен общий обзор всех функций системы. Им нужно уверенно выполнять свои операции.

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

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

К моменту переключения должны быть готовы:

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

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

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