# Регламент бизнес-процесса — как написать SOP пошагово Регламенты в промышленных компаниях пишут дважды: первый раз — когда пришёл аудит или заказчик потребовал документ, второй — когда процесс уже развалился и виноватого не найти. Оба варианта дают текст, который никто не читает. Рабочий регламент появляется из другой потребности: процесс повторяется, его выполняют несколько человек, и результат у них получается разный. Я писал такие документы на продажах, производстве и сервисе — и разница между живым SOP и мёртвым всегда в двух вещах: кто его писал и что в нём измеримо. ## Когда регламент действительно нужен Не каждый процесс заслуживает документа. Фильтр простой: процесс повторяется чаще, чем раз в месяц, его выполняет больше одного человека, и цена ошибки заметна. Если хотя бы одно условие не выполняется, регламент превратится в файл, который открывают при приёме нового сотрудника и больше никогда. Второй триггер — передача процесса. Запуск нового направления, наём первого сотрудника на роль, которую до этого закрывал руководитель, выход на новый рынок с локальной командой. На двух направлениях мы описывали единый процесс от лида до доставки именно в этой ситуации: продажи и проектное управление между направлениями не были формализованы, и каждое вело сделку по-своему. Результатом стали стандартные операционные процедуры с ролями и сроками плюс схема целевой структуры — документ писался не ради документа, а под конкретную задачу свести два разных способа работать в один. Третий триггер — масштабирование операции. Процесс ремонта БПЛА мы формализовали в нотации BPMN не потому, что этого требовал регулятор, а потому что его предстояло разворачивать на нескольких площадках. Диаграмма, её код и текстовое описание — три формы одного и того же, каждая для своего читателя: схема для обсуждения, код для версионирования, текст для исполнителя. ## Из чего состоит рабочий SOP Регламент, который применяют, отвечает на шесть вопросов. Всё остальное — приложения. 1. **Триггер.** Событие, с которого процесс начинается: поступила заявка с сайта, подписан договор, закрыт месяц. Регламент без триггера не имеет точки входа, и люди не понимают, в какой момент им надо в него заглянуть. 2. **Роли.** Кто выполняет шаг, кто согласует, кого уведомляют. Роли, а не фамилии: документ переживёт трёх менеджеров, если в нём написано «координатор производства», а не имя человека. 3. **Шаги в порядке выполнения.** Формулировка в повелительном наклонении и в единственном действии: «отправить спецификацию заказчику», а не «осуществляется взаимодействие по спецификации». 4. **Сроки по каждому шагу.** Не общий срок процесса, а время на конкретный шаг. Без этого узкое место не видно, и разбор просроченной сделки превращается в спор. 5. **Артефакт на выходе шага.** Что появляется как результат: заполненная карточка в CRM, подписанный акт, расчёт в таблице. Шаг без артефакта невозможно проверить. 6. **Критерий готовности и порядок эскалации.** Что считается выполненным и что делать, если шаг застрял. Отсутствие пункта об эскалации — главная причина, по которой сделки зависают неделями и никто об этом не знает. Отдельно — объём. Регламент на двадцать страниц не читают. Если процесс не помещается в две-три страницы, скорее всего, это не один процесс, а три, и их нужно разделить по границам ответственности. ## Кто пишет — и почему не руководитель в одиночку Документ, написанный руководителем за выходные, описывает не процесс, а представление руководителя о процессе. Разница обнаруживается на первой же неделе применения: в тексте нет половины реальных ситуаций, зато есть шаги, которые давно никто не делает. Рабочая схема — собрать процесс с теми, кто его выполняет, и зафиксировать на совещании. На индийском направлении регламент ведения CRM появился именно так: продажи велись без единого протокола фиксации данных, мы провели совещание и закрепили порядок ежедневных обновлений и протоколов встреч. Ключевое здесь не текст, а то, что команда участвовала в его составлении, — регламент, принятый на совещании, применяют; регламент, разосланный по почте, обсуждают в курилке. Роль продакта или руководителя в этой схеме другая: задать структуру, вытащить неудобные вопросы о границах ответственности и не дать документу разрастись. Люди, выполняющие процесс, описывают его подробнее, чем нужно, — почти всегда требуется сокращать, а не дописывать. ## Как внедрить, чтобы регламент не умер через месяц Написание — меньшая часть работы. Внедрение состоит из четырёх шагов, и пропуск любого из них возвращает команду к прежнему хаосу. Сначала — пилот на ограниченном объёме: одно направление, одна команда, две-три недели. За это время вылезают все ситуации, которых нет в тексте, и это нормально, а не признак плохого документа. Затем — правка по итогам пилота, желательно в тот же день, пока замечания свежие. Дальше — назначение владельца: конкретный человек, который отвечает за актуальность документа и к которому идут с вопросом «а как быть, если». Регламент без владельца устаревает за квартал. И наконец — дата пересмотра в самом документе, а не в чьих-то планах. Работающая практика, которую я взял из инженерного подхода к разбору сбоев: каждый случай, когда процесс дал сбой, разбирается не для поиска виноватого, а для ответа на вопрос, какого шага или критерия не хватало в регламенте. Это превращает документ в живой стандарт, который улучшается от каждой ошибки, а не в свод правил, которые нарушают. ## Чем регламент отличается от стандарта и методологии Термины путают, и от этого документы получаются не того размера. Регламент описывает одну операцию с конкретными шагами и сроками — уровень исполнителя. Методология описывает подход и этапы работы над классом задач — уровень руководителя направления. Стандарт задаёт требования к результату и перечень обязательных артефактов — уровень компании. Практический пример разницы: когда мы формализовали коммерциализацию сложных B2B-продаж, результатом был именно стандарт — каноническая связка документов, которая должна быть у любой сделки, плюс аудит уже накопленных материалов: 11 документов проверялись против базы почти из тысячи предприятий, а на выходе осталась работающая база почти из 280 контактов. Стандарт отвечал на вопрос «что должно быть», а регламент продаж и производства, написанный отдельно, отвечал на вопрос «кто и в какой срок это делает». Смешивать эти два документа в один — верный способ получить текст, бесполезный на обоих уровнях. ## Вывод Регламент пишется не для папки и не для аудита, а для того, чтобы результат процесса перестал зависеть от того, кто его сегодня выполняет. Берите только повторяющиеся процессы с заметной ценой ошибки. Держите структуру из триггера, ролей, шагов, сроков, артефактов и критериев готовности — и обязательно с порядком эскалации. Пишите вместе с исполнителями и фиксируйте на совещании, а не рассылкой. Обкатывайте на пилоте, назначайте владельца и ставьте дату пересмотра. Документ без владельца и даты пересмотра — это не стандарт, а архив. ## Мои кейсы по теме - [[SOP и оргструктура для двух направлений]] - [[Регламент продаж и производства]] - [[Регламент CRM-дисциплины продаж]] - [[Формализация процесса ремонта БПЛА]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.