r_keeper и Shelter: как связать ресторан с гостиницей, отелем или санаторием

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

Похожие сложности возникают с:

Один из самых понятных сценариев — закрытие ресторанного заказа на номер гостя.

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

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

Перед запуском такого сценария важно определить:

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

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

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

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

Поэтому автоматизация питания начинается не с установки кассы, а с описания правил:

После этого уже выбирают, какие данные должны передаваться между Shelter и r_keeper.

Обслуживание в номерах — ещё один сценарий, где раздельные системы неудобны.

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

Для автоматизации важны не только деньги. Нужно решить:

Если room service занимает заметную долю продаж, его лучше рассматривать как отдельный бизнес-процесс, а не как обычный заказ ресторана с комментарием «в номер 214».

Гостиничные комплексы часто продают не отдельные услуги, а пакет: номера, конференц-зал, кофе-брейки, банкет, питание группы и дополнительные активности.

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

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

Для группового мероприятия стоит заранее определить:

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

Крупный отель может включать основной ресторан, лобби-бар, бар у бассейна, пляжную точку, room service и банкетную службу. Для гостя всё это — услуги одного объекта. Для учёта — разные рабочие места, меню, склады и сотрудники.

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

Shelter при этом остаётся источником информации по проживанию и гостиничному счёту.

Интеграция Shelter и r_keeper не отменяет ресторанный складской учёт.

Продажа блюда должна по-прежнему попадать в контур, где ресторан контролирует продукты, полуфабрикаты, себестоимость и движение запасов. Для этого используется соответствующая складская система r_keeper.

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

Именно поэтому при автоматизации гостинично-ресторанного комплекса полезно разделять три уровня:

Связь между системами нужна, но роли у них разные.

Чем теснее связаны системы, тем важнее права пользователей.

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

При настройке определяют:

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

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

Отдельное внимание — нестандартным доработкам. Если объект много лет развивался, в нём могут быть собственные отчёты, обработки и интеграции. Любое изменение нужно оценивать с учётом этих зависимостей.

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

Минимальный набор сценариев:

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

Связка r_keeper и Shelter особенно полезна, если:

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