Александр Костин – Операционное управление без бюрократии: SOP, регламенты и процессы, которые работают (страница 4)
SOP должен быть читаемым не только для автора, но и для человека, который пришёл через полгода.
Принцип «короткий, но завершённый»
Одна из самых вредных ошибок – писать SOP так, будто вы «объясняете тему». SOP не должен объяснять. Он должен приводить к результату. Поэтому ключевой принцип: SOP короткий, но завершённый. Короткий – значит без философии, без истории появления процесса, без длинных рассуждений. Завершённый – значит по нему можно выполнить задачу и проверить качество результата.
Если в SOP нет критериев «готово», это не SOP, а рассказ. Если в SOP нет входов и требований к исходным данным, он будет порождать вопросы. Если нет исключений и эскалаций, он будет ломаться в реальности.
Оптимальная длина: как выбрать «не слишком длинно» без потери смысла
Универсального числа страниц нет, но есть практическое правило: один процесс – один документ, который можно прочитать за 3–7 минут. Если процесс сложный, его надо делить на под-процедуры, а не раздувать один SOP до размеров романа.
Если у вас получается слишком длинно, обычно причина одна из трёх.
Вы описываете сразу несколько процессов. Например, «подготовка отчёта» и «отправка отчёта» и «обсуждение отчёта» – это разные процедуры. Их можно связать ссылками, но не смешивать.
Вы пытаетесь включить обучение. В SOP не надо учить человека профессии. SOP описывает стандарт выполнения операции. Обучение компетенции – отдельная тема, отдельные материалы.
Вы пытаетесь закрыть все исключения. В реальности у любого процесса есть десятки редких случаев. В SOP достаточно описать 3–7 типовых исключений и правило эскалации, а не пытаться предвидеть всё.
Если процесс действительно большой, правильное решение – сделать «корневой SOP» (общая логика и ответственность) и набор «под-SOP» на отдельные участки.
Шаблон SOP: минимальный стандарт, который стоит внедрить сразу
Ниже – структура, которая в большинстве команд приживается лучше всего. Она не требует бюрократии, но закрывает всё необходимое.
Название SOP
Формат: действие + объект + контекст. Пример: «Обработка входящего лида из сайта», «Подготовка коммерческого предложения на SEO», «Закрытие месяца по оплатам».
Название должно быть таким, чтобы по нему было ясно, что именно происходит и где применяется.
Цель и результат
Коротко: зачем процедура существует и что считается результатом. Не более одного абзаца.
Пример смысла: «Обеспечить обработку лида в течение X часов, зафиксировать данные в CRM, назначить следующий шаг, чтобы лид не “потерялся” и был квалифицирован».
Область применения
Когда используем SOP, а когда нет. Это важно, чтобы не возникало ложного требования «делать всегда так», если есть другие каналы или сценарии.
Пример: «Применяется для лидов с сайта и мессенджеров. Не применяется для входящих от партнёров (см. SOP …)».
Роли и ответственность
Кто инициатор, кто исполнитель, кто принимает/проверяет, кто владелец процесса, кто эскалирует.
Здесь важно не перечислять всех подряд, а зафиксировать ответственность.
Если у вас нет формальных ролей, используйте должности или функции: менеджер продаж, аккаунт, проект-менеджер, бухгалтер, руководитель направления.
Входы
Что должно быть на старте.
Это не «всё, что можно», а обязательный минимум: данные клиента, доступы, договорённости, шаблоны, ссылки на папку, канал коммуникации.
Отдельно полезно фиксировать «если входов нет – что делаем» (это потом уйдёт в исключения).
Инструменты и артефакты
Какие системы используются и что создаётся по итогам: задача в трекере, карточка в CRM, документ в папке, письмо клиенту, акт, отчёт, файл.
Это место, где вы закрепляете, где живёт результат. Без этого документы тонут в хаосе «а где это искать».
Пошаговая процедура
Сердце SOP.
Правила написания шагов:
– один шаг = одно действие;
– шаг начинается с глагола;
– у каждого шага есть ожидаемый промежуточный результат (пусть кратко);
– если есть выбор, описывайте критерии выбора, а не «делайте по ситуации».
Важная деталь: шаги должны быть проверяемыми. «Провести анализ» – плохо. «Собрать список ключевых запросов, сгруппировать по намерению, сформировать структуру предложения» – лучше, потому что результат можно проверить.
Контроль качества и критерии «готово»
Это блок, который чаще всего забывают, и именно из-за этого SOP не работает.
Критерии «готово» должны быть объективными: что проверяем, где, по каким признакам.
Формат удобен как чек-лист, но без превращения в таблицу.
Примеры критериев:
– все обязательные поля заполнены;
– документ оформлен по шаблону;
– ссылки рабочие;
– файлы названы по стандарту;
– отправлено подтверждение клиенту;
– задача переведена в нужный статус;
– данные синхронизированы в системе.
Исключения и эскалации
Что делать, если что-то пошло не так: нет входных данных, клиент не отвечает, нет доступа, ошибка интеграции, конфликт сроков.
Ключевое – правило эскалации: кому и когда передаём проблему, чтобы не зависало.
Если у вас пока нет SLA, фиксируйте хотя бы «в течение рабочего дня» и «немедленно при риске срыва срока».
Версионность и владелец
Дата, версия, кто владелец, когда пересматривать.
Это критично, потому что SOP без владельца умирает.
Пересмотр можно поставить раз в квартал или при изменении инструмента/условий.
Если вы внедрите эти 10 блоков как обязательный минимум, у вас получится SOP, который можно поддерживать и использовать.
Язык SOP: как писать, чтобы документ выполнялся, а не раздражал
Язык должен быть прикладным, без «канцелярита» и без лишней строгости. Люди не любят документы не потому, что они против дисциплины. Они не любят документы, потому что документы часто пишут так, что их невозможно быстро применить.
Практические правила языка: