+79189465889

Блокнот на пружине

VS

SOP на 15 страниц

Как я заставила SOP работать
Часть 1
Что не так с блокнотом?
Когда я только пришла в новый проект на должность Руководителя службы приема и размещения отдел был укомплектован на 35%. Предшественник ушел без передачи дел. Я задала ряд стандартных вопросов супервайзеру СПиР, которая работала в отделе второй год.

В первые дни сложился следующий диалог:
Я
Итак, что у нас имеется из SOP, регламентов, чек-листов? Как ведете лог-бук?
супервайзер
У нас такого нет
я
А как вы обучаете новых сотрудников?
супервайзер
Ну, у нас есть блокнот...
И тут, мне выносят его — блокнот на пружине. Хочу отметить, что как таковая запись важной информации с шагами для себя — прекрасный инструмент, и крайне полезен для новых сотрудников при обучении.
Но, если мы говорим о единственном месте хранения фундаментальной информации одного из ключевых подразделений отеля — это вызывает сомнения.
Позднее выяснилось, что таких блокнотов всего три, один из них был создан ночным администратором, и два разными сотрудниками дневной смены.
Интересно, что информация от сотрудников на одной и той же должности имела существенные различия, как в результате действий, так и в процессе их выполнения. Например, один администратор при опоздании гостя отменял трансфер через 15 минут, второй — через 40.
Фронт работ был мне понятен, и после личного прохождения курса юного администратора в полях я приступила к созданию всей базовой документации и базы знаний.
Но, как оказалось, на блокнотах череда удивительных вещей
не закончилась. Ведь, начав формирование базы знаний в CRM системе,
на старом облаке, я нашла их – SOP Службы приема и размещения. Даже не очень старые, написанные около года назад, а значит давние сотрудники не могли не знать об их существовании.
Для гостя — лотерея. Для бизнеса —хаос.
Фронт работ был мне понятен, и после личного прохождения курса юного администратора в полях я приступила
к созданию всей базовой документации
и базы знаний.
Но, как оказалось, на блокнотах череда удивительных вещей
не закончилась. Ведь, начав формирование базы знаний в CRM системе,
на старом облаке, я нашла их – SOP Службы приема и размещения. Даже не очень старые, написанные около года назад, а значит давние сотрудники не могли не знать об их существовании.
Один из документов - SOP о процессе заказа такси гостям состоящий
из 2 предложений, буквально в формате узнать куда надо ехать, вызвать такси. В результате новый сотрудник не знал, какую машину заказывать (эконом или бизнес), кто и как оплачивает такси и куда начислять оплату.
В таком же стиле были описаны ряд фундаментальных процессов,
и ко мне пришло четкое понимание, почему сотрудники даже не вспоминали о существовании документов. А еще, стало очевидно,
что блокноты – единственное хранилище знаний.
Инструкция ради инструкции, не имеющая никакой практической значимости для исполнителя, частое явление во всех сферах бизнеса. А когда не было ни времени,
ни желания эту инструкцию писать, рождаются вот такие документы. Пылящиеся на забытом облаке и о которых никто из сотрудников никогда не вспомнит, потому что они сами, как исполнители процесса, выполняющие эти задачи каждый день знают, как лучше это написать, и как понятным языком объяснить это новому коллеге.
Но и у самостоятельных, квалифицированных, но не контролируемых сотрудников есть свои последствия.
Возьмем двоих администраторов, условно обозначим их А и Б.
  • Сотрудник А
    - Работает 2 года
    - За время его работы сменилось 2 руководителя
    - Работает в смене №1
  • Сотрудник Б
    - Работает 8 месяцев
    - Все время работал под управлением последнего руководителя
    - Работает в смене №2
