Александр Костин – Операционное управление без бюрократии: SOP, регламенты и процессы, которые работают (страница 5)
– короткие предложения;
– глаголы действия;
– конкретика вместо общих слов («создать задачу в трекере с дедлайном и ответственным» вместо «поставить задачу»);
– избегать оценочных слов («качественно», «аккуратно», «правильно») без критериев;
– единые термины (если у вас «лид» – это одно, не пишите в другом SOP «заявка» как будто это другое);
– не писать «в случае необходимости» без уточнения, что считается необходимостью.
Если вы видите фразы «как правило», «обычно», «желательно», «по возможности», это сигнал, что SOP либо не готов, либо в нём нет критериев.
Уровень детализации: сколько «микрошагов» нужно
Есть постоянный спор: писать ли микрошаги типа «нажмите кнопку» или оставлять на уровне логики. Правильный ответ зависит от аудитории SOP.
Если SOP для новичка или для человека вне функции, микрошаги важны. Иначе он не выполнит процедуру и начнёт спрашивать.
Если SOP для профессионала, микрошаги раздражают и создают ощущение бюрократии.
Компромиссный подход: пишите шаги на уровне действий и результатов, а микрошаги добавляйте только там, где люди чаще всего ошибаются или где интерфейс действительно критичен. Например, в доступах, оплатах, публикациях, отправке документов.
Ещё один подход – делать «основной SOP» без микрошагов, а для сложных мест делать «подпроцедуру» на один экран: «как выдать доступ», «как проверить оплату», «как загрузить файл». Тогда вы не захламляете основной документ, но даёте точную инструкцию там, где это нужно.
Версии, изменения, актуальность: как не утонуть в обновлениях
SOP устаревает всегда. Меняются инструменты, меняются роли, меняются условия. Поэтому вопрос не в том, как сделать SOP вечным, а в том, как сделать обновление управляемым.
Минимальный стандарт версионности:
– версия вида 1.0, 1.1, 1.2 для мелких правок и 2.0 для крупных изменений;
– дата последнего обновления;
– владелец;
– короткий лог изменений: 2–5 строк «что поменялось».
Лог изменений нужен не ради формальности. Он нужен, чтобы люди доверяли документу: «ага, обновили недавно, учитывает новые правила». Если SOP выглядит как текст без даты и владельца, он воспринимается как устаревший, даже если он актуален.
Правило живой документации: обновление должно быть частью работы, а не отдельным проектом. Если процесс изменился, владелец процесса обязан обновить SOP в тот же день или на следующий рабочий день, иначе SOP начнёт врать.
Владелец SOP: кто это и почему без него всё ломается
У каждого SOP должен быть один владелец. Это не обязательно руководитель. Это человек, который отвечает за то, что процедура соответствует реальности и приводит к нужному результату. Владелец:
– утверждает текст;
– принимает предложения по улучшению;
– обновляет документ при изменениях;
– следит за внедрением (хотя бы на уровне обратной связи).
Если владельца нет, SOP превращается в общий файл, который никто не обновляет. Если владельцев несколько, начинаются конфликты и размывание ответственности.
Роль владельца особенно важна в первых 10–20 SOP. Именно в этот период формируется доверие к системе. Один-два устаревших SOP способны убить инициативу быстрее, чем отсутствие SOP.
Где хранить SOP и как сделать так, чтобы их реально открывали
Хранение – это часть внедрения. Если SOP лежат в папке «Регламенты», куда никто не заходит, они не работают. SOP должны быть там, где человек выполняет работу.
Практические варианты:
– база знаний/вики компании;
– внутри трекера задач как ссылка в шаблоне задачи;
– внутри CRM как подсказка к этапу;
– в общей структуре папок проекта, но с единым индексом и поиском.
Правило: SOP должны быть связаны с точкой действия. Например, если у вас есть шаблон задачи «Подготовить КП», то в описании задачи должна быть ссылка на SOP «Подготовка КП». Если этап в CRM «Квалификация лида», то в подсказке этапа должен быть краткий стандарт или ссылка на SOP.
Если SOP не встроен в рабочий поток, он не будет читаться, даже если он идеальный.
Как ИИ помогает писать SOP по шаблону, не ломая смысл
ИИ идеально подходит для того, чтобы превращать хаотичный рассказ в структурированный документ. Но ему нужно давать правильный вход.
Лучший источник для SOP – не «как должно быть», а реальный пример выполненной задачи: переписка, список шагов, скриншоты/артефакты, итоговый файл, список ошибок, которые происходили. Вы даёте ИИ: «Вот как мы это делали в последний раз, вот что получилось, вот где были проблемы». ИИ преобразует это в SOP по шаблону.
Но важно: проверка владельцем обязательна. ИИ может:
– пропустить шаг;
– добавить несуществующий шаг;
– перепутать порядок;
– предложить критерий качества, который вы фактически не проверяете;
– неверно описать исключения.
Правильный цикл такой: ИИ делает черновик → владелец процесса правит факты → исполнитель тестирует SOP в реальной задаче → владелец фиксирует правки → версия 1.0 утверждена.
Итоги
SOP, который реально используют, строится на едином шаблоне и на практическом языке. Он должен быть коротким, но завершённым: входы, шаги, критерии «готово», исключения и правило эскалации. Без владельца и версионности SOP умирает, а хуже всего – начинает врать и убивает доверие к системе. Хранить SOP нужно не «где-то в папке», а в точке действия: в задачах, в CRM, в вики с быстрым доступом. ИИ ускоряет создание SOP, но ответственность за фактическую правильность всегда остаётся за владельцем процесса.
Глава 4. Как собрать знания из голов в SOP: интервью, разбор реальных кейсов, «тень» исполнителя и быстрые черновики
Шаблон SOP сам по себе ничего не решает, если вы не умеете быстро добывать содержимое. Главная проблема операционки не в том, что люди не хотят писать документы. Проблема в том, что знания о том, «как у нас реально делается работа», размазаны по головам, перепискам, устным договорённостям и привычкам. Люди действуют автоматически, опираясь на опыт, и им трудно развернуть это в последовательность шагов. Когда вы просите: «Опиши процесс», вам отвечают общими словами или дают фрагменты. В итоге SOP получается либо слишком поверхностным, либо превращается в длинный роман о профессии.
Поэтому нужен системный способ извлечения знаний. Без него вы будете тратить недели на сбор информации, раздражать команду и получать документы, которые нельзя применять. Хорошая новость: извлечение знаний можно поставить на поток. ИИ здесь помогает, но не заменяет факты. Он ускоряет упаковку и структурирование, а «сырьё» вы должны собрать правильным способом.
Почему люди плохо «пишут процессы» и как это учитывать
Есть несколько психологически и организационно понятных причин.
Люди не считают свою работу процессом. Для них это поток решений. Они помнят «сложные места» и «исключения», но не видят повторяемую основу.
Люди не умеют оценивать уровень детализации. Они либо уходят в общие слова («провести анализ», «подготовить документ»), либо начинают описывать интерфейсные микрошаги без логики.
Люди боятся, что SOP превратится в контроль и «вынесение мозга». Поэтому часть информации скрывается не сознательно, а на уровне сопротивления: «зачем это, и так работает».
Люди перегружены. Даже если они согласны, у них нет времени писать. А просить их «написать SOP» – это фактически дать ещё одну задачу без понятного результата.
Вывод простой: SOP не «пишут». SOP собирают. И вы как операционный организатор должны выстроить сбор так, чтобы человеку было легко дать фактуру, а не писать документ.
Четыре источника правды: что использовать вместо «опиши процесс»
Есть четыре источника, которые почти всегда дают достаточно материала, чтобы сделать качественный SOP.
Первый – реальный завершённый кейс. Конкретная задача, выполненная недавно. С итоговым артефактом: файлом, письмом, карточкой в CRM, закрывающими, отчётом, согласованием. По кейсу легко восстановить шаги.
Второй – переписка и история задач. Где видны уточнения, задержки, повторяющиеся вопросы, причины переделок. Это кладезь для блока «исключения» и «эскалации».