Описание бизнес-процессов: зачем это нужно небольшой команде

Слово «бизнес-процесс» тянет за собой картинку из учебника: отдел аналитиков, стрелочки BPMN, консультант с презентацией на сорок слайдов. У меня нет ни отдела, ни консультанта — операционку по нескольким сайтам и продуктам держат я и агенты Claude. Тем не менее описывать процессы приходится постоянно: без текста агенту нечего выполнять, а мне — нечего передать.

Дальше — не про нотации и не про то, как выглядит «зрелая» компания. Про то, как описать процесс так, чтобы его можно было отдать другому человеку или машине, и почему у этого текста в 2026 году появился второй читатель.

Зачем описывать процесс, если вас один или трое

Три причины, а не абстрактная управленческая зрелость.

Передать. Если процесс живёт только у вас в голове, вы — единственная точка отказа. Заболели, уехали, наняли человека — и он повторяет ваши же ошибки, потому что читать ему нечего. У меня весь SEO-конвейер по нескольким сайтам держат агенты Claude и автоматика на cron — без штата. Это работает только потому, что каждый шаг записан текстом: что делать, в каком порядке, что считается результатом. Самый залётный ролик моего канала так и называется — «6 проектов, 0 сотрудников»: 16 057 просмотров и 580 новых подписчиков, это 67% всех подписок канала за квартал. За кадром там не магия, а именно то, о чём эта статья — описанные процессы вместо найма.

Автоматизировать. Отдать шаг агенту можно, только если написано, что конкретно он должен сделать и по каким правилам. «Разберись с заявками» — это пожелание, а не инструкция. «Заявка попала в CRM без телефона — напиши автору письмо-запрос, жди сутки, если ответа нет — закрой лид с пометкой «нет контакта»» — это уже можно исполнять, и не важно, кто исполняет: человек или агент.

Найти потерю. Пока процесс не записан пошагово, часть шагов продолжает выполняться по инерции, даже если смысла в них больше нет. В одном из моих проектов коллтрекинг продолжал работать и тратить деньги полгода — пока рекламная кампания стояла на паузе. Никто не прописал шаг «остановили рекламу — отключили коллтрекинг», и это стоило около 19 000 ₽ впустую. Опиши кто-нибудь этот процесс от начала до конца заранее — пропуск был бы виден на бумаге раньше, чем в счёте.

С чего начать: один процесс, который болит сильнее всего

Не пытайтесь описать все процессы сразу — это неподъёмно и почти всегда бросается на середине. Возьмите один: тот, из-за которого вы вчера злились, или тот, что тормозит рост сильнее остальных. Обычно это либо приём заявок, либо то, что происходит сразу после оплаты.

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

Как описывать, чтобы это было полезно

Нотации вроде BPMN и IDEF0 существуют не просто так — они удобны для моделирования бизнес-процессов, когда систему разбирают несколько отделов и схему передают между информационными системами. Для команды из одного-трёх человек это лишний слой: правила читаете вы сами и агент, которому вы их отдадите, а не конвейер интеграций. Текстового описания достаточно, если в нём есть шесть вещей.

Результат — чем процесс заканчивается и как это проверить, а не «в целом всё хорошо». Вход — что его запускает. Шаги по порядку, без пропусков «и так понятно». Ответственный на каждом шаге — человек или агент, а не «команда». Точки отказа — места, где обычно ломается. И критерий «готово» — не «сделал», а способ убедиться, что сделано правильно. Схема бизнес-процесса не помешает, если развилок много и текст неудобно держать в голове целиком, но начинать стоит с текста.

Вот как это может выглядеть на простом процессе продаж:

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

Поворот: описание процесса — это инструкция для агента

До агентов, которые реально что-то делают, а не только отвечают на вопросы, у текста с описанием процесса был один читатель — человек, которому вы передаёте дело. Сейчас читателей минимум два, и второй ничего не домысливает: он выполняет ровно то, что написано, и ни жестом, ни интонацией его на ходу не поправить.

Вся моя работа сейчас держится именно на этом. Второй мозг хранит не только заметки, но и правила: что агент должен сделать, в каком порядке, куда записать результат. Текст правил и есть исполняемый документ — не метафора, а буквально то, что агент читает перед тем, как начать работу.

Похожий принцип — в личном трекере задач: голосовая заметка в Telegram уходит в Obsidian, три раза в день её разбирает Claude и раскладывает по трём уровням — проекты с целью, спринты-вехи и задачи на сегодня. Работает это не потому, что модель «умная», а потому, что описание процесса точное: что считать проектом, что спринтом, куда класть остальное. Собрать такого ИИ-агента не сложнее, чем написать для него правильную инструкцию.

Что бывает, если описание неточное

Обратная сторона того же свойства: агент не переспрашивает и не досочиняет из здравого смысла. Если в описании нет шага «проверить результат», агент отчитается об успехе, даже если по факту ничего не произошло. Это не гипотеза — у меня так было.

Где описания мертвеют

Регламент, написанный один раз, стареет быстрее, чем кажется. Через три месяца в реальности появляется новый шаг, которого нет в тексте, — обходной путь для частного случая, — а через полгода на бумаге остаётся описание процесса, которого уже не существует. Хуже всего, когда по этому мёртвому тексту продолжает работать агент: он честно выполняет старые правила, а результат больше не совпадает с тем, что нужно бизнесу.

Есть простое правило, которое держит описания живыми: обновлять их по факту изменения, а не по графику. Не «раз в квартал ревизия регламентов», а «поменяли шаг — в тот же день поправили текст». Ревизия по графику почти всегда откладывается, а правка по факту занимает две минуты, пока вы ещё помните, что именно изменили.

Как за выходные описать пять ключевых процессов

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

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

Дальше — расшифровка. Она получается неплохим черновиком сама по себе: устная речь уже держит порядок шагов, а лишние слова легко убрать при чтении. Я расшифровываю такие разговоры локально, без подписок — как это устроено, разобрал отдельно: транскрибация аудио в текст.

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

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

Полного регламента у вас, скорее всего, не получится с первого захода — и это нормально. Достаточно текста, по которому другой человек или агент пройдёт процесс без ваших пояснений на ходу. Остальное — правки по факту, когда станет видно, что не совпадает.