Александр Костин – Операционное управление без бюрократии: SOP, регламенты и процессы, которые работают (страница 3)

Что делать в этом случае. Разделяйте «эксперимент» и «операцию». Эксперимент – это режим, где вы допускаете вариативность, но фиксируете выводы. Операция – это повторяемая часть, которую вы готовы стандартизировать. Для нестабильных процессов пишите не SOP, а «правила игры»: что является целью, какие рамки, какие метрики, какие запреты и что обязательно фиксировать. А SOP делайте на те куски, которые повторяются независимо от эксперимента: фиксация данных, этапы согласования, формат отчёта, правила коммуникации.

Если процесс меняется каждую неделю, SOP будет постоянно устаревать. А устаревшие SOP хуже отсутствия SOP: они создают ложную уверенность.

Как понять, что процесс готов к SOP

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

Что запускает процесс. Какой конкретный сигнал или событие означает «начали».

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

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

Как проверяется качество. Один-два критерия, по которым можно сказать «нормально» или «не нормально».

Если на эти вопросы нет ответа – вы пока в зоне неопределённости. Там лучше начинать с упрощённого чек-листа или мини-стандарта, а не пытаться написать полноценный SOP.

Приоритизация по «точкам трения»: где возникают вопросы и переписки

Ещё один очень практичный способ выбрать процессы – посмотреть не на «важность», а на «шум». Шум – это переписки, уточняющие вопросы, пересогласования, напоминания, просьбы «скинь ещё раз», «а где это лежит», «а кто делает», «а какие сроки», «а что считать готовым». Шум – это показатель отсутствия стандарта.

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

Правило простое: если один и тот же вопрос повторяется чаще двух раз в неделю, это кандидат на SOP или хотя бы на короткий стандарт.

Стыки процессов: почему именно там живёт хаос и как это учитывать

Самые дорогие сбои почти всегда происходят на стыках: между продажами и производством, между производством и финальным контролем, между выполнением и финансами, между поддержкой и технической частью. Внутри отдела люди ещё как-то договорятся. На стыке начинается «это не ко мне», «я думал, ты», «я отправил, но не знаю куда», «я жду данных».

Приоритизация должна учитывать стыки как отдельный класс процессов. Часто выгоднее описать не «всё производство», а именно процедуру передачи: что должно быть передано, в каком виде, где зафиксировано, кто подтверждает получение, что делать, если чего-то не хватает. Это быстро снижает провалы.

Если вы выбираете первые SOP, включите минимум один SOP на стык между функциями. Это даст эффект непропорционально усилиям.

Минимально жизнеспособный SOP: что должно быть, чтобы документ работал

Когда вы выбрали первые процессы, возникает следующий риск: начать писать «как книгу» и утонуть в деталях. Чтобы SOP был рабочим, ему достаточно минимального набора элементов.

Название операции. Должно быть однозначным: что делаем.

Цель. Одним абзацем: зачем это нужно и какой результат ожидается.

Область применения. Когда применяется SOP, а когда нет.

Роли. Кто инициирует, кто выполняет, кто принимает, кто эскалирует при проблеме.

Входы. Что нужно иметь на старте: данные, доступы, документы, ссылки на шаблоны.

Шаги. Последовательность действий, без лишней философии.

Критерии качества. Как проверить, что результат соответствует стандарту.

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

Исключения и эскалации. Что делать, если не хватает входов или процесс упёрся.

Версия и владелец. Кто отвечает за актуальность, когда последний раз обновляли.

Всё остальное – детали, которые добавляются, если реально нужны. Если вы сделаете SOP на одну-две страницы, но он будет применяться, это лучше, чем десять страниц «идеала», который никто не открывает.

Как использовать ИИ для приоритизации, не доверяя ему решение

ИИ может помочь ускорить приоритизацию, но решение должно оставаться за вами. Роль ИИ здесь – не «определить важность», а структурировать материал и подсветить закономерности.

Что можно делать.

Собрать список процессов из разрозненных источников. Вы даёте ИИ сырой текст: переписки, список задач, названия статусов, типовые просьбы. ИИ вынимает из этого повторяющиеся операции и формулирует их в виде «глагол + объект».

Сгруппировать процессы по функциям. Продажи, выполнение, финансы, поддержка, HR.

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

Но есть вещи, которые ИИ не знает: вашу реальную стоимость ошибки, реальную частоту и реальные узкие места. Поэтому правильный подход: ИИ делает черновой список и группировку, вы подтверждаете факты и выбираете стартовую волну.

Если вы хотите ускорить ещё сильнее, используйте приоритизацию через простой вопрос к владельцам функций: «Какие три операции вы бы стандартизировали завтра, чтобы меньше страдать?» Это не голосование «по справедливости». Это сбор боли. ИИ потом поможет превратить ответы в список SOP и привести к общему формату.

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

Иногда процесс важный, частый и дорогой, но внедрить SOP в нём сейчас невозможно. Например, потому что нет владельца, нет дисциплины фиксации данных, нет минимальных инструментов или команда слишком перегружена, чтобы изменить привычку. В таком случае лучше начать с процесса чуть менее «идеального», но внедряемого, чтобы создать доверие к системе.

Внедряемость – это четвертый критерий, негласный. Он включает три вещи: понятен ли процесс, есть ли владелец, есть ли канал, где SOP будет реально использоваться (система задач, чек-лист, шаблон, форма). Если этого нет, документ повиснет в воздухе.

Поэтому стартовая волна SOP должна давать не только эффект, но и победу: чтобы люди увидели, что «это реально помогает», и готовы были продолжать.

Реестр процессов как основа: зачем фиксировать даже то, что вы пока не описываете

Есть полезная привычка: вести реестр процессов. Это список всех операций, которые вы потенциально будете стандартизировать, с короткими пометками: владелец, статус (нет SOP / черновик / утверждён / внедрён), риск, частота, дата последнего обновления.

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

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

Итоги

Вы не строите операционку «целиком». Вы строите её волнами, начиная с процессов, которые повторяются часто, дорого ломаются и тянут время ключевых людей. Приоритизация должна быть быстрой и опираться на реальную боль, а не на идеальные представления. Начинайте с 5–7 процессов, которые дают эффект, и обязательно включайте хотя бы один SOP на стык между функциями – там живёт основной хаос. Пишите минимально жизнеспособные SOP, которые можно применять, а не «идеальные документы». Используйте ИИ для структурирования и ускорения, но подтверждайте факты и оставляйте решение за владельцами процессов.

Глава 3. Шаблон SOP, который реально используют: структура, язык, длина, версии и ответственность

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

Шаблон SOP – это не «красивый документ». Это инструмент внедрения. Он должен помогать человеку выполнить работу, а руководителю – проверить результат, а компании – быстро обновить стандарт, когда меняются инструменты или условия. Если SOP не выполняет эти функции, он превращается в архивный файл, который существует «для галочки».

Зачем вообще нужен единый шаблон: три практических эффекта

Единый шаблон даёт три эффекта, которые ощущаются почти сразу.

Первое – скорость производства SOP. Когда формат одинаковый, вам не нужно каждый раз думать «как писать». Вы просто заполняете поля.

Второе – скорость чтения и применения. Исполнитель привыкает, что важные вещи всегда находятся в одном месте: входы, шаги, критерии качества, исключения. Это снижает сопротивление и уменьшает ошибки.

Третье – поддерживаемость. Если у вас 30–100 SOP, поддерживать их без стандарта невозможно. Единый шаблон делает обновление механическим: поменяли инструмент – нашли соответствующий блок – обновили шаги и критерии.