Кому нужны какие права доступа в гостинице?

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

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

Общий вход стирает автора каждого действия

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

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

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

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

Не стоит сохранять запасной общий пароль «на всякий случай». Именно им начинают пользоваться в выходной, при срочной подмене и после поломки телефона. Аварийную учетную запись можно держать у владельца, но ее пароль должен отличаться от рабочих, вход должен оставлять отдельное событие, а после использования пароль нужно сменить.

Роль описывает работу, а не статус человека

Хорошая роль отвечает на вопрос «что человек делает в эту смену», а не «насколько мы ему доверяем». Доверенному сотруднику тоже не нужна кнопка удаления базы. Новичку иногда нужен доступ к оплатам, если он один принимает деньги ночью. Решение принимает процесс, а не стаж и личная симпатия.

Для мини-отеля обычно достаточно четырех базовых ролей: владелец, администратор, горничная и бухгалтер. Пятая появляется, если есть управляющий несколькими объектами. Не создавайте отдельную роль под каждого человека, иначе через месяц никто не поймет, чем отличаются «администратор 2» и «администратор новый». Исключение лучше оформить как временное дополнительное право с датой окончания.

Рабочая матрица может выглядеть так:

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

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

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

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

Горничной нужен номер, а не досье гостя

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

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

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

Федеральный закон № 152-ФЗ не содержит таблицу ролей для гостиницы. Статья 7 требует от тех, кто получил доступ к персональным данным, не раскрывать и не распространять их без законного основания. Статья 19 требует установить правила доступа и регистрировать действия с персональными данными в информационной системе. Практический вывод уже закона: владелец сам определяет, какие сведения нужны каждой функции, и должен суметь объяснить это решение.

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

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

Администратору не всегда нужна вся финансовая картина

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

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

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

Скидки тоже требуют границы. Разрешение «до 10% без согласования» понятнее, чем полное право менять цену. Для более крупной скидки администратор отправляет запрос владельцу, а решение остается в комментарии или журнале. Так вы защищаете выручку и не заставляете гостя ждать звонка из-за любой мелочи.

Доступ к финансовым данным нескольких объектов выдавайте отдельно по каждому объекту. Управляющий домом и баней может видеть оба, администратор дома не должен автоматически видеть выручку бани. Общий аккаунт владельца для всей сети не повод копировать такой же охват каждому сотруднику.

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

Опасные действия нельзя прятать внутри широкой роли

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

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

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

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

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

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

Личный вход должен оставаться личным

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

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

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

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

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

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

Журнал нужен для восстановления, а не для слежки

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

Запись «бронь изменена» почти бесполезна. Владелец должен увидеть, что пользователь Анна в 14:37 изменил дату выезда брони 1842 с 12 на 13 августа, а затем система пересчитала сумму. Тогда можно проверить звонок гостя, сменный комментарий и оплату. Без старого значения остается только новая версия, а причина расхождения теряется.

Статья 19 Федерального закона № 152-ФЗ прямо связывает правила доступа с регистрацией и учетом действий над персональными данными. Я бы не сводил это требование к формальной галочке в локальном акте. Журнал приносит практическую пользу в тот же день, когда гость оспаривает изменение, номер оказывается продан дважды или исчезает документ.

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

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

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

Выдача и отзыв прав требуют одного владельца процесса

За доступ должен отвечать конкретный человек, обычно владелец объекта или управляющий, а не «кто сейчас свободен». Он создает учетную запись, выбирает роль, назначает объекты, ставит срок временным правам и закрывает доступ при смене обязанностей.

Запрос на дополнительное право можно уместить в одну запись:

Сотрудник: Ирина К.
Роль: администратор ночной смены
Объект: гостевой дом
Действие: возврат до 5 000 руб.
Основание: самостоятельное закрытие смены
Срок: 01.08.2026 - 31.08.2026
Согласовал: владелец

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

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

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

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

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

Ограничения надо проверять чужими руками

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

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

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

Повторите тест после обновления системы, добавления нового канала продаж и изменения роли. Новая функция иногда появляется с правом по умолчанию, которого раньше не существовало. Особенно внимательно проверяйте экспорт, уведомления и доступ к нескольким объектам.

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

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

Если система не умеет роли, компенсируйте это честно

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

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

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

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

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

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

Права доступа должны пережить ночную смену

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

Для каждой роли заранее определите, кто подменяет человека и как на время выдать дополнительные права. Ночная смена может получить право принять оплату, но не должна автоматически получать месячные отчеты и управление пользователями. Временный доступ заканчивается сам или снимается утром ответственным человеком.

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

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

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