Made on
Tilda
Управление ответственностью
Как убрать провалы между службами. Сквозной процесс, владелец результата и карта передачи вместо поиска виноватого.
Введение
Бронирование принято, пожелание записано, номер убран, техническая заявка закрыта. Но гость приезжает и не получает того, что ему подтвердили. Каждая служба может показать свою выполненную задачу, а отель в целом — нет. Именно так выглядит провал между подразделениями: отдельные действия состоялись, но никто не обеспечил их соединение в готовую услугу.
«Ответственность в отеле нельзя описать только должностными инструкциями. Необходимо определить, как задача проходит между людьми, кто принимает передачу и кто проверяет окончательный результат».
Иначе управляющий становится постоянным посредником между службами, а гость — невольным контролёром исполнения.
У гостиничной услуги редко бывает один исполнитель. Семейное размещение может затрагивать бронирование, стойку, хаускипинг, техническую службу и питание. При этом гость покупает не последовательность внутренних операций, а понятный результат: номер нужной категории, подготовленные места, работающий санузел и согласованные условия.
Майкл Хаммер, один из разработчиков процессного подхода к управлению, определял бизнес-процесс как сквозную работу, создающую ценность для клиента. Он подчёркивал различие между отдельной задачей и целым результатом: покупателю важно получить заказанное, а не узнать, что внутри компании правильно выполнили несколько подготовительных действий.
Для отеля это очень практичная мысль. Гостю не нужно разбираться, какая служба потеряла комментарий. Ему нужно получить подтверждённое размещение.
Учебный пример: дополнительное место
Семья забронировала номер с дополнительным местом. Отдел бронирования внёс информацию в систему. Стойка увидела её, но предположила, что хаускипинг получает такие задачи автоматически. Хаускипинг работал по другому списку. При заезде дополнительное место отсутствует.
Кто ошибся?
Если порядок передачи не установлен, вопрос нельзя сводить к поиску самого невнимательного сотрудника. Сначала нужно выяснить, каким образом информация должна была стать заданием.
Запись в системе, сообщение в чате и назначенная задача — разные вещи. Если это различие не определено, сотрудники будут по-разному понимать момент завершения своей работы.
Ступень 1
Сотрудник выполнил конкретную операцию.
Ступень 2
Следующий участник получил необходимые сведения и принял задачу.
Ступень 3
Процесс завершён, обещанное условие обеспечено.
Один человек может совмещать несколько уровней. Но они должны быть названы.
Например, администратор принял просьбу. Это не обязательно означает, что он лично должен принести оборудование или отремонтировать сантехнику. Однако порядок должен объяснять, кто проследит, чтобы обращение не осталось между принятием и исполнением.
На мой взгляд, одна из самых неудачных формулировок — «за это отвечают все». В ней может быть правильный посыл о командной работе, но нет механизма решения.
Другая крайность — объявить одного руководителя ответственным за всё, не дав ему доступа к информации и возможности влиять на процесс.
Хаммер отдельно описывал роль владельца сквозного процесса: он отвечает за устройство и результативность процесса, но не обязательно является линейным руководителем всех участвующих сотрудников.
Для гостиницы это означает, что можно назначить человека, который согласует порядок подготовки заезда и контролирует его работу, не переподчиняя ему техническую службу и хаускипинг.
Но такие полномочия должны быть реальными. Собственник или управляющий определяет:
Без этого «владелец процесса» превращается в красивое название человека, который всем напоминает, но ничего не может изменить.
APQC, профессиональная организация по производительности и качеству, описывает матрицу RACI как инструмент определения ролей и ответственности внутри процесса. Материал размещён в библиотеке ASQ.
В RACI различаются:
Роли в матрице
Необязательно внедрять английские буквы во все документы. Можно использовать русские обозначения. Важно сохранить различие ролей.
Я предлагаю назначать одного понятного ответственного за итог каждого выделенного результата. При этом сам процесс нужно разделить на достаточно конкретные этапы: иначе одна строка «обеспечить хороший сервис» ничего не прояснит.
| Этап | Исполнитель | Подтверждённый результат | Кому передаётся |
|---|---|---|---|
| Принять запрос | Бронирование | Условия записаны без противоречий | Стойке |
| Проверить возможность | Уполномоченный сотрудник | Понятно, что подтверждено гостю | Участникам подготовки |
| Подготовить номер | Хаускипинг | Места и комплектация готовы | Проверяющему |
| Устранить дефект | Техническая служба | Работоспособность проверена | Службе выпуска номера |
| Подтвердить готовность | Назначенный сотрудник | Номер разрешён к размещению | Стойке |
| Завершить координацию | Стойка | Условия заезда обеспечены | Гостю |
В конкретном отеле часть функций может быть объединена.
Я предлагаю начинать не с переписывания всех регламентов, а с повторяющихся сценариев, затрагивающих несколько служб.
Здесь важно разделить «убран», «проверен», «исправен» и «доступен для заезда».
Учебная ситуация
После уборки обнаружен технический дефект. Номер получает статус чистого, но информация о дефекте остаётся в отдельном сообщении. Стойка видит чистый номер и выдаёт ключ.
Решение — не требование «внимательнее читать чат». Нужно определить, какие статусы разрешают размещение и кто вправе их устанавливать.
Если система не поддерживает нужный маршрут, потребуется понятное временное решение. Но оно должно иметь ответственного и срок пересмотра, а не становиться бессрочной зависимостью от памяти сотрудников.
Человек сообщает, что кондиционер не работает. Стойка создаёт заявку, инженер выполняет действие, заявка закрывается.
Но что именно означает закрытие? Инженер посетил номер? Перезапустил оборудование? Проверил устойчивую работу? Кто сообщил гостю результат?
Я предлагаю различать техническое завершение и завершение обращения. Первое подтверждает специалист. Второе означает, что результат понятен и дальнейшие действия согласованы.
Не обязательно звонить гостю после каждой мелочи. Способ подтверждения выбирается по ситуации. Однако внутри отеля должно быть ясно, кто отвечает за связь, если проблема не устранена полностью.
Особенно опасен статус «сделано», когда фактически применена временная мера. Тогда требуется указать ограничение и следующий шаг.
Завтрак включён в бронирование, но в списке ресторана гостя нет. Стойка уверена, что данные передаются автоматически. Ресторан не хочет предоставлять услугу без подтверждения. Гость должен доказывать оплаченные условия.
Здесь нужно проверить источник данных, время обновления и порядок обработки исключения.
Нельзя строить процесс так, чтобы спор между службами решался у входа в ресторан за счёт гостя. Должен существовать внутренний маршрут проверки с понятными полномочиями.
Если ошибка повторяется, необходимо искать причину в настройке тарифа или обмене данными. Постоянный ручной звонок может помочь сегодня, но не исправляет устройство процесса.
Сообщение «посмотрите номер» недостаточно. Получатель не знает, что именно требуется, насколько срочно и кто ждёт ответа.
Это не обязательно отдельная форма. Такие поля могут находиться в гостиничной системе, сервисном модуле или согласованном рабочем инструменте.
Если сообщение отправлено человеку, который не на смене, задача ещё не находится под управлением.
Нужно определить механизм принятия: назначение на дежурную роль, подтверждение исполнителя или иной надёжный порядок. А также маршрут на случай отсутствия ответа.
При этом не стоит требовать отдельной ручной отметки для каждого информационного сообщения. Подтверждение необходимо там, где без него возникает существенный риск потери действия.
«Срочно» — не измеримый срок. Но и произвольно назначенные десять минут не всегда полезны.
Нужно различать время реакции, время диагностики и время окончательного решения. Для сложной технической неисправности эти интервалы могут существенно различаться.
Гостю нельзя обещать завершение, которое никто не подтвердил. Зато можно согласовать время следующего обновления и выполнить это обещание.
Мессенджер удобен для оперативного общения. Но если завершённые и незавершённые задачи смешаны с обсуждениями, возникают трудности контроля.
Я предлагаю отделять разговор о задаче от её рабочего статуса. Каким инструментом это сделать — вопрос масштаба и возможностей объекта.
Главное, чтобы ответственный мог увидеть открытые задачи, сроки и ограничения, не перечитывая всю переписку смены.
Новый порядок полезен, если уменьшает потери и помогает гостю. Количество заполненных полей само по себе этого не доказывает.
Для первого этапа я предлагаю выбрать один процесс, описать фактический маршрут и собрать данные до изменения.
Долю обращений, выполненных в согласованный срок:
Здесь важно заранее определить, что считается выполнением и какие задачи входят в расчёт. Незавершённые задачи нельзя просто исключать, чтобы улучшить показатель.
Дополнительно полезны:
Сравнение периодов
За период проверены 120 сопоставимых обращений. В 18 случаях обнаружены потери при передаче — 15%.
После изменения маршрута в следующем периоде среди 120 обращений зафиксировано 6 таких случаев — 5%.
Это повод изучить результат, но не автоматическое доказательство, что весь эффект вызван новым порядком. Нужно сравнить состав обращений, загрузку, смены и способ регистрации.
Если новый порядок требует больше времени, чем решаемая проблема, его нужно упростить. Но упрощение не должно возвращать зависимость от одного человека.
Согласованная работа служб начинается не с призыва «быть командой», а с понятной передачи ответственности. Сотрудники должны знать, что они делают, что получают от других и где заканчивается процесс.
«В ОТЕЛЬПРОСТО мы предлагаем проверять управление через готовую услугу. Если все внутренние задачи выполнены, а обещание гостю нет, значит, карта ответственности ещё не доведена до результата».
Эксперты ОТЕЛЬПРОСТО помогут описать фактический маршрут процесса, найти точки потери, назначить владельца результата и выстроить карточку передачи задачи без лишней бюрократии.
Больше материалов для отельеров — в наших Telegram-каналах:
Будни управляющего
Практика операционного управления, ежедневные ситуации, разборы решений
👉 https://t.me/budniypravlyaushegoОТЕЛЬПРОСТО
Экспертные статьи, аналитика, интервью с практиками гостиничного бизнеса
👉 https://t.me/otelprosto