Почему новый процесс не работает после его запуска: где компании теряют результат

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

Но именно здесь многие компании начинают терять результат.

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

В UP SUSHI мы пришли к этому выводу не теоретически. По мере роста сети стало очевидно: чем больше становится ресторанов и процессов, тем опаснее рассчитывать на то, что одна инструкция автоматически изменит поведение всей системы.

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

Но после запуска возникают вопросы: кто отвечает за процесс? Где фиксируется результат? Кто контролирует устранение замечаний? Кто проводит повторную проверку? Что происходит, если одно и то же нарушение возникает снова?

Если на эти вопросы нет ответов, компания получила не работающий процесс, а инструкцию.

Именно поэтому первый вопрос при запуске любого нового процесса должен звучать не «Кто написал регламент?», а «Кто отвечает за его результат?».

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

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

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

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

Еще одна распространенная ошибка — запускать процессы без понятных критериев эффективности.

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

Пока на эти вопросы нет конкретных ответов, руководитель фактически управляет процессом на ощущениях.

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

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

Но затем внимание переключается на другие задачи.

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

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

Важно понимать: нормально, если новый процесс не начинает работать идеально с первого дня.

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

Это не означает, что процесс был ошибкой.

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

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

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

И только после этого процесс становится частью операционной системы компании.

В итоге получается простая, но важная разница:

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

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

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