Разработка регламентов и SOP

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

Почему регламенты не работают

• Написаны для проверяющего, а не для исполнителя. Формулировки вида «сотрудник обязан обеспечить своевременное...» не говорят, что нажать и куда записать.
• Слишком длинные. Документ, который нельзя прочесть за пять минут, не читают в момент, когда он нужен.
• Нет ответственного за документ. Процесс изменился, регламент — нет. Через полгода он врёт, и им перестают пользоваться.
• Не привязаны к рабочему месту. Инструкция лежит в общей папке, а работа идёт в CRM. Ссылка должна быть там, где выполняется действие.
• Написаны сверху. Тот, кто выполняет процесс каждый день, знает про него больше — и не узнаёт свою работу в чужом описании.

Структура рабочего SOP

1. 01Название по действию: «Принять и квалифицировать входящую заявку», а не «Регламент отдела продаж»
2. 02Когда применяется: триггер запуска процесса
3. 03Кто выполняет: роль, а не фамилия
4. 04Шаги: пронумерованные, по одному действию в шаге, с указанием системы и поля
5. 05Критерий готовности: по чему видно, что шаг выполнен правильно
6. 06Исключения: что делать в двух-трёх типовых нестандартных ситуациях
7. 07Владелец и дата пересмотра

С чего начинать, если процессов много

Описывать всё подряд бессмысленно: на середине пути первые документы устареют. Порядок — по цене ошибки и частоте: сначала процессы, где ошибка стоит денег или клиента, потом те, что выполняются чаще всего, потом остальные. Обычно 8–12 SOP закрывают 80% ежедневной работы компании.

Регламенты и онбординг

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