Оба сотрудника имеют достаточный стаж для наставничества над новыми членами команды. Но условия и содержание их пути в роли абсолютно отличаются. Также как подходы к процессам, и алгоритм действий. Потому что единого стандарта выполнения нет, а значит каждый сам, методом проб и ошибок ищет наиболее комфортный для себя лично способ решения задачи. И именно своему авторскому методу наставник будет обучать новичка.
Реальный кейс: новичок после недели у сотрудника А перешел к Б. Через три дня мы получили жалобу гостя — ему дважды списали депозит, потому что порядок действий в оплатах был разным, и сотрудник запутался в двух методах.
Казалось бы, в чем проблема что бы каждый работал так как ему удобнее? Главное же результат. «Не мешай людям работать» говорила мне моя команда, когда я просила их показывать мне выполнение каждого процесса.
И в узком смысле это может быть правдой, если мы говорим
о расположении ручки на столе, хотя 5С мог бы с этим поспорить. А если мы говорим о корректной проверке разнесенных оплат в счетах после большого заезда? Или о принятии оплаты? Кто готов брать на себя риски неописанного, а значит неконтролируемого процесса?
Но в то же время, огромный документ, написанный по всем правилам
с использованием BPMN, будет воспринят едва ли иначе, и об этом будет второй кейс.
В другом отеле базово ситуация с SOP была более ясной, проблема заключалась в их актуальности. Руководство решило запустить централизованный проект, нацеленный на общее повышение зрелости компании. Шаг важный и новый, а значит нужно привлечь экспертов
в этой области что бы они нас научили как правильно писать эти документы.
Процесс работы заключался в еженедельных консультация с экспертом, который объяснял методологию работы и помогал создавать BPMN схемы, являющиеся неотъемлемой частью описания бизнес-процесса.
В целом, все звучит неплохо, за исключением того, что я категорически была недовольна качеством созданного мною документа. При этом,
с точки зрения методологии все была сделано на отлично.
— Так в чем же проблема?
— Методологически правильно.
Практически — мертво.
Невозможно написать регламент по решению спорных ситуаций с гостем с вариантами ответов
А и Б.
Невозможно описать по шагам как предвосхищать ожидания гостя.
Эти процессы намного глубже сухой схемы.
Они заключаются в объяснении команде базовых ценностей и стандартов коммуникации,
и объяснении зачем им следует поступать таким образом.
Тогда я поняла: проблема в том, что мы пишем SOP для себя, для компании, а не для сотрудников. Я открыто озвучила, что эти SOP
не будут использоваться в отделе, и мы создали отдельные, живые инструкции.
Часть 2
Что делать?
И так, для себя я сформировала 3 правила идеальных SOP
  1. Объем

1 процесс = 1 SOP.

Вам не нужен документ обо всем чем занимается отдел в одном файле.

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


SOP для закрытия смены кассира — 1 страница.

SOP для уборки столов после гостя — 1 страница.

Никто не прочитает 15 страниц о том, как принимать багаж.

2. SOP для сотрудников, а не для галочки

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

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


Мой любимый life-hack по SOP, где задействован ПК/другая техника – вставлять скрины экрана на каждое действие с указанием куда нажимать и что выбирать в разных ситуациях. Таким образом, даже самый забывчивый сотрудник всегда сможет посмотреть нужный ему функционал.


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


Когда я пишу SOP, обычно, они проходят процесс редактуры в 2 этапа.

И редактирует их самый строгий критик - моя команда.


  1. После написания я отдаю файл супервайзеру, который в полевых условиях чаще выполняет те же действия. Здесь момент более технический, все ли нюансы учтены, есть ли какие-то дополнительные сложности, которые помешают команде выполнять выстроенный в моей голове процесс. Потому что структура в голове руководителя и реальная жизнь чаще всего отличаются.
  2. Тестирование SOP линейным персоналом. Здесь я давала документ администраторам. Как новым, так и более опытным сотрудникам для того, чтобы они подтвердили или опровергли жизнеспособность предложенного алгоритма. Важно понять, насколько понятно все расписано, возникли ли вопросы после прочитанного. Если что-то было непонятно, значит это незаконченный SOP, и его нужно редактировать.

И да, команда будет сопротивляться. "Мы и так всё знаем" — самая опасная фраза. Поэтому SOP не пишут надолго в кабинете. Их пишут вместе с теми, кто их будет нарушать. И переписывают, когда находят лучший способ.

3. Ответ на вопрос «Зачем»

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


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

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


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

Что вы можете сделать уже завтра:
Выбрать самый частый процесс вашего отдела

Написать SOP на 1-2 страницы
Дать его новичку — попросить выполнить без подсказок
Исправить все, что было непонятно
Повесить SOP там, где выполняется процесс
(а не в облако)
Зачем вообще описывать бизнес-процессы?
  • Чтобы новый сотрудник начал приносить пользу не через 3 месяца, а через 3 дня.
  • Чтобы при уходе ключевого администратора вы не искали блокнот на пружине.
  • Чтобы ваш бренд работал одинаково в понедельник утром и в субботу вечером.
SOP — это не бюрократия.
Это страховка от хаоса для тех, кто хочет сохранить ДНК бренда в быстроменяющихся условиях.
Made on
Tilda