Когда говорят про Shared Services Center, в голове сразу всплывают банки, телеком, металлурги. Hospitality в этот ряд обычно не ставят — считается, что отельный бизнес слишком разный от объекта к объекту, чтобы централизовать что-то всерьёз.
Это заблуждение. Гостиничная индустрия — возможно, одна из самых благодарных сред для shared services, просто отрасль до конца с этим не разобралась. Ниже — разбор того, как устроен такой переход: что выносится, как строится governance, где обычно ломается проект, и что нужно заложить в дизайн, чтобы не разбирать модель через год.
Зачем это нужно отельной группе
Отель — это операция 24/7 с десятками функций: фронт-офис, housekeeping, F&B, ski operations на курортах, инженерка, продажи, маркетинг, revenue management, IT, финансы, HR. На каждом объекте размещения всё это есть в каком-то виде.
Когда у группы один отель — нормально. Когда объектов несколько — начинается типовая боль:
- В каждом отеле свой айтишник, который чинит принтеры и параллельно интегрирует PMS
- В каждом отеле свой маркетолог, который сам себе SMM, контекст и email-маркетинг
- Revenue manager либо есть и перегружен, либо его нет вообще
- Данные по выручке собираются вручную в Excel, потому что BI «дорого»
Дублирование функций — раз. Разный уровень компетенций между объектами — два. Невозможность накопить экспертизу — три. И четвёртое, самое болезненное: GM каждого отеля тянет на себе функции, в которых он не специалист, потому что больше некому.
Shared Services решает все четыре проблемы сразу. Если правильно построить.
Что выносить, а что оставить на объекте
Первое решение, которое надо принять — границу централизации. Здесь работает простой принцип: централизуется то, что не требует физического присутствия и где экспертиза накапливается через объём.
В SSC обычно уходит:
- IT-инфраструктура и интеграции — серверы, сети, PMS, POS, системы контроля доступа Axess/SKIDATA, интеграции между ними
- Digital и онлайн-продажи — сайты, booking engine, метапоиск, контекст, SMM
- Data и аналитика — единый дашборд по выручке, USALI-репортинг, BI
- Revenue management — централизованная команда, обслуживающая все объекты по единой методологии
- Часть маркетинга — бренд, performance, CRM-маркетинг
На объектах остаётся:
- Operations в чистом виде — фронт, housekeeping, F&B, инженерка
- Локальный sales (личные продажи корпоративам региона)
- HR-операции (хотя политики и C&B становятся централизованными)
Логика простая: всё, что про «руки и физическое присутствие гостя» — на объекте. Всё, что про «голову, экспертизу и технологии» — в SSC.
Каталог услуг: точка, где обычно всё ломается
Самый недооценённый этап построения SSC — это каталог услуг. И именно здесь у большинства проектов происходит первый серьёзный кризис.
Когда функции выносятся в отдельную сервисную компанию, у объектов размещения появляется законный вопрос: «А что конкретно мы получаем за то, что отдали свой IT-бюджет наверх?». Если внятного ответа в формате каталога услуг нет — начинается партизанская война. GM-ы пишут жалобы, что им не отвечают, начинают втихаря нанимать «своих» айтишников, бюджет SSC раздувается, а удовлетворённость падает.
Каталог должен быть в три уровня:
L1 — что SSC вообще делает. Высокоуровневые сервисные направления: «Управление IT-инфраструктурой», «Поддержка PMS», «Digital-продажи», «Data и отчётность», «Revenue Management как сервис». Это нужно для GM-ов и финансового директора группы — чтобы было ясно, за что они платят аллокацию.
L2 — конкретные сервисы внутри направлений. Например, внутри «Поддержка PMS»: настройка тарифов, поддержка пользователей, интеграции с OTA, ночной аудит, изменения структуры номерного фонда. Это уровень, на котором работают operations-руководители отелей.
L3 — операционные процедуры с SLA. Время реакции на инцидент критичности «1» — 15 минут. Время добавления нового тарифа — 4 часа. Время подключения нового OTA — 5 рабочих дней. Это уровень, на котором живут координаторы и инженеры.
Главный принцип: L1 без L3 не работает. Если GM-у говорят «мы поддерживаем PMS», а он не понимает, что это значит на уровне «когда ему ответят, если он в три ночи увидит, что не выгружаются цены на Booking», — доверия не будет.
Governance: где разваливается матричная модель
Здесь начинаются классические грабли матричной структуры — и выбираться из них долго.
Самая распространённая стартовая модель: SSC — это отдельная компания, GM объектов — это «клиенты», между ними договор на услуги. Звучит логично. На практике разваливается за полгода.
Почему: GM объекта по факту не «клиент». Он не может уволить SSC и нанять другого. Он не может отказаться от услуги. Он не голосует рублём. И когда SSC говорит «это не входит в SLA», у GM нет рычага.
Рабочая модель — трёхслойная governance:
Слой 1. Process Owners на уровне группы. За каждый сквозной процесс (Guest Journey, Revenue Cycle, Cost Management, Digital Sales) назначен владелец процесса — функциональный директор группы. Он отвечает за то, как этот процесс устроен во всей группе, какие в нём KPI, и где границы между объектом и SSC.
Слой 2. Service Delivery Owners в SSC. Внутри сервисной компании за каждое направление каталога услуг назначен ответственный. Он работает с Process Owner на уровне методологии и со всеми GM-ами на уровне исполнения.
Слой 3. Functional Leads на объектах. На каждом отеле есть человек, который является «представителем» SSC-функции на земле. Например, не отдельный айтишник, а координатор IT, который является глазами и руками SSC на объекте, но административно подчиняется GM.
RACI между этими тремя слоями прописывается мучительно — закладывайте на это месяца три. Но это та работа, которую нельзя пропустить. Без RACI любая операционная неразбериха превращается в политику.
Как измерять эффективность
Когда оптимизируется оргструктура, главный страх стейкхолдеров — «вы сократите людей, и качество упадёт». Поэтому метрики надо вводить до трансформации, чтобы потом было с чем сравнивать.
Смотреть надо на четыре группы KPI:
Операционные. Время решения тикетов по приоритетам, % SLA-compliance, доступность критических систем (PMS, POS, channel manager). Стандартные ITSM-метрики.
Финансовые. Стоимость функции на номер в год, FTE на N номеров, доля IT/Digital в общих расходах группы. Здесь работают отраслевые бенчмарки от STR и HVS.
Качественные. NPS внутреннего клиента — GM и руководители объектов оценивают SSC раз в квартал. Это, как правило, самая полезная метрика — потому что цифры по тикетам могут быть хорошими, а отношения — плохими.
Бизнес-метрики. Что в итоге даёт централизация revenue management — рост RevPAR? Что даёт централизация digital-продаж — рост доли прямых бронирований? Это та метрика, ради которой всё затевается.
Три ошибки, которых стоит избежать
Эти ошибки повторяются в большинстве SSC-проектов в гостиничной индустрии — независимо от размера группы и страны.
Первое — начинать с реструктуризации, а не с governance. Типичный сценарий: людей сначала переводят в SSC, а потом полгода разбираются, кто кому подчиняется и кто за что отвечает. Правильная последовательность обратная: сначала RACI и каталог услуг на бумаге, потом организационные изменения.
Второе — недооценивать change management. GM-ы объектов воспринимают SSC как «у нас отобрали ресурсы» — это нормальная защитная реакция, и она длится примерно полтора года, если её не вести системно. Системная работа по переупаковке смысла трансформации с первого дня сокращает этот период до полугода.
Третье — не закладывать AI-слой в дизайн. Несколько лет назад это было бы преждевременно, сегодня — обязательно. Каждый сервис в каталоге надо проектировать с вопросом: что здесь будет делать AI-агент через 12 месяцев, и как организация к этому готовится? Без этого через два года SSC превращается в legacy быстрее, чем то, что только что централизовали.
Что из этого универсально
Можно подумать, что это всё про hospitality. Но если убрать слова «отель», «PMS» и «RevPAR», и заменить их на индустрию читателя — получается универсальный playbook.
Принципы, которые работают везде:
- Централизуй то, где экспертиза накапливается через объём. Не централизуй то, где важно физическое присутствие
- Без каталога услуг с тремя уровнями детализации SSC превращается в чёрный ящик
- Без отдельного слоя Process Owners на уровне группы матрица «SSC vs объекты» развалится
- Метрики надо ставить до трансформации, иначе нечем будет защищаться
- Закладывай AI-слой в дизайн с первого дня
Hospitality в этом смысле — хорошая лаборатория. Если оргмодель работает в среде с десятками функций, круглосуточной операцией, сильной зависимостью от людей и непредсказуемой выручкой — она почти наверняка сработает там, где условия проще.
Сергей Львов — консультант по гостиничной технологии и предприниматель. 15 лет в индустрии: CIO кластеров горнолыжных курортов, CEO внутренней tech-компании крупной гостиничной группы. Сегодня консультирует отели и курорты в РФ и СНГ.