Заявка висит у менеджера третий день, и никто в компании не может сказать, на каком именно шаге она застряла, потому что путь заявки от сайта до счёта никто никогда не записывал целиком.
Со мной это случалось и в отделе, и в аудите: процессы живут в головах трёх людей, из которых один в отпуске, второй уволился, и описание фактически исчезло вместе с ними.
Именно поэтому описание бизнес-процессов стоит собирать самим, до того как оно понадобилось срочно.
Консультант тут пригождается ровно одним: он смотрит на процесс со стороны и задаёт неудобные вопросы про разрывы. Этот взгляд можно воспроизвести внутри команды, если описывать процесс по фиксированной форме и проверять результат по ней же.
За 17 лет в корпоративном ИТ и аудите я привыкла смотреть на любой процесс со стороны данных: где остаётся след каждого шага, там процесс существует, где следа нет, там живут только разговоры.
Спрос на эту тему устойчивый: на 01.10.2026 в поиске Дзена по запросу "описание бизнес процессов" нашлось 20 материалов, у самого читаемого 2721 просмотров и 63% дочитываний. Люди ищут форму и пример, и ниже будет форма, которую можно заполнить сегодня же.
Что считать процессом и где его граница
Процесс это путь от входа к результату, который повторяется и который кто-то ждёт снаружи или внутри компании: заявка становится счётом, оплата закрывается отгрузкой, жалоба превращается в ответ клиенту. Пока вы можете назвать вход, выход и то, кто этот выход ждёт, перед вами процесс, и его можно описывать.
Главная ошибка на старте это попытка описать всё сразу и очень подробно. Описание расползается на десятки страниц, команда теряет силы на третьем процессе, и папка с описаниями умирает в статусе "черновик" до следующего аудита.
Я всегда начинаю с границы: одна фраза вида "процесс идёт от поступления заявки с сайта до постановки задачи ответственному менеджеру, включая распределение".
Граница, записанная одной фразой, экономит больше времени, чем любой шаблон. Она отсекает соседние процессы, которые иначе затянут в описание всё: закупки, бухгалтерию и заодно корпоративную культуру.
Как собрать скелет процесса за один разговор
Скелет собирают на одной встрече с теми, кто процесс делает руками, и занимает это у меня обычно полтора-два часа на процесс средней сложности.
На встрече идём по шагам от входа до выхода, и каждый шаг записываем одной строкой: действие, исполнитель-роль, система или документ, где остаётся след. Роль вместо фамилии принципиальна: люди уходят, роли остаются, и описание переживает текучку.
След шага это мой главный критерий честности описания. Если после шага не остаётся письма, записи в системе, таблицы или документа, значит шаг либо не существует, либо делается в чате и умрёт вместе с чатом. Это то место, где взгляд со стороны данных ловит разрывы раньше, чем они выстрелят.
Частая ловушка на этом этапе: исполнители описывают процесс так, как он должен работать по регламенту, который никто не открывал два года. Поэтому я прошу показать последний реальный случай и иду по нему, шаг за шагом, со скриншотами систем по ходу. Реальный кейс одной заявки даёт больше правды, чем любое интервью про "как у нас принято".
Насколько подробно описывать каждый шаг
Глубину описания задаёт цена ошибки на шаге и частота его повторения. Шаг, который выполняется каждый день и ошибка на котором стоит потерянного клиента, описывают подробно: действия, сроки, точки передачи и то, как проверить результат. Шаг редкий и дешёвый достаточно назвать одним пунктом в общей карте процесса.
Отдельно про сроки: их ставят только там, где есть ожидание, то есть шаг не выполняется сразу. Если заявка ждёт распределения до конца рабочего дня, в описании появляется срок "до конца рабочего дня", и это правило, по которому процесс можно измерить.
Описание без сроков читается красиво, но управлять по нему нельзя: у вас не будет способа понять, что процесс забуксовал.
Если после описания вы хотите поставить над процессами автоматизацию, например бота в Telegram или MAX, который принимает заявки и раздаёт их по ролям, описание становится прямым заданием на такую работу: разработчику бота нужны ровно те поля, которые вы уже записали, шаги, роли и точки передачи.
Документацию платформы для разработчиков MAX можно посмотреть на dev.max.ru, и она читается понятнее, когда перед глазами карта вашего процесса.
Шаблон карточки процесса
Ниже шаблон, который я использую сама. Заполните его по одному процессу, и у вас на руках будет описание, пригодное и для аудита, и для постановки задачи на автоматизацию.
КАРТОЧКА ПРОЦЕССА
1. Название процесса: [что происходит, одним словосочетанием]
2. Результат процесса: [что получается на выходе, измеримо]
3. Граница процесса: [от какого события до какого события]
4. Кто ждёт результат: [роль внутри или клиент снаружи]
5. Владелец процесса: [роль, отвечающая за процесс целиком]
6. Вход: [откуда приходит событие, запускающее процесс]
7. Частота: [сколько раз в день, неделю, месяц]
8. Шаги процесса:
Шаг 1. [действие] | исполнитель: [роль] | система или документ: [где след] | срок: [если есть ожидание]
Шаг 2. [действие] | исполнитель: [роль] | система или документ: [где след] | срок: [если есть ожидание]
Шаг N. [по числу реальных шагов]
9. Точки передачи: [где результат одного шага переходит к другому исполнителю]
10. Что считаем: [показатель, по которому видно, что процесс жив]
11. Известные разрывы: [шаги без исполнителя, без системы, без следа]
КАРТОЧКА ПРОЦЕССА
1. Название процесса: [что происходит, одним словосочетанием]
2. Результат процесса: [что получается на выходе, измеримо]
3. Граница процесса: [от какого события до какого события]
4. Кто ждёт результат: [роль внутри или клиент снаружи]
5. Владелец процесса: [роль, отвечающая за процесс целиком]
6. Вход: [откуда приходит событие, запускающее процесс]
7. Частота: [сколько раз в день, неделю, месяц]
8. Шаги процесса:
Шаг 1. [действие] | исполнитель: [роль] | система или документ: [где след] | срок: [если есть ожидание]
Шаг 2. [действие] | исполнитель: [роль] | система или документ: [где след] | срок: [если есть ожидание]
Шаг N. [по числу реальных шагов]
9. Точки передачи: [где результат одного шага переходит к другому исполнителю]
10. Что считаем: [показатель, по которому видно, что процесс жив]
11. Известные разрывы: [шаги без исполнителя, без системы, без следа]
Проверка готовности простая: у каждого шага названа роль исполнителя, за каждым шагом стоит система или документ, а у шагов с ожиданием указан срок. Если все три условия выполнены, описание переживёт уход любого конкретного человека, включая владельца процесса.
Когда карточек набирается на целый отдел, их собирают в общую карту процессов: список названий с границами, без шагов. Карта отвечает на вопрос "что у нас вообще есть", а карточка на вопрос "как это устроено внутри".
Для первой автоматизации всегда берут процесс с самой высокой частотой и самым коротким путём.
Если хочется пройти этот путь быстрее и с внешним взглядом на разрывы, мы делаем такую работу как услугу обследования и дискавери перед проектом: собираем карты процессов, находим разрывы и превращаем это в задание на автоматизацию, вот страница услуги. Но шаблон выше работает и без нас, честно.
Вопросы, которые задают перед описанием процессов
Сколько времени занимает описание одного процесса?
На процесс средней сложности уходит одна встреча на полтора-два часа с исполнителями плюс час на оформление карточки и проверку разрывов. Дальше время зависит от того, сколько процессов вы описываете подряд, потому что на третьем-четвёртом карточки заполняются заметно быстрее, у команды появляется навык и понимание формы.
Кто должен быть владельцем процесса?
Владельцем назначают роль, у которой есть полномочия менять шаги и разбирать конфликты на стыках, обычно это руководитель направления, через который проходит большая часть шагов. Важно, чтобы владелец не совпадал по всем процессам с одним человеком, иначе карта превращается в личную память одного руководителя со всеми её рисками.
Что делать с процессами, которые живут только в голове одного человека?
Такой процесс описывают в первую очередь и обязательно по реальным случаям: берёте последние пять-десять эпизодов и восстанавливаете шаги по ним, задавая вопрос "что ты делаешь после этого" до самого результата. Полученное описание сразу проверяете на разрывы, потому что процессы из одной головы чаще всего содержат шаги без следа в системах.
Нужно ли описывать процессы перед внедрением CRM или бота?
Да, и это самый частый случай, когда описание окупается сразу: любая система внедряется под процесс, и без его карты вы получаете настройку под чьё-то представление о процессе, которое через полгода придётся переделывать.
Карта процессов на входе внедрения сокращает споры о том, как "правильно", потому что вместо мнений появляется записанный путь с исполнителями и следами.
Что проверить у себя уже на этой неделе
Возьмите один процесс с высокой частотой, например обработку входящих заявок, и заполните по нему карточку шаблона за одну встречу с исполнителями.
Потом пройдите по трём проверкам: у каждого шага есть роль, у каждого шага есть след в системе или документе, у шагов с ожиданием есть срок. Разрывы, которые вы найдёте, и есть ваш план доработки процесса, записанный бесплатно и своими руками.
Напишите в комментариях, какой процесс опишете первым, и я подскажу, на что смотреть в нём внимательнее.
Новые разборы выходят в моём канале: t.me/promaren.
Обследование процесса и техническое задание
1–2 недели, 150 000 ₽; при заказе разработки — бесплатно
Первоисточники
Частые вопросы
Как описать бизнес-процесс без консультантов?
Сначала зафиксируйте результат и границу процесса одной фразой, затем выпишите шаги от входа до выхода, назначьте каждому шагу роль исполнителя, привяжите системы и документы, задайте сроки. Форма карточки из этой статьи позволяет собрать рабочее описание силами команды за один-два прохода.
Какая глубина описания процесса считается достаточной?
Достаточная глубина зависит от частоты шага и цены ошибки на нём. Частые шаги с дорогими ошибками описывают подробно, включая сроки и точки контроля, редкие и дешёвые достаточно назвать одним пунктом, иначе документ разрастётся и его перестанут читать.
Кто в компании должен описывать бизнес-процессы?
Описывает тот, кто процесс видит изнутри каждый день, а проверяет и собирает в единую карту человек со стороны, например руководитель направления или внутренний контролёр. Внешний консультант нужен только там, где нет своего взгляда со стороны данных.
Чем описание процесса отличается от инструкции сотрудника?
Инструкция отвечает на вопрос, какие кнопки нажать в конкретной системе, а описание процесса показывает весь путь от входа до результата: кто передаёт, что кому, в какие сроки и где остаётся след. Инструкции пишут уже поверх описанного процесса.
Марина Погодина, основатель PROMAREN
17 лет в ИТ и управлении технологическими рисками, из них 14 лет в аудите ИТ и внутреннем контроле. Более 60 аудитов ИТ и информационной безопасности.